Datenqualität erfolgreich steuern: Praxislösungen für Business-intelligence-projekte [3., überarbeitete und erweiterte Auflage] 9783864900426, 9783864916410, 9783864916427, 3864900425, 3864916410

Table of contents :
Geleitwort zur 3. Auflage......Page 5
Vorwort zur 3. Auflage......Page 7
Abb. 1 Grobe Architektur für Business Intelligence......Page 8
Teil I......Page 19
1.1 Daten......Page 21
Abb. 1–1 Semiotisches Dreieck (in Anlehnung an [Hinrichs 2002, S. 27])......Page 22
1.2 Qualität......Page 23
Abb. 1–2 Analogie zwischen industrieller Fertigung und Datenverarbeitung (Data Warehousing) (in Anlehnung an [Grimmer/Hinrichs 2001, S. 72])......Page 24
1.3 Datenqualität......Page 25
Tab. 1–1 Liste möglicher Datenqualitätskriterien......Page 26
Tab. 1–2 Definition ausgewählter Datenqualitätskriterien......Page 27
Abb. 1–3 Taxonomie von Datenqualitätskriterien (vgl. [Hinrichs 2002, S. 30])......Page 28
1.4 Datenqualitätsmanagement......Page 29
Abb. 1–5 Entwicklungsstufen des Qualitätswesens (in Anlehnung an [Wolf 1999, S. 63])......Page 30
Abb. 1–6 Plan-Do-Check-Act-Zyklus (vgl. [Redman 1996])......Page 31
Abb. 1–7 Total-Quality-data-Management-Methodik (TQdM) nach English (vgl. [English 1999, S. 70])......Page 32
Abb. 1–8 Ordnungsrahmen für das Datenqualitätsmanagement (vgl. [Otto et al. 2008, S. 218])......Page 34
1.5 Zusammenfassung......Page 35
2 Ausprägungen und Ursachen schlechter Datenqualität......Page 37
2.1 Geschäftstreiber......Page 38
Abb. 2–1 Datenqualität beeinflusst Geschäftstreiber.......Page 39
Wettbewerb......Page 40
Fazit......Page 41
2.2 Ausprägungen schlechter Datenqualität......Page 42
Zeitnähe......Page 43
Zuverlässigkeit......Page 44
2.3 Ursachen schlechter Datenqualität......Page 45
Datenerfassung......Page 46
Prozesse......Page 47
Architektur......Page 48
Definitionen......Page 49
Abb. 2–4 Gemeinsames Vokabular als Basis......Page 50
Datenverfall......Page 51
Vorgehensweise......Page 52
Abb. 2–5 Beispiel für Ursachen von Datenqualitätsproblemen bei einem Finanzdienstleister......Page 53
2.5 Empfehlungen......Page 54
3 Auswirkungen schlechter Datenqualität......Page 55
3.1 Datenqualitätskosten......Page 56
Tab. 3–1 Beispiel für eine Priorisierung von Projekten in Unternehmen......Page 57
Abb. 3–1 Aufteilung von Datenqualitätskosten (in Anlehnung an [Eppler/Helfert 2004, S. 311] und [Otto et al. 2008, S. 219])......Page 58
Durch schlechte Datenqualität verursachte Kosten......Page 59
Kosten zur Verbesserung sowie Sicherstellung einer ausreichenden Datenqualität......Page 60
Abb. 3–2 Vereinfachte Darstellung des Zusammenhangs zwischen Datenqualitätskosten und der erreichbaren Datenqualität......Page 61
Abb. 3–3 Nutzenpotenziale (in Anlehnung an [Eppler/Helfert 2004, S. 3] und [Otto et al. 2008, S. 219])......Page 62
Abb. 3–4 Geschäftstreiber für das Datenqualitätsmanagement (Gartner) (vgl. [Friedman 2006])......Page 63
International Financial Reporting Standards......Page 64
Basel III......Page 65
IMDS......Page 66
3.3 Business-Case-Betrachtungen......Page 67
Abb. 3–6 Business-Case-Betrachtungen......Page 69
3.4 Empfehlungen......Page 70
4.1 Aufbauorganisation......Page 71
Abb. 4–1 Organisationseinheiten im Vergleich......Page 72
Abb. 4–2 Rollen und Gremien......Page 74
Rollen......Page 76
Gremien......Page 80
Abb. 4–4 Service-Lebenszyklus nach ITIL V3 (vgl. [Cartlidge et al. 2007])......Page 81
Laufende Datenqualitätssicherung und -reporting......Page 82
Datenqualitätsproblem-Management......Page 83
Datenqualitätseskalations-Management......Page 84
4.3 Empfehlungen......Page 85
5.1 Referenzarchitektur......Page 87
Abb. 5–1 Referenzarchitektur für Business Intelligence......Page 88
5.1.1 Datenquellen und Datenströme......Page 89
5.1.2 Datenintegration......Page 90
5.1.4 Informationsbereitstellung......Page 91
5.1.7 Querschnittsprozesse......Page 92
Verteilte Datenhaltung......Page 93
Historisierung......Page 94
Abb. 5–2 Konzept des Change Data Capture......Page 95
Abb. 5–3 Separierung von Right Time Data......Page 96
Filesystem......Page 97
Self Service Business Intelligence......Page 98
Abb. 5–4 Referenzarchitektur für Datenqualitätsmanagement während der Entwicklung......Page 99
Abb. 5–5 Referenzarchitektur für Datenqualitätsmanagement zur Laufzeit......Page 100
5.4 Serviceorientierte Architektur......Page 101
Abb. 5–7 Beispiel für eine datenzentrierte Domänenbildung......Page 102
5.5 Master Data Management......Page 103
Abb. 5–8 Referenzarchitektur für Master Data Management......Page 104
Abb. 5–10 Architekturvariante Registrierung......Page 105
Abb. 5–12 Architekturvariante »Transaction Hub«......Page 106
5.5.2 Umsetzung......Page 107
5.6 Empfehlungen......Page 108
6.1 Definitionen von Big Data......Page 109
Abb. 6–1 Framework für Big Data......Page 110
6.1.1 Fachlich-datenbezogene Sicht......Page 111
6.1.2 Gartner-Sicht......Page 112
6.2 Bedeutung der Datenqualität bei Big Data......Page 113
Abb. 6–3 Bedeutung von Datenqualität für Big Data (vgl. [Omikron 2012])......Page 114
6.3 Herausforderung externe Daten......Page 115
6.4 Herausforderung unstrukturierte Daten......Page 117
6.5 Herausforderung Geschwindigkeit......Page 118
6.6 Herausforderung Volumen......Page 119
6.7 Empfehlungen......Page 120
7 Kennzahlen zur Messung der Datenqualität......Page 121
7.1 Anwendungsmöglichkeiten von Kennzahlen......Page 122
Tab. 7–1 Vor­ und Nachteile der Verwendung von Kennzahlen......Page 123
Abb. 7–1 Messpunkte innerhalb der BI-Referenzarchitektur (siehe auch Abb. 5–1 auf S. 70)......Page 124
Messpunkt 1: Quellsysteme......Page 125
Messpunkt 3: Unternehmensweites Data Warehouse......Page 126
7.3 DQ-Metriken......Page 127
7.4 Kennzahlen für ausgewählte Datenqualitätskriterien......Page 130
7.5 Kennzahlenbaum......Page 132
7.6 Kennzahlenformular......Page 133
7.7 Empfehlungen......Page 134
Teil II......Page 135
Abb. II–1 Aufgaben des Datenqualitätsmanagements entlang des Datenflusses......Page 137
8 Verbesserung der Datenqualität im Quellsystem......Page 141
Abb. 8–1 Verbesserung der Prozesse in den Quellsystemen......Page 142
Definition der Zielwerte......Page 143
Analyse der Datenqualitätsprobleme und Identifikation der verursachenden Prozesse......Page 144
Änderung der Prozesse......Page 145
Bewertung der Prozessänderungen......Page 146
8.2 Empfehlungen......Page 147
9 Data Profiling......Page 149
Abb. 9–2 Der iterative Data-Profiling-Prozess......Page 150
9.1.2 Schritt 2: Analyse der integrierten Daten......Page 151
9.1.4 Schritt 4: Fachliche Bewertung der Ergebnisse......Page 152
9.2 Zusammensetzung des Data-Profiling-Teams......Page 153
9.3 Vorgehensweise beim Data Profiling......Page 154
Attributnamenanalyse......Page 155
Datentypanalyse......Page 156
Abb. 9–4 Ergebnis einer Datentypanalyse (Beispielausschnitt)......Page 157
Abb. 9–5 Prozentuale Verteilung der Länge des Attributs NAME (Beispiel)......Page 158
Tab. 9–1 Ergebnis einer Genauigkeitsanalyse für JAHRESEINKOMMEN (Beispiel)......Page 159
Abb. 9–6 Häufigkeitsverteilung Anzahl Kinder bei einer Wertebereichsanalyse......Page 160
Tab. 9–2 Standardisierung von Telefonnummern......Page 161
Domänenanalyse......Page 162
Abb. 9–8 Ergebnis einer Domänenanalyse (Beispiel)......Page 164
Eindeutigkeitsanalyse......Page 165
Abb. 9–9 Ergebnisse der Eindeutigkeitsanalyse (Beispiel)......Page 166
Abb. 9–10 Ergebnisse einer NULL-Werte-Analyse (Beispiel)......Page 167
Regeln zu Domänen......Page 168
Abb. 9–11 Beispiel zur Erweiterung von Domänenanalyse-Ergebnissen......Page 169
Regeln zu Wertebereichen......Page 170
Tab. 9–3 Ergebnis einer Genauigkeitsanalyse für das Attribut STUNDEN (Beispiel)......Page 171
Regeln zu Textattributen......Page 172
Regeln zu fehlenden Werten......Page 174
Eigene Regeln......Page 175
9.5.1 Analyse auf Schlüsselattribute......Page 176
Abb. 9–13 Ergebnis einer Analyse auf Schlüsselattribute (Beispiel)......Page 178
9.5.2 Analyse auf abgeleitete Werte......Page 179
9.5.3 Analyse von Datensätzen mit Geschäftsregeln......Page 180
9.6.1 Analyse von Tabellen auf referenzielle Abhängigkeiten......Page 181
Abb. 9–14 Referenzielle Integrität zwischen den Tabellen KUNDEN_STAMM und BESTELLUNG (Beispiel)......Page 183
Redundante Attribute......Page 184
Anzahl Datensätze......Page 185
Regeln zur Anzahl von Datensätzen......Page 186
Regeln für zeitabhängige Attribute/Objekte......Page 187
Abb. 9–17 Arten der Regeln zu zeitabhängigen Attributen/Objekten (Übersicht)......Page 188
Tab. 9–8 Ergebnis der Regelprüfung auf Aktualität (Beispiel)......Page 189
Abb. 9–18 Werteentwicklung für die Größe eines Babys......Page 190
Regeln für Ereignisse......Page 191
9.7 Empfehlungen......Page 192
10.1 Validierung auf vier Ebenen......Page 193
Abweisung der fehlerhaften Daten......Page 194
Abweisung der fehlerhaften Daten mit Bericht......Page 195
Zurückhaltung der fehlerhaften Daten mit Bericht......Page 196
Verarbeitung der fehlerhaften Daten mit Bereinigung und Kennzeichnung......Page 197
Validierung bei der Extraktion......Page 198
Validierung bei der Extraktion und beim Laden......Page 199
Abb. 10–3 Validierung mit formalen Datenregeln (Beispiel)......Page 200
Abb. 10–4 Validierung mit fachlichen Geschäftsregeln (Beispiel)......Page 201
Abb. 10–5 Ansätze zur Erstellung der Regeln für die Validierung (vgl. [Maydanchik 2008])......Page 202
10.6 Empfehlungen......Page 203
11.1 Standardisierung......Page 205
Abb. 11–3 Normierung der Daten bei der Standardisierung (Beispiel)......Page 206
11.2 Datenbereinigung......Page 207
Abb. 11–4 ETL- und Bereinigungsprozess mit Workflow-Steuerung......Page 208
Methoden zur Bereinigung der Daten......Page 209
Ablage der Originärdaten......Page 210
Überschreibung des originären Werts......Page 211
Tab. 11–1 Kennzeichnung der auswertbaren Zeilen durch ein Flag......Page 212
Erkennung und Konsolidierung von Duplikaten......Page 213
Abb. 11–7 Prozess zur Erkennung und Konsolidierung von Duplikaten......Page 215
Reduzierung des Suchraums......Page 216
Abb. 11–8 Durch Partitionierung unerkannte Duplikate (Beispiel)......Page 218
Abb. 11–9 Sortierte Nachbarschaft (Beispiel)......Page 219
Erkennung von Duplikaten......Page 220
Abb. 11–11 Vergleichsfunktion zur Bestimmung von Duplikaten (Beispiel)......Page 221
Abb. 11–12 Bewertungsmaßstab zur Genauigkeit der Duplikaterkennung......Page 222
Ähnlichkeitsmetriken......Page 223
Abb. 11–13 Übersicht der Ansätze zur Ähnlichkeitsbestimmung für textuelle Attribute......Page 224
Tab. 11–2 Ersetzungsregeln der Kölner Phonetik......Page 225
Abb. 11–14 Ähnlichkeit von Bi-Grammen (Beispiel)......Page 228
Duplikate konsolidieren......Page 230
Abb. 11–16 Unterschiedliche Fälle bei der Zusammenführung von Daten (Beispiel)......Page 231
Konfliktvermeidende Verfahren......Page 232
Konfliktlösende Verfahren......Page 233
Abb. 11–18 Selektionsverfahren nach Histogramm (Beispiel)......Page 234
11.3 Standardisierung und Bereinigung im ETL-Prozess......Page 235
11.5 Empfehlungen......Page 236
12.1 Wirtschaftsinformationen......Page 237
Abb. 12–1 Aufbau des D&B Family Trees......Page 238
Abb. 12–2 Duplikaterkennung durch Nutzung der DUNS-Nummer......Page 239
12.2 Geografische Informationen......Page 240
Abb. 12–3 Data-Mining-Prozess mit Geografischen Informationssystemen (GIS) (vgl. [Feix 2007, S. 54])......Page 241
12.3 Soziodemografische Informationen......Page 242
Tab. 12–1 Haushaltsbildung von Adressdaten......Page 243
UNSPSC......Page 244
eClass......Page 245
Abb. 12–5 Aufbau der eClass-Materialhierarchie (Release 6.1)......Page 246
12.6 Branchenklassifizierung......Page 247
Tab. 12–4 Branchenzuordnungen am Beispiel »Information und Kommunikation«......Page 248
Tab. 12–5 Aufbau des NAICS­Code......Page 249
12.7 Empfehlungen......Page 250
13.1 Bereitstellung der Daten......Page 251
Abb. 13–1 Definition einer Zwischenschicht (Beispiel)......Page 252
Abb. 13–2 Beispiel für ein Dashboard......Page 253
Tab. 13–1 Unterschiede zwischen Scorecards und Dashboards......Page 254
Aufgaben der Visualisierung......Page 255
Regeln für eine bessere Visualisierung......Page 256
Abb. 13–4 Gleiches Diagramm ohne Botschaft im Vergleich mit unterschiedlichen Botschaften (vgl. [Hichert 2004])......Page 259
Abb. 13–5 Visuelle Aufmerksamkeit für die verschiedenen Bildschirmbereiche (vgl. [Few 2008, S. 3f.])......Page 261
Abb. 13–6 Beispiel für eine aus Microsoft-Excel erzeugte Grafik (vgl. [Bissantz et al. 2010, S. 445])......Page 262
Abb. 13–7 Negativbeispiel für ein Dashboard (Nachahmung eines Armaturenbretts)......Page 263
Abb. 13–9 Bild mit höherer Informationsdichte......Page 265
Abb. 13–11 Preis des Euros über 65 bzw. 12 Monate in Bezug zu drei Währungen (vgl. [Tufte 2006, S. 8])......Page 266
Abb. 13–12 Auswirkungen einer erhöhten Skalierung (Beispiel)......Page 267
Regeln zur Organisation und Sicherheit......Page 268
13.3 Empfehlungen......Page 269
14.1 Metadaten: Begriff und Strukturierung......Page 271
Abb. 14–1 Nutzenpotenziale Metadaten (vgl. [Auth 2004, S. 181])......Page 272
14.2 Metadatenarchitekturen......Page 273
Zentrales Metadaten-Repository......Page 274
Lokale Repositorys mit zentralem Repository......Page 275
14.3 Metadatenmanagement......Page 276
Tab. 14–1 Metadaten entlang der BI-Referenzarchitektur......Page 278
Abb. 14–3 Metadaten zu Datenflüssen......Page 279
Abb. 14–5 Metadaten zu einer Tabelle......Page 280
Informationsbereitstellung......Page 281
Metadaten zur Datenqualität......Page 282
Abstammungs- und Auswirkungsanalysen......Page 283
Erfüllung regulatorischer Anforderungen......Page 284
Metadaten für das Data Profiling......Page 285
14.7 Empfehlungen......Page 286
15 Data Quality Monitoring......Page 287
Definition der Kennzahlen......Page 288
Analyseansätze......Page 289
Tab. 15–1 Beispiele für DQ­Werkzeuge......Page 291
15.3 DQ-Phasenkonzepte......Page 292
Abb. 15–1 Kreislauf Data Quality Monitoring......Page 294
Laufendes Data Profiling......Page 295
Berichtswesen......Page 296
Historienreihe......Page 297
Abb. 15–3 Historischer Vergleich der Entwicklung von Datenqualitätskriterien......Page 298
Datenqualitätsradar......Page 299
Benachrichtigungen......Page 300
15.6 Empfehlungen......Page 301
16.1 Anbieter und Produkte......Page 303
Tab. 16–1 Exemplarische Anwendungsfälle für Datenqualitätsmanagement......Page 305
Data Profiling......Page 306
Duplikate......Page 307
Anreicherung......Page 308
Abb. 16–2 Referenzarchitektur für die Integration der Komponenten und Services des Datenqualitätsmanagements......Page 309
16.6 Sprachen und Länder......Page 311
16.8 Empfehlungen......Page 312
Teil III......Page 313
Einleitung......Page 315
Abb. III–1 Verwendetes Projektmodell......Page 316
Abb. III–2 Abbildung der Projektphasen auf den RUP......Page 317
17 Datenqualitätsmanagement in einer Studie......Page 319
Identifikation der Quellsysteme......Page 320
Tab. 17–1 Vergleich der Materialdatenstrukturen der Stammdatensysteme Alpha und Bravo......Page 321
Tab. 17–2 Tabelle mit Übersicht der Datenverantwortlichen (Beispiel)......Page 322
Tab. 17–3 Tabelle mit Übersicht über die Metadatenquellen (Beispiel)......Page 324
Quantitative Analyse der Quellsysteme......Page 325
Tab. 17–4 Teilergebnis (Auszug) des Data Profiling der Materialdaten im Stammdatensystem Bravo (Aggregation)......Page 327
Tab. 17–5 Ergebnis des Data Profiling der Spalte MINDESTMENGE der Materialdaten im Stammdatensystem Bravo (Genauigkeitsanalyse)......Page 328
Qualitative Analyse des Zielsystems......Page 329
Abb. 17–2 Dokumentation der Erwartungen an die Datenqualität (Beispiel)......Page 330
Abb. 17–3 Erwartungen an die Datenqualität am Beispiel der Vollständigkeit der Materialstammdaten......Page 331
Abb. 17–4 Zielarchitektur......Page 332
Auswahl geeigneter Werkzeuge......Page 333
17.3 Bewertung......Page 334
17.5 Empfehlungen......Page 335
18.1 Spezifikation der Schnittstellen......Page 337
18.2 Definition der Rollen in der Datenorganisation......Page 338
18.3 Festlegung der Datenqualitätsziele......Page 340
Abb. 18–2 Datenqualitätsanforderungen zu Beziehungen zwischen fachlichen Objekten......Page 341
Abb. 18–3 Bericht mit Datenqualitätskennzahlen......Page 342
18.4 Bezeichnung und Definition der Objekte......Page 343
18.5 Festlegung der Geschäftsregeln......Page 345
18.7 Data Profiling in der Spezifikation......Page 347
18.8 Entwurf des Systems......Page 348
Tab. 18–1 Zielstruktur und Abbildungsverzeichnis für die Materialstammdaten......Page 350
18.9 Empfehlungen......Page 351
19.1 Übertragung der Datenqualitätsziele......Page 353
19.2 Konventionen und Richtlinien......Page 354
19.3 Entwurf des Systems......Page 355
Abb. 19–1 Gesamtarchitektur für Spend Management Reporting......Page 356
Abb. 19–2 Fehlende Trennung zwischen fachlicher und qualitätssteuernder Logik im ETL-Prozess......Page 357
Abb. 19–3 Umsetzung von Domänen als Dimension (ADAPT ™-Notation)......Page 358
Abb. 19–4 DQ-Frontends für den Data Steward......Page 359
Abb. 19–5 DQ-Management innerhalb der Datenintegration......Page 360
19.5 Empfehlungen......Page 361
20.1 Einhaltung der Konventionen, Richtlinien und Konzepte......Page 363
Profiling des Datenbankmodells......Page 364
20.3 Einbindung der Datenverantwortlichen und Benutzer......Page 365
20.4 Realisierung der Datenqualitätsmaßnahmen......Page 366
20.6 Empfehlungen......Page 367
Tab. 21–1 Maturity-Modell für das Datenqualitätsmanagement (in Anlehnung an die ISO-Norm 15504)......Page 369
Abb. 21–1 Qualitätsgeregelte Steuerung der Datenprozesse......Page 370
21.3 Empfehlungen......Page 371
Abb. 21–3 Datenqualitätsmanagement......Page 372
Anhang......Page 373
Abkürzungen......Page 375
Literatur......Page 377
Index......Page 385
www.dpunkt.de......Page 0

Citation preview

Detlef Apel ist der Subject Matter Expert für Stammdaten- und Datenqualitätsmanagement bei Capgemini. Durch seine mehr als 17-jährige Erfahrung mit der Datenintegration aus heterogenen Systemen, dem Reporting, der Analyse und der Big Data Analytics ist er schnell auf das Datenqualitätsmanagement als wesentlichen Wettbewerbsvorteil für Unternehmen gestoßen. Er hat namhafte Kunden aus unterschiedlichen Branchen bei der Einführung und Optimierung ihres Datenmanagements erfolgreich beraten sowie als Architekt und Entwickler die technische Implementierung übernommen. Weiter ist er Redner auf verschiedenen Konferenzen, Autor zahlreicher Fachpublikationen und Vertreter des ExpertConnect-Programms von Capgemini. Dr. Wolfgang Behme ist als Global Support Manager im Competence Center BI/CRM/eCom/Mobility bei der Continental Reifen Deutschland GmbH verantwortlich für den weltweiten Support der SAP BW Plattform, auf der alle BI-Anwendungen der ReifenDivision laufen. Er arbeitet seit mehr als 15 Jahren im BI-Umfeld und ist Autor und Herausgeber diverser Fachpublikationen. Sein Anliegen, den Austausch zwischen Theorie und Praxis zu fördern, wird durch zahlreiche Vorträge auf verschiedenen BI-Konferenzen sowie durch Lehraufträge an Hochschulen deutlich.

Rüdiger Eberlein ist Chief Technology Officer Business Information Management bei Capgemini Deutschland. Als Architekt von Anwendungslandschaften hat er sich immer wieder mit der Problematik der Datenqualität auseinandergesetzt. Er hat BI- und BigData-Analytics-Lösungen für Unternehmen verschiedener Branchen wie Automobil, Finanzdienstleister, Telekommunikation und Öffentlicher Bereich mitgestaltet. Weiter hat er mehrere Fachartikel zu Architekturthemen aus Big Data Analytics und Business Intelligence veröffentlicht sowie Vorträge auf Konferenzen gehalten. Als Verantwortlicher der Rubrik Daten der Capgemini IT Trends Studie weiß er um die enorme Bedeutung, die das Thema Datenqualität für CIOs in Deutschland hat. Christian Merighi ist Senior Berater im Bereich BI/DWH Strategic Services bei Teradata GmbH in Österreich. Zu seinen Aufgabengebieten gehören die fachliche Konzeption von Business-Intelligence-/ Data-Warehouse-Lösungen, die Erarbeitung von Kosten/NutzenModellen sowie die Definition von Vorgehensmodellen für die Projektumsetzung in diesen Bereichen. In den letzten Jahren hat er sich im Rahmen dieser Tätigkeiten zudem auf den Bereich BI & Data Governance (Konzeption und Aufbau BICC) sowie das ganzheitliche Datenqualitätsmanagement fokussiert. In diesem Umfeld verantwortet er Projekte bei Unternehmen in Österreich, Deutschland und Osteuropa.

Detlef Apel · Wolfgang Behme · Rüdiger Eberlein · Christian Merighi

Datenqualität erfolgreich steuern Praxislösungen für Business-Intelligence-Projekte

3., überarbeitete und erweiterte Auflage

Edition TDWI

Detlef Apel · [email protected] Wolfgang Behme · [email protected] Rüdiger Eberlein · [email protected] Christian Merighi · [email protected] Fachlektorat: Marcus Pilz Lektorat: Christa Preisendanz Copy-Editing: Annette Schwarz, Ditzingen Herstellung: Birgit Bäuerlein Umschlaggestaltung: Anna Diechtierow, Heidelberg Druck und Bindung: M.P. Media-Print Informationstechnologie GmbH, 33100 Paderborn Fachliche Beratung und Herausgabe von dpunkt.büchern in der Edition TDWI: Marcus Pilz · [email protected] Bibliografische Information der Deutschen Nationalbibliothek Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar. ISBN: Buch PDF ePub

978-3-86490-042-6 978-3-86491-641-0 978-3-86491-642-7

3., überarbeitete und erweiterte Auflage Copyright © 2015 dpunkt.verlag GmbH Wieblinger Weg 17 69123 Heidelberg Die vorliegende Publikation ist urheberrechtlich geschützt. Alle Rechte vorbehalten. Die Verwendung der Texte und Abbildungen, auch auszugsweise, ist ohne die schriftliche Zustimmung des Verlags urheberrechtswidrig und daher strafbar. Dies gilt insbesondere für die Vervielfältigung, Übersetzung oder die Verwendung in elektronischen Systemen. Es wird darauf hingewiesen, dass die im Buch verwendeten Soft- und Hardware-Bezeichnungen sowie Markennamen und Produktbezeichnungen der jeweiligen Firmen im Allgemeinen warenzeichen-, marken- oder patentrechtlichem Schutz unterliegen. Alle Angaben und Programme in diesem Buch wurden mit größter Sorgfalt kontrolliert. Weder Autor noch Verlag können jedoch für Schäden haftbar gemacht werden, die in Zusammenhang mit der Verwendung dieses Buches stehen. 543210

v

Geleitwort zur 3. Auflage

Es zeugt von einem anhaltenden Interesse für das Thema Datenqualität und auch für die Qualität der vorliegenden Publikation, dass nun schon die 3. Auflage erscheinen kann. Ich danke den Autoren Detlef Apel, Dr. Wolfgang Behme, Rüdiger Eberlein und Christian Merighi für die überaus fundierten Ausführungen und die Breite, in der sie das Feld der Datenqualität im Kontext von Business Intelligence abhandeln. Es ist deutlich erkennbar, dass alle Autoren die Problemdomäne um schlechte Datenqualität in Unternehmen nicht nur theoretisch erfasst haben, sondern aus ihrer Praxiserfahrung heraus auch Lösungsansätze zu liefern vermögen. Auch in der 3. Auflage ist es zu Anpassungen und Erweiterungen gekommen, die dem Buch gutgetan haben und dessen Wert noch steigern. Da in der Unternehmenspraxis der Druck zur Verbesserung der Datenqualität nicht nachlässt, bin ich sicher, dass die vielen hilfreichen Handreichungen zur Arbeit in BI-Projekten das Buch zu einem ständigen Begleiter der Projektmitarbeiter machen. Darüber hinaus nimmt das Werk auch einen festen Platz in der Literaturliste der Hochschulen und Universitäten ein, denn es vermittelt in sehr anschaulicher Art und Weise die Problemstellungen und die Lösungswege, welche wir den Studierenden näherbringen wollen. In diesem Sinn empfehle ich allen Lesern die Lektüre der 3. Auflage, sei es als Lehrstoff oder als Kompendium zur eigenen Projektarbeit. Univ.-Prof. Dr. Peter Chamoni

vi

Geleitwort zur 3. Auflage

vii

Vorwort zur 3. Auflage

Nach Schätzungen (vgl. [Crosby 1979, S. 15] und [Juran 1988, S. 1]) verursacht schlechte Datenqualität in Unternehmen Verluste in Höhe von bis zu 25 Prozent des operativen Gewinns. Aufgrund der zunehmenden Integration von IT in die Geschäftsprozesse der Unternehmen, der Anforderungen hinsichtlich Compliance sowie der Einbeziehung unternehmensexterner Daten (z.B. Big Data) nimmt die Bedeutung von Datenqualität nochmals erheblich zu. Die Hoffnung vieler Unternehmen auf Lösung der Datenqualitätsproblematik durch die Einführung von Standardsoftware für Enterprise Resource Planning (ERP), Customer Relationship Management (CRM), Supply Chain Management (SCM) u.a. hat sich nicht erfüllt und macht endlich Platz für wirksame Maßnahmen. Im Mittelpunkt dieses Buches steht die Vermittlung langjähriger Erfahrungen aus BI­Projekten mit Datenqualitätsmanagement­Aktivitäten bei Unternehmen unterschiedlicher Branchen. Neben der anwender­ und praxisorientierten Darstellung der verschiedenen Bereiche von Datenqualitätsmanagement (DQM) werden die Best Practices und Lessons Learned dargestellt, sodass der Leser eigene Projekte in diesem Umfeld erfolgreich durchführen kann. Generell werden Daten über eine Benutzerschnittstelle erfasst oder durch Geschäftslogik von IT­Systemen erzeugt. Meistens fließen die Daten weiter in andere IT­Systeme und werden dabei transformiert. Ein Datenfluss kann viele Stationen haben. Das Data Warehouse ist häufig nur die »Endstation« solcher Datenflüsse. Werden fehlerhafte Daten nicht erkannt und behandelt, führen sie im Verlauf des Datenflusses zu Folgefehlern, die sich leicht zu größeren Problemen aufschaukeln können. Es liegt also auf der Hand, ein Datenqualitätsmanagement möglichst frühzeitig im Datenfluss anzusetzen. Nachhaltiges Datenqualitätsmanagement ist daher idealerweise eine unternehmensweite Aktivität, die ggf. von Vorhaben für Business Intelligence oder auch Customer Relationship Management angestoßen werden muss. In den meisten Unternehmen kommen fehlerhafte Daten erst im Data Warehouse ans Licht. Das liegt daran, dass dort alle Daten in Gänze und verdichtet betrachtet werden, während beim Datenzugriff durch operative Systeme nur einige Felder in dem einen oder anderen Datensatz zutage treten. Schlechte Datenqualität lässt sich im Data Warehouse nicht verbergen. Allerdings ist es oft

viii

Vorwort zur 3. Auflage

genau diese schlechte Datenqualität, die die Akzeptanz der BI­Anwendung durch den Endanwender in den Fachbereichen verhindert und häufig direkt zum Misserfolg des mit dem Data Warehouse verbundenen Vorhabens führt. Wer will schon wichtige geschäftliche Entscheidungen auf fehlerhafte Daten stützen? Da lässt es sich noch besser aus dem Bauch heraus entscheiden. Dieses Buch hat nicht den Anspruch eines unternehmensweiten Datenqualitätsmanagements, sondern fokussiert auf den Bereich Business Intelligence, wo der Schmerz mit fehlerhaften Daten am größten ist. Unter Business Intelligence (BI) wird ein integrierter, unternehmensspezifischer, IT­basierter Gesamtansatz zur Unterstützung betrieblicher Entscheidungen verstanden. »Business Intelligence ist der Prozess, der Daten in Informationen und weiter in Wissen umwandelt« (Definition von Howard Dresdner (Gartner) 1989). Unternehmensentscheidungen und Prognosen stützen sich auf dieses Wissen und führen zu geschäftlichem Mehrwert. Business Intelligence kommt sowohl zur Unterstützung strategischer Entscheidungen als auch im operativen Bereich zum Einsatz. Business Intelligence umfasst ein breites Spektrum an Anwendungen und Technologien und ist der Oberbegriff für Data Warehousing, Data Mining, Online Analytical Processing und Analytische Anwendungen. Im weiteren Sinne umfasst Business Intelligence auch die Erschließung unstrukturierter Daten mittels Content­ und Dokumentenmanagement. Letztgenannte Bereiche sind jedoch nicht Gegenstand dieses Buches. Betrachtet wird lediglich die Business Intelligence im engeren Sinn, also auf strukturierte Daten bezogen. Endanwender der Fachbereiche

Business-Intelligence-Portal

Abb. 1

Reporting, Analyse, Data Mining

Knowledge-Management

Data Warehouse

Content-, Dokumentenmanagement

Struktuierte Daten

Unstruktuierte Daten

Grobe Architektur für Business Intelligence

Das Data Warehouse ist eine konsolidierte Datenhaltung zur Unterstützung von Reporting und Analyse. »Ein Data Warehouse ist eine themenorientierte, integrierte, chronologisierte und persistente Sammlung von Daten, um das Management bei seinen Entscheidungsprozessen zu unterstützen« (vgl. [Inmon 1996]). Das Buch gliedert sich in drei Teile. Im ersten Teil wird beschrieben, was Datenqualitätsmanagement ausmacht. Der zweite Teil befasst sich mit der Umsetzung und stellt insbesondere technische Hilfsmittel dar. Im dritten Teil wird

Vorwort zur 3. Auflage

ix

erklärt, wie man Verfahren, Methoden, Organisation und Werkzeuge des Datenqualitätsmanagements in der Praxis einsetzt. Zu Beginn des ersten Teils (Kapitel 1) werden die wesentlichen Begriffe im Zusammenhang mit Datenqualitätsmanagement definiert. In Kapitel 2 wird erklärt, woran sich schlechte Datenqualität festmacht und wo die Ursachen dafür liegen. In Kapitel 3 wird dargelegt, warum es sich lohnt, ein Datenqualitätsmanagement aufzusetzen. In Kapitel 4 werden die organisatorischen Belange in Bezug auf die Datenqualität ausführlich geschildert. Die Architektur für BI­Anwendungen wird unter dem Blickwinkel der Datenqualität in Kapitel 5 betrachtet. In Kapitel 6 wird Big Data Analytics mit den Herausforderungen an das Datenqualitätsmanagement diskutiert. Hierbei wird auch auf den Bereich der unstrukturierten Daten eingegangen. Das Kapitel 7 beschreibt, wie sich Datenqualität messen lässt. Im zweiten Teil des Buches werden wichtige Prinzipien der technischen Umsetzung des Datenqualitätsmanagements beschrieben. Dabei werden die Werkzeuge zur Unterstützung des Datenqualitätsmanagements betrachtet, angefangen beim Metadatenmanagement über Data Profiling, die Validierung, Bereinigung und Anreicherung von Daten bis hin zur fortlaufenden Überwachung der Datenqualität. Anschließend wird auf die Integration der Werkzeuge in die Anwendungslandschaft der jeweiligen IT­Umgebung eingegangen. Am Ende dieses Buchteils werden Kriterien zur Produktauswahl aufgeführt. Der dritte und letzte Teil des Buches bildet Datenqualitätsmanagement auf das Vorgehen in BI­Projekten ab. Dabei werden die einzelnen Phasen eines BI­Projekts von der Vorstudie über Spezifikation, Design und Umsetzung bis zum Betrieb im Unternehmen betrachtet. Für jede Projektphase werden die jeweils einzusetzenden Elemente des Datenqualitätsmanagements benannt, die im zweiten Teil des Buches beschrieben wurden. Somit bietet der dritte Buchteil für Projektverantwortliche eine unverzichtbare Hilfestellung zur erfolgreichen Durchführung von Projekten. Was hat sich in der 3. Auflage geändert? Im 1. Teil des Buches wurde das Thema Big Data neu aufgenommen, da es für die Welt der Business Intelligence eine neue Evolutionsstufe darstellt und somit Auswirkungen auf das Datenqualitätsmanagement hat. Weiterhin wurden in allen Kapiteln Aktualisierungen vorgenommen. Detlef Apel, Wolfgang Behme, Rüdiger Eberlein, Christian Merighi Troisdorf, Hannover, München, Wien, im Dezember 2014

x

Vorwort zur 3. Auflage

xi

Inhaltsübersicht

Teil I

1

1

Datenqualität

2

Ausprägungen und Ursachen schlechter Datenqualität

19

3

Auswirkungen schlechter Datenqualität

37

4

Organisation

53

5

Referenzarchitektur für Business-Intelligence-Anwendungen

69

6

Big Data

91

7

Kennzahlen zur Messung der Datenqualität

Teil II

3

103 117

8

Verbesserung der Datenqualität im Quellsystem

123

9

Data Profiling

131

10

Erfolgreiche Datenvalidierung und -filterung

175

11

Standardisierung und Bereinigung

187

12

Datenanreicherung

219

13

Verbesserung der Datenqualität in der Bereitstellung und Visualisierung

233

14

Wertschöpfung durch Metadaten

253

15

Data Quality Monitoring

269

16

Produktauswahl und -integration

285

Inhaltsübersicht

xii

Teil III

295

17

Datenqualitätsmanagement in einer Studie

301

18

Datenqualitätsmanagement in der Spezifikation

319

19

Datenqualitätsmaßnahmen in der Konstruktionsphase

335

20

Steuerung der Datenqualität in der Realisierung

345

21

Steuerung der Datenqualität im Betrieb

351

Anhang

355

Abkürzungen

357

Literatur

359

Index

367

xiii

Inhaltsverzeichnis

Teil I

1

1

Datenqualität

3

1.1 1.2 1.3 1.4 1.5

Daten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Qualität . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Datenqualität . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Datenqualitätsmanagement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2

Ausprägungen und Ursachen schlechter Datenqualität

19

2.1 2.2 2.3 2.4 2.5

Geschäftstreiber . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ausprägungen schlechter Datenqualität . . . . . . . . . . . . . . . . . . . . . . Ursachen schlechter Datenqualität . . . . . . . . . . . . . . . . . . . . . . . . . . Beispiel: Finanzdienstleister . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Empfehlungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

20 24 27 34 36

3

Auswirkungen schlechter Datenqualität

37

3.1 3.2 3.3 3.4

Datenqualitätskosten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Gesetzliche Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Business-Case-Betrachtungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Empfehlungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

38 45 49 52

4

Organisation

53

4.1 4.2 4.3

Aufbauorganisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 Ablauforganisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 Empfehlungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Inhaltsverzeichnis

xiv

5

Referenzarchitektur für Business-Intelligence-Anwendungen

69

5.1

5.6

Referenzarchitektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1.1 Datenquellen und Datenströme . . . . . . . . . . . . . . . . . . . . . . 5.1.2 Datenintegration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1.3 Datenhaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1.4 Informationsbereitstellung . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1.5 Anwender und Rollen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1.6 Operative Anwendungen und Prozesse . . . . . . . . . . . . . . . . 5.1.7 Querschnittsprozesse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Problemstellen und Lösungsansätze hinsichtlich der Datenqualität . . 5.2.1 Datenquellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2.2 Datenintegration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2.3 Datenhaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2.4 Informationsbereitstellung . . . . . . . . . . . . . . . . . . . . . . . . . . Architektur für Datenqualitätsmanagement . . . . . . . . . . . . . . . . . . . . Serviceorientierte Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Master Data Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.5.1 Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.5.2 Umsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Empfehlungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

69 71 72 73 73 74 74 74 75 75 76 79 80 81 83 85 86 89 90

6

Big Data

91

6.1

6.2 6.3 6.4 6.5 6.6 6.7

Definitionen von Big Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 6.1.1 Fachlich-datenbezogene Sicht . . . . . . . . . . . . . . . . . . . . . . . 93 6.1.2 Gartner-Sicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 6.1.3 Technisch-infrastrukturelle Sicht . . . . . . . . . . . . . . . . . . . . . 95 Bedeutung der Datenqualität bei Big Data . . . . . . . . . . . . . . . . . . . . . 95 Herausforderung externe Daten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 Herausforderung unstrukturierte Daten . . . . . . . . . . . . . . . . . . . . . . . 99 Herausforderung Geschwindigkeit . . . . . . . . . . . . . . . . . . . . . . . . . . 100 Herausforderung Volumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 Empfehlungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

7

Kennzahlen zur Messung der Datenqualität

103

7.1 7.2 7.3 7.4 7.5 7.6 7.7

Anwendungsmöglichkeiten von Kennzahlen . . . . . . . . . . . . . . . . . . Messpunkte für Datenqualität . . . . . . . . . . . . . . . . . . . . . . . . . . . . . DQ-Metriken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Kennzahlen für ausgewählte Datenqualitätskriterien . . . . . . . . . . . . Kennzahlenbaum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Kennzahlenformular . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Empfehlungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

104 106 109 112 114 115 116

5.2

5.3 5.4 5.5

Inhaltsverzeichnis

Teil II

xv

117

8

Verbesserung der Datenqualität im Quellsystem

8.1 8.2

Vorbeugung vor neuen Datenqualitätsproblemen . . . . . . . . . . . . . . 124 Empfehlungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

9

Data Profiling

131

9.1

9.7

Data-Profiling-Prozess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.1.1 Schritt 1: Integration der Daten . . . . . . . . . . . . . . . . . . . . 9.1.2 Schritt 2: Analyse der integrierten Daten . . . . . . . . . . . . . 9.1.3 Schritt 3: Darstellung der Ergebnisse . . . . . . . . . . . . . . . . 9.1.4 Schritt 4: Fachliche Bewertung der Ergebnisse . . . . . . . . . Zusammensetzung des Data-Profiling-Teams . . . . . . . . . . . . . . . . . Vorgehensweise beim Data Profiling . . . . . . . . . . . . . . . . . . . . . . . Data-Profiling-Verfahren zur Analyse von Attributen . . . . . . . . . . . 9.4.1 Standardanalysen auf Attributebene . . . . . . . . . . . . . . . . . 9.4.2 Analyse der Attribute mit Geschäftsregeln . . . . . . . . . . . . Data-Profiling-Verfahren zur Analyse von Datensätzen . . . . . . . . . 9.5.1 Analyse auf Schlüsselattribute . . . . . . . . . . . . . . . . . . . . . 9.5.2 Analyse auf abgeleitete Werte . . . . . . . . . . . . . . . . . . . . . . 9.5.3 Analyse von Datensätzen mit Geschäftsregeln . . . . . . . . . Data-Profiling-Verfahren zur Analyse von Tabellen . . . . . . . . . . . . 9.6.1 Analyse von Tabellen auf referenzielle Abhängigkeiten . . 9.6.2 Analyse von Tabellen mit Geschäftsregeln . . . . . . . . . . . . Empfehlungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

132 133 133 134 134 135 136 137 137 150 158 158 161 162 163 163 168 174

10

Erfolgreiche Datenvalidierung und -filterung

175

10.1 10.2 10.3 10.4 10.5 10.6

Validierung auf vier Ebenen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Filterung fehlerhafter Daten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Validierung bei Extraktion oder Laden . . . . . . . . . . . . . . . . . . . . . . Arten der Datenvalidierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Erstellung der Validierungsregeln und Speicherung der Ergebnisse . Empfehlungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

175 176 180 182 184 185

11

Standardisierung und Bereinigung

187

11.1 11.2 11.3 11.4 11.5

Standardisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Datenbereinigung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Standardisierung und Bereinigung im ETL-Prozess . . . . . . . . . . . . . Verfahren für nicht zu bereinigende Daten . . . . . . . . . . . . . . . . . . . Empfehlungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

187 189 217 218 218

9.2 9.3 9.4

9.5

9.6

123

Inhaltsverzeichnis

xvi

12

Datenanreicherung

219

12.1 12.2 12.3 12.4 12.5 12.6 12.7

Wirtschaftsinformationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Geografische Informationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Soziodemografische Informationen . . . . . . . . . . . . . . . . . . . . . . . . . Haushaltsbildung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Standards zur Klassifizierung von Waren und Dienstleistungen . . . . Branchenklassifizierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Empfehlungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

219 222 224 225 226 229 232

13

Verbesserung der Datenqualität in der Bereitstellung und Visualisierung

233

13.1 13.2 13.3

Bereitstellung der Daten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233 Visualisierung der Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235 Empfehlungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251

14

Wertschöpfung durch Metadaten

253

14.1 14.2 14.3 14.4 14.5 14.6 14.7

Metadaten: Begriff und Strukturierung . . . . . . . . . . . . . . . . . . . . . . Metadatenarchitekturen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Metadatenmanagement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Metadatenkategorien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Probleme bei der Erstellung: Motivation und Aktualität . . . . . . . . . Nutzung von Metadaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Empfehlungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

253 255 258 260 265 265 268

15

Data Quality Monitoring

269

15.1 15.2 15.3 15.4 15.5 15.6

DQ-Planung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . DQ-Assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . DQ-Phasenkonzepte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Methoden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Verantwortlichkeiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Empfehlungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

270 271 274 277 283 283

16

Produktauswahl und -integration

285

16.1 16.2 16.3 16.4 16.5 16.6 16.7 16.8

Anbieter und Produkte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Auswahlkriterien im Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . Funktionale Kriterien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Einbeziehung der Fachbereiche . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sprachen und Länder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Einbindung in DQM-Prozesse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Empfehlungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

285 287 287 291 293 293 294 294

Inhaltsverzeichnis

Teil III

xvii

295

17

Datenqualitätsmanagement in einer Studie

301

17.1 17.2 17.3 17.4 17.5

Analyse des Istzustands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Entwurf des Sollkonzepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Bewertung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Umsetzungsplanung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Empfehlungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

302 311 316 317 317

18

Datenqualitätsmanagement in der Spezifikation

319

18.1 18.2 18.3 18.4 18.5 18.6 18.7 18.8 18.9

Spezifikation der Schnittstellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . Definition der Rollen in der Datenorganisation . . . . . . . . . . . . . . . Festlegung der Datenqualitätsziele . . . . . . . . . . . . . . . . . . . . . . . . . Bezeichnung und Definition der Objekte . . . . . . . . . . . . . . . . . . . . Festlegung der Geschäftsregeln . . . . . . . . . . . . . . . . . . . . . . . . . . . . Messung der Qualität von Definitionen und Geschäftsregeln . . . . . Data Profiling in der Spezifikation . . . . . . . . . . . . . . . . . . . . . . . . . Entwurf des Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Empfehlungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

319 320 322 325 327 329 329 330 333

19

Datenqualitätsmaßnahmen in der Konstruktionsphase

335

19.1 19.2 19.3 19.4 19.5

Übertragung der Datenqualitätsziele . . . . . . . . . . . . . . . . . . . . . . . . Konventionen und Richtlinien . . . . . . . . . . . . . . . . . . . . . . . . . . . . Entwurf des Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Erstellung eines Prototypen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Empfehlungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

335 336 337 343 343

20

Steuerung der Datenqualität in der Realisierung

345

20.1 20.2 20.3 20.4 20.5 20.6

Einhaltung der Konventionen, Richtlinien und Konzepte . . . . . . . . Data Profiling in der Realisierung . . . . . . . . . . . . . . . . . . . . . . . . . . Einbindung der Datenverantwortlichen und Benutzer . . . . . . . . . . Realisierung der Datenqualitätsmaßnahmen . . . . . . . . . . . . . . . . . . Durchführung von Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Empfehlungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

345 346 347 348 349 349

21

Steuerung der Datenqualität im Betrieb

351

21.1 21.2 21.3

Monitoring und Berichtswesen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352 Ausbildung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353 Empfehlungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353

xviii

Inhaltsverzeichnis

Anhang

355

Abkürzungen

357

Literatur

359

Index

367

Teil I 1

Datenqualität

3

2

Ausprägungen und Ursachen schlechter Datenqualität

19

3

Auswirkungen schlechter Datenqualität

37

4

Organisation

53

5

Referenzarchitektur für Business-Intelligence-Anwendungen

69

6

Big Data

91

7

Kennzahlen zur Messung der Datenqualität

103

2

3

1

Datenqualität

Der Begriff Datenqualität ist sehr stark subjektiv geprägt. Sowohl bei der Befragung von Fachleuten als auch in der Literatur erhält man zu diesem Thema sehr unterschiedliche Antworten. Viele Autoren gehen in Ermangelung einer einheitlichen Definition daher auf die beiden Grundbestandteile des Begriffs zurück und definieren sowohl Daten als auch Qualität allgemein und folgen damit Larry English, einem der Pioniere auf dem Gebiet der Datenqualität: »The best way to look at information quality is to look at what quality means in the general marketplace and then translate what quality means for information« (vgl. [English 1999, S. 15ff.]). In diesem Kapitel werden zunächst die grundlegenden Begriffe Daten und Qualität und daraus abgeleitet der Begriff Datenqualität erläutert. Nach einer ausführlichen Beschreibung der Eigenschaften wird auf unterschiedliche Taxonomien eingegangen. Den Abschluss des Kapitels bildet das Thema Datenqualitätsmanagement.

1.1

Daten

Die aktuelle Situation in den Unternehmen ist durch eine steigende Datenflut gekennzeichnet. Beispielsweise fallen durch die Vernetzung von Scannerkassen in Supermärkten oder die Speicherung von Verbindungsdaten in der Telekommunikationsbranche große Datenmengen an. Dieser Trend wird durch neue Entwicklungen wie Radio Frequency Identification (RFID) noch verstärkt. Nach Schätzungen der Gartner­Gruppe würde die Einzelhandelskette Wal­Mart täglich Daten im Umfang von 7 Terabyte generieren, wenn alle Artikel mit RFID­Marken versehen würden (vgl. [Raskino/Fenn/Linden 2005]). Gemäß einer IDC-Studie (vgl. [IDC 2011]) ist die weltweit produzierte Datenmenge im Jahr 2011 auf ein Volumen von 1,8 Zettabyte1 angestiegen. Daten allein haben jedoch nur einen begrenzten Wert, erst in einem sinnvollen Kontext werden daraus unternehmensrelevante Informationen. 1.

1 Zettabyte = 1 Billion Gigabyte

4

1 Datenqualität

Bisher gibt es keine einheitliche Definition des Begriffs Daten. Den meisten Definitionen ist jedoch gemein, dass sie Daten nicht getrennt, sondern im Zusammenhang mit Information und Wissen betrachten, weil sich die Begriffe jeweils ergänzen (vgl. [English 1999, S. 18; Helfert 2002, S. 13; Müller 2000, S. 5ff. u.a.]). Zumeist findet eine Hierarchisierung statt, deren unterstes Glied die Daten darstellen. Hierbei wird häufig die Semiotik als Strukturierungshilfe (Syntaktik – Semantik – Pragmatik) genutzt, die die allgemeine Lehre von den Zeichen, Zeichensystemen und Zeichenprozessen in das Gebiet der Informatik überträgt. Information – Semantik Bedeutung von Zeichenfolgen

Daten – Syntaktik Struktur von Zeichenfolgen

Abb. 1–1

Wissen – Pragmatik Verwendung von Zeichenfolgen

Semiotisches Dreieck (in Anlehnung an [Hinrichs 2002, S. 27])

Auf syntaktischer Ebene werden lediglich die Zeichen sowie ihre mathematisch­statistischen Beziehungen untereinander (z.B. relative Häufigkeit innerhalb bestimmter Grundstrukturen) untersucht, ohne dabei auf die Bedeutung der Zeichen einzugehen. Diese maschinenlesbaren Zeichenfolgen (Daten) bilden somit die Informationen der realen Welt ab. Wird den Daten Bedeutung hinzugefügt, gelangt man auf die semantische Ebene, d.h., die Daten werden in einem bestimmten Kontext gesehen, und man spricht von Information. Auf der pragmatischen Ebene steht der direkte Benutzer (Interpreter) im Mittelpunkt der Untersuchungen, d.h., hier spielt die Wirkung von Information auf die sie verarbeitenden Verwender (Menschen, Maschinen) eine wichtige Rolle. Somit kommt die pragmatische Ebene der Wirklichkeit am nächsten, indem sie sich über die ersten zwei Ebenen hinausgehend noch mit Fragen der jeweiligen Absicht und des Werts für den einzelnen Benutzer befasst. Erst dann wird aus der Information Wissen. Aus Gründen der besseren Lesbarkeit bezieht sich in den nachfolgenden Kapiteln dieses Buches der Begriff Datenqualität sowohl auf die Qualität der Daten als auch auf die Qualität der Informationen.

1.2 Qualität

1.2

5

Qualität

Der Begriff Qualität stammt ab vom lateinischen »qualitas« und bedeutet Eigenschaft oder Beschaffenheit. Ursprünglich weder positiv noch negativ belegt, wird der Begriff in der Umgangssprache automatisch als positiv angesehen. Die Suche nach einer einheitlichen Definition führt zu einer Vielzahl von Definitions­ und Interpretationsversuchen. Eine allgemein akzeptierte Begriffsbeschreibung ist die DIN­Norm 55 350. Danach ist die »Qualität die Gesamtheit von Eigenschaften und Merkmalen eines Produktes oder einer Tätigkeit, die sich auf deren Eignung zur Erfüllung festgelegter oder vorausgesetzter Erfordernisse beziehen« (vgl. [DIN 55350]). Einer der ersten Systematisierungsansätze geht auf Garvin (vgl. [Garvin 1984, S. 40ff.]) zurück, der fünf generelle Qualitätsvorstellungen unterscheidet: ■ ■ ■ ■ ■

Produktorientierter Ansatz Anwenderorientierter Ansatz Prozessorientierter Ansatz Wertbezogener Ansatz Transzendenter Ansatz

Die produktbezogene Sicht entspricht einem objektiven Qualitätsbegriff, weil Qualität als eine messbare, genau spezifizierbare Größe, die das Produkt beschreibt, gesehen wird. Qualität stellt dabei eine objektive Größe dar, die unabhängig von subjektiven Wahrnehmungen bestimmt werden kann, d.h., dieser Ansatz bezieht sich nur auf das Endprodukt, unabhängig von den Kunden (Benutzern). Qualitätsdifferenzen lassen sich damit auf die Unterschiede in den Produkteigenschaften zurückführen. Der kunden­ oder anwenderbezogene Ansatz hingegen definiert die Qualität eines Produkts über den Produktnutzer, und somit entscheidet ausschließlich der Kunde, inwieweit das Produkt der geforderten Qualität entspricht (subjektive Beurteilung des Kunden). In die amerikanische Literatur hat dieser Ansatz Eingang über die Definition »fitness for purpose« oder »fit for use« gefunden. Dabei können verschiedene Endbenutzer unterschiedliche Bedürfnisse haben, sodass die Qualität des gleichen Produkts unterschiedlich bewertet werden kann. Beim Herstellungsbezug (prozessorientierter Ansatz) wird angenommen, dass Qualität dann entsteht, wenn der Herstellungsprozess optimal und kontrolliert verläuft und alle Vorgaben (Produktspezifikationen) eingehalten werden. Abweichungen von dem definierten Prozess werden als Qualitätsverlust angesehen. Der wertbezogene Ansatz betrachtet Qualität unter Kostengesichtspunkten. Ein Produkt ist dann von hoher Qualität, wenn die Kosten und die empfangene Leistung in einem akzeptablen Verhältnis stehen. Der transzendente Ansatz kennzeichnet Qualität als vorgegebene Vortrefflichkeit, Einzigartigkeit oder Superlativ. Qualität wird als Synonym für hohe Standards und Ansprüche angesehen. Dieser Grundgedanke setzt ein philosophi-

6

1 Datenqualität

sches Verständnis voraus, das davon ausgeht, dass Qualität nicht messbar, sondern nur erfahrbar ist. Dieser Ansatz ist für den hier zu betrachtenden Kontext von Business Intelligence nicht geeignet. Auch wenn die hier beschriebenen Ansätze für die Fertigungsindustrie entwickelt wurden, lassen sie sich ohne Weiteres auf den Bereich der Datenqualität übertragen, wie die folgenden Analogien zeigen (vgl. [Wang/Ziad/Lee 2001, S. 3f.]. Ein Datenverarbeitungsprozess kann auch als Herstellungsprozess im Sinne der Fertigungsindustrie gesehen werden. Die Datenquellen (Lieferanten), die die Rohdaten (Rohmaterialien) bereitstellen, bilden den Ausgangspunkt der Wertschöpfungskette. Sie werden im Zuge der Integration/Transformation (Produktionsprozess) bearbeitet. Das Ergebnis des Prozesses sind die Datenprodukte, die den Datenbeziehern (Kunden) zu Auswertungszwecken zur Verfügung gestellt werden. Data Warehousing

Kunden

Datennutzer

Produkte Produktion/Veredelung Rohstoffe

Qualitätsmanagement

Industrielle Fertigung

Lieferanten Abb. 1–2

Datenprodukte Produktion/Veredelung Rohstoffe Lieferanten

Analogie zwischen industrieller Fertigung und Datenverarbeitung (Data Warehousing) (in Anlehnung an [Grimmer/Hinrichs 2001, S. 72])

Der wesentliche Unterschied liegt im Betrachtungsgegenstand sowie dessen Qualitätsmerkmalen. Im industriellen Fertigungsprozess werden physische Produkte erstellt, die Merkmale wie Haltbarkeit, Länge und Gewicht aufweisen. Im dargestellten Kontext der Datenverarbeitung entspricht das Produkt einem bestimmten Ausschnitt des Datenbestands, auch als Datenprodukt (gleichbedeutend mit einem Datensatz) bezeichnet. Zur Bestimmung der Qualität wird einem Produkt eine Menge von Merkmalen zugeordnet. Ein Merkmal ist dabei eine Eigenschaft, die zur Unterscheidung von Produkten in qualitativer oder quantitativer Hinsicht herangezogen werden kann (vgl. [Behme 2002, S. 52]). Während in der Industrie der Qualitätsbegriff seit Jahrzehnten einen wichtigen Platz einnimmt, taucht der Begriff Datenqualität erst Mitte der 1990er­Jahre vermehrt auf. Die Vorgaben zu Datenqualität liegen damit in ihrer Entwicklung hinter den im Kontext der industriellen Fertigung entwickelten Standards hinsichtlich Qualität deutlich zurück.

1.3 Datenqualität

1.3

7

Datenqualität

Es gilt nun, aus den obigen allgemeinen Daten­ und Qualitätsdefinitionen den Begriff der Datenqualität abzuleiten. Helfert hat die in der Literatur vorhandenen Ansätze zur Definition von Datenqualität untersucht und einander gegenübergestellt (vgl. [Helfert 2002, S. 69ff.] und [Helfert 2000, S. 62ff.]). Das Ergebnis dieser Untersuchung zeigt, dass der Anwender das Qualitätsniveau festlegt und damit im Kontext der Datenverarbeitung ausschließlich der anwenderorientierte Ansatz (vgl. [Müller 2000, S. 15; English 1999, S. 52ff.]) sinnvoll ist. Datenqualität wird daher nach Würthele definiert als »mehrdimensionales Maß für die Eignung von Daten, den an ihre Erfassung/Generierung gebundenen Zweck zu erfüllen. Diese Eignung kann sich über die Zeit ändern, wenn sich die Bedürfnisse ändern« (vgl. [Würthele 2003, S. 21]). Diese Definition macht deutlich, dass die Qualität von Daten vom Zeitpunkt der Betrachtung sowie von dem zu diesem Zeitpunkt an die Daten gestellten Anspruchsniveau abhängt. Um die Datenqualität letztendlich messbar zu machen, bedarf es objektiver Merkmale (auch Qualitätskriterien genannt), die den Daten (Datenprodukten) zugeordnet werden. Diese werden dabei aufgrund der praktischen Erfahrungen intuitiv definiert, auf Basis von Literaturrecherchen erstellt oder anhand von empirischen Untersuchungen zusammengestellt (vgl. [Helfert 2002, S. 69]). Die Qualitätskriterien müssen messbar sein, damit der jeweilige Erfüllungsgrad durch den Datennutzer ermittelt werden kann. In der Praxis wird es einen hundertprozentigen Erfüllungsgrad der Kriterien nicht geben, vielmehr sind jeweils anwendungs­ oder kundenbezogene Anspruchsniveaus (Sollwerte) zu definieren, an denen die Datenqualität gemessen wird. Beispielsweise gelten für Quartals­ oder Jahresbilanzen im Bankenbereich, die kurzfristig nach Ablauf des jeweiligen Zeitraums an die Aufsichtsbehörden übermittelt werden, sehr hohe Ansprüche an die Genauigkeit und Aktualität. Dagegen sind bei Auswertungen zum Kundenverhalten geringere Anspruchsniveaus akzeptabel. Tabelle 1–1 zeigt eine Übersicht über häufig genannte Datenqualitätskriterien (DQ­Kriterien) in alphabetischer Reihenfolge (in Anlehnung an [Helfert/Herrmann/Strauch 2001, S. 7]).

8

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

1 Datenqualität

Aktualität Allgemeingültigkeit Alter Änderungshäufigkeit Aufbereitungsgrad Bedeutung Benutzbarkeit Bestätigungsgrad Bestimmtheit Detailliertheit Effizienz Eindeutigkeit Fehlerfreiheit Flexibilität Ganzheit Geltungsdauer Genauigkeit Glaubwürdigkeit Gültigkeit Handhabbarkeit

Tab. 1–1

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Integrität Informationsgrad Klarheit Kompaktheit Konsistenz Konstanz Korrektheit Neutralität Objektivität Operationalität Performanz Portabilität Präzision Problemadäquatheit Prognosegehalt Quantifizierbarkeit Rechtzeitigkeit Redundanzfreiheit Referenzielle Integrität Relevanz

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Robustheit Seltenheit Sicherheit Signifikanz Testbarkeit Unabhängigkeit Überprüfbarkeit Verdichtungsgrad Verfügbarkeit Verlässlichkeit Verschlüsselungsgrad Verständlichkeit Vollständigkeit Wahrheitsgehalt Wiederverwendbarkeit Wirkungsdauer Zeitbezug Zeitnähe Zugänglichkeit Zuverlässigkeit

Liste möglicher Datenqualitätskriterien

Im Folgenden wird lediglich auf eine Auswahl der vorgestellten Qualitätskriterien näher eingegangen, da die Liste zum Teil Doppelungen enthält sowie nicht alle Kriterien als besonders geeignet erscheinen (vgl. [Hinrichs 2002, S. 30f.; Zeh 2009, S. 43f.]): Datenqualitätskriterien

Definition

Korrektheit Fehlerfreiheit

Die Attributwerte eines Datensatzes (im Data Warehouse) entsprechen denen der modellierten Entitäten der realen Welt, d.h., die Daten stimmen mit der Realität überein.

Konsistenz

Die Attributwerte eines Datensatzes weisen keine logischen Widersprüche untereinander oder zu anderen Datensätzen auf. Inkonsistente Daten innerhalb der operativen Systeme führen zu massiven Glaubwürdigkeitsproblemen in den analytischen Systemen.

Zuverlässigkeit Nachvollziehbarkeit

Die Attributwerte sind vertrauenswürdig, d.h., die Entstehung der Daten ist nachvollziehbar. Insbesondere bei externen Daten ist auf die Zuverlässigkeit der Quellen zu achten. Aber auch innerhalb des Data Warehouse müssen die verschiedenen Transformationen der Daten nachvollziehbar sein. Dies beginnt bei der Erfassung der Daten und geht bis zur Erstellung der Berichte in den analytischen Systemen.

➝

1.3 Datenqualität

9

Datenqualitätskriterien

Definition

Vollständigkeit

Die Attributwerte eines Datensatzes sind mit Werten belegt, die semantisch vom Wert NULL (unbekannt) abweichen. Eine andere Definition bezieht sich auf den modellierten Ausschnitt der Welt. Alle wichtigen Entitäten, Beziehungen und Attribute müssen im System repräsentiert sein. Vollständigkeit beschreibt auch die generelle Verfügbarkeit von Inhalten, die der Anwender benötigt, um seine Arbeit überhaupt durchführen zu können. Dies behandelt die Frage, ob beispielsweise alle Datenbereiche in den Business-Intelligence-Systemen integriert sind, um die Anforderungen zu erfüllen. Des Weiteren beschreibt dieses Kriterium auch, ob die Daten komplett im ELT-Prozess oder im Fehlerfall in das Data Warehouse übernommen werden. Besonders schwierig ist dies beispielsweise bei tagesaktuellen Lieferungen aus verschiedenen Zeitzonen.

Genauigkeit

Abhängig vom jeweiligen Kontext liegen die Daten in der geforderten Genauigkeit (z.B. Anzahl Nachkommastellen) vor.

Aktualität Zeitnähe Zeitbezug

Alle Datensätze entsprechen jeweils dem aktuellen Zustand der modellierten Welt und sind damit nicht veraltet. Die Daten bilden die tatsächlichen Eigenschaften des Objekts zeitnah ab. Mangelnde Aktualität kann einerseits aus der Frequenz der Ladezyklen resultieren (z.B. wöchentlich statt täglich) oder durch die verspätete Pflege der Daten bereits im operativen System (z.B. keine regelmäßige Neubewertung von Sicherheiten).

Redundanzfreiheit

Innerhalb der Datensätze dürfen keine Duplikate vorkommen. Als Duplikate werden hierbei Datensätze verstanden, die dieselbe Entität in der realen Welt beschreiben. Sie müssen aber nicht notwendigerweise in allen Attributwerten übereinstimmen.

Relevanz

Der Informationsgehalt einer Datensatzmenge bezüglich eines definierten Anwendungskontextes deckt sich mit dem Informationsbedarf einer Anfrage.

Einheitlichkeit

Die Repräsentationsstruktur einer Menge von Datensätzen ist einheitlich, d.h., sie werden fortlaufend gleich abgebildet.

Eindeutigkeit

Ein Datensatz muss eindeutig interpretierbar sein, d.h., die vorhandenen Metadaten müssen die Semantik des Datensatzes festschreiben.

Verständlichkeit

Die Datensätze stimmen in ihrer Begrifflichkeit und Struktur mit den Vorstellungen des Fachbereichs überein.

Schlüsseleindeutigkeit

Die Primärschlüssel der Datensätze sind eindeutig.

Referenzielle Integrität

Im relationalen Modell muss jeder Fremdschlüssel eindeutig auf einen existierenden Primärschlüssel referenzieren.

Tab. 1–2

Definition ausgewählter Datenqualitätskriterien

Die beiden letzten Kriterien stellen eine spezielle Ausrichtung auf das relationale Datenbankmodell dar. Aufgrund der sehr starken Verbreitung des relationalen Modells ist diese Sichtweise legitim. Die sechs DQ­Kriterien Korrektheit, Konsistenz, Zuverlässigkeit, Vollständigkeit, Zeitnähe und Relevanz werden in Abschnitt 2.3 nochmals aufgegriffen und im Kontext Business Intelligence näher betrachtet.

10

1 Datenqualität

Das folgende Beispiel (in Anlehnung an [Leser/Naumann 2007, S. 354f.]) aus dem BI­Umfeld verdeutlicht die Relevanz der DQ­Kriterien Vollständigkeit, Zeitnähe und Glaubwürdigkeit. Als Entscheidungsgrundlage für das Management eines Industrieunternehmens werden regelmäßig aus einem Data Warehouse Berichte erstellt: ■ Diese Berichte müssen Daten aus allen Werken vollständig abdecken, sonst sind die Produktionszahlen ungenau. ■ Die Berichte müssen zeitnah abrufbar sein, sonst kann nicht schnell genug bei einer veränderten Absatzlage reagiert werden. ■ Wenn die Zahlen in den Berichten nicht stimmen, weil in der Vergangenheit nachträglich viele Daten manuell geändert wurden, sind die Kennzahlen unglaubwürdig, und die Akzeptanz der BI­Lösung sinkt. Dieses Beispiel zeigt deutlich, dass Datenqualität stets mehrdimensional zu betrachten ist. Wird die Datenqualität auf ein einzelnes Kriterium (wie beispielsweise Vollständigkeit) reduziert, wird die Datenqualität von den Anwendern dennoch gefühlt als schlecht wahrgenommen, wenn veraltete Daten vorliegen (DQKriterium Zeitnähe). Werden die hier vorgestellten DQ­Kriterien strukturiert in Gruppen zusammengefasst, spricht man von einem Qualitätsmodell. Ein wesentliches Charakteristikum eines solchen Modells ist die Zerlegungssystematik. In der Literatur sind diverse Systematiken zu finden (vgl. [Wang/Strong 1996, S. 20; Redman 1996, S. 267]), die bei genauerer Betrachtung gewisse Unstimmigkeiten bezüglich der Zerlegung aufweisen. Ziel dieses Kapitels ist es jedoch nicht, diese Lücke durch ein eigenes Modell zu schließen. Daher sei an dieser Stelle beispielhaft zunächst das Qualitätsmodell von Hinrichs vorgestellt, das sich aus den beschriebenen Qualitätskriterien ableiten lässt: Datenqualitätskriterien Glaubwürdigkeit

Nützlichkeit

Interpretierbarkeit

Schlüsselintegrität (relational)

Korrektheit

Vollständigkeit

Einheitlichkeit

Schlüsseleindeutigkeit

Konsistenz

Genauigkeit

Eindeutigkeit

Referenzielle Integrität

Zuverlässigkeit

Zeitnähe

Verständlichkeit

Redundanzfreiheit Relevanz

Abb. 1–3

Taxonomie von Datenqualitätskriterien (vgl. [Hinrichs 2002, S. 30])

Diesem eher aus theoretischer Sicht entstandenen Qualitätsmodell stellt die Deutsche Gesellschaft für Informations­ und Datenqualität (DGIQ) eine Kategorisierung gegenüber, die aus einer Studie (vgl. [Wang/Strong 1996]) durch Befragung von IT­Anwendern hervorgegangen ist (siehe Abb. 1–4).

1.4 Datenqualitätsmanagement

11

Quelle: DGIQ IQ-Definition – 2007

System Zugänglichkeit

Bearbeitbarkeit

Aktualität Wertschöpfung

Nutzung

Vollständigkeit Angemessener Umfang

systemunterstützt zweckabhängig

hohes Ansehen Fehlerfreiheit

IQ

inhärent Objektivität

Inhalt

Glaubwürdigkeit Relevanz Ver- Übersicht- einheitliche eindeutige Darstellung Auslegbarkeit ständlichkeit lichkeit

darstellungsbezogen

Darstellung Abb. 1–4

Taxonomie von Datenqualitätskriterien (vgl. [DGIQ 2007])

Ergänzend zu den bereits beschriebenen Kriterien sind vor allem die Zugänglichkeit und die Bearbeitbarkeit hinzugekommen. Unter Zugänglichkeit wird die einfache Abrufbarkeit der Daten für den Anwender verstanden. Inwieweit die Daten leicht für unterschiedliche Zwecke zu bearbeiten sind, wird mit dem Kriterium Bearbeitbarkeit ausgedrückt.2 Die Identifikation und Klassifikation von Datenqualitätskriterien allein reicht für die Messung der Datenqualität allerdings nicht aus. Was fehlt, sind konkrete, numerische Metriken. Nur darüber kann später geprüft werden, ob die Verbesserungsmaßnahmen auch wirkungsvoll waren (»You cannot control what you cannot measure« (vgl. [deMarco 1982])). Die Anwendung geeigneter Metriken ermöglicht eine Quantifizierung von Datenqualitätskriterien und ist somit die Voraussetzung zur Bildung von Qualitätskennzahlen. In Kapitel 7 wird genauer auf die Bildung dieser Kennzahlen auf Basis ausgewählter DQ­Kriterien eingegangen.

1.4

Datenqualitätsmanagement

Das nachträgliche Bereinigen von Daten, das durch eine Vielzahl an existierenden Werkzeugen zur Fehlererkennung und ­korrektur erleichtert wird, ist im Vergleich zu qualitätssichernden Maßnahmen um den Faktor 5–10 teurer (vgl. [Hankins 1999]). Trotzdem finden in den Unternehmen kaum präventive Maßnahmen statt, sondern es wird erst beim Auftreten von Problemen reagiert (vgl. [Otto et al. 2008, S. 215f.]). Dieses reaktive Vorgehen führt u.a. dazu, dass Risiken nicht rechtzeitig erkannt werden oder gesetzliche Auflagen nicht zu erfüllen sind (siehe Abschnitt 3.2). Erst langsam kommt es in den Unternehmen zu einem Sinneswandel und 2.

Eine ausführliche Beschreibung der einzelnen Kriterien findet sich in [Rohwedder et al. 2011, S. 25ff.].

12

1 Datenqualität

somit zu einem proaktiven Ansatz mit einem Datenqualitätsmanagement, das von vornherein auf qualitativ hochwertige Daten setzt und kostenintensive nachträgliche Bereinigen minimiert. Das dazu erforderliche Qualitätsmanagement umfasst nach DIN ISO 8402 »alle Tätigkeiten der Gesamtführungsaufgabe, die die Qualitätspolitik, ­ziele und ­verantwortung festlegen sowie durch Mittel wie Qualitätsplanung, ­lenkung, ­sicherung und ­verbesserung im Rahmen des Qualitätsmanagementsystems verwirklichen« (vgl. [DIN ISO 8402]). Hieraus wird deutlich, dass das Qualitätsmanagement in der Gesamtstrategie des Unternehmens verankert sein muss. Diese aus heutiger Sicht sinnvolle Definition entwickelte sich in der Historie seit Beginn des 20. Jahrhunderts gemäß Abbildung 1–5 in vier Stufen: Total Quality Management Total Quality Control Qualitätssicherung Qualitätskontrolle › Zunehmende Arbeitsteilung › Produkt- und Technikorientierung › Endkontrolle

Abb. 1–5

› Prozess- und produktionsorientierte Qualitätskontrolle › Technikorientierung › Statistische Methoden

› Ausweitung der Qualitätssicherung auf alle qualitätsrelevanten Prozesse › Kundenorientierung

› Ganzheitliche Qualitätskonzeption › Kundenorientierung (extern und intern) › Mitarbeiterorientierung › Proaktive Qualitätssicherung

Entwicklungsstufen des Qualitätswesens (in Anlehnung an [Wolf 1999, S. 63])

In der ersten Stufe (Qualitätskontrolle) wurde eine klare Trennung zwischen der Produktion und der Qualitätskontrolle vorgenommen, d.h., festgestellte Mängel konnten erst nachträglich am bereits fertigen Produkt erkannt und bereinigt werden. Erst in den 1930er­Jahren wurde die Qualitätskontrolle in den Produktionsprozess integriert. Damit war es möglich, die Fehler während des Prozesses am Entstehungsort zu beheben (Qualitätssicherung). In den 1960er­Jahren setzte sich zunehmend die Erkenntnis durch, dass sich durch die prozessbegleitenden Maßnahmen nicht alle Fehlerquellen abstellen lassen. Daher wurde das Qualitätswesen sowohl auf die vorgelagerten Bereiche wie Forschung & Entwicklung oder Konstruktion als auch auf die nachgelagerten Bereiche wie den Vertrieb ausgedehnt. Geprägt wurde diese Stufe durch Feigenbaum (vgl. [Feigenbaum 1961]), der den Begriff »Total Quality Control« einführte. Die ständige Weiterentwicklung der Konzepte führte zu dem heute bekannten, ganzheitlichen Qualitätsmanagement (Total Quality Management), das in der Gesamtstrategie des Unternehmens integriert sein muss.

1.4 Datenqualitätsmanagement

13

Für den Aufbau eines Qualitätsmanagements (QM) sind vor allem die Bereiche Qualitätsplanung und ­lenkung von Interesse (vgl. [English 1999, S. 70ff.]). Aufgabe der Qualitätsplanung ist es, die Qualitätsanforderungen an den Prozess und das Produkt in überprüfbarer Form festzulegen. Dies beinhaltet die Auswahl von Qualitätskriterien sowie die Festlegung von Sollwerten (Anspruchsniveaus) für diese Kriterien. Die Qualitätslenkung, zu der Arbeitstechniken und Tätigkeiten gehören, die zur Erfüllung der Qualitätsanforderungen angewendet werden, setzt die Qualitätsplanung um. Dazu müssen geeignete Prozesse identifiziert und Maßnahmen zum Erreichen einer Prozesskonformität ergriffen werden. Produkt­ und Prozessqualität müssen im Rahmen der Qualitätslenkung gemessen werden (vgl. [Helfert 2002, S. 40ff.]). Die Qualitätssicherung umfasst vor allem organisatorische Maßnahmen, die nach außen sicherstellen sollen, dass im Unternehmen ein Qualitätsmanagement existiert. Die Ausführungen zum Qualitätsmanagement lassen sich auf ein Datenqualitätsmanagement (DQM) für den Datenverarbeitungsprozess übertragen. Besonders erwähnenswert sind in diesem Zusammenhang die Arbeiten von Wang (vgl. [Wang 1998; Wang/Strong 1996]) am Massachusetts Institute of Technology (MIT), der eine Adaption der QM­Konzepte unter der Bezeichnung Total Data Quality Management (TDQM) entwickelte. Der Grundgedanke seiner Methode ist der sogenannte Plan­Do­Check­Act­Zyklus, der die Ideen von Deming als Regelkreis beschreibt (siehe Abb. 1–6). Planen (plan) Ausführen (do)

Verbessern (act) Überprüfen (check)

Abb. 1–6

Plan-Do-Check-Act-Zyklus (vgl. [Redman 1996])

14

1 Datenqualität

Redman (1996)

English (1999)

Name der Strategie

Data Quality Policy/Program, Managing Information Chains

Total Quality data Management, Information Quality Environment: the 14 Points of Information Quality

Grundgedanke

Die Etablierung einer UnterDas Managen der Informationskette als Zyklus mit einem nehmenskultur der Informationsqualität als Basis für Prozessverantwortlichen. DatenqualitätsprozessDabei werden die Kundenverbesserungen. bedürfnisse durch ein Datenqualitätsprogramm und feststehende Grundsätze für Datenqualität berücksichtigt.

Die Kultur ist angelehnt an die Theorien des Total Quality data Management und Demings 14-PunkteProgramm für Change Management.

Einzelne Methoden

Error detection and correction, Statistical Quality Control, Measurement-System

Statt einzelner Methoden werden unterschiedliche Prozessabläufe vorgestellt, deren Aktivitäten man schrittweise folgen kann.

Praxisbeispiel

AT & T, Telstra Corporation Limited

Kein Beispiel, an dem die Gesamtstrategie durchgespielt wird, es werden nur einzelne Phasen oder Schritte beispielhaft erläutert

Tab. 1–3

Vergleich ausgewählter DQM­Strategien

Der Zyklus beginnt mit der Definition der Datenqualitätsziele (Plan). Anschließend wird der Istzustand der Daten aufgenommen und analysiert (Do, Check). Im letzten Schritt muss durch den Einsatz geeigneter Methoden die Datenqualität verbessert werden (Act). Das Konzept des TDQM wurde u.a. von English (vgl. [English 1999, S. 69ff.]) weiterentwickelt, der eine Vorgehensweise zur kontinuierlichen Datenqualitätsverbesserung einführte (siehe Abb. 1–7). Datenumstrukturierung & -bereinigung Bestimmung der Datenschema- & Systemqualität

1

Bestimmung der Datenqualität

2

Bestimmung der Kosten mangelhafter Datenqualität

3

4

Optimierung der Datenverarbeitungsprozesse

5

Abb. 1–7

Total-Quality-data-Management-Methodik (TQdM) nach English (vgl. [English 1999, S. 70])

1.4 Datenqualitätsmanagement

15

Hinrichs (2002)

Helfert (2002)

Olson (2003)

CLIQ – Data Cleansing mit intelligentem Qualitätsmanagement

Proaktives Datenqualitätsmanagement

Data Quality Assurance Program

Vorgehensmodell für den Datenintegrationsprozess im DWH mit fester Reihenfolge der Integrationsphasen. In Anlehnung an die ISO 9001:2000 werden Datenqualitätsmaßnahmen eingebunden.

Die operative Ebene der Qualitätsplanung und -lenkung wird in die Gesamtführungsaufgabe integriert, die Datenqualitätspolitik, -ziele und Verantwortung für Datenqualität festlegt.

Programm aus drei zu kombinierenden Komponenten:

Sämtliche Methoden werden innerhalb des Integrationsprozesses vorgestellt, wie z. B. statistische Prozesskontrollen regelbasierte Prüfungen, Duplikatbereinigung.

Forderung der Bereitstellung von Methoden und Maßnahmen für die Ausführung der Datenqualitätsprozesse. Statistische Methoden, Data Mining zur Musterbeschreibung.

Data-Profiling-Methoden zur Generierung korrekter Metadaten, zur Aufdeckung von ungenauen oder falschen Daten: beispielsweise Analyse der Spalteneigenschaften, Strukturanalyse

Data Quality Mining (DaimlerChrysler AG)

Beschreibung des Konzepts eines operativen Datenqualitätsmanagements für Crédit Suisse Financial Services

Dimension der Datenqualität, Methodik und Aktivitäten. Fokus sind jedoch nicht alle Dimensionen von Datenqualität, sondern die Genauigkeit der Daten.

Neben der bereits erwähnten Erweiterung gibt es in der wissenschaftlichen Literatur eine Vielzahl von Arbeiten, die sich mit dem Thema Datenqualitätsmanagement, basierend auf den Gedanken von Wang, auseinandersetzen. Die wichtigsten sind in Tabelle 1–3 aufgeführt (vgl. [Behme/Nietzschmann 2005, S. 46]). Bei der Betrachtung der einzelnen Strategien zeigt sich, dass entweder ein eher technisch orientierter Ansatz gewählt wurde oder der Fokus auf dem Managementkonzept liegt. Einig ist man sich aber, dass die technisch orientierten Ansätze nicht ohne ein begleitendes Managementkonzept möglich sind. Für die Umsetzung eines Datenqualitätsmanagements für ein Data-Warehouse-System lassen sich drei Bereiche identifizieren (vgl. [Helfert/Herrmann/ Strauch 2001, S. 19]): ■ Datenqualität als Unternehmenskultur und ­philosophie ist als Verpflichtung des Managements anzusehen. ■ Ein Qualitätsmanagementsystem (nach ISO 8402) ist zu etablieren, das in allen Bereichen geeignete Prozesse, Richtlinien, Pläne sowie Test­ und Prüfverfahren aufsetzt, um die geforderte Datenqualität dauerhaft zu erreichen.

16

1 Datenqualität

■ Zur Ausübung der Qualitätsprozesse sind geeignete Methoden, Verfahren und Werkzeuge zur Verfügung zu stellen. Auf Basis der bestehenden Datenqualitätsmanagement­Ansätze haben Otto u.a. einen Ordnungsrahmen entwickelt, der dem Ansatz des Business Engineering folgt (vgl. [Otto et al. 2008, S. 215ff.]). Dieser Ordnungsrahmen setzt sich aus den folgenden sechs Gestaltungselementen zusammen: ■ ■ ■ ■ ■ ■

Datenqualitätsstrategie Führungssystem Data Governance Datenmanagement­Prozesse Datenarchitektur und Datenhaltung Systemunterstützung

Den Aufbau des Ordnungsrahmens zeigt Abbildung 1–8. Die Datenqualitätsstrategie befindet sich auf der Ebene »Strategie«, wodurch die enge Verzahnung mit der Unternehmensstrategie deutlich wird. Zwischen den Ebenen »Strategie« und »Organisation« liegt das Führungssystem, das die Umsetzung der Strategie steuert. Die Ebene »Organisation« enthält zum einen die Data Governance (Zuordnung der Aufgaben und Verantwortlichkeiten im Rahmen des DQM) sowie die Datenmanagement­Prozesse (umfasst die Prozesse Anlage, Pflege und Ausphasen der Daten). Auf der Ebene »Systeme« wird im Rahmen der Datenarchitektur der Geltungsbereich für einzelne Datenobjekte definiert (z.B. globale versus lokale Lieferantennummer). Außerdem legt die Datenarchitektur fest, welche Rolle die Systeme bei der Anlage, Änderung und Verteilung der Stammdaten spielen. Strategie

Datenqualitätsstrategie Führungssystem

Organisation

Systeme

Data Governance

Datenmanagement-Prozesse

Datenarchitektur und Datenhandling

Systemunterstützung

Abb. 1–8

Ordnungsrahmen für das Datenqualitätsmanagement (vgl. [Otto et al. 2008, S. 218])

1.5 Zusammenfassung

1.5

17

Zusammenfassung

Die Ausführungen in diesem Kapitel machen deutlich, dass die Anforderungen an die Datenqualität jeweils von dem Unternehmen und insbesondere von den Anwendern der Daten abhängen. Eine allgemein gültige Festlegung, was eine gute Datenqualität im Rahmen von Business­Intelligence­Lösungen ausmacht, gibt es nicht. Um Datenqualität aber nicht nur als abstraktes Gebilde stehen zu lassen, wurde mithilfe der Datenqualitätskriterien eine Operationalisierung vorgenommen. Die Aufgabe im konkreten Projekt besteht darin, eine Auswahl dieser Kriterien zu treffen und jeweils auf das Unternehmen und den Projekthintergrund passende Anspruchsniveaus festzulegen und diese zu realisieren. Insgesamt wird auch deutlich, dass Datenqualität keine Einmal­Aktion im Rahmen eines Projekts ist, sondern vielmehr als eine permanente Aufgabe angesehen werden muss. Dazu ist bei den Mitarbeitern ein Bewusstsein für Datenqualität zu schaffen sowie die Motivation, diese auch herzustellen. Nur so kann langfristig und nachhaltig eine bessere Datenqualität sichergestellt werden.

18

1 Datenqualität

19

2

Ausprägungen und Ursachen schlechter Datenqualität

Die Zielsetzung dieses Kapitels ist es, ein grundlegendes Verständnis für wesentliche Ursachen und Ausprägungen schlechter Datenqualität zu schaffen. Die Ausführungen beziehen sich dabei auf den in Kapitel 1 eingeführten Begriff der anwenderorientierten Qualitätsvorstellung. Wie in diesem einführenden Kapitel beschrieben, basiert die nachgefragte Qualität von Daten einerseits auf den subjektiven Anforderungen der Anwender und hängt andererseits wesentlich von der Anforderung der beabsichtigten Anwendung ab. Regulatorische Anforderungen haben oftmals andere Qualitätsansprüche als z.B. Marketing-Anwendungen. Auf Business-Intelligence-Projekte bezogen ist diese Sichtweise der anwenderorientierten Qualitätsvorstellung sicherlich am besten geeignet, da sich die Qualität der Daten unmittelbar auf die dort entwickelten Anwendungen auswirkt. Dieses Kapitel behandelt nun im Folgenden die Ursachen und Auswirkungen schlechter Datenqualität basierend auf Erfahrungen aus solchen Projekten. Business-Intelligence-Projekte und deren Ergebnisse stellen in vielen Fällen den erstmaligen Kontakt der Anwender mit den Daten dar; den Anwendern eröffnet dies oftmals eine komplett neue Sichtweise auf die Daten bzw. ermöglicht erstmals eine Verknüpfung verschiedener Bestände von Daten. Damit einher geht jedoch die Unsicherheit bezüglich der Datenqualität aufgrund fehlender Vergleichsmöglichkeiten bzw. großer Datenvolumina, die manuell nicht mehr überprüfbar sind. Dies kann in letzter Konsequenz dazu führen, dass die Akzeptanz von Business-Intelligence-Projekten massiv unter schlechter Datenqualität oder auch nur unter subjektiv wahrgenommenen Datenqualitätsproblemen leidet (vgl. [Friedman/Richardson 2008]). Business-Intelligence-Anwendungen sind zudem meist das letzte Glied in der Kette der Datenaufbereitung und -bereitstellung. Aus diesem Grund scheitern Business-Intelligence-Projekte oftmals wegen fehlender Akzeptanz durch die Anwender. Daher ist es für eine erfolgreiche Umsetzung solcher Projekte unumgänglich, bei den Projektsponsoren und potenziellen Anwendern frühzeitig ein Verständnis für die Ursachen und Auswirkungen schlechter Datenqualität aufzubauen.

20

2 Ausprägungen und Ursachen schlechter Datenqualität

Die Capgemini-Studie »IT Trends 2011« (vgl. [Capgemini 2011]) zeigt, dass Datenqualität für Unternehmen zu den Top-5-Themen im IT-Umfeld gehört. Im Rahmen dieser Studie wurde Datenqualität bereits das fünfte Jahr in Folge als eines der am höchsten priorisierten Themen genannt. IT-seitig ist also laut dieser Studienreihe die Wichtigkeit von Datenqualität für die erfolgreiche Umsetzung von IT- und somit letztendlich auch von Geschäftsinitiativen zumindest weitestgehend bekannt. Eine Sensibilisierung der Endanwender für die Ursachen und Auswirkungen schlechter Datenqualität und in letzter Konsequenz für den Umgang damit ist als ein wesentlicher Schritt zum Projekterfolg dringend zu empfehlen. Diese Problematik ist bereits im Vorfeld von Projekten zu berücksichtigen, und es sind Maßnahmen aufzuzeigen, um negativen Auswirkungen entgegenzusteuern. Es kommt dabei allerdings erschwerend hinzu, dass die Ursachen schlechter Datenqualität sehr vielfältig sind und deren Vermeidung oftmals auch unter größtmöglichen Anstrengungen nicht immer durchgängig möglich ist. Auch aus diesem Grund ist eine dahingehende frühzeitige Sensibilisierung der Anwender ein wichtiger Baustein für die erfolgreiche Umsetzung von Business-IntelligenceProjekten.

2.1

Geschäftstreiber

Eine schlechte oder auch nur unzureichende Datenqualität hat Auswirkungen auf viele unterschiedliche Bereiche in Unternehmen bzw. in Organisationen1 generell. Eine Verbesserung der Datenqualität ist deshalb ein wünschenswertes Unterfangen, das prinzipiell auf wenig Widerstand trifft. In der Praxis ist die Sicherung der Datenqualität jedoch eine komplexe und oftmals sehr aufwendige Angelegenheit. Budget- und Ressourcenbeschränkungen sind in den meisten Organisationen die Realität. Es sind daher in jedem Fall Kosten-Nutzen-Betrachtungen anzustellen, um eine Argumentation hinsichtlich der Mittelbereitstellung aufzubauen. Diese Kosten-Nutzen-Betrachtungen können dabei sowohl quantitativer als auch qualitativer Natur sein (siehe Kap. 3). In diesem Abschnitt sind im Folgenden vier Kategorien2 von Geschäftstreibern beschrieben, die ein aktives Management der Datenqualität erfordern. Diese Geschäftstreiber geben oftmals den initialen Anstoß zur Verbesserung mangelhafter Datenqualität. Zudem erfordern die zunehmende Integration von Geschäftsprozessen und Anwendungen über Abteilungsgrenzen hinweg (und immer öfter auch über Unternehmensgrenzen hinweg) sowie Ansätze wie Serviceorientierte Architektu1. 2.

Es wird im Folgenden meist von Unternehmen gesprochen, das Gesagte gilt allerdings größtenteils für Organisationen aller Art. im Folgenden kurz Geschäftstreiber genannt

2.1 Geschäftstreiber

21

ren (SOA), die Einbindung von Business Intelligence in operative Prozesse (operational BI) und Right Time Business Intelligence saubere Daten. Während einer Right-Time-Datenintegration bleibt schlichtweg keine Zeit mehr für die Durchführung umfassender Datenqualitätsmaßnahmen. Viele Unternehmen gehen derzeit dazu über, mittels Informationen aus Right-Time-Business-IntelligenceAnwendungen operative Geschäftsprozesse zu unterstützen, und erkennen dabei unmittelbar die Wichtigkeit einer entsprechenden hohen Datenqualität. Abbildung 2–1 zeigt nun vier Geschäftstreiber, die direkt durch die Qualität der Daten beeinflusst werden und somit eine der geplanten Anwendung3 entsprechende, akzeptable Datenqualität speziell im Rahmen der Datenbereitstellung durch Business-Intelligence-Anwendungen voraussetzen.

Kosten & Risiken

Wettbewerb

Datenqualität

Compliance

Steuerung

Abb. 2–1

Datenqualität beeinflusst Geschäftstreiber.

Diese vier Geschäftstreiber sind grundsätzlich unabhängig von bestimmten Branchen oder Unternehmen, hängen allerdings oftmals direkt mit Business-Intelligence-Projekten bzw. mit der Datenbereitstellung und Datenverwendung generell zusammen. Aus den diversen Anforderungen dieser Geschäftstreiber heraus entsteht daher in weiterer Folge die Forderung nach einem nachhaltigen und ganzheitlichen Datenqualitätsmanagement.

3.

Die Begriffe »Anwendung« und »System« werden synonym verwendet.

22

2 Ausprägungen und Ursachen schlechter Datenqualität

Compliance

Externe regulatorische Vorgaben sowie die interne Revision erfordern die Definition und die Umsetzung einheitlicher Standards und Mechanismen für ein aktives Datenqualitätsmanagement. Wesentliche Zielsetzung dabei ist die Etablierung unternehmensweiter Richtlinien und Strukturen zur Sicherstellung der Datenqualität bzw. zur Standardisierung des Umgangs mit schlechter Datenqualität und auftretenden Datenqualitätsproblemen. Regulatorische Vorgaben sind zum Beispiel der Sarbanes-Oxley Act, die International Financial Reporting Standards (IFRS) sowie Basel-II-Vorgaben für Finanzdienstleistungen. Im Zuge der jüngsten Turbulenzen auf den Finanzmärkten wurden weitere regulatorische Anforderungen definiert bzw. bereits verabschiedet, die von den Unternehmen zu erfüllen sind (Dodd-Frank Act, Basel III) und die ebenfalls eine entsprechende Qualität der Daten voraussetzen (siehe auch Abschnitt 3.2). Kosten und Risiken

Das Erkennen und die frühzeitige Behebung von Datenqualitätsproblemen sowie ein laufendes aktives Datenqualitätsmanagement reduzieren das tägliche operative Risiko in den Unternehmen. Speziell betrifft das operative Geschäftsprozesse, die auf qualitativ hochwertige Daten aus den Business-Intelligence-Anwendungen4 angewiesen sind. Das aktive Beheben schlechter Datenqualität mindert generell die Projektrisiken und führt zu geringeren Kosten bzw. zu reduzierten Durchlaufzeiten von Projekten (insbesondere auch von Business-Intelligence-Projekten). Besonders betroffen sind dabei die Entwicklungen von Schnittstellen und Datenmigrationen zwischen Anwendungen. Dies ist insbesondere relevant, da die Forderung nach immer agileren und schnelleren Projekten keine Zeit für projektinterne Datenqualitätsmaßnahmen mehr lässt. Während auf der einen Seite eine zu niedrige Eigenkapitalhinterlegung im Finanzsektor aus regulatorischer Sicht problematisch ist, bedeutet auf der anderen Seite eine zu hohe Eigenkapitalhinterlegung erhöhte Kosten für das Unternehmen. In jedem Fall ist die Qualität der Daten daher ein wesentlicher Einflussfaktor für die korrekte Kalkulation. Wettbewerb

Im täglichen Wettbewerb (vgl. [Davenport/Harris 2007]) um den Kunden ist eine dem Verwendungszweck entsprechende Datenqualität Voraussetzung, z.B. für den Erfolg von Kampagnen sowie bei der effizienten Entwicklung neuer Produkte. Für eine Verbesserung der Kundenbeziehung ist eine hohe Qualität der 4.

Trifft prinzipiell auf alle Systeme in Organisationen zu.

2.1 Geschäftstreiber

23

Daten ebenso förderlich (z.B. durch eine korrekte Anrede). Im Customer-ServiceBereich erhöht eine gesicherte Datenqualität zudem die Chancen für ein erfolgreiches Cross Selling von Produkten und Leistungen. Jene Anwendungen, die sich hinter dem Schlagwort Big Data verbergen, fallen insbesondere auch unter diese Kategorie. Speziell sind dies die Verarbeitung und Analyse von unstrukturierten und semistrukturierten Daten zum besseren Verständnis und zur Voraussage des Kundenverhaltens sowie die Integration in die bestehende BI-Architektur der Unternehmen. Dadurch ergeben sich erweiterte Anforderungen an ein aktives Datenqualitätsmanagement (siehe Kap. 6). Speziell zu erwähnen ist in diesem Zusammenhang auch das immer stärkere Aufkommen von mobilen Applikationen und sogenannten Location Based Services (vgl. [Economist 2012a]). Diese Services sind gelinde gesagt unbrauchbar, wenn die auf den Karten dargestellten Informationen nicht eine entsprechende Qualität haben. Steuerung

Für die Unternehmenssteuerung verantwortliche Personen müssen sich auf die Qualität der bereitgestellten Informationen verlassen können, da diese eine unmittelbare Auswirkung auf die Qualität der Entscheidungen im Unternehmen hat. Unter diesen Punkt fallen im Gegensatz zu den kurz- bis mittelfristigen Sichtweisen der anderen Kategorien vor allem Entscheidungen, die die mittel- bis langfristige Ausrichtung des Unternehmens beeinflussen. Merger & Acquisition-Aktivitäten erfordern ebenfalls eine hohe Qualität der Daten, da die erfolgreiche und zugleich effiziente Zusammenführung unterschiedlicher Unternehmen davon abhängig ist. Fazit

Wie einleitend bereits erwähnt, ist die Wahrnehmung der Qualität der Daten durch den jeweiligen Anwender weitestgehend subjektiv bestimmt bzw. durch die beabsichtigte Anwendung vorgegeben. Dieselben Daten können für verschiedene Anwender unterschiedliche Qualität besitzen. Dies kann durchaus bedeuten, dass eine für einen Anwender (z.B. aus dem externen Rechnungswesen/Wirtschaftsprüfer) schlechte Datenqualität einer ausreichenden bis guten Datenqualität für einen anderen Anwender (zum Beispiel aus dem Vertrieb für Kampagnenmanagement) entspricht bzw. auch umgedreht. Diese Unterscheidung ist gerade im Umfeld von Business-Intelligence-Projekten von außerordentlicher Wichtigkeit. Eine 100-prozentige Qualität aller Daten ist praktisch mit vertretbarem Aufwand nicht erreichbar. Der Grad der benötigten Qualität ist daher immer in Abhängigkeit von der beabsichtigten Anwendung zu evaluieren und zu entscheiden. Bei einer mehrfachen Verwendung von Datenbereichen durch verschiedene Anwendungen mit teils unterschiedlichen Daten-

24

2 Ausprägungen und Ursachen schlechter Datenqualität

qualitätsanforderungen ist die unternehmensweite Kommunikation von Datenqualitätsproblemen essenziell (siehe Kap. 4). Eine frühzeitige Verifikation der Qualität der Daten sowie die zeitgerechte Einbindung der betroffenen Anwender und die Einleitung von Gegenmaßnahmen ist daher eine wesentliche Voraussetzung, um die Auswirkungen schlechter Datenqualität auf die diversen Geschäftstreiber in den Griff zu bekommen.

2.2

Ausprägungen schlechter Datenqualität

Wie kann Datenqualität nun ausgedrückt werden? Die oben beschriebenen Geschäftstreiber erfordern jeweils eine bestimmte Qualität der Daten. Die Ausprägungen von als schlecht wahrgenommener Datenqualität lassen sich anhand der bereits in Kapitel 1 definierten Datenqualitätskriterien festmachen. Die in diesem Kapitel ausgewählten Ausprägungen schlechter Datenqualität bzw. deren Auswirkungen in der realen Welt sind insbesondere im Rahmen verschiedener Business-Intelligence-Projekte sehr stark von den jeweiligen Anwendern reklamiert worden. Der Anspruch dieses Kapitels ist nun keineswegs eine generelle Definition und Auflistung aller möglichen Ausprägungen schlechter Datenqualität. Der Fokus liegt hier speziell auf jenen Datenqualitätskriterien, deren Verwendung sich insbesondere in Business-Intelligence-Projekten bewährt hat. Die Darstellung in Abbildung 2–2 beschränkt sich daher auf die wesentlichen Ausprägungen schlechter Datenqualität, dargestellt mittels sechs ausgewählter Datenqualitätskriterien. Die Abbildung zeigt, dass von BI-Projekten und somit auch von den beabsichtigten Anwendungen ein bestimmter Druck zur Sicherstellung einer gewissen Datenqualität ausgeht. Um die entsprechende nachgefragte Datenqualität auch bereitstellen zu können, ist im Kern ein aktives Datenqualitätsmanagement notwendig.

2.2 Ausprägungen schlechter Datenqualität

25

BI-Projekte

Zeitnähe

Vollständigkeit

Relevanz

Datenqualitätsmanagement

Korrektheit

Konsistenz

Zuverlässigkeit

Anwendung

Abb. 2–2

Datenqualitätskriterien aus Sicht der Anwendung

Im Folgenden sollen beispielhaft die Inhalte dieser sechs Datenqualitätskriterien beschrieben werden. Zielsetzung dabei ist es, ein besseres Verständnis für die unterschiedlichen Ausprägungen schlechter Datenqualität im Umfeld von Business-Intelligence-Projekten zu schaffen. Zeitnähe

Zeitnähe hat aus Sicht der Anwender von Business-Intelligence-Systemen grundsätzlich zwei Ausprägungen, die die subjektiven Anforderungen an die Qualität der Daten beeinflussen. Einerseits ist dies der Anlieferungszeitpunkt der Daten aus den Quellsystemen bzw. der Zeitpunkt der Verfügbarkeit der Daten für den Anwender in den Business-Intelligence-Systemen. Daten besitzen aus Sicht der Anwendung dann eine schlechte Qualität, wenn sie nicht zu dem vom Anwender benötigten Zeitpunkt zur Verfügung stehen. Dieses Problem potenziert sich mit der Verknüpfung von Daten verschiedener Bereitstellungszeitpunkte. Die zweite Ausprägung betrifft die Aktualität der angelieferten Daten. Darunter fällt zum Beispiel die Aktualität der Pflege von Telefon- und Adressdaten. Ein anderes aktuelles Beispiel aus dem Einsatzfeld von Banken ist die regelmäßige Neubewertung von Sicherheiten für Kredite.

26

2 Ausprägungen und Ursachen schlechter Datenqualität

Korrektheit

Das Datenqualitätskriterium Korrektheit beschreibt die inhaltliche und formale Komponente der Daten. Korrekte Daten beinhalten die inhaltlich richtigen Informationen in den vordefinierten Formaten der Attribute. Somit müssen zum Beispiel die Geburtsdaten von Personen nicht nur inhaltlich richtig sein, sondern die Anlieferung hat auch im vordefinierten Datenformat (z.B. ttmmjjjj) zu erfolgen. Die bereitgestellten Informationen in den Anwendungen bilden somit die reale Welt im vordefinierten Format ab. Konsistenz

Die Konsistenz bzw. die Inkonsistenz von Daten stellt gerade im Umfeld von Business-Intelligence-Anwendungen oftmals ein massives Problem hinsichtlich der Wahrnehmung schlechter Datenqualität dar. Die Inkonsistenz selbst kann dabei praktisch an jeder Stelle im Rahmen der Datenverarbeitung, beginnend bei der Datenerfassung, entstanden sein. Konsistenz in diesem Zusammenhang bezieht sich dabei in erster Linie auf die Übereinstimmung bzw. auf die vorhandene Möglichkeit zum Abgleich von Daten aus verschiedenen analytischen und operativen Anwendungen. Dieses Kriterium zielt auf die Widerspruchsfreiheit der Daten aus unterschiedlichen Anwendungen ab. Inkonsistente Daten führen zu inkonsistenten Berichten und zu einem Glaubwürdigkeitsproblem für die gesamte BusinessIntelligence-Anwendung. Zuverlässigkeit

Das Kriterium Zuverlässigkeit beschreibt die ausreichende Verfügbarkeit von Informationen, um die ursprüngliche Herkunft und die verschiedenen Transformationen der Daten nachvollziehen zu können. Dies beginnt bei der initialen Erfassung der Daten und geht hin bis zur Erstellung der Berichte aus den BIAnwendungen5 heraus. Hier ist insbesondere das Thema Metadatenmanagement zu erwähnen (siehe Kap. 14). Zur Vertrauensbildung trägt die sogenannte Reconciliation bei. Reconciliation beschreibt in diesem Zusammenhang den Abgleich von Daten aus unterschiedlichen Datenquellen. Im Speziellen ist mit diesem Begriff der Abgleich von Detaildaten aus dem Data Warehouse mit Daten aus dem Hauptbuch des Buchhaltungssystems gemeint.

5.

Die Begriffe »BI-Anwendung« und »analytische Anwendung« werden synonym verwendet.

2.3 Ursachen schlechter Datenqualität

27

Relevanz

Relevanz beschreibt, inwieweit das Informationsangebot der Anwendungen mit dem Informationsbedarf der Anwender übereinstimmt. Eine 100-prozentige Qualität der bereitgestellten Daten ist aus Sicht der Anwender unzureichend, wenn die bereitgestellten Daten nicht benötigt werden bzw. andere Daten vonnöten sind. Die Relevanz beschreibt somit die generelle Verfügbarkeit von Inhalten, die der Anwender benötigt, um seine Aufgaben vollständig erfüllen zu können. Dies führt zu der Frage, ob z.B. alle wesentlichen Datenbereiche in den BusinessIntelligence-Systemen integriert sind, um die Anforderungen der Anwender erfüllen zu können. Semantische Datenmodelle können hier bei der Kommunikation zwischen den Geschäftsbereichen und der IT zu Hilfe genommen werden. Vollständigkeit

Die Vollständigkeit der Daten hat wiederum zwei Ausprägungen. Einerseits kennzeichnet dieses Kriterium die Vollständigkeit der übermittelten Daten zwischen den Anwendungen, das bedeutet, es sind im Zuge der Transformationen keine Daten verloren gegangen. Andererseits bezeichnet das Datenqualitätskriterium Vollständigkeit die vollständige Befüllung der angelieferten Attribute mit Daten, d.h., die einzelnen Attribute beinhalten keine NULL-Werte.

2.3

Ursachen schlechter Datenqualität

Was sind nun die Ursachen schlechter Datenqualität? Wie kann schlechte Datenqualität überhaupt entstehen? Ebenso wie die Ausprägungen sind auch die Ursachen schlechter Datenqualität grundsätzlich sehr vielfältig. Gerade im Rahmen von Business-IntelligenceProjekten ist es wesentlich, die Ursachen zu verstehen, um diese rechtzeitig adressieren zu können. Davon ist in vielen Fällen der Erfolg dieser Projekte abhängig. Bevor nun detaillierter auf verschiedene Kategorien von Ursachen eingegangen wird, sei noch der Einflussfaktor Unternehmenskultur (vgl. [Friedman 2012]) erwähnt. Unternehmen mit einem hohen Qualitätsbewusstsein und laufenden Qualitätsprogrammen werden im Durchschnitt weniger Datenqualitätsprobleme haben als Unternehmen, die diesen Themen tendenziell eher teilnahmslos gegenüberstehen. Wie in vielen anderen Belangen auch beginnt dies mit der Einstellung und der Vorbildwirkung der Unternehmensleitung.

28

2 Ausprägungen und Ursachen schlechter Datenqualität

Datenerfassung Benutzerfehler

Redundanz Ressourcen

Know-how

Wachstum

Erfassungsprozesse

Know-how Inkonsistenz Fehlende Regeln

Kommunikation Medienbrüche

Feedbackprozesse

Korrekturen

Datenqualität

Prozesse Ignoranz

Silo-Denken

Prozesse

Abb. 2–3

Datenverwendung

Architektur

Definitionen

Problembewusstsein

Ressourcen

Datenverfall

Ursachen schlechter Datenqualität

Abbildung 2–3 gibt in sechs Kategorien zusammengefasst einen ersten Überblick über eine Auswahl von wesentlichen Ursachen schlechter Datenqualität, deren Auswirkungen insbesondere in Business-Intelligence-Projekten bzw. in den Anwendungen häufig zutage treten. Datenerfassung

Die initiale Eingabe der Daten ist eine der wesentlichsten Quellen für das Auftreten schlechter Datenqualität. Die verschiedenen Ursachen für Fehler bei der Erfassung der Daten sind vielfältig. Dies beginnt bei einfachen Benutzerfehlern und geht hin bis zu fehlenden Ressourcen, um eine korrekte Datenerfassung in unterschiedlichen, meist hochkomplexen Anwendungen garantieren zu können. Benutzerfehler unterteilen sich zum Beispiel in falsche Eingaben, fehlendes Know-how für eine korrekte Bedienung der Anwendungen, falsche Interpretationen der zu erfassenden Daten sowie die unvollständige Erfassung der Daten aufgrund fehlender Informationen. Eine der grundlegenden Ursachen für das Entstehen schlechter Datenqualität bereits bei der Datenerfassung ist das fehlende Problembewusstsein für die sich potenzierenden Auswirkungen mangelhafter Datenqualität auf den nachfolgenden Ebenen der Informationsverarbeitung. Einhergehend damit sind die fehlenden Beschäftigungsanreize für eine korrekte Erfassung von Daten. Es wird oftmals ausschließlich die Anzahl der eingegebenen Daten und die Geschwindigkeit der Erfassung gemessen, ohne ausreichend auf die Qualität zu achten. Dies führt in weiterer Folge auch dazu, dass keine Zeit für eventuell notwendige Rückfragen bei Unklarheiten im Rahmen der Erfassung zur Verfügung steht. Ein mangelhaftes Design der Eingabemasken stellt eine weitere Quelle für Probleme bei der Erfassung der Daten dar. Die Absicherung einzelner Felder bzw. die Plausibilisierbarkeit der Inhalte ist nicht immer ausreichend, die Möglichkeiten zur Einschränkung der Erfassung in den Masken bleiben ungenutzt. Zudem erfolgt das Design solcher Masken meist aus Sicht eines einzigen Unternehmensbereichs, etwa durch den Vertrieb.

2.3 Ursachen schlechter Datenqualität

29

Dies führt dazu, dass sich z.B. abgesicherte Muss-Felder in den Eingabemasken vor allem an den Bedürfnissen des Vertriebs orientieren und vorhandene Kann-Felder nicht weiter eingeschränkt werden. Aus Sicht des externen Rechnungswesens haben diese Kann-Felder möglicherweise eine ganz andere Bedeutung und führen in weiterer Folge zu Datenqualitätsproblemen im Rahmen der Bilanzerstellung. Ein potenzieller Ressourcenmangel im Zuge der Datenerfassung zieht in vielen Fällen ebenfalls eine mangelhafte Datenqualität nach sich, falls beispielsweise über längere Zeiträume keine bzw. nur eine eingeschränkte Datenerfassung erfolgt. Dies hat Auswirkungen auf die Zeitnähe der Daten in den verschiedenen Business-Intelligence-Anwendungen. Eine unzureichend aktuelle Datenerfassung hat unter Umständen falsche Meldungen an die Aufsichtsbehörden zur Folge oder kann zu Irritationen in den Kundenbeziehungen führen. Fehlerhafte externe Daten sind zusätzlich oftmals einer der Gründe für schlechte Datenqualität in den Business-Intelligence-Anwendungen. Externe Daten können dabei unter anderem zugekaufte Adressdaten sein. Die Schlussfolgerung daraus ist, dass bereits bei der Erfassung der Daten die Bedürfnisse des Gesamtunternehmens in die Überlegungen zur Sicherstellung der Datenqualität einfließen müssen, um so aus einer ganzheitlichen Sichtweise heraus entsprechende Maßnahmen definieren zu können. Prozesse

Diese Kategorie beschreibt die Auswirkungen auf die Datenqualität, die sich durch die Komplexität der Abläufe in den Unternehmen bzw. durch generell mangelhaft aufgesetzte Prozesse im Zuge der Datenverarbeitung ergeben. Dies beginnt bereits bei der Erfassung der Daten und zieht sich hin bis zur Erstellung der Berichte. Fehlende oder auch nur unvollständig aufgesetzte Prozesse führen zu fehlerhaften Datenerfassungen. Fehlende Prüfprozesse im Sinne einer weiteren Absicherung hinsichtlich Falscheingaben verstärken dies zusätzlich. Ergänzend zu den Erfassungsprozessen sind fehlende Feedbackprozesse ebenfalls problematisch, da Möglichkeiten zur standardisierten Revidierung falscher Eingaben fehlen. Diese Probleme werden zusätzlich noch durch eventuelle Brüche in den verwendeten Medien verstärkt, z.B. durch eine Unterbrechung der automatisierten Datenverarbeitung durch manuelle Ergänzungen oder auch durch eine teilweise manuelle Erfassung innerhalb der Kette von der Datenerfassung bis zur Datenverwendung. Abteilungsübergreifende Prozesse mit einem Übergang der Verantwortung im Rahmen der Datenbereitstellung führen ebenfalls zu Abstimmungsproblemen und ziehen potenziell eine Verschlechterung der Datenqualität nach sich. Das Überschreiten von Unternehmensgrenzen, beispielsweise hervorgerufen durch ein Outsourcing der Datenerfassung, stellt eine weitere besondere Heraus-

30

2 Ausprägungen und Ursachen schlechter Datenqualität

forderung an die Sicherstellung der Datenqualität dar. Diese Konstrukte sind meist ausschließlich auf Kostenersparnis und die Maximierung der erfassten Datenmengen bzw. auf eine Minimierung der Erfassungszeiten aufgebaut. Die für eine Sicherstellung der Datenqualität erforderlichen Ressourcen und deren zeitliche Verfügbarkeit spielen dabei häufig nur eine sekundäre Rolle. Fehlende standardisierte Abstimmungsprozesse zwischen den Daten auf verschiedenen Stufen der Verarbeitungskette führen dazu, dass die Erkennung potenzieller Fehler erst sehr spät stattfindet. Daraus resultiert eine Verkürzung der Reaktionszeiten bei auftretenden Datenqualitätsproblemen. Eine in den Verarbeitungsprozess integrierte Reconciliation im Sinne eines Abgleichs der Daten des Data Warehouse mit den Buchhaltungssystemen ermöglicht z.B. ein frühzeitiges Reagieren auf Abweichungen in wichtigen Bereichen. Architektur

Das richtige Design der Datenarchitektur eines Unternehmens ist ein grundlegender Baustein zur Sicherstellung der Datenqualität. Unter den Begriff Datenarchitektur fallen hier neben der Vielfalt der verwendeten Technologien und der bereitgestellten Daten auch deren Zugänglichkeit bzw. Unzugänglichkeit durch die Anwender. Das Design der Datenarchitektur beginnt bereits mit den operativen Systemen, die als Datenquellen für die durchzuführenden Aufgaben ausgelegt sein müssen. Eine konsistente Konzeption der Datenintegration der BI-Anwendungslandschaft beginnt bei den ETL6-Prozessen bzw. den Datenflüssen zwischen diesen Systemen. Inhaltlich klar abgegrenzte analytische Data Marts sind dabei ebenso eine wesentliche Voraussetzung für eine konsistente Datenarchitektur von Unternehmen. Das Thema Datenarchitektur im Umfeld von Business-Intelligence-Projekten wird in Kapitel 5 im Detail behandelt. In diesem Abschnitt erfolgt zunächst eine erste Sensibilisierung hinsichtlich der Datenarchitektur als Ursache von Datenqualitätsproblemen. In vielen Unternehmen sind in den vergangenen Jahren die operativen Anwendungslandschaften kontinuierlich gewachsen und um zusätzliche Funktionalitäten erweitert worden, die ursprünglich nicht vorgesehen waren. Das Ergebnis dieser nachträglichen Modifikationen ist oftmals eine heterogene operative Anwendungslandschaft mit redundanten, inkonsistenten Datenhaltungen sowie redundanten Transformationen zwischen den verschiedenen Anwendungen. Systemumstellungen, Datenmigrationen und Fehler in den Anwendungen selbst führen bereits in den operativen Systemen zu einer Verschlechterung der Datenqualität. Die auf dieser Stufe entstehenden Probleme vervielfachen sich im

6.

ETL = Extraktion, Transformation, Laden

2.3 Ursachen schlechter Datenqualität

31

Zuge der Datenverarbeitung bis hin in die BI-Anwendungen und führen zu einem erhöhten Aufwand für die Eindämmung der Auswirkungen. Innerhalb der BI-Anwendungslandschaft sind die Problembereiche analog den operativen Anwendungen. Dazu kommen noch inkonsistente Transformationen der Daten aus den operativen Systemen in die verschiedenen analytischen Systeme. Dies zieht Inkonsistenzen in den Berichten und einen erhöhten Abstimmungsaufwand zwischen den Anwendungen nach sich. Zusammenfassend führen Datenflüsse zwischen verschiedenen Anwendungen unweigerlich zu Problemen, hervorgerufen durch unterschiedliche Felddefinitionen und mehrfache Transformation der Daten. Im Zuge der Betrachtung von Datenqualitätsproblemen ist daher immer ein Augenmerk auf die Datenflüsse zwischen den Anwendungen zu legen. Das Design der Datenarchitektur sowie die Nachvollziehbarkeit von Transformationen in den Datenflüssen sind wesentliche Voraussetzungen für die nachhaltige Sicherstellung der Datenqualität. Definitionen

Ein weiterer oftmals vernachlässigter Punkt hinsichtlich schlechter Datenqualität sind inkonsistente fachliche Beschreibungen der Daten. Dies beinhaltet unterschiedliche Definitionen von Feldformaten, verschiedene Inhalte von grundsätzlich identischen Feldern in verschiedenen Business-Intelligence-Anwendungen oder vielfach sogar bereits in den Quellsystemen sowie miteinander unvereinbare Sichtweisen auf das Unternehmen durch die einzelnen Unternehmensbereiche. Diese unterschiedlichen Sichtweisen innerhalb von Unternehmen können sich auch oftmals bereits durch inkonsistente Geschäftsprozesse manifestieren. Bedingt durch heterogene Anwendungslandschaften verstärken sich die Auswirkungen dieser unterschiedlichen Definitionen auf die Qualität der Daten mit jeder weiteren Transformation zwischen den Anwendungen. Diese Kategorie hat hinsichtlich einer konsistenten Business-Intelligence-Architektur höchste Relevanz. Gerade spezifische Data Marts in den einzelnen Fachbereichen der Unternehmen bergen die Gefahr inkonsistenter Definitionen in sich. Die Konzeption vieler Anwendungen erfolgt sehr oft aus Sicht eines einzelnen Unternehmensbereichs, ohne Berücksichtigung der Bedürfnisse des Gesamtunternehmens. Ein wesentlicher Grund dafür ist oftmals die eingeschränkte Verfügbarkeit von Ressourcen und Budgets, aber auch fehlendes Problembewusstsein oder im schlimmsten Fall einfach nur Ignoranz. Dies führt in weiterer Folge unweigerlich zu erhöhten Abstimmungserfordernissen aufgrund inkonsistenter Berichte. Unterschiedliche Sichtweisen auf ein Unternehmen sind zum Beispiel voneinander abweichende Definitionen der Produktkataloge eines Unternehmens oder auch inkonsistente Definitionen der Kundensegmentierungen bzw. eine fehlende einheitliche Definition des Umsatzbegriffs. Auf der anderen Seite kann es durchaus bewusst unterschiedliche Sichten innerhalb eines Unternehmens geben, wie z.B. unterschiedliche Anforderungen an Abgrenzungen von internem Controlling

32

2 Ausprägungen und Ursachen schlechter Datenqualität

und externem Rechnungswesen. In diesem Fall ist eine entsprechende Dokumentation und Kommunikation sicherzustellen. Zur Auflösung solcher Inkonsistenzen gehen Unternehmen dazu über, ein Business-Glossar (vereinheitlichtes Vokabular und Definitionen) oder auch fachliche bzw. semantische Datenmodelle zu definieren. In letzter Konsequenz können solche Modelle eine fachliche Neudefinition des Datenfundaments eines Unternehmens bedeuten. Viele subjektiv durch die Anwender wahrgenommenen Datenqualitätsprobleme lassen sich auch auf mangelhafte Kommunikation innerhalb der Unternehmen zurückführen. Oftmals ist es schon ausreichend, entsprechende abteilungsübergreifende Kommunikationsforen in den Unternehmen einzurichten, um eine Reihe von Datenqualitätsproblemen auszumerzen. Ein gemeinsames, fachlich abgestimmtes Vokabular ist allerdings die Minimalvoraussetzung, um Fortschritte in dieser Hinsicht erzielen zu können. Wenn es in einem Unternehmen keine einheitliche Sichtweise darauf gibt, was ein Kunde eigentlich ist bzw. was einen Kunden zu einem Kunden macht, wird die Definition von einheitlichen Geschäftsprozessen, von konsistenten Definitionen der benötigten Datenfelder und letztendlich IT-Systemen zur Herausforderung. Die vereinfachte Darstellung in Abbildung 2–4 zeigt, dass ein gemeinsames Vokabular im Kern die Basis für konsistente Geschäftsprozesse, Datendefinitionen und die nachfolgende Implementierung der verschiedenen Systeme (operativ als auch Business Intelligence) ist.

Systeme Datendefinitionen Geschäftsprozesse

Vokabular

Abb. 2–4

Gemeinsames Vokabular als Basis

Auf organisatorische Aspekte des Datenqualitätsmanagements wird explizit in Kapitel 4 eingegangen.

2.3 Ursachen schlechter Datenqualität

33

Datenverwendung

Die inkorrekte Nutzung von Anwendungen führt bei den Empfängern von Daten aus diesen Anwendungen ebenfalls zum subjektiven Empfinden einer schlechten Datenqualität. Die inkorrekte Nutzung durch den Anwender äußert sich dabei vornehmlich in zwei verschiedenen Ausprägungen. Einerseits ist dies die inkonsistente Durchführung von Datenkorrekturen in verschiedenen Applikationen bzw. in unterschiedlichen analytischen Anwendungen. Dazu kommt, dass diese Korrekturen in den seltensten Fällen in den operativen Systemen nachgezogen werden. Generell sind Datenkorrekturen immer in den Quellanwendungen durchzuführen. In Ausnahmefällen, z.B. im Zuge der Bilanzerstellung, kann es aus zeitlichen Gründen vorkommen, dass Korrekturen zwischenzeitlich auch innerhalb der BI-Anwendungslandschaft durchgeführt werden müssen. Dies muss in jedem Fall nach vordefinierten Regeln sowie nach Abstimmung mit der internen Revision stattfinden. Andererseits fällt in diese Kategorie auch das fehlende Know-how der Anwender für die Interpretation der Daten oder auch das mangelnde Wissen, um eine korrekte Erstellung von Berichten in den diversen Anwendungen zu gewährleisten. Datenverfall

Das Problem des Datenverfalls tritt speziell in Business-Intelligence-Anwendungen zutage, da diese Systeme für viele Anwender oftmals die einzigen Datenquellen darstellen. Im Laufe der Zeit kommt es zu einem unweigerlichen Verfall mancher Daten. Beispiele dafür sind in erster Linie Adress- und Telefondaten, die sich im Verlauf der Zeit naturgemäß ändern. Ein weiteres Beispiel für den Verfall von Daten ist die Zugehörigkeit von Personen zu bestimmten Berufsgruppen, die sich ebenfalls regelmäßig ändern kann. Der Datenverfall führt unweigerlich zur Ungültigkeit von Daten und somit in weiterer Folge zu einem Datenqualitätsproblem. Es ist daher notwendig, entsprechende Prozesse aufzusetzen, um einerseits gefährdete Daten zu erkennen und andererseits diese Daten laufend aktuell zu halten. Zudem fehlen meist die entsprechenden Ressourcen, um die Aktualisierung durchzuführen, bzw. fehlt oftmals überhaupt das Problembewusstsein. Der Datenverfall wird durch das Datenqualitätskriterium Zeitnähe abgebildet.

34

2 Ausprägungen und Ursachen schlechter Datenqualität

Fazit

Zusammenfassend sind das Fehlen klar definierter Verantwortungen, das Nichtumsetzen notwendiger Maßnahmen sowie inkonsistente Datenarchitekturen die wesentlichsten Ursachen für schlechte Datenqualität. Daher sind in jedem Business-Intelligence-Projekt die Kette der Datenverarbeitung sowie die zugehörigen Verantwortungen zu untersuchen und mögliche Probleme proaktiv aufzuzeigen. Weiterhin ist über alle Kategorien hinweg das Thema der nur in den seltensten Fällen ausreichend vorhandenen Ressourcen und Budgetmittel relevant. Oftmals sind die Datenqualitätsprobleme im Unternehmen bekannt, allerdings werden keine Maßnahmen zu deren Bereinigung ergriffen. Dies ist in vielen Fällen auf ein fehlendes Bewusstsein für die Auswirkungen schlechter Datenqualität bei den Entscheidungsträgern zurückzuführen. Die Kosten-Nutzen-Darstellung von Maßnahmen zur Sicherung der Datenqualität lässt sich zudem nicht immer ausreichend quantitativ belegen (siehe Kap. 3).

2.4

Beispiel: Finanzdienstleister

Abschließend soll beispielhaft ein Business-Intelligence-Projekt angeführt werden, das bei einem Finanzdienstleister durchgeführt wurde. Im Zuge dieses Projekts erfolgten eine Erhebung von Datenqualitätsproblemen sowie deren Kategorisierung nach Ursachen. Die Ergebnisse dieser Erhebung wurden verwendet, um in weiterer Folge die Auswirkungen der Datenqualität auf das Business-Intelligence-Projekt frühzeitig abschätzen und davon ausgehend entsprechende Maßnahmen planen zu können. Ausgangssituation

Ausgangssituation in diesem Projekt war die Implementierung eines unternehmensweiten Data Warehouse und eine damit einhergehende Konsolidierung der über das gesamte Unternehmen verteilten analytischen Data Marts. Die Erhebung der Datenqualitätsprobleme war in diesem Zusammenhang ein Begleitprojekt mit zwei Zielsetzungen: einerseits die Reduktion der Projektrisiken und andererseits die Erstellung eines Maßnahmenkatalogs, um den anschließenden regulären Betrieb der Anwendung auf qualitativ hohem Niveau sicherstellen zu können. Vorgehensweise

Im Rahmen des Projekts erfolgten eine qualitative Erhebung mittels persönlicher Interviews hinsichtlich subjektiv wahrgenommener Datenqualitätsprobleme und eine Analyse deren Ursachen. Dabei wurden die künftigen Anwender quer über das gesamte Unternehmen befragt.

2.4 Beispiel: Finanzdienstleister

35

Die so erhobenen Probleme wurden konsolidiert und zu sechs Kategorien zusammengefasst. Die Kategorien entsprechen dabei den in Abschnitt 2.3 dargestellten Ursachen für schlechte Datenqualität. In Summe wurden insgesamt circa einhundert Einzelprobleme aufgenommen, analysiert und kategorisiert. Ergebnis

Die Ergebnisse dieser Interviews und der anschließenden Kategorisierung der Datenqualitätsprobleme sind in Abbildung 2–5 grafisch dargestellt. Auf der y-Achse sind die sechs Problemkategorien bzw. die Ursachen schlechter Datenqualität aufgetragen, auf der x-Achse die Anzahl der einzelnen genannten Datenqualitätsprobleme je Ursache. Aus diesem Beispiel ist klar ersichtlich, dass die Erfassung der Daten aus Sicht der Anwender die mit Abstand größten Probleme verursacht. Dies war durchaus zu erwarten. Etwas überraschend in diesem Beispiel mag erscheinen, dass fehlende bzw. falsche Definitionen bereits an zweiter Stelle stehen, während die Prozesse und die Architektur erst mit etwas Abstand folgen.

Datenerfassung

Definition

Architektur

Prozesse

Datenverfall

Datenverwendung 0

Abb. 2–5

5

10 15 20 25 30 Anzahl erfasster Datenqualitätsprobleme

35

40

Beispiel für Ursachen von Datenqualitätsproblemen bei einem Finanzdienstleister

Die Probleme, die durch die Datenverwendung und den zeitlichen Verfall der Daten hervorgerufen werden, sind aus Sicht der Anwender in diesem Unternehmen anzahlmäßig nur von geringer Bedeutung. Die konkreten Auswirkungen der einzelnen Datenqualitätsprobleme auf die Compliance mit regulatorischen Anforderungen bzw. auf andere Risiken sind im Einzelfall unabhängig von der Anzahl der Probleme je Kategorie zu betrachten. Eventuell notwendige Maßnahmen müssen einzeln analysiert, entschieden, mit Ressourcen versehen und umgesetzt werden.

36

2 Ausprägungen und Ursachen schlechter Datenqualität

Erkenntnisse

Wie oben erwähnt, ist aus Abbildung 2–5 ersichtlich, dass der Großteil der Datenqualitätsprobleme bereits aus der Erfassung der Daten resultiert. Dies war durchaus zu erwarten und zeigt, dass Maßnahmen zur Sicherstellung der Datenqualität möglichst frühzeitig aufzusetzen sind. Die hohe Anzahl von Problemen in der Kategorie Definitionen lässt sich im Wesentlichen auf die Tatsache zurückführen, dass die Ursache der subjektiven Wahrnehmung schlechter Datenqualität in einem Unternehmensbereich oftmals eine bewusste Entscheidung eines anderen Unternehmensbereichs war. Verstärkt wurde diese Problematik durch den mangelnden Zugang zu existierenden Definitionen. Das sogenannte Datenqualitätsproblem besteht somit in vielen Fällen in einer mangelhaften Kommunikation zwischen den Unternehmensbereichen. Eine Vielzahl der Probleme, die in die Kategorie Definitionen fallen, lässt sich oftmals auf fehlende Kommunikationsforen innerhalb des Unternehmens zurückführen. Diese Erkenntnis ist gerade in Hinblick auf Business-Intelligence-Projekte mit fachbereichsspezifischen Anwendungen wesentlich. Das wichtigste Ergebnis der Untersuchung war allerdings die Erkenntnis, dass die Verantwortung für eine Sicherstellung der Datenqualität auf allen Ebenen der Datenverarbeitung fehlte. Die erste Maßnahme in diesem Projekt war somit der Aufbau einer entsprechenden Data-Governance-Organisation inklusive der Zuweisung klar definierter Verantwortungen.

2.5

Empfehlungen

Zusammenfassend ist festzuhalten, dass die Ursachen für schlechte Datenqualität vielfältig sind. Schlechte Datenqualität ist sehr oft eine subjektive Wahrnehmung aus Sicht der jeweiligen Anwender. Um die Datenqualität aktiv zu managen und nachhaltige Verbesserungen herbeiführen zu können, sind die Ursachen schlechter Datenqualität im Einzelfall frühzeitig im Rahmen von BI-Projekten zu analysieren und geeignete Maßnahmen zu definieren. Dazu gehört insbesondere eine Sensibilisierung der Anwender. Aktives Datenqualitätsmanagement bedeutet in letzter Konsequenz klar zugewiesene Verantwortungen für die Sicherstellung der Datenqualität auf allen Ebenen der Datenverarbeitung sowie die Bereitstellung entsprechender Budgetmittel und Ressourcen, um auch tatsächlich Verbesserungen herbeiführen zu können.

37

3

Auswirkungen schlechter Datenqualität

Im täglichen Leben gibt es nur allzuviele Beispiele für schlechte Datenqualität. Wer hat nicht schon mehrere Werbebriefe von der gleichen Firma bekommen? Während es im privaten Bereich aber oft bei einem Ärgernis bleibt, sind die Auswirkungen schlechter Datenqualität aus Unternehmenssicht ungleich höher. Allein in den USA betragen die Kosten (z.B. Zusatzkosten für Porto, Druck und Gehälter) aufgrund von schlechter Datenqualität nach einer Studie des TDWI (The Data Warehousing Institute) ca. 600 Milliarden US­Dollar pro Jahr (vgl. [Eckerson 2002]). Auch das Abbrechen von Business­Intelligence­ oder Customer­Relationship­Management­Projekten verursacht immense Kosten, wie Untersuchungen von Gartner belegen (vgl. [Keizer 2004]). Eine weitere Gartner-Studie, im Rahmen derer mehr als 140 Unternehmen quer über eine Reihe von Branchen befragt wurden, bestätigt diese Erkenntnisse eindrucksvoll (vgl. [Friedman 2010]). Der geschätzte durchschnittliche durch Datenqualitätsprobleme verursachte Verlust dieser befragten Unternehmen beträgt jährlich 8,2 Millionen US-Dollar. 22% dieser Unternehmen gaben jährliche Verluste von 20 Millionen US-Dollar oder mehr an, während 4% sogar jährliche Verluste in Höhe von ca. 100 Millionen US-Dollar angaben. Ein weiterer Punkt sind die Kosten von strategischen Fehlentscheidungen durch das Management aufgrund eines fehlerhaften Datenmaterials. In diese Kategorie fällt auch der benötigte Zeitaufwand, um inkonsistente Kennzahlen zu validieren und zu interpretieren. Aber welche Investitionen zur Verbesserung der Datenqualität lohnen sich? Wann amortisiert sich eine Dublettenbereinigung meiner Geschäftspartnerdaten? Diesen und anderen dringenden Fragen müssen sich die Verantwortlichen in den Unternehmen angesichts des steigenden Kostendrucks immer häufiger stellen. Dieses Kapitel beleuchtet die Auswirkungen schlechter Datenqualität für die Unternehmen sowohl hinsichtlich monetärer als auch bezüglich nicht quantifizierbarer Aspekte und stellt sich dabei der Frage, wie sich Budgets zur Verbesserung der Datenqualität generieren lassen bzw. welche Problematiken im Umfeld beschränkter Unternehmensbudgets zu beachten sind.

38

3.1

3 Auswirkungen schlechter Datenqualität

Datenqualitätskosten

Nach wie vor stellt es für viele Unternehmen eine Herausforderung dar, die Wirtschaftlichkeit von Maßnahmen zur Verbesserung der Datenqualität nachzuweisen. In der Literatur findet man viele beeindruckende Zahlen von Beispielen, die zeigen, welche zum Teil enormen Kosten durch eine schlechte Qualität von Daten anfallen können: ■ Durch ein internes Audit stellte ein europäisches Unternehmen fest, dass für ca. 4 Prozent der Bestellungen keine Rechnungen gestellt wurden. Für ein Unternehmen mit einem Umsatz von 2 Milliarden US­Dollar bedeutet dies einen Verlust in Höhe von 80 Millionen US­Dollar (vgl. [English 1999, S. 8]). ■ Fehlerhafte Preisdaten in Datenbanken des Handels verursachen jährlich Kosten in Höhe von ca. 2,5 Milliarden US­Dollar. Audits haben gezeigt, dass vier von fünf über Scanner ausgelesene Preise die am Etikett ausgezeichneten Preise übersteigen (vgl. [deFries/Seidl/Windheuser 2002, S. 92]). Auch wenn dies aus Sicht des Unternehmens zusätzliche Erlöse einbringt, führt es auf Dauer zu einem negativen Image. ■ US­Finanzbehörde 1992: Knapp 100.000 Steuererstattungsbescheide waren nicht zustellbar (vgl. [English 1999]). ■ Eine Großbank verrechnet sich bei der Ermittlung ihrer Gewinne um 200 Millionen Schweizer Franken. Schuld war die mangelhafte Integration der Daten einer kurz vorher (1 Jahr) akquirierten Versicherung. ■ Die Dresdner Bank hat die Wertpapierdepots ihrer Kunden zweimal in Euro umgerechnet. Dadurch stand anschließend in den Kontoauszügen nur noch ein Viertel des ursprünglichen Guthabens (vgl. [Dresdner Bank 1999, S. 47]). ■ Nestlé USA hat durch die Reduktion der unterschiedlichen Spezifikationen für die Zutat Vanille die Anzahl der Lieferanten massiv reduzieren können und so jährliche Einsparungen von 30 Millionen US­Dollar generiert. Insgesamt hatten derartige operative Einsparungen ein jährliches Volumen von 1 Milliarde US­Dollar (vgl. [Economist 2010]). So beeindruckend solche Zahlen auch sein mögen, es bleibt die Herausforderung, diese Beispiele auf das eigene Unternehmen zu übertragen und damit die Skepsis für Datenqualitätsmaßnahmen beim Management auszuräumen. Ein Punkt, an dem viele Vorstandsvorlagen zur Finanzierung eines Datenqualitätsmanagement­Projekts scheitern, ist die unzureichende Quantifizierung der einzusparenden Kosten und der zu generierenden Nutzenpotenziale, die eine Qualitätssteigerung mit sich bringen würde. Die obige Liste ließe sich beliebig fortführen und zeigt auch anschaulich, dass sich der Nutzen von verbesserter Datenqualität durchaus quantifizieren lässt. Es ist oftmals nur notwendig, etwas genauer hinzusehen und tiefergehende Überlegungen dazu anzustellen. Grundsätzlich ist ein Business Case (siehe Abschnitt 3.3) für Datenqualität nicht schwieriger zu gestalten als einer für andere Investiti-

3.1 Datenqualitätskosten

39

onsprojekte. Es liegt immer auch an der Aufbereitung des Themas, da Datenqualität per se nicht unbedingt ein attraktives Betätigungsfeld ist, mit dem man im Unternehmen punkten kann. Des Weiteren wird das Thema Datenqualität für die Erfüllung von regulatorischen Anforderungen ebenfalls immer wichtiger. Immer mehr gesetzliche Anforderungen (siehe Abschnitt 3.2) erfordern ein proaktives Management der Datenqualität und in weiterer Folge dann auch dessen Nachweis. Ein weitaus größeres Problem ist allerdings, dass beschränkte Unternehmensbudgets unmittelbar einen Wettbewerb unterschiedlicher Initiativen im Unternehmen erzeugen. Dies führt unweigerlich dazu, dass eine Priorisierung der Projekte in den Unternehmen stattfinden muss und selbst Projekte mit einem überzeugenden Business Case keine Berücksichtigung finden. Eine Regelung hinsichtlich einer Priorisierung von Projekten, wie sie in großen Unternehmen oftmals vorkommt, kann folgendermaßen aussehen: Projekttreiber in Unternehmen

Priorität

Gesetzliche Vorgaben (siehe auch Abschnitt 3.2)

1

Gruppenprojekte (z.B. in multinationalen Konzernen)

2

Projekte mit unmittelbarer Auswirkung auf den Kunden bzw. auf die Kundenzufriedenheit

3

Projekte mit GuV­Auswirkung

4

Weitere Projekte

5

Tab. 3–1

Beispiel für eine Priorisierung von Projekten in Unternehmen

Da die Budgets und internen Ressourcen meist nicht einmal ausreichen, um alle Anforderungen mit Priorität 1 umsetzen zu können, stehen alle Projektanträge, die nicht unter diesen Punkt fallen, von Beginn an vor dem Scheitern. Eine gute Möglichkeit, Budgets für Datenqualität zu generieren, ist es, alle Projekte, die unter den ersten Punkt fallen, hinsichtlich dahingehender Relevanz zu untersuchen und Datenqualität als Teilprojekt hineinzureklamieren. Dies funktioniert mitunter sehr gut, da es wenige Projekte gibt, bei denen Datenqualität kein Thema ist. Wesentlich ist dabei allerdings, dass dies bereits sehr frühzeitig in den Projektplanungsphasen berücksichtigt wird. Ein weiterer Grund, warum Datenqualitätsprobleme für das Management nicht immer sichtbar sind, sind die sogenannten verdeckten Kosten, d.h., dass z.B. die offensichtlichen Datenqualitätsprobleme von diversen selbstmotivierten Mitarbeitern neben ihren sonstigen Tätigkeiten behoben werden. Dies findet dann oftmals seinen Niederschlag in vermehrten Überstunden und in weiterer Folge natürlich in zusätzlichen Kosten. Eine Ausnahme, wie sich trotzdem sehr kurzfristig relativ große Budgets generieren lassen, sind »Schock­Ereignisse«, z.B.:

40

3 Auswirkungen schlechter Datenqualität

■ Der Vorstand eines großen europäischen Finanzdienstleistungsunternehmens erhält von zwei Unternehmensbereichen Berichte, die im Wesentlichen die gleichen Zahlen auf Summenebene ausweisen müssten. In der Realität weisen diese Zahlen eine Differenz von 1 Milliarde Euro aus. ■ Der Aufsichtsrat eines Weltmarktführers in der produzierenden Industrie vergleicht einen aktuellen Monatsbericht mit dem Vormonatsbericht und entdeckt dabei massive, nicht erklärbare Inkonsistenzen. In beiden Fällen war die Genehmigung von kurzfristigen Sonderbudgets zur Beseitigung der zugrunde liegenden Datenqualitätsprobleme kein großes Thema mehr. Eine weitere sehr gute Möglichkeit, die Unternehmensleitung von wichtigen Datenqualitätsmaßnahmen zu überzeugen, ist, Kennzahlen zu definieren, die unmittelbar wiederum Maßnahmen adressieren, die die uneingeschränkte Aufmerksamkeit des Topmanagements genießen (vgl. [Redman 2008b]). Ein Beispiel dazu ist ein Unternehmen, das die Qualität des Kundenservice als ein wesentliches Unterscheidungsmerkmal zum Wettbewerb definiert hat. Die Kennzahl könnte sich dann auf die Anzahl der Kunden beziehen, die nicht Opfer eines Datenfehlers (z.B. inkorrekte Rechnung oder falsche Anrede) innerhalb eines Jahres wurden. Zielsetzung wäre es dann, diese Anzahl mit diversen Datenqualitätsprogrammen laufend zu erhöhen. Generell lassen sich die Datenqualitätskosten gemäß Abbildung 3–1 in die Kosten verursacht durch schlechte Datenqualität sowie in die Kosten zur Verbesserung bzw. Sicherstellung einer ausreichenden Datenqualität unterteilen.

Datenqualitätskosten

Kosten verursacht durch schlechte Datenqualität

Kosten zur Verbesserung bzw. Sicherstellung einer ausreichenden Datenqualität

Direkte Kosten

Präventivkosten

Indirekte Kosten

Entdeckungskosten

Bereinigungskosten

Abb. 3–1

Aufteilung von Datenqualitätskosten (in Anlehnung an [Eppler/Helfert 2004, S. 311] und [Otto et al. 2008, S. 219])

3.1 Datenqualitätskosten

41

Durch schlechte Datenqualität verursachte Kosten

Direkte Kosten entstehen sofort, d.h. unmittelbar hervorgerufen durch die schlechte Datenqualität selbst. ■ Beispiel 1: Abhängig von der Quelle im Unternehmen gibt es zwei Zahlen für das Einkaufsvolumen eines globalen Lieferanten. Um zu verifizieren, welche Zahl korrekt ist, entstehen Kosten (sog. Nachweiskosten). ■ Beispiel 2: Bei der Überprüfung von Kennzahlen wird erkannt, dass aufgrund einer falschen Währungsumrechnung im Quellsystem eine Reihe von Zahlen falsch an das Data Warehouse weitergegeben wurden. Für die Richtigstellung der Daten ist die Währungsumrechnung zu korrigieren und die Daten müssen neu geladen werden (sog. Wiedereingabekosten). Indirekte Kosten entstehen mittelbar durch die schlechte Datenqualität in Form falscher Entscheidungen oder Aktionen. Die folgende Aufzählung zeigt anhand verschiedener Beispiele die Vielfalt von indirekten Kosten hervorgerufen durch schlechte Datenqualität: ■ Umsatzeinbußen: Durch falsche Preisauszeichnungen, Lizenzvereinbarungen etc. entstehen den Unternehmen signifikante Umsatzeinbußen. ■ Verschwendung von Budgets: Durch die Versendung von Werbebriefen an falsche oder nicht existente Adressen entstehen unnötige Mehrkosten. Durch eine regelmäßige Validierung der Adressen können Kosten eingespart werden. ■ Fehlentscheidungen: Aufgrund von Entscheidungen, die auf falschen Zahlen basieren, wird das Potenzial einer ausgewählten Zielgruppe für eigene Produkte unterschätzt und daher nicht voll ausgeschöpft. Ursache hierfür können inkonsistente Stamm­ und Bewegungsdaten sein. ■ Imageverluste: Wiederholte Unzufriedenheit bei den Kunden (z.B. durch schlechte Beratung im Callcenter aufgrund falscher Daten) kann zu einem Markenwechsel führen. Da es jedoch sehr unterschiedliche Gründe für eine Kundenabwanderung geben kann, ist die Zuordnung der Ursache (z.B. schlechte Datenqualität) nicht immer eindeutig. ■ Gerichtliche Auseinandersetzungen: Schäden, die nachweislich auf schlechten oder falschen Daten basieren, können zu Rechtsstreitigkeiten zwischen Kunden und Unternehmen oder zwischen dem Staat und Unternehmen führen.

42

3 Auswirkungen schlechter Datenqualität

■ Betrugsversuche im E-Business: Studien belegen, dass nur etwa 10 Prozent der Angaben, die von Besuchern von Webseiten gemacht werden, korrekt sind (vgl. [English 2002]). Oft werden bewusst Mehrfachanmeldungen mit leicht modifizierten Angaben gemacht, um dadurch beispielsweise an Bonusprogrammen teilnehmen zu können. ■ Produktionsmängel: Bedingt durch falsch eingestellte Maschinen kommt es bei der Produktion zu einem erhöhten Ausschuss, der ein teures Nacharbeiten notwendig macht. Werden die Mängel nicht erkannt, kann es im schlimmsten Fall sogar zu Rückrufaktionen kommen. ■ Vertrauensverluste: Schlechte Datenqualität führt schnell einmal zu Vertrauensverlusten in die eigenen Daten innerhalb der Unternehmen. Dies hat dann oftmals endlose Diskussionen (d.h. nicht zu unterschätzenden Zeitaufwand) über die richtigen Kennzahlen und letztendlich auch verzögerte oder nicht getroffene Entscheidungen zur Folge. Kosten zur Verbesserung sowie Sicherstellung einer ausreichenden Datenqualität

Die Kosten zur Sicherstellung und Erhaltung ausreichender Datenqualität lassen sich prinzipiell in drei Kategorien aufteilen (vgl. [Won/Choi 2003, S. 73ff.]): a) Präventionskosten: Grundsätzlich gibt es zwei Vorgehensweisen, um die Eingabe falscher Daten vorab zu minimieren: manuell oder systemgestützt; oftmals ergibt eine Kombination dieser beiden am meisten Sinn. Beide Herangehensweisen führen zu erhöhten Kosten, die ganzheitlich betrachtet jedoch sehr gut investiert sind. Um die Mitarbeiter für das Thema Datenqualität zu sensibilisieren, sind Schulungen besonders sinnvoll. Der Aufbau einer entsprechenden Datenqualitätsorganisation (siehe Kap. 4) kann hier äußerst hilfreich sein. b) Entdeckungskosten: Hierbei geht es um das Messen der Datenqualität. Mithilfe von Plausibilitätsberichten lassen sich sehr viele Unstimmigkeiten in den Daten schnell erkennen. Beispiel: Ist das monatliche Bestellvolumen einer Warengruppe ungefähr bekannt, können Bestellungen mit überdimensional großen Bestellmengen sofort als Fehlbuchungen identifiziert werden. Die Investition in die Einrichtung eines Qualitätskennzahlensystems ist daher zu empfehlen (siehe hierzu auch Kap. 7). Hilfreich ist hier vor allem auch das regelmäßige Durchführen von sogenannten Data­Profiling­Projekten (siehe auch Kap. 9) zur frühzeitigen Erkennung neuer Datenqualitätsprobleme.

3.1 Datenqualitätskosten

43

c) Bereinigungskosten: Um falsche Daten in einem Data Warehouse zu bereinigen, die nicht mehr durch Korrektureingaben in den Quellsystemen richtiggestellt werden können, sind Update­Routinen zu implementieren. Nicht immer ist dies über automatische Routinen (Update­Statement über eine bestimmte Tabelle) möglich. In der Praxis wird die Korrektur immer eine Kombination von manuellen und automatisierbaren Tätigkeiten sein. Weiterführende Betrachtungen hinsichtlich der Kosten für das Entdecken und Bereinigen von Datenqualitätsfehlern im Vergleich zur präventiven Vermeidung von Datenqualitätsfehlern kommen zu der Schlussfolgerung, dass die Prävention im Schnitt um ca. 2/3 geringere Gesamtkosten zur Folge hat (vgl. [Redman 2008a]). Die präventive Vermeidung betrifft in erster Linie die Beseitigung der originären Ursachen in den operativen Quellsystemen bzw. bereits in den diversen Unternehmensprozessen. Kosten

Kosten verursacht durch schlechte Datenqualität

Kosten zur Verbesserung/ Sicherstellung einer guten Datenqualität

Qualität

Abb. 3–2

100 %

Vereinfachte Darstellung des Zusammenhangs zwischen Datenqualitätskosten und der erreichbaren Datenqualität

Um sich abschließend ein Bild der gesamten Datenqualitätskosten zu machen, sind die geschätzten Kosten einer schlechten Datenqualität den errechneten Kosten zur Verbesserung der Datenqualität gegenüberzustellen und zu analysieren, mit dem Ziel, die kostengünstigste Kombination zu identifizieren. Abbildung 3–2 zeigt in einer vereinfachten schematischen Form, wie sich dieser Zusammenhang grafisch darstellt. In dem grau schattierten Bereich sind die gesamten Datenqualitätskosten (Total Quality Cost) am geringsten. Zu einer Wirtschaftlichkeitsrechnung gehört neben der Kostenaufstellung und ­analyse auch die Darstellung von Nutzenpotenzialen (siehe Abb. 3–3). Der strategische Nutzen ist in der Regel nicht immer unmittelbar quantifizierbar. Wie soll man eine Umsatzsteigerung direkt aufgrund einer erhöhten Kundenzufrie-

44

3 Auswirkungen schlechter Datenqualität

denheit messen? Unter diesen Punkt fallen beispielsweise auch die aufgrund mangelhafter Datenqualität fehlerhaften Requirements-Analysen bei Großprojekten. Die dadurch entstandenen Mehrkosten (ganz zu schweigen von überhaupt gescheiterten und abgebrochenen Projekten) lassen sich im Nachhinein möglicherweise nur mehr schwer der unzureichenden Datenqualität zuweisen. Hier kann eine Qualifizierung des Nutzens oftmals weiterhelfen bzw. lassen sich Quantifizierungen basierend auf den Erfahrungen aus der Vergangenheit annähernd durchführen. Etwas einfacher ist dies im operativen Bereich möglich (vgl. [Otto et al. 2008, S. 220]). Beispielsweise kann man durch genauere Gewichtsangaben Transportkosten einsparen. Im Bereich der Prozessanalyse sind ebenfalls Einsparungen zu errechnen. Nutzenpotenziale

Strategisch

Operativ

Wettbewerbsvorteile

Verkürzte Prozesslaufzeiten

Kundenzufriedenheit

...

...

Abb. 3–3

Nutzenpotenziale (in Anlehnung an [Eppler/Helfert 2004, S. 3] und [Otto et al. 2008, S. 219])

Beispielsweise für den Versandhandel (im Rahmen des Kampagnen­Managements) lassen sich die negativen Auswirkungen schlechter Datenqualität mit Beispielrechnungen belegen. Annahmen:

15 Millionen Kunden Zusendung von zwei Spezialkatalogen pro Kunde und Jahr 10% Postrückläufer Herstellkosten pro Spezialkatalog 3,50€, Porto 0,55€

Vermeidbare Kosten:

Rückläufer: 1,5 Mio.(3,50€+0,55€)=6.075.000€

3.2 Gesetzliche Anforderungen

3.2

45

Gesetzliche Anforderungen

Wenn man die Auswirkungen schlechter Datenqualität untersucht, sind es neben den in Abschnitt 3.1 beleuchteten Aspekten auch immer mehr gesetzliche und behördliche Auflagen, die von den Unternehmen zu beachten sind. Die Anzahl solcher Regelungen hat in den vergangenen Jahren stetig zugenommen. Die damit verbundene Nachweispflicht setzt eine einwandfreie Datenqualität voraus. Nach einer Studie von Gartner sind Compliance­Vorgaben ein wesentlicher Treiber (vgl. Abschnitt 2.1) für ein aktives Datenqualitätsmanagement (siehe Abb. 3–4). In der Grafik steht der Wert 1 für eine geringe Bedeutung als Geschäftstreiber, der Wert 7 für eine sehr hohe Bedeutung als Geschäftstreiber.

Unterstützung von Compliance-Aktivitäten

5,89

Verbesserung der Anwenderakzeptanz der wichtigsten Applikationssysteme

5,77

Unterstützung von CRM-Initiativen

5,68

Unterstützung von Business-Intelligenceoder Data-Warehouse-Initiativen

5,63

Stärkung des Vertrauens in die eigene Datenbasis

5,57

Antwort auf Datenqualitätsinitiativen bei Wettbewerbern

5,06

Folgen eines signifikanten Schadenfalls durch schlechte Datenqualität

4,71 0

Abb. 3–4

1

2

3

4

5

6

7

Geschäftstreiber für das Datenqualitätsmanagement (Gartner) (vgl. [Friedman 2006])

Mit dem Begriff Compliance wird die Einhaltung von Gesetzen und Richtlinien in den Unternehmen bezeichnet. Übersetzt werden kann der Begriff mit »Regelüberwachung« oder einfach »Überwachung«. Im Rahmen der Compliance­Maßnahmen muss sichergestellt werden, dass die nationalen und internationalen Gesetze und Richtlinien gegen kriminelle Handlungen (z.B. Betrug), Finanzsanktionen, Marktmissbrauch, Interessenkonflikte, Datenschutz, Insiderhandel oder Geldwäsche eingehalten werden. Beispielsweise ist laut einer EU­Verordnung eine Geschäftsbeziehung mit Personen, die in den US­/EU­Antiterrorlisten (wie z.B. die US Denied Persons List (DPL) oder der Liste des EU-Ministerrates (2008/ 568/GASP)) aufgeführt sind, unter Strafe verboten (vgl. [Kokemüller/Haupt 2012, S. 109]).

46

3 Auswirkungen schlechter Datenqualität

Ein manueller Abgleich scheidet aufgrund der hohen Anzahl von Datensätzen aus. Die Lösung muss vielmehr im Einsatz entsprechender Software liegen, um die Adressen mit den einzelnen Negativlisten abzugleichen. Der Einsatz solcher Software muss durch die Implementierung von Prozessen ergänzt werden, damit ein permanenter und gleichzeitig routinemäßiger Abgleich ermöglicht wird. Eine beispielhafte Auswahl verschiedener Gesetze und Richtlinien zeigt Abbildung 3–5. Die Anforderungen an das Datenqualitätsmanagement müssen durch die Unternehmensführung vorgegeben, getragen und überwacht werden. Übergreifende behördliche und gesetzliche Vorgaben

Branchenspezifische Vorgaben

■ International Financial Reporting Standards (IFRS) ■ Sarbanes-Oxley Act ■ Regelungen des Bundesaufsichtsamts für den Wertpapierhandel (BAWe) ■ …

■ ■ ■ ■ ■ ■

Abb. 3–5

Basel II – Finanzdienstleistungen Basel III – Finanzdienstleistungen Dodd-Frank Act – Finanzmarkt REACH – Chemische Industrie IMDS – Automobilindustrie …

Gesetze und Richtlinien als Compliance-Anforderungen

International Financial Reporting Standards

Die International Financial Reporting Standards (IFRS) sind eine Sammlung von Regeln für die Rechnungslegung erwerbswirtschaftlicher Unternehmen. Abschlüsse, die nach den IFRS aufgestellt werden, sollen in erster Linie Informationen über die Vermögens­, Finanz­ und Ertragslage des Unternehmens liefern. Die herkömmliche deutsche Rechnungslegung nach dem Handelsgesetzbuch (HGB) bezweckt dagegen für Jahresabschlüsse vornehmlich den Gläubigerschutz und erst zweitrangig die Informationen zu Vermögens­, Finanz­ und Ertragslage des Unternehmens. Verständlichkeit, Entscheidungsrelevanz, Wesentlichkeit, Zuverlässigkeit und Vergleichbarkeit sind die qualitativen Anforderungen, denen der Abschluss genügen muss. Insgesamt sollen die IFRS ■ die Vergleichbarkeit der Abschlüsse kapitalmarktorientierter Unternehmen weltweit erleichtern, ■ den Aufbau eines integrierten Kapitalmarkts gewährleisten, der effizient funktioniert, ■ den Schutz der Anleger verbessern, ■ das Vertrauen in die Finanzmärkte und den freien Kapitalverkehr im Binnenmarkt stärken.

3.2 Gesetzliche Anforderungen

47

Sarbanes-Oxley Act

Der Sarbanes­Oxley Act von 2002 (auch SOX, SarbOx oder SOA genannt) ist ein US­Bundesgesetz, das als Reaktion auf Bilanzskandale diverser Unternehmen (z.B. Enron oder Worldcom) das Vertrauen in die Berichterstattung von Unternehmen verbessern soll. Im Hinblick auf Datenqualität ist besonders Section 404 zu beachten, die auf die Angemessenheit der internen Kontroll­ und Berichtsstrukturen abzielt und dabei die Verantwortung des Managements explizit festlegt. Dodd-Frank Act

Der Dodd-Frank Act von 2010 ist ein US-Bundesgesetz, das als Reaktion auf die Finanzmarktkrise der vorhergehenden Jahre den US-Finanzmarkt neu regelt. Wesentliche Zielsetzung des Dodd-Frank Act ist die Förderung der Stabilität des US-Finanzmarkts durch Verbesserung der Verantwortlichkeit und der Transparenz. Ein entsprechendes Vertrauen in die Qualität der Informationen ist hier natürlich eine wesentliche Voraussetzung. Basel II

Basel II bezeichnet die Gesamtheit der Eigenkapitalvorschriften, die vom Basler Ausschuss für Bankenaufsicht in den letzten Jahren vorgeschlagen wurden. Die Regeln müssen gemäß den EU­Richtlinien 2006/48/EG und 2006/49/EG seit dem 1. Januar 2007 in den Mitgliedstaaten der Europäischen Union für alle Kreditinstitute und Finanzdienstleistungsinstitute angewendet werden. Die daraus resultierenden neuen Anforderungen an das Kreditrisikomanagement sowie den Umgang mit operativen Risiken bei Finanzinstituten setzen wiederum eine ausreichende Datenqualität voraus; z.B. falls die Qualität der Kriterien zur Kalkulation der Eigenkapitalquote unzureichend ist, entstehen dem Institut entweder zu hohe Kosten (zu hohe Eigenkapitalquote) oder es ist nicht regelkonform (zu niedrige Eigenkapitalquote). Basel III

Basel III ist ein umfassendes Reformpaket des Basler Ausschusses für Bankenaufsicht zu Basel II, mit dem die Regulierung, die Aufsicht und das Risikomanagement im Bankensektor weiter gestärkt werden sollen. Ziel dieser Maßnahmen ist es: ■ die Resistenz des Bankensektors gegenüber Schocks aus Stresssituationen im Finanzsektor und in der Wirtschaft, unabhängig von ihrem Ursprung, zu verbessern ■ Risikomanagement und Führungsstrukturen zu verbessern ■ Transparenz und Offenlegung der Banken zu stärken

48

3 Auswirkungen schlechter Datenqualität

Bei den Reformen geht es um: ■ die Regulierung auf Einzelinstitutsebene, die zur Stärkung der Widerstandskraft der einzelnen Banken in Stressphasen beiträgt ■ systemweite Risiken, die sich im gesamten Bankensektor aufbauen können, sowie die prozyklische Verstärkung dieser Risiken im Zeitverlauf Diese beiden Aufsichtsansätze ergänzen sich, denn eine erhöhte Widerstandskraft der einzelnen Banken verringert das Risiko systemweiter Schocks. Basel III ist Teil der stetigen Bestrebungen des Basler Ausschusses, die Rahmenbedingungen der Bankenaufsicht zu verbessern. Es baut auf dem Papier Internationale Konvergenz der Eigenkapitalmessung und Eigenkapitalanforderungen (Basel II) auf. Innerhalb der Europäischen Union erfolgte die entsprechende Umsetzung der Basel-III-Empfehlungen per 1. Januar 2014 durch Adaptierungen der Capital Requirements Directive (CRD). REACH

Bei REACH (Registration, Evaluation, Authorisation and Restriction of Chemicals) handelt es sich um eine EU00Chemikalienverordnung, die am 1. Juni 2007 in Kraft getreten ist. Als EU­Verordnung besitzt REACH in allen Mitgliedstaaten Gültigkeit. Ziel von REACH ist die Vereinfachung des bisher geltenden Chemikalienrechts, das dadurch grundlegend harmonisiert und vereinfacht wird. Unter REACH müssen künftig alle Chemikalien, die in der EU hergestellt, verwendet oder verbraucht werden, bei der Europäischen Chemikalienagentur in Helsinki registriert werden. Dazu müssen sehr viele Daten, z.B. Gesundheits­ und Umweltgefahren, erhoben und in Dossiers zusammengefasst werden. Diese eingereichten Dossiers werden in Helsinki bewertet (d.h. evaluiert). Besonders besorgniserregende Stoffe müssen zugelassen (d.h. autorisiert) werden und dürfen nicht für alle Zwecke verwendet werden. IMDS

Mit IMDS (International Material Data System) wird ein Archiv­, Austausch­ und Verwaltungssystem für den Fahrzeugbau bezeichnet. Auf seiner Basis wird ein Materialdatenblatt erstellt, in dem für das betreffende Bauteil alle verwendeten Werkstoffe und anteiligen Stoffkomponenten benannt sind sowie alle erforderlichen Daten erfasst werden, die für das spätere Recycling des Fahrzeugteils notwendig sind. Die aufgeführten Beispiele an gesetzlichen Anforderungen machen deutlich, dass nur Unternehmen mit einer ausreichenden Datenqualität in der Lage sind, jederzeit belastbare und reproduzierbare Berichte zu erzeugen.

3.3 Business-Case-Betrachtungen

49

Verbraucherschutz und Betrugsbekämpfung

Neben den rein gesetzlichen oder branchenspezifischen Vorgaben gilt es auch, Maßnahmen zur Betrugsbekämpfung oder dem Verbraucherschutz im Unternehmen zu etablieren. Dazu gehören sogenannte Robinsonlisten. Dies sind Schutzlisten mit Kontaktdaten von Personen, die keine unaufgeforderte Werbung (Brief, E-Mail etc.) erhalten wollen. Diese Kontaktsperren werden von den möglichen Empfängern ausgesprochen. Der Eintrag in diese Listen ist kostenlos. Geführt werden sie sowohl von den Unternehmen selbst oder von Verbraucherschutzorganisationen. Für die Unternehmen steht die Selbstverpflichtung dahinter, dem Wunsch der eingetragenen Verbraucher nach Werbefreiheit nachzukommen. Bei den Blacklists zur Betrugsbekämpfung geht die Initiative vom Absender (dem Unternehmen) aus. Aus unterschiedlichen Gründen, wie z.B. säumige Schuldner oder der Benutzung von offensichtlichen Fantasienamen, soll die Kontaktaufnahme unterbunden werden (vgl. [Kokemüller/Haupt 2012, S. 110]).

3.3

Business-Case-Betrachtungen

Was sind die wesentlichen Elemente, die es bei der Erstellung eines Business Case zum Thema Datenqualität zu beachten gilt? Dieser Abschnitt gibt einen ersten Überblick über Business-Case-relevante Inhalte. Prinzipiell ist zu sagen, dass sich ein Business Case für Datenqualität strukturell nicht wirklich von einem Business Case für z.B. IT-Vorhaben unterscheidet. Zu Beginn gilt es zu überlegen, was man mit der Aufbereitung des Business Case erreichen will. In erster Linie will man das Topmanagement von einem Vorhaben überzeugen und dafür auch die notwendigen Budgets und Ressourcen genehmigt bekommen. Deshalb ist es ratsam, die Struktur und den Business Case selbst möglichst managementgerecht aufzubereiten. Dies beginnt mit einer überzeugenden Antwort auf die WARUM-Frage. Eine Struktur, die sich für die Aufbereitung bewährt hat, kann folgendermaßen aussehen: 1. Management-Überblick: Kurze und prägnante Beschreibung des Nutzens, der Ziele, der Inhalte, der Potenziale und der durch dieses Vorhaben zu behebenden Probleme – schlüssige Antwort auf die WARUM-Frage 2. Umfang des Vorhabens: Beschreibung des Umfangs der Vorhabens. Welche Prozesse, Systeme, Unternehmensbereiche etc. sind davon betroffen? 3. Annahmen und Prämissen: Kurzer Überblick über die wichtigsten Rahmenbedingungen des Vorhabens. Welche Annahmen wurden für die Kalkulation des gegenständlichen Busi-

50

3 Auswirkungen schlechter Datenqualität

ness Case getroffen? Welche Voraussetzungen müssen für die erfolgreiche Umsetzung gegeben sein? 4. Kosten-Nutzen-Kalkulation: Nachfolgende Punkte können Teil einer solchen Kalkulation (siehe auch Abb. 3–6) sein. Eine ROI-Kalkulation (Return on Investment) ist optional und wird vom konkreten Vorhaben (z.B. ob quantifizierbarer Nutzen erzielt wird) abhängig sein: • • • •

initiale und laufende Kosten des Vorhabens qualitativer Nutzen quantitativer Nutzen (unmittelbar und über die Zeit aufgerechneter Nutzen) ROI

5. Risiken: Beschreibung der wesentlichsten Risiken, die sich durch das gegenständliche Vorhaben ergeben, bzw. jener Risiken, die den Erfolg gefährden könnten. Dazu gehört auch die Definition von Maßnahmen, um diese Risiken mindern zu können. 6. Zusammenfassung: Abschließend folgt noch eine Wiederholung und kurze Zusammenfassung der wichtigsten Punkte und Aussagen des Business Case. Ein weiteres Thema, das bei der Genehmigung von Projektbudgets durchaus entscheidend sein kann, ist die Unterscheidung zwischen OPEX1 und CAPEX2. OPEX sind im Wesentlichen die laufenden betrieblichen Aufwendungen, während unter CAPEX jene Investitionen fallen, die in der Bilanz aktiviert und über die Zeit abgeschrieben werden. Die diesbezüglichen Möglichkeiten und Anforderungen sind dann im Bedarfsfall mit den jeweiligen Finanzabteilungen in den Unternehmen abzuklären. Abbildung 3–6 gibt nun einen beispielhaften Überblick über wesentliche Positionen, die für die Kalkulation eines Business Case relevant sein können. Abbildung 3–6 ist keine vollständige Auflistung aller möglichen Positionen, sondern soll vielmehr eine erste Anregung als Basis für weiterführende Betrachtungen im konkreten Anlassfall sein.

1. 2.

Operational Expenditure Capital Expenditure

3.3 Business-Case-Betrachtungen

51

I. Kosten

II. Nutzen

Initiale Kosten

Quantitativ (siehe Abschnitt 3.1)

a. b) c) d)

Hardware Software Sonstige Infrastruktur Personalkosten

a) Höherer Umsatz, z.B.

• •

b) Kostenreduktion, z.B.

Intern Extern

e) Schulungen f) Sonstige Kosten Laufende Kosten a) Personalkosten • •

• • • • •

Weniger Fehler bei Rechnungslegung Höhere Erfolgsraten bei Marketingaktionen Reduzierte Wechselfrequenz von Kunden Reduzierter Aufwand für Fehlersuche und Fehlerbehebung Reduzierter Aufwand durch effizienteres Berichtswesen Optimierte Versandkosten Verbesserte Betrugserkennung Reduzierte Entwicklungskosten

Qualitativ (siehe Abschnitt 3.2) a) Erfüllung gesetzlicher Vorgaben, z.B.

Intern Extern

•

b) Softwarelizenzen c) Wartungsbudget & kleinere Adaptionen d) Schulungen e) Sonstige Kosten

Abb. 3–6

• • •

Reduzierte Wahrscheinlichkeit regulatorischer Strafen

b) Weitere • • • •

Kundenzufriedenheit Erhöhtes Vertrauen von Investoren Mitarbeiterzufriedenheit Höhere Entscheidungsqualität

Business-Case-Betrachtungen

Initiale Kosten sind in diesem Zusammenhang in erster Linie Kosten, die entweder einmalig für Datenqualitätsbereinigungsaktionen oder für den Implementierungsaufwand von z.B. Data-Profiling-Lösungen (oder Ähnlichem) anfallen, die dann im Betrieb fortlaufend Einsatz finden. Darunter versteht man auch jene Kosten, die für einmalige Adaptionen in den Quellsystemen oder für Änderungen in den Unternehmensprozessen anfallen (siehe auch Abschnitt 2.3 für die vielfältigen Ursachen von Datenqualitätsproblemen). Hardware- und Softwarekosten können in diesem Zusammenhang dann anfallen, wenn z.B. Werkzeuge für Data Profiling, Workflow Management oder auch Data Cleansing zu beschaffen sind. In Ausnahmefällen können auch umfangreichere Änderungen in der Vorsystemlandschaft notwendig sein, die die Hardware, Software oder auch die Netzwerkinfrastruktur betreffen. Die laufenden Kosten fallen dann im Betrieb der jeweiligen Lösung an. Dies kann z.B. ein periodisches Data Profiling sein, das wiederum kleinere Änderungen bzw. Maßnahmen zur Erhöhung der Datenqualität nach sich ziehen kann oder auch der Ausgangspunkt für das nächste größere Vorhaben inklusive eines neuen Business Case sein kann. Zum Betrieb gehört auch ein laufendes Monitoring der Datenqualität mittels Kennzahlen bzw. die Erstellung von periodischen Datenqualitätsberichten. Ein weiterer Punkt, der hier zu beachten ist, sind die anfallenden laufenden Kosten für eine entsprechende Aufbau- und Ablauforganisation (siehe Kap. 4).

52

3 Auswirkungen schlechter Datenqualität

Abschließend lässt sich zum Thema Business Case sagen, dass der Erfolg des Vorhabens bereits zu einem großen Teil von einer überzeugenden und konsistenten Antwort auf die WARUM-Frage abhängt. Das gilt nicht nur für die notwendigen Genehmigungen, sondern auch für die Fokussierung auf das Wesentliche im Projekt selbst.

3.4

Empfehlungen

Die Ausführungen in diesem Kapitel zeigen anhand von Beispielen, welche Auswirkungen schlechte Datenqualität haben kann bzw. welche Datenqualitätskosten anfallen können und warum es unerlässlich ist, Datenqualität aktiv zu steuern. Die Generierung von Budgets zur Verbesserung der Datenqualität stellt oftmals eine große Herausforderung dar, die sich allerdings in vielen Fällen (wenn auch nicht in allen) durchaus meistern lässt. Da Datenqualitätsprojekte eine beschränkte Attraktivität haben und wenig Möglichkeiten zur Profilierung innerhalb der Unternehmen bieten, ist auch die Bereitschaft zur Übernahme der Verantwortung solcher Projekte oftmals limitiert. Letztendlich zeigt die Erfahrung aus vielen BI­Projekten immer wieder: Die frühzeitige Herstellung von Datenqualität im Rahmen dieser Projekte kostet bedeutend weniger als die qualitativen und quantitativen Kosten der nachfolgenden Auswirkungen von fehlender Datenqualität. Gerade aus diesem Grund muss die Steigerung der Datenqualität immer im Gesamtkontext der Unternehmensprozesse gesehen werden. Erst durch die Betrachtung und Verbesserung vieler Prozesse innerhalb eines Unternehmens wird die Datenqualität nachhaltig beeinflusst. Auslöser für Datenqualitätsprojekte im BI­Umfeld sind oft – wie bereits zu Beginn des Abschnitt 3.2 dargestellt – Anforderungen aufgrund neuer Compliance­Vorgaben. In diesem Sinn kann Compliance nicht nur als Kostentreiber, sondern auch als Chance für die Unternehmen gesehen werden, längst überfällige Datenqualitätsprojekte proaktiv anzugehen und die Potenziale verbesserter Datenqualität zu nutzen.

53

4

Organisation

Dieses Kapitel widmet sich dem organisatorischen Umfeld des Datenqualitätsmanagements (DQM). Einerseits wird die Aufbauorganisation dargestellt, d.h. welche Rollen mit welchen Zuständigkeiten zu etablieren sind, um ein erfolgreiches Datenqualitätsmanagement in der Praxis zu ermöglichen. Andererseits wird kurz auf die Ablauforganisation, d.h. die wesentlichsten Prozesse rund um das Datenqualitätsmanagement, eingegangen.

4.1

Aufbauorganisation

Eine wohldefinierte Organisationsstruktur ist eine essenzielle Komponente eines jeden Datenqualitätskonzeptes, mit der Zielsetzung, klare Rollen und Zuständigkeiten im Datenqualitätsmanagement zu definieren. Ohne die eindeutige Zuweisung von Aufgaben und Kompetenzen zu konkreten Personen ist ein wirksames Datenqualitätsmanagement nicht durchführbar. Im Datenqualitätsmanagement gilt das Gleiche wie auch sonst in allen Bereichen von Organisationen: Wo keine Verantwortung zugewiesen ist, findet auch keine Verbesserung statt. Ein Blick in die Literatur führt im Wesentlichen zu der in Tabelle 4–1 dargestellten Aufteilung von Rollen und Gremien, wenn auch die Bezeichnungen für die einzelnen Instanzen unterschiedlich sind. Rolle

Quellen

Sponsor

Strategic Information Steward [English 1999], Executive Level [Newman & Logan 2006], Executive Sponsor [Marco & Smith 2006], Executive Council [Dember 2006]

Datenqualitätslenkungsausschuss

Business Information Stewardship Team [English 1999], Data Governance Council [Dyché/Levy 2006; Marco/Smith 2006], Governance Committee [Russom 2006], GRCS Board [Dember 2006], Trustee Council [Dyché/Levy 2006], Legislative Level [Newman/Logan 2006], Enterprise Information Governance Steering Committee [Kight/Smith 2007]

➝

54

4 Organisation

Rolle

Quellen

Datenqualitätsmanager

Master Data Coordinator [Swanton 2005], Director of Data Management [Dyché/Levy 2006], Chief Steward [Marco/Smith 2006], Corporate Steward [Russom 2006], Lead Steward [Dember 2006], Data Czar [Dyché/Levy 2006], Data Governance Council [Kight/Smith 2007]

Fachlicher Data Steward

Information Professionals [Redman 1996], Business Information Steward [English 1999], Business Data Steward [Dyché/Levy 2006], Subject Area Steward [Newman/Logan 2006], Master Data Lead [Swanton 2005], Domain Steward [Russom 2006], Business Steward [Marco/Smith 2006], Subject Matter Expert [Dyché/Levy 2006], Data Stewardship Team [Kight/Smith 2007]

Technischer Data Steward

Database Steward & Information Architecture Steward [English 1999], Technical Steward [Marco/Smith 2006], Source System Data Steward [Dyché/Levy 2006]

Tab. 4–1

Übersicht über die verschiedenen Rollen im Datenqualitätsmanagement (in Anlehnung an [Wende 2007a] und [Wende 2007b])

Oft gibt es die in Abbildung 4–1 dargestellte Dreiteilung in einen Datenqualitätslenkungsausschuss (Entscheidungsgremium), einen zentralen Datenqualitätsmanager (bzw. ein zentrales Datenqualitätsmanagementteam) und dezentrale Data Stewards, die für gewisse Datenbereiche (IT und Fachbereich) zuständig sind.

Rollen/Gremien

Datenqualitätslenkungsausschuss

Datenqualitätsmanager (zentral) Data Stewards (dezentral)

Abb. 4–1

Organisationseinheiten nach Kight/Smith

Organisationseinheiten nach Russom

Governance Commitee

Enterprise Information Governance Steering Commitee (Vision) Data Governance Council (Strategy) Data Governance Council (Strategy) Data Stewardship Team (Tactics)

Executive Sponsors Corporate Stewards Domain Stewards

IT Directors Line-of-Business Managers

Organisationseinheiten im Vergleich

Beispielhaft wird hier auf zwei Ansätze näher eingegangen. Von Kight/Smith (vgl. [Kight/Smith 2007]) wird eine Dreiteilung in Enterprise Information Governance Steering Committee, Data Governance Council und Data Stewardship Team vorgeschlagen. Das Enterprise Information Governance Steering Committee entspricht im Groben dem Datenqualitätslenkungsausschuss, nur dass dort als abgedecktes Themenspektrum neben Datenqualität auch andere Data-GovernanceAspekte (z.B. Datendefinitionen und Zuständigkeiten) behandelt werden. Es

4.1 Aufbauorganisation

55

nimmt Data-Governance-Lösungen ab, finanziert Datenqualitäts- und sonstige Data-Governance-Initiativen und löst bereichsübergreifende Konflikte. Ein solch breiterer Data-Governance-Ansatz (ggf. auch kombiniert mit anderen BI-Governance-Themen, wie z.B. der Planung einer Roadmap für die BI-Landschaft) wird auch von den Autoren empfohlen. Die Darstellung in diesem Buch fokussiert jedoch auf den Datenqualitätsmanagement-Anteil. Das Data Governance Council versteht sich als strategische Einheit, die übergreifende Datenqualitäts-(bzw. Data-Governance-)Standards definiert und die Aktivitäten der Data Stewards in den einzelnen Fachbereichen koordiniert. Die Data Stewards, zuständig für (taktische) Datenqualitätssicherung, Datendefinitionen sowie Freigabe von Daten zum Zugriff, sind als Subject Matter Experts in den Fachbereichen angesiedelt und im (virtuellen) Data Stewardship Team zusammengefasst. Kight/Smith unterscheiden zwischen Business Stewards, Application Stewards und Quality Stewards. Letztere entsprechen in etwa der DataSteward-Rolle, wie sie in diesem Buch verwendet wird. Russom (vgl. [Russom 2006]) nimmt genauso eine Dreiteilung vor, ebenfalls mit etwas breiterem (Data-Governance-)Fokus. Als Entscheidungsgremium (entsprechend dem Datenqualitätslenkungsausschuss) dient hier das Governance Committee, bestehend aus Sponsoren für das Datenqualitätsmanagement (Board Level) sowie Fachbereichs- und IT-Managern. Die zentrale, koordinierende Einheit (Datenqualitätsmanager) wird durch die Corporate Stewards gebildet, nach Russom in der IT angesiedelt. Die Domain Stewards letztlich entsprechen in ihrer Rolle den fachlichen Data Stewards. Als Grundlage für die weitere Darstellung im Verlauf dieses Buches dienen die Rollen mit ihren Zuständigkeiten sowie Gremien gemäß Abbildung 4–2. Eine solche Organisationsstruktur ist von den Autoren bereits in mehreren Projekten implementiert worden und hat sich in der Praxis bewährt. Die Darstellung orientiert sich dabei an der in Kapitel 5 dargestellten Referenzarchitektur von BIAnwendungen. Hier seien allerdings noch ein paar warnende Worte angebracht. Speziell große Unternehmen sind nicht immer rein rational handelnde Einheiten. Ganz im Gegenteil ist hier oftmals die inoffizielle Politik ein wesentlicher Einflussfaktor für Entscheidungen in Unternehmen. Dies bedeutet, dass es nicht immer möglich sein wird, die ideale Organisationsstruktur umzusetzen. In solch einem Fall wird eine pragmatische Vorgehensweise angebracht sein, die die wichtigsten Funktionen und Tätigkeiten das Datenqualitätsmanagement betreffend in der bestehenden Organisationsstruktur unterbringt. Oftmals sind es auch nur Kleinigkeiten wie die Rollenbezeichnungen, die an die herrschenden Gegebenheiten anzupassen sind. Es wird hier geraten, dass in jedem Fall die Unternehmenskultur und der Einfluss der inoffiziellen Politik zu bedenken (und wenn möglich zu analysieren) sind, bevor versucht wird, organisatorische Entscheidungen herbeizuführen.

56

4 Organisation

Zielsetzung sollte es in jedem Fall sein, in der Sache Datenqualitätsmanagement Fortschritte zu erzielen, d.h. letztendlich die Datenqualität zu verbessern. Es wäre nicht das erste Mal, dass ein derartiges Vorhaben wegen eines verletzten Egos scheitert. Sponsor

Datenqualitätslenkungsausschuss Datenqualitätsmanager Datenqualitäts-Jour-Fixe

Data Stewards Fachbereich 1

Data Stewards Fachbereich n

…

Data Stewards IT-Bereich

Systemverantwortliche Informationsbereitstellung

Data Warehouse Systemverantwortliche Datenhaltung

Data Warehouse Data Mart

Systemverantwortliche Datenquellen

Op. Sys.

Op. Sys. Op. Sys.

Data Mart

Data Mart

Oper. System

Op. Sys.

Datenerfassung

Abb. 4–2

Rollen und Gremien

Prinzipiell lässt sich feststellen, dass in einem datenqualitätsorientierten Unternehmen grundsätzlich jeder Mitarbeiter auf jeder Ebene für die Datenqualitätssicherung in seinem Bereich zuständig ist. Das beginnt bei der Datenerfassung und erstreckt sich über Administratoren und fachliche Verantwortliche für IT-Systeme (Datenquellen und -haltung sowie Informationsbereitstellung) bis hin zu den Anwendern, die die definitionskonforme Verwendung der Daten sicherzustellen haben. Wie bereits erwähnt, wird in diesem Buch ein Data Governance Council, also ein Datenqualitätslenkungsausschuss, vorgeschlagen. Dieser wird vom Management der Fachbereiche fachbereichsübergreifend besetzt (inkl. Beteiligung von IT), entscheidet über strittige Datenqualitätsmaßnahmen und stellt die Finanzierung sicher.

4.1 Aufbauorganisation

57

Der Datenqualitätsmanager koordiniert die Datenqualität »End-to-End« quer über das gesamte Unternehmen, das beinhaltet insbesondere das Verfolgen von Datenqualitätsproblemen und den entsprechenden Verbesserungsmaßnahmen, unabhängig davon, ob diese im Zuge der Datenerfassung, in Datenquellen, Schnittstellen, Datenhaltungs- oder Datenbereitstellungssystemen vorzunehmen sind. Der Datenqualitätsmanager – bzw. das Datenqualitätsmanagement-Team, denn bei größeren Unternehmen ist die Aufgabe nicht mehr durch eine einzelne Person zu erfüllen – hat die unternehmensweite Auswirkung von Datenqualitätsproblemen zu berücksichtigen. Dies bedeutet, dass beispielsweise ein im Controlling identifiziertes Problem durch ihn an andere betroffene Bereiche (z.B. Marketing) zu kommunizieren ist. Um diese Aufgabe erfüllen zu können, ist eine sogenannte Betroffenheitsmatrix zu definieren. Diese Matrix ermöglicht die Identifikation aller Unternehmensbereiche, die die von den Datenqualitätsproblemen betroffenen Informationen bzw. Attribute grundsätzlich verwenden. Die Data Stewards übernehmen primär die Datenqualitätssicherung mithilfe von Datenanalysen in den Datenhaltungssystemen (Data Warehouse oder Data Marts) und nehmen Datenqualitätsprobleme von den Anwendern entgegen. Korrekturen sind in erster Linie wie erwähnt von der Datenerfassung direkt in den Quellsystemen vorzunehmen. Je nach Architektur und Unternehmensrichtlinien sind ggf. auch Korrekturen in den Datenhaltungssystemen direkt möglich und können unter Umständen auch von den zuständigen Data Stewards durchgeführt werden (siehe Kap. 8). Gemeinsam mit dem Datenqualitätsmanager bilden die Data Stewards den Datenqualitäts-Jour-Fixe, der als operatives Arbeitsgremium Datenqualitätsprobleme und -maßnahmen bespricht, sodass nur strittige Fälle an den Datenqualitätslenkungsausschuss weitergeleitet werden müssen (Eskalation). Systemverantwortliche in der IT stellen den ordnungsgemäßen technischen Betrieb der Quell-, Datenhaltungs- und Datenbereitstellungssysteme sowie der zugehörigen Transformationen zwischen den Systemen sicher. Oft sind auch fachlich Verantwortliche für einzelne Systeme definiert, insbesondere, wenn ein ITSystem unter Kontrolle eines einzelnen Fachbereichs steht. In diesem Fall sind die fachlichen Systemverantwortlichen für Datenqualitätssicherungsmaßnahmen in den betreffenden Systemen (insbesondere Quellsystemen) zuständig und übernehmen ggf. neben der Datenerfassung auch die Korrekturen in diesen. Die Datenerfassung ist für die Eingabe korrekter und vollständiger Daten in die Quellsysteme verantwortlich. Werden Datenqualitätsprobleme identifiziert, liegt im Zuständigkeitsbereich der Datenerfassung auch die Korrektur der fehlerhaften Daten in den Quellsystemen. Die Kernrollen und Gremien werden im Folgenden noch einmal im Detail dargestellt, wobei der Fokus auf ihrer gegenseitigen Interaktion liegt.

58

4 Organisation

Rollen

Sponsor Der Sponsor stellt die Unterstützung des Vorstands bzw. der Geschäftsführung für das Datenqualitätsmanagement sicher. In der Regel kommt der Sponsor aus dem C-Level, d.h. Chief Executive Officer (CEO), Chief Financial Officer (CFO) oder Chief Information Officer (CIO). Der Sponsor gibt die grundsätzliche Ausrichtung vor und stellt eine entsprechende Budgetierung sicher. Datenqualitätsmanager Die Hauptaufgabe des Datenqualitätsmanagers (Data Quality Manager) liegt in der unternehmensweiten Koordination des Datenqualitätsmanagements, d.h., er hat eine Vermittlerrolle zwischen den Data Stewards untereinander und zu den Systemverantwortlichen in der IT. In Unternehmen mit einer fortschrittlichen BIGovernance-Organisation ist der Datenqualitätsmanager oft im Business-Intelligence-Kompetenzzentrum (BICC) angesiedelt oder mit einer eigenen Stabsstelle unter dem Chief Information Officer (CIO). Hin und wieder findet sich in der Literatur auch der Ausdruck Chief Data Quality Officer (CDQO) oder KonzernDatensteward für die Rolle, die hier als Datenqualitätsmanager bezeichnet wird. Der Datenqualitätsmanager wird von den Data Stewards über den aktuellen Datenqualitätsstatus und relevante Datenqualitätsprobleme informiert und gibt diese Informationen an die betroffenen Stakeholder (z.B. andere Data Stewards) weiter. Mithilfe von übergreifenden und konsolidierten Datenqualitätskennzahlen und -berichten (siehe Kap. 7 und 15) kann er sich zusätzlich ein eigenes Bild machen. Diese Berichte dienen auch der Präsentation des aktuellen Datenqualitätsstatus im Datenqualitätslenkungsausschuss. Weiterhin behält der Datenqualitätsmanager (sinnvollerweise über ein zentrales Metadaten-Repository, siehe Kap. 14) den Überblick über die definierten Datenqualitätskennzahlen, um eine unternehmensweite Konsolidierung zu erreichen und Redundanzen möglichst weitgehend zu vermeiden. Der Datenqualitätsmanager ist von den Systemverantwortlichen über Änderungen in den IT-Systemen (Datenquelle, -haltung und Informationsbereitstellung) zu informieren, um die Auswirkungen auf die Datenqualität (per Rücksprache mit den zuständigen Data Stewards) beurteilen zu können. Es ist hierbei auch sicherzustellen, dass der Datenqualitätsmanager einen Überblick über neue Initiativen und Projekte (z.B. Migrationsprojekte) im Unternehmen erhält, um diese hinsichtlich Datenqualitätsrelevanz einschätzen und Maßnahmen einbringen zu können. Je nach Ausprägung der BI-Governance hat diese Informationen der BI-Governance-Manager bereitzustellen. Der Datenqualitätsmanager (bzw. der Leiter des Teams) stellt die Agenda der Lenkungsausschussmeetings sowie des Datenqualitäts-Jour-Fixe zusammen, lädt die Teilnehmer ein und moderiert diese Besprechungen.

4.1 Aufbauorganisation

59

Eine weitere Verantwortung des Datenqualitätsmanagers ist die Definition unternehmensweiter Datenqualitätsstandards, -methoden und -prozesse. Die Abstimmung (bzw. der Wissenstransfer) dieser Standards erfolgt über die Data Stewards, die Abnahme danach im Datenqualitätslenkungsausschuss. Der Datenqualitätsmanager initiiert die Umsetzung von Datenqualitätsmaßnahmen (siehe Abschnitt 4.2) in Abstimmung mit den Data Stewards und den Systemverantwortlichen. Er nimmt eine Vorpriorisierung der Anforderungen vor und bringt diese im Datenqualitätslenkungsausschuss zur Entscheidung. Bei Uneinigkeit über Datenqualitätsprobleme bzw. -maßnahmen verweist der Datenqualitätsmanager diese nach einem Versuch der Konsensfindung mit den Data Stewards im Datenqualitäts-Jour-Fixe an den Datenqualitätslenkungsausschuss. Data Steward (technisch und fachlich) Die Rolle der Data Stewards wird häufig in fachliche und technische Zuständigkeit unterschieden. Die fachlichen Data Stewards sind in den jeweiligen Fachbereichen angesiedelt (z. B. Controlling, Buchhaltung, Einkauf) und zeichnen für unterschiedliche Datenbereiche verantwortlich (z. B. Kundenstammdaten, Produktstammdaten, Verkaufstransaktionen). Es ist unbedingt notwendig, dass für alle Datenbereiche eines Data Warehouse Data Stewards nominiert werden, um eine lückenlose Datenqualitätssicherung zu gewährleisten. Die Zuweisung der Data Stewards zu den Datenbereichen erfolgt nach abgestimmten Regeln durch den Datenqualitätsmanager. Im Falle der Uneinigkeit über die Zuständigkeit für einen Datenbereich greift der Eskalationsprozess (Konsensversuch im Datenqualitäts-Jour-Fixe, finale Entscheidung im Datenqualitätslenkungsausschuss). Um den Datenqualitätsmanager bei der Aufteilung der Verantwortung auf die einzelnen Felder in einem Enterprise Data Warehouse zu unterstützen, sind wie erwähnt eigens dafür definierte Prinzipien oder Regelwerke zu definieren. Meist ist nicht eindeutig klar, welcher Fachbereich für welche Felder im Data Warehouse die Verantwortung übernehmen soll oder muss. Für diesen Fall ist es eben hilfreich, Regelwerke zu definieren, die die Zuweisung der Verantwortung eindeutig klarstellen. Ein solches Regelwerk, wie es in der einen oder anderen Form von den Autoren in Projekten bereits definiert wurde, kann nun folgendermaßen aussehen: 1. Schnittstelle/Quellsystem: Wenn es bereits eine klare Verantwortung eines Fachbereichs für das Quellsystem oder dessen Schnittstelle in das Data Warehouse gibt, dann ist dieser Bereich für die entsprechenden Felder im Data Warehouse zuständig. Falls (1) zu keiner eindeutigen Lösung führt, dann (2).

60

4 Organisation

2. Verwendung der Daten/Usage Matrix: Eine Usage Matrix dokumentiert die Verwendung der Daten in einem Data Warehouse. Falls nur ein einziger Bereich diese Daten verwendet, dann wird diesem Bereich die Verantwortung zugewiesen. Falls (2) zu keiner eindeutigen Lösung führt, dann (3). 3. Geschäftsverantwortung: Wenn es eine eindeutige Geschäfts-verantwortung eines Bereichs für die Daten gibt (z.B. für Kundendaten), dann ist dieser Bereich für den Inhalt der Felder im Data Warehouse verantwortlich. Falls (3) zu keiner eindeutigen Lösung führt, dann (4). 4. Überlappende Verantwortung: Falls für gewisse Datenfelder keine eindeutige Verantwortung zugewiesen werden kann, sind diese Felder logisch aufzuteilen, d.h., die Verantwortung für die unterschiedlichen Kundengruppen ist auf mehrere Bereiche verteilt (Privatkunden, Firmenkunden etc.). Die hier dargestellte Reihenfolge entspricht natürlich den Prioritäten des jeweiligen Unternehmens und kann im Bedarfsfall entsprechend adaptiert werden. Data Stewards definieren des Weiteren Datenqualitätskennzahlen und -berichte (siehe Kap. 6) zur laufenden Datenqualitätssicherung (siehe Abschnitt 4.2) und nehmen Anforderungen zum Monitoring von Anwendern entgegen. Data Stewards erkennen Datenqualitätsprobleme und initiieren Maßnahmen, die auch die Datenkorrekturen beinhalten. Je nach Architektur und Unternehmensrichtlinie nehmen sie in Ausnahmefällen Korrekturen im Data Warehouse auch selbst vor. In jedem Fall überwachen sie die Umsetzung der von ihnen initiierten Maßnahmen und leiten sie im Falle einer nicht zeitgerechten Umsetzung an den Datenqualitätsmanager zur Eskalation weiter. Data Stewards definieren weiterhin Prüfregeln für ihren Datenbereich, die in die Quellsysteme und/oder Ladeprogramme integriert werden können. Letzteres geschieht über den Datenqualitätsanforderungsprozess (siehe Abschnitt 4.2). Data Stewards nehmen gemeinsam mit dem Datenqualitätsmanager am Datenqualitäts-Jour-Fixe teil. Die technischen Data Stewards beschäftigen sich mit Fragen der IT-Architektur und mit Möglichkeiten, Datenqualitätsprozesse systemgestützt zu implementieren. Für ihren Verantwortungsbereich definieren die technischen Data Stewards beispielsweise Datenformate oder Datenflüsse. Die Datenqualitätsmaßnahmen in den Quellsystemen werden in Abstimmung mit den jeweiligen Systemverantwortlichen initiiert. Wichtig dabei ist, dass der Datenqualitätsmanager darüber informiert wird und so unternehmensweit den Überblick behält.

4.1 Aufbauorganisation

61

In größeren Unternehmen, und dort insbesondere in Fachbereichen mit mehreren Data Stewards, besteht die Notwendigkeit, sogenannte Data-StewardKoordinatoren oder auch Lead Data Stewards zu nominieren. Diese Data-Steward-Koordinatoren koordinieren die Data Stewards innerhalb des eigenen Fachbereichs und vertreten diesen Fachbereich in bereichsübergreifenden Gremien, wie z.B. im Datenqualitäts-Jour-Fixe. Des Weiteren hat der Data-Steward-Koordinator die Verantwortung der End-to-End-Betrachtungen von Datenqualität innerhalb des eigenen Fachbereichs, d.h., er hat den Überblick, falls DQ-Probleme auftreten, welche Auswirkungen diese Probleme an anderen Stellen bzw. in anderen Systemen in diesem Fachbereich haben können. Ein Data-Steward-Koordinator wird oftmals auch der Single Point of Contact (SPOC) für Datenqualitätsthemen oder -probleme der jeweiligen Anwender aus diesem Fachbereich sein. Die Ausführungen zeigen, dass es für die Zuordnung der Aufgaben zu den Rollen keine allgemein gültigen Richtlinien gibt. Vielmehr hängt die konkrete Zuordnung von diversen Faktoren wie Größe, Diversifikation oder Branchenzugehörigkeit ab. Abbildung 4–3 zeigt exemplarisch eine mögliche Zuordnung. Dabei wurde für die Zuständigkeit die sogenannte RACI-Notation gewählt. Die RACI-Matrix ist eine Spezialform der Verantwortlichkeitsmatrix, bei der es vier Arten von Zuständigkeiten gibt: a) (R) Responsible, d. h. verantwortlich im Sinne der konkreten Durchführung b) (A) Accountable, d.h. verantwortlich im disziplinarischen Sinne (z. B. verantwortlich, dass alle Lieferantenstammdaten bei der Anlage eine D-U-N-S-Nummer erhalten) c) (C) Consulted, d.h. beratend in fachlicher Hinsicht (z.B. SAP-R/3-Experte für die Customizing-Einstellungen der verschiedenen Materialstammdaten-Sichten) d) (I) Informed, d.h. benötigt die Information, wenn bestimmte Entscheidungen (z.B. Definition von Datenqualitätskriterien) getroffen wurden

62

4 Organisation

Rollen DQLenkungsausschuss Governance-Modell

DQManager

Techn. Data Steward

R, A

C

I

Stammdatenobjekte

A

C

R

C

Stammdatenprozesse

A

C

R

C

Prozessüberwachung Stammdatenqualität Aufgaben

Fachl. Data Steward

R, A A

Qualitätsüberwachung

R

C

C

R, A

I

I

A

I

Stammdatenpflege Informationsarchitektur

A

R

C

I

Projekte

I

R, A

C

C

Support

R

R

Training

C

R, A

C

C

R, A

C, I

Kommunikation

I

R: Responsible A: Accountable C: Consulted I: Informed

Abb. 4–3

Zuordnung von Aufgaben zu Rollen (Beispiel) (in Anlehnung an [Otto et al. 2008])

Gremien

Datenqualitätslenkungsausschuss Der Datenqualitätslenkungsausschuss ist das Entscheidungsgremium und hat die finale Entscheidungsvollmacht bezüglich der Umsetzung der vorgeschlagenen Datenqualitätsmaßnahmen. Der Lenkungsausschuss koordiniert die Maßnahmen geschäftsbereichsübergreifend und ist die letzte Eskalationsstufe bei Uneinigkeit über die Umsetzung. Darüber hinaus nimmt der Ausschuss DQ-Standards und -Richtlinien ab. Übliche Zyklen für einen Datenqualitätslenkungsausschuss sind zwei bis vier Meetings im Jahr, um Datenqualitätsziele zu definieren und über Verbesserungsmaßnahmen und weitere Aktivitäten zu entscheiden. Dies gilt unter der Voraussetzung, dass dringliche Probleme auf der Basis häufigerer Meetings in einem operativen Forum, dem sogenannten Datenqualitäts-Jour-Fixe, zur Sprache kommen und einer Lösung zugeführt werden können. Der Datenqualitätslenkungsausschuss entscheidet ggfs. gemeinsam mit der Linienorganisation auch über die Anzahl, Zusammensetzung und Zuordnung der Data Stewards. Datenqualitäts-Jour-Fixe Der Datenqualitäts-Jour-Fixe hat sich in der Praxis als konsensorientiertes Arbeitsgremium bewährt. Teilnehmer sind die Data Stewards und der/die Datenqualitätsmanager. Die Grundidee des Datenqualitäts-Jour-Fixe ist ein unternehmensweiter Austausch und eine Lösung von übergreifenden Datenqualitätspro-

4.2 Ablauforganisation

63

blemen, bei denen mehr als ein Fachbereich betroffen ist. So muss nicht jedes Datenqualitätsproblem an den Lenkungsausschuss weitergeleitet werden. Zum Datenqualitäts-Jour-Fixe lädt der Datenqualitätsmanager ein, er stellt auch die Agenda zusammen und moderiert den Jour Fixe. Als Meeting-Frequenz hat sich in der Praxis ein zwei- bis vierwöchiger Zyklus als sinnvoll erwiesen. Der aktuelle Datenqualitätsstatus und kritische Datenqualitätsprobleme werden besprochen und mögliche Lösungswege identifiziert. Im Fall einer Uneinigkeit oder bei der Notwendigkeit einer Finanzierungsentscheidung auf höherer Ebene wird das Problem an den Datenqualitätslenkungsausschuss weitergeleitet.

4.2

Ablauforganisation

In den Rollenbeschreibungen wurden bereits die Hauptabläufe in Form des Zusammenarbeitsmodells zwischen den Rollen angesprochen. Im Folgenden sollen noch kurz die im Datenqualitätsmanagement relevanten Prozesse dargestellt werden. Konkret wird auf die laufende Datenqualitätssicherung und das laufende Datenqualitätsreporting sowie auf das Datenqualitätsproblem-, Datenqualitätsanforderungs- und Datenqualitätseskalations-Management eingegangen. Zur Einordnung der Prozesse in eine übergeordnete Data bzw. BI Governance (als Teilmenge der IT Governance) wird im Folgenden kurz der Zusammenhang mit den relevanten Prozessen nach ITIL V31 betrachtet. Abbildung 4–4 zeigt den Service-Lebenszyklus nach ITIL V3 mit den darin definierten Prozessen. Continual Service

• Service Catalog Management • Service Level Management • Capacity Management • Availability Management • IT Service Continuity Management • Information Security Management • Supplier Management

Improvement

• Service Measurement & Reporting

Service Design Service Strategy

Service Transition

• Service Desk • Event Management • Incident Management • Problem Management • Access Management • Technical Management • Application Management

Abb. 4–4 1.

proual S ve m e r en vice t

ITIL

Co n I mtin

ice er v t al S e n nu ve m nti ro Co Imp

Service Operation

• Financial Management • Service Portfolio Management • Demand Management

Service-Lebenszyklus nach ITIL V3 (vgl. [Cartlidge et al. 2007])

ITIL = Information Technology Infrastructure Library

• Change Management • Service Asset & Configuration Management • Release & Deployment Management • Knowledge Management

64

4 Organisation

Wie in Tabelle 4–2 dargestellt, korrespondiert der im Folgenden beschriebene Prozess zur laufenden Datenqualitätssicherung und zum laufenden Datenqualitätsreporting mit dem Service Measurement & Reporting nach ITIL. Das Datenqualitätsproblem-Management entspricht dem Incident und Problem Management nach ITIL. Eine Differenzierung in Incidents (einmalig) und Probleme (wiederkehrend) wird in diesem Buch nicht vorgenommen. Das Datenqualitätsanforderungs-Management schließlich entspricht dem Change Management nach ITIL. Für das Datenqualitätseskalations-Management gibt es in ITIL keine direkte Entsprechung. Korrespondierender Prozess nach ITIL

Datenqualitätsprozess

Beschreibung

Laufende Datenqualitätssicherung und -reporting

Behandelt den regulären Prozess zur laufenden Prüfung der Datenqualität und zum Reporting über den Status

Service Measurement & Reporting

DatenqualitätsproblemManagement

Prozess zum Handling von Datenqualitätsproblemen, zu deren Priorisierung und zur Identifikation von Verbesserungsmaßnahmen

Incident Management, Problem Management

DatenqualitätsanforderungsManagement

Behandelt die Aktivitäten zur Priorisierung und von Anforderungen (insbesondere Datenqualitätsmaßnahmen) und zur Initiierung von deren Umsetzung

Change Management

Eskalationsmanagement

Behandelt die Eskalation von ungelösten Datenqualitätsproblemen und Maßnahmen bei Uneinigkeit

–

Tab. 4–2

Datenqualitäts- und IT-Service-Management-Prozesse im Vergleich

Durch die laufende Datenqualitätssicherung werden Probleme identifiziert, die im Datenqualitätsproblem-Management verfolgt werden. Aus einem Problem können Maßnahmen entstehen, die über das DatenqualitätsanforderungsManagement einer Umsetzung zugeführt werden. Laufende Datenqualitätssicherung und -reporting

Wie bereits erwähnt ist jeder Mitarbeiter eines datenqualitätsorientierten Unternehmens zu datenqualitätsorientiertem Handeln verpflichtet, einige Rollen haben jedoch eine weiterführende Verantwortung zur laufenden Datenqualitätssicherung (siehe Abschnitt 4.1). Der Prozess zur laufenden Datenqualitätssicherung und zum laufenden Datenqualitätsreporting beinhaltet alle regulären Aufgaben und Aktivitäten zur kontinuierlichen Prüfung der Datenqualität. Prüfung bedeutet dabei einerseits das Erstellen von Datenqualitätsberichten auf Basis definierter Kennzahlen (siehe

4.2 Ablauforganisation

65

Kap. 7 und 15), andererseits aber auch andere Techniken, wie Ad-hoc-Anfragen via SQL oder die Auswertung von Fehlerlogs von Beladeprogrammen (ETL) zur Befüllung von Data Warehouses oder Data Marts. Technisch geschieht dies durch die IT, fachlich durch die Data Stewards und potenzielle fachliche Systemverantwortliche. Die Frequenz der Datenqualitätsprüfung (Erstellung der Berichte, Prüfung der Beladelogs) ist nach Bedarf zu definieren. Oft orientiert man sich an den Beladezyklen der entsprechenden Datenbereiche im Data Warehouse oder an besonderen Bedürfnissen zur Datenverwendung (z.B. monatliche Controlling-Berichte). Data Stewards führen ihre Analysen in den ihnen zugewiesenen Datenbereichen durch. Identifiziert der Data Steward dabei ein Datenqualitätsproblem, greift der Datenqualitätsproblem-Managementprozess. Außerdem geben die Data Stewards den Datenqualitätsstatus an den Datenqualitätsmanager weiter, der sich zusätzlich der bereichsübergreifenden und konsolidierten Datenqualitätsberichte bedient. Der Datenqualitätsmanager informiert die betroffenen Stakeholder über den Status und über kritische Datenqualitätsprobleme. Der Datenqualitätsmanager berichtet darüber hinaus im Datenqualitätslenkungsausschuss über den Datenqualitätsstatus, nachdem dieser im Datenqualitäts-Jour-Fixe diskutiert wurde. Datenqualitätsproblem-Management

Das Datenqualitätsproblem-Management definiert den Ablauf zum Bearbeiten von Datenqualitätsproblemen und -maßnahmen. Datenqualitätsprobleme sollten in einem Issue-Tracking-Werkzeug, wie es auch in der Softwareentwicklung zum Einsatz kommt, gesammelt und verwaltet werden. Hier kann dann auch ein Workflow nach den definierten Prozessschritten aufgebaut werden, um die Prozessunterstützung zu automatisieren und manuelle Arbeitsschritte zu reduzieren. Datenqualitätsprobleme werden entweder vom Data Steward im Rahmen seiner laufenden Datenqualitätssicherung identifiziert und erfasst oder – wenn sie von einem Anwender bei der Datenverwendung identifiziert werden – erreichen den Data Steward aufgrund seiner Zuständigkeit für einen bestimmten Datenbereich über das Tracking-Werkzeug. Der Data Steward nimmt auch die Bewertung der Kritikalität des Problems vor. Über den Workflow wird dann auch der Datenqualitätsmanager über relevante Datenqualitätsprobleme (je nach Kritikalität) informiert. Datenqualitätsmanager und Data Stewards, ggf. nach Rücksprache mit dem Systemverantwortlichen, identifizieren daraufhin, soweit möglich, eine Maßnahme im Rahmen des Datenqualitätsanforderungs-Prozesses. Dies betrifft insbesondere aufwendigere Maßnahmen, die ein gewisses Budget und Ressourcen zur Umsetzung benötigen. Bei kleineren Maßnahmen (z.B. einer Datenkorrektur) wird üblicherweise die Umsetzung direkt (ohne explizites Anforderungsmanagement) initiiert.

66

4 Organisation

Bei einer Uneinigkeit über den Lösungsansatz oder bei Ausbleiben der Umsetzung einer Maßnahme wird der Eskalationsprozess angestoßen, sprich das Problem wird über den Datenqualitäts-Jour-Fixe (konsensorientiert) an den Datenqualitätslenkungsausschuss weitergeleitet. Auf Basis der Informationen über besonders kritische Datenqualitätsprobleme identifiziert und informiert der Datenqualitätsmanager die betroffenen Stakeholder. Datenqualitätsanforderungs-Management

Üblicherweise wird in Unternehmen kein eigenes DatenqualitätsanforderungsManagement etabliert. Vielmehr folgen Datenqualitätsanforderungen dem regulären Anforderungsprozess von IT-Anforderungen. Der Vollständigkeit halber soll der Prozess hier trotzdem im Kontext Datenqualität dargestellt werden. Das Anforderungsmanagement beinhaltet die Aufgaben und Aktivitäten, die zur Initiierung der Umsetzung von (aufwendigeren) Datenqualitätsanforderungen benötigt werden. Der Prozess behandelt die Identifikation, Sammlung, Kategorisierung und Priorisierung der Anforderungen bis zum Anstoßen der Umsetzung. Die Umsetzung selbst ist nicht mehr Teil des Anforderungsmanagements. Der Data Steward identifiziert Datenqualitätsanforderungen innerhalb seines Datenbereichs. Dies können zum einen Maßnahmen sein, die sich aus Datenqualitätsproblemen ergeben (z.B. aufwendigere Datenkorrekturen), oder auch Anforderungen zur Unterstützung der Datenqualitätssicherung, wie z.B. die Implementierung zusätzlicher Datenqualitätskennzahlen oder -berichte. Die Anforderung wird an den Datenqualitätsmanager zur Koordination weitergegeben (dies kann unter Umständen auch durch ein Anforderungsmanagementsystem, ebenfalls workflowbasiert, unterstützt werden). Der Datenqualitätsmanager sammelt alle Anforderungen, führt eine Vorpriorisierung durch und bringt diese bei Bedarf im Datenqualitätslenkungsausschuss zur Entscheidung. Datenqualitätseskalations-Management

Das Datenqualitätseskalations-Management dient der Eskalation von Datenqualitätsproblemen und überfälligen Datenqualitätsmaßnahmen entlang der Stufen Datenqualitätsmanager – Datenqualitäts-Jour-Fixe – Datenqualitätslenkungsausschuss. Der gleiche Weg wird auch bei Uneinigkeit im Datenqualitäts-Jour-Fixe über Zuständigkeiten von Data Stewards oder Lösungsansätze für Datenqualitätsmaßnahmen gewählt. Ausgelöst wird eine Eskalation üblicherweise von einem Data Steward, der eine Maßnahme für ein von ihm identifiziertes Datenqualitätsproblem initiieren möchte. Erreicht er direkt keine Einigkeit, gibt er das Problem an den Datenqualitätsmanager weiter. Dieser nimmt es für den Datenqualitäts-Jour-Fixe auf die Agenda. Dort wird das Problem diskutiert und eine konsensbasierte Lösung gesucht.

4.3 Empfehlungen

67

Gelingt dies nicht, kommt das Problem bzw. der Streitfall beim nächsten Datenqualitätslenkungsausschuss auf die Agenda. Dort fällt im Zweifel eine Entscheidung per Mehrheitsentscheid. Unabhängig davon, auf welcher Ebene die Entscheidung fällt, ist sie an die betroffenen Stakeholder zu kommunizieren.

4.3

Empfehlungen

Die Umsetzung einer Organisationsstruktur für das Datenqualitätsmanagement ist kein Selbstzweck, sondern eine Notwendigkeit. Um nachhaltig die Datenqualität zu sichern, ist es wichtig, die richtigen Mitarbeiter einzubeziehen und ihnen entsprechende Rollen zuzuordnen. Bereits in der Projektphase für neue BIAnwendungen müssen die späteren Data Stewards benannt und integriert werden. Alle Beteiligten müssen (mit Unterstützung des Sponsors) regelmäßig motiviert werden, die Prozesse zu leben und entsprechend aufrechtzuerhalten. Oftmals ist es allerdings schwierig, Mitarbeiter für diese Datenqualitätsorganisation zu rekrutieren. Zusätzliche Stellen werden nur selten genehmigt, die vorhandenen Mitarbeiter sind zumeist ausgelastet. Die Argumentation, dass durch präventive Datenqualitätssicherung in Summe Ressourcen gespart werden, wird oft nicht akzeptiert. Diese Argumentation ist hinsichtlich des Aufwandes über das gesamte Unternehmen betrachtet meist richtig, für den einzelnen Mitarbeiter oder die einzelne Abteilung allerdings nicht immer. Eine Möglichkeit, solch eine Datenqualitätsorganisation trotz eingeschränkter oder fehlender Ressourcen initial aufzusetzen, ist nun, mit sehr niedrigen Aufwandsschätzungen zu beginnen. Dies könnte bedeuten, dass bestehende Mitarbeiter zu Beginn nur einen sehr geringen Bruchteil ihrer Zeit für Datenqualitätssicherung aufwenden müssen. Wichtig dabei ist, dass einmal ein Überblick über die bestehenden Probleme im Unternehmen erstellt wird und die Datenqualitätsorganisation die wesentlichsten Aufgaben wie Koordination und Kommunikation wahrnimmt. Die nächsten Schritte ergeben sich dann, wenn einmal das Ausmaß der Problematik erkannt und entsprechend dokumentiert wurde.

68

4 Organisation

69

5

Referenzarchitektur für Business-Intelligence-Anwendungen

Das folgende Kapitel fokussiert darauf, zu zeigen, wie man eine gute Architektur im Sinne der Datenqualität konzipieren kann. Zu Beginn wird ein allgemeines Verständnis für eine Business-Intelligence-Architektur entwickelt. Anschließend werden typische Problemstellen in der Architektur benannt. Es wird diskutiert, welche Paradigmen der serviceorientierten Architektur für Datenqualität relevant sind. Am Ende wird kurz auf das Konzept des Master Data Management und seinen Bezug zu Business Intelligence sowie zur Datenqualität eingegangen. Die Tragweite der Problematik der Datenqualität ist erst mit dem Aufbau von BI­Anwendungen richtig ans Tageslicht gekommen. Denn im Data Warehouse werden die Daten nicht mehr nur in einzelnen Datensätzen betrachtet, sondern vom ersten bis zum letzten Datensatz. Sie werden nicht isoliert innerhalb der einen oder anderen Anwendung verwendet, sondern im unternehmensweiten Zusammenhang. Obwohl Datenqualitätsprobleme selten durch die BI­Anwendung verursacht werden, stellen sie für diese seit jeher ein Damoklesschwert dar. Jede BI­Anwendung muss eine gewisse Datenqualität sicherstellen, die sogenannte Akzeptanzschwelle überwinden. Dieser Druck hat dazu geführt, dass sich BI­Architekten früher als andere IT­Architekten dieser Problematik gewidmet haben. Viele Lösungsansätze und Werkzeuge für das Datenqualitätsmanagement wurden in der BI­Welt geboren. Die Architektur einer BI­Anwendung ist die Grundlage für zahlreiche darauf aufsetzende IT­Anwendungen. Es ist wichtig, die Problematik der Datenqualität bereits bei der Aufstellung der Architektur zu adressieren, denn eine Architektur lässt sich im Nachhinein nur mit großem Aufwand ändern.

5.1

Referenzarchitektur

Die Architektur einer Business­Intelligence­Anwendung ist recht komplex. Zum Verständnis ist im Folgenden eine Referenzarchitektur beschrieben, auf der die anderen Kapitel des Buches aufsetzen.

Abb. 5–1

Referenzarchitektur für Business Intelligence

Empfänger Data Steward

Reporting

Analyse

Risiko Mgmt.

Adv. Analytics

Performance Mgmt.

Inf. Discovery

Compliance

BI-Anwendungen (Geschäftsfunktionen, Branchen)

Ersteller

Planung

Scorecarding

Relationship Mgmt.

…

Dashboarding

Operative Anwendungen und Prozesse

Informelle Daten

ODBC

Staging Area

Data Marts

JDBC

Operative IT-Systeme Standard-SW, Individual-SW

SQL

Extraktion

Transformation

Datenqualität

Laden

XML

XML/A

IDOC

Marktdaten D&B, S&P, …

BAPI

PMML

R

MR

Data Streaming

File System

Hive

Big Data Sensor Logs, Social Feeds, Clickstream, Server Logs, Audio, Video, Bilder, Dokumente, …

Enterprise Application Integration

Operational Data Store

ODBO MDX

Stammdaten-Hubs Kunden, Produkte, …

File

Data Warehouse

SQL ODBC JDBC BAPI xQuery

BI-Plattform Portal, Suche, Collaboration, Personalisierung, Semantische Zugriffsschicht, Sicherheit, Scheduling, SDK, Services

BI-FrontendWerkzeuge

Administrator

CWMI

Metadaten

Unstrukturierte Daten

Datenströme

Alerting

Data Profiling

Strukturierte Daten

Datenquellen

Datenintegration

Datenhaltung

Informationsbereitstellung

Anwender und Rollen

70 5 Referenzarchitektur für Business-Intelligence-Anwendungen

Systemmanagement

Prozessmanagement

Metadatenmanagement

5.1 Referenzarchitektur

71

Die in Abbildung 5–1 dargestellte Referenzarchitektur stellt vordergründig die technische Sichtweise dar. Fachliche und infrastrukturelle Aspekte sind weniger reflektiert. Zur Vereinfachung werden nicht sämtliche Details abgebildet, sondern lediglich die hinsichtlich Datenqualität relevanten Komponenten bzw. Services. Der primäre Datenfluss ist von unten nach oben gerichtet. Die datenqualitätsspezifischen Architekturelemente sind durch eine Umrandung hervorgehoben. In den folgenden Abschnitten werden die einzelnen Schichten und Services dieser Referenzarchitektur näher erläutert.

5.1.1

Datenquellen und Datenströme

Die unterste Schicht der Referenzarchitektur umfasst die Datenquellen und -ströme, die sich in verschiedene Kategorien einteilen lassen. Die Quelldaten eines Data Warehouse kommen nicht ausschließlich aus IT­gestützten Systemen. Einige wichtige Daten stammen eher aus informellen Quellen, die meistens auf Office­Produkten wie Microsoft Access und Excel basieren. Häufig speichern Fachbereiche wie Controlling und Marketing in diesen informellen Quellen auf pragmatische Weise Daten mit starker Relevanz für Business Intelligence. Die meisten Quelldaten stammen jedoch aus IT­gestützten operativen Systemen. Das sind einerseits Standardanwendungen für ERP, CRM, SCM, SRM wie z.B. SAP ECC, Oracle Applications, Salesforce.com oder andere. Andererseits sind es individuell entwickelte Anwendungen, die in der Regel die wettbewerbsrelevanten Kernprozesse des Unternehmens abbilden. Neben den IT­Anwendungen, die die Geschäftsprozesse unterstützen, gibt es je nach Entwicklungsstand des Unternehmens bereits Stammdaten­Hubs (auch: Master Data Management). Die Aufgabe von Stammdaten­Hubs ist es, die aus historischen Gründen redundant auf verschiedene IT­Anwendungen und deren Datenhaltungen verteilten Stammdaten konsistent zu halten. Ein Stammdaten­Hub bietet daher eine übergreifende, unternehmensweite, konsolidierte Sicht auf die Stammdaten einer Datendomäne. Typische Stammdatendomänen sind z.B. Kunde, Produkt, Organisationseinheit. Sollte die IT eines Unternehmens über Stammdaten­Hubs verfügen, so werden die Dimensionen des Data Warehouse bevorzugt aus diesen Hubs extrahiert. Nicht alle wichtigen Daten können im Unternehmen selbst erfasst werden. Häufig bringen externe Daten viel Mehrwert in eine Business­Intelligence-Anwendung. Beispiele für »klassische« externe Daten (siehe Kap. 12) sind Marktdaten von Marktforschungsinstituten, geografische und demografische Daten von der Post und anderen Anbietern sowie Adressdaten potenzieller Neukunden. Neben diesen externen Daten, die wir als »klassisch« bezeichnen, gibt es eine Reihe von externen Daten, die im Zuge der Fortentwicklung der IT, insbesondere des Internets, in den letzten Jahren neu dazugekommen sind. In sozialen Medien

72

5 Referenzarchitektur für Business-Intelligence-Anwendungen

(z.B. Facebook, Internetforen) und Blogs befinden sich auswertungsrelevante Daten. Weiterhin gibt es das sogenannte »Internet der Dinge«, das von extern Daten an zentrale Server übermittelt, die analysiert werden. Dazu zählen wir die in modernen Autos zunehmend verbauten Sensoren, Smartmeter1 der Energieanbieter, RFID-Chips u.a. Diese Daten fallen gemeinhin unter den Begriff Big Data. Häufig besitzen sie auch ein großes Datenvolumen. Manche dieser Daten sollen sehr zeitnah, also innerhalb von Stunden, Minuten oder Sekunden, ausgewertet werden, um umgehend darauf zu reagieren. In diesem Fall werden die Daten als fortlaufender Datenstrom gelesen. Neben diesen neuartigen, externen Daten rechnet man auch unstrukturierte Daten zu Big Data. Unstrukturierte Daten können sowohl von intern als auch von extern stammen. Darunter werden Dokumente, E-Mails, Sprache, Bilder und Video verstanden.

5.1.2

Datenintegration

Auf die Quelldatenschicht setzt die Schicht der Datenintegration auf. Sie umfasst die Komponenten, die die Daten aus den Quellen extrahieren sowie in die Strukturen des Data Warehouse bzw. der Data Marts transformieren und laden. Dabei sind beim heutigen Stand der Technik drei wesentliche Technologien zu unterscheiden. Die ETL2­Technologie ist die für die Befüllung eines Data Warehouse gebräuchlichste. Ihre wesentlichen Stärken gegenüber den alternativen Technologien sind die Mächtigkeit der Transformationsfunktionalität, der performante Umgang mit großen Datenvolumen sowie die Behandlung der Datenqualität. Der letztgenannte Aspekt wird im zweiten Teil dieses Buches ausführlich beschrieben. Die größte Schwäche der ETL­Technologie ist die begrenzte Datenaktualität, die letztlich in der Batch­Orientierung der ETL­Technologie begründet ist. Wesentlich mehr Zeitnähe lässt sich mit der EAI3­Technologie erzielen. Diese kann mit Message­basierten Systemen oder auch mit einem Enterprise Service Bus umgesetzt sein. Häufig wird diese Technologie zum Datenaustausch zwischen operativen IT­Anwendungen verwendet. Das Data Warehouse ist dann nur ein weiterer Empfänger von Daten. Die jüngste Datenintegrationstechnologie ist das Data Streaming. Dabei werden die Daten fortlaufend gelesen.

1. 2. 3.

Smartmeter ist ein »intelligenter« Zähler für Energie, z.B. Strom oder Gas, der dem jeweiligen Anschlussnutzer den tatsächlichen Energieverbrauch und die tatsächliche Nutzungszeit anzeigt. Extraktion, Transformation, Laden Enterprise Application Integration

5.1 Referenzarchitektur

5.1.3

73

Datenhaltung

Nach der Datenintegration werden die Daten persistent in einem Data Warehouse gehalten. Optional können Ausschnitte des Data Warehouse zusätzlich auch in Data Marts gehalten werden, die für einen Bereich von Anforderungen speziell aufbereitet sind. Die Datenstrukturen des Data Warehouse orientieren sich an den Informationsanforderungen der Anwender. Sie unterscheiden sich in vielerlei Hinsicht von den Datenstrukturen der Quellsysteme. Big Data bietet neben den klassischen Datenhaltungsformen Dateisysteme als Form der Datenhaltung an. Der wesentliche Vertreter hierfür ist das Hadoop Filesystem. Verglichen mit herkömmlichen Data Warehouses zeichnet es sich insbesondere durch folgende Merkmale aus: ■ ■ ■ ■ ■

Open Source Software kostengünstige Commodity Hardware sehr gute Skalierbarkeit kann sehr große Datenvolumina halten kann auch unstrukturierte Daten halten

5.1.4

Informationsbereitstellung

Um eine heterogene Datenhaltungslandschaft übergreifend auszuwerten, wird mitunter Datenvirtualisierung eingesetzt. Dabei werden die Daten von der Zielanwendung, sei es ein BI­Analysetool oder eine BI­Anwendung, angefordert und erst im Moment der Anforderung aus den betreffenden operativen Datenquellen, Data Warehouse oder Filesystem abgefragt. Hierüber lässt sich eine sehr hohe Datenaktualität erzielen. Auf der anderen Seite sind die Datenvolumen sehr begrenzt. Zudem wird eine hohe Qualität der Quelldaten vorausgesetzt, da sich diese im Zuge der Ad­hoc­Abfrage nicht mehr wesentlich behandeln und bereinigen lässt. Aus Sicht der DQ ist hierbei insbesondere schwierig, dass die Datenbasis für Auswertungen, Joins etc. sehr volatil und daher absehbar ist, dass es zu häufigen Abweichungen von Reports, KPI etc. kommt. Die Bereitstellung der Informationen kann über viele verschiedenartige BI­Frontend­Tools erfolgen. Die am häufigsten zum Einsatz kommenden Produktkategorien sind hierbei Reporting und Analyse (auch OLAP oder Ad­hocQuerying). Alternativ zur Ad-hoc-Analyse besteht die relativ junge Kategorie der sogenannten Information Discovery. Dabei werden die Daten auf explorative und ganzheitliche Weise vom Endanwender betrachtet, weniger kennzahlenbezogen als bei Reporting und Analyse. Weitere BI-Frontend-Kategorien sind u.a. Dashboards (Visualisierung) und Alerting, Scorecards, Planung und Budgetierung sowie Data Mining. Häufig basieren mehrere dieser BI­Frontend­Tools auf derselben BI­Plattform. Die meisten BI­Plattformen kapseln die Datenhaltung in einer semantischen Schicht.

74

5 Referenzarchitektur für Business-Intelligence-Anwendungen

Mit den BI­Frontend­Tools lässt sich nicht nur direkt auf die Daten des Data Warehouse zugreifen. In zunehmendem Maße werden hierzu BI­Anwendungen zu spezifischen fachlichen Themenbereichen mit den BI­Frontend­Tools erstellt. Dabei kann zwischen individuell erstellten Anwendungen und Standardsoftware unterschieden werden. Das Business­Intelligence­Portal kapselt den Zugriff der Endanwender auf Tools und Anwendungen und implementiert einen Single Point of Access für verschiedene Anwender auf die diversen Tools und Anwendungen. Business Intelligence Services sind ein oft verwendetes Mittel, um Informationen und Wissen aus der BI-Anwendung für operative Prozesse und Anwendungen verfügbar zu machen.

5.1.5

Anwender und Rollen

Ersteller von Berichten, Analysen und anderen BI­Komponenten definieren mittels der BI­Frontends die Abfragen samt Formatierung, Visualisierung und Workflow. Die Konsumenten verwenden die definierten BI­Komponenten bzw. ­Anwendungen. Administratoren verantworten die Prozesse auf Software­ und Hardwareebene. Data Stewards steuern alle Aktivitäten rund um die Sicherstellung der Qualität der Daten und sind Ansprechpartner für Probleme mit Dateninhalten. Die Aufgaben von Data Stewards werden in Kapitel 4 ausführlich beschrieben.

5.1.6

Operative Anwendungen und Prozesse

Business Intelligence wird in zunehmendem Maße auch in operative Prozesse bzw. Anwendungen eingebettet (sog. Operational Business Intelligence). Durch die Anreicherung operativer Prozesse mit dem in der BI­Anwendung aufgebauten Wissen lassen sich diese intelligenter gestalten.

5.1.7

Querschnittsprozesse

Das Prozessmanagement steuert die Prozesse der Datenintegration sowie der Informationsbereitstellung. Das Systemmanagement stellt die Funktionsweise von Soft­ und Hardware sicher. Metadaten fallen an vielen Stellen der BI­Anwendung an. Entsprechend schwierig ist es, einen übergreifenden und konsistenten Blick auf die Metadaten zu gewinnen. Das ist die Aufgabe des Metadatenmanagements (siehe Kap. 14).

5.2 Problemstellen und Lösungsansätze hinsichtlich der Datenqualität

5.2

75

Problemstellen und Lösungsansätze hinsichtlich der Datenqualität

Dieser Abschnitt bezieht sich auf die zuvor dargestellte Referenzarchitektur für Business­Intelligence­Anwendungen (siehe Abb. 5–1). Dabei werden Problemstellen in der Architektur hinsichtlich der Datenqualität benannt. Der Übersichtlichkeit halber sind die Problemstellen jeweils einer Schicht der Referenzarchitektur zugeordnet. Einige Lösungsansätze müssen primär durch Design oder entsprechende Governance adressiert werden, wie z.B. Change Data Capture und Spread Marts. Viele Lösungsansätze hingegen sind unter dem Begriff Datenqualitätsmanagement gebündelt und lassen sich mit Werkzeugen unterstützen. Diese werden in anderen Kapiteln, vor allem im zweiten Buchteil, in der Tiefe behandelt. Die elementaren Problemstellen für Datenqualität sind die Datenerfassung und Datenflüsse. Datenerfassung ist in einer Business­Intelligence­Anwendung eher selten. Mitunter werden Stammdaten direkt im Data Warehouse erfasst oder es werden Plandaten für Simulationen in operative Bestände übernommen. In der Regel aber werden die Daten aus den Quellsystemen extrahiert. Die dabei definierten Datenflüsse bergen einerseits ein hohes Risiko der Datenverfälschung, andererseits aber auch die Chance zur Datenbereinigung. Praktisch stellt die Schicht der Datenintegration – und darin wiederum der Schritt der Datentransformation – den Schwerpunkt bezüglich des Datenqualitätsmanagements innerhalb der Business­Intelligence­Architektur dar.

5.2.1

Datenquellen

Redundante Datenhaltung

Operative Daten liegen aus verschiedenen Gründen in mehreren Anwendungen verteilt vor. Insbesondere Stammdaten werden häufig redundant in mehreren Anwendungen gepflegt, was zwangsläufig zu Abweichungen der Dateninhalte führt. Verteilte Datenhaltung

Operative Daten liegen mitunter verteilt in verwandten Anwendungen, aber an mehreren Standorten des Unternehmens vor. Insbesondere bei internationalen Konzernen oder nach Unternehmensübernahmen fällt dieses Problem ins Gewicht. Die Dateninhalte sind dann häufig landesspezifisch unterschiedlich definiert. Bei der zentralen Erstellung einer Bilanz oder auch im Meldewesen ist es problematisch, diese Diskrepanzen wieder aufzulösen.

76

5 Referenzarchitektur für Business-Intelligence-Anwendungen

Konsistenz und Zeit

Mitunter sind operative Systeme phasenweise nicht konsistent. Häufig müssen erst bestimmte Tagesend­Batches laufen, bevor die Daten konsistent extrahiert werden können. Bei global agierenden Unternehmen spielt auch die Zeitverschiebung eine wichtige Rolle. Ein Börsentag in New York hat andere Anfangs­ und Endzeiten als der in Frankfurt und Tokio.

5.2.2

Datenintegration

Medienbrüche

Zwischen den Quellsystemen und der BI­Anwendung können Medienbrüche Probleme bei der Datenqualität verursachen. Ein Teil der Daten kann bei der Übertragung verloren gehen. Unterschiedliche Zeichensätze in Quelle und Ziel bzw. der Wechsel der Betriebssystem­Plattform können zu Problemen führen. Konsolidierung verschiedener Quellen

Nicht selten gibt es zu einem Zieldatenobjekt mehrere Quellobjekte, deren Strukturen voneinander abweichen. Es ist eine elementare Aufgabe des Data Warehouse, unterschiedliche Quellstrukturen zu konsolidieren, also auf einen gemeinsamen Nenner zu bringen. Das ist nicht immer in Gänze und unter dem Gesichtspunkt der Datenqualität möglich. Datenredundanz

Im Data Warehouse ist es erlaubt, Daten redundant zu halten, wenn dies den Prozess der Informationsbereitstellung zum Anwender oder der Anwendung wesentlich vereinfacht bzw. beschleunigt. Typische Datenredundanzen entstehen durch das Star­Schema (vgl. [Kimball 2002]) mit denormalisierten Dimensionen sowie die Haltung zusätzlicher Aggregate (z.B. Materialized Views bzw. Query Tables). Um Problemen mit der Datenqualität vorzubeugen, sollten die Transformationen der Basisdaten zu den redundanten Daten einfach gehalten werden. Weiterhin ist das Management der Synchronisation wichtig, um die Konsistenz nach Änderungen sicherzustellen. Historisierung

Eine wesentliche Aufgabe des Data Warehouse ist die Historisierung der Daten, die im Prozess der Datenintegration umzusetzen ist. In der Praxis gestaltet sich das oft schwierig, wenn die Quellen keine oder nur unzureichende Angaben zur zeitlichen Entwicklung eines Datenobjekts machen.

5.2 Problemstellen und Lösungsansätze hinsichtlich der Datenqualität

77

Häufig wird nur der aktuelle Stand des Datenobjekts persistent gehalten. Zwischenstände zwischen den Zeitpunkten zweier aufeinander folgender Datenextraktionen gehen so bei einer rein Batch-orientierten ETL-basierten Datenintegration verloren. Wenn dieser Umstand nicht akzeptabel ist, sollte man daher über Varianten zur fortlaufenden Datenextraktion nachdenken. Das ist möglich über einen Message-basierten Ansatz. Dabei werden sämtliche oder ausgewählte Datenmodifikationen aus dem Quellsystem in eine Message Queue propagiert, die dann vom Zielsystem lückenlos abgearbeitet wird. Einen ähnlichen Ansatz verfolgt das Konzept des Change Data Capture (siehe Abb. 5–2). Dabei werden die Änderungen durch die Quellanwendung (z.B. SAP) oder das Datenbankmanagementsystem (z.B. Oracle) der Quelle in ein Change Log protokolliert. Der Schritt der Datenextraktion erfolgt dann nicht auf dem Quellsystem, sondern auf dem Change Log. Pull-Ansatz

Datenziele Zentralisierte Daten

Datenintegration Datenkonsolidierung

Staging Area Push-Ansatz Protokollierung der Datenänderungen

Datenquellen

Abb. 5–2

Konzept des Change Data Capture

Wenn die Quelle noch nicht einmal über Zeitstempel verfügt, ist die Qualität des Zeitbezugs vollkommen in Frage gestellt. Gut ist es, wenn Quelldaten nicht nur mit einem Zeitstempel, sondern mit einem Gültigkeitszeitraum hinterlegt sind – optional, und nur falls notwendig, zusätzlich mit dem Zeitraum des Kenntnisstands. Genau genommen sollten sich diese temporalen Angaben nicht nur auf einen gesamten Datensatz, sondern auf jedes einzelne Element beziehen. Es ist augenscheinlich, dass die aufgestellte Idealvorstellung in der Praxis nicht mit einem akzeptablen Aufwand­Nutzen­Verhältnis abzubilden ist. Stetiger Konflikt-

78

5 Referenzarchitektur für Business-Intelligence-Anwendungen

punkt ist der Umgang mit Wiederholungsläufen, Korrekturlieferungen, Tagesabgrenzungen (bei unterschiedlichen Zeitzonen oder verspäteten Lieferungen). Aber punktuell sind diese Ansätze sehr wohl wichtig und finden auch Anwendung. Beispielsweise sind Versicherungen sehr akribisch in der temporalen Beschreibung ihrer Verträge mit den Kunden. Right Time Data Integration

Neben der Unterstützung strategischer Entscheidungen wird in zunehmendem Maße von Business-Intelligence-Lösungen auch die Unterstützung operativer Entscheidungen erwartet. Häufig ist es in dem Zuge erforderlich, Daten aus operativen Geschäftsprozessen sehr zeitnah in das Data Warehouse zu laden. Man spricht dann von Right Time Data Integration. Hierbei sind der klassischen Datenintegrationstechnologie ETL Grenzen gesetzt. Es kommen andere Technologien wie Change Data Capture, Enterprise Application Integration/Enterprise Service Bus, Data Streaming oder auch Enterprise Information Integration (Data Federation) zum Einsatz. Unter dem Zeitdruck und aufgrund der begrenzten Möglichkeiten der alternativen Datenintegrationstechnologien bezüglich Datentransformation werden dabei häufig Kompromisse hinsichtlich der Validierung, Behandlung und Bereinigung der Qualität zu ladenden Daten gemacht. Es ist daher wichtig, eine Überwachung der Qualität der so geladenen Daten durchzuführen und zu prüfen, ob die erreichte Datenqualität ausreichend zuverlässig für die zu unterstützende operative Entscheidung ist. Eine weitere Anregung ist, die zeitnah geladenen Daten in separate Datenbereiche zu laden und als qualitativ minderwertig zu kennzeichnen (siehe Abb. 5–3). So vermeidet man, dass Daten unterschiedlicher Qualität in denselben Datenobjekten stehen und letztlich der Endanwender bzgl. der tatsächlich vorhandenen Datenqualität in die Irre geführt wird. Informationsbereitstellung

Unternehmensweites Data Warehouse

Right Time Data

Enterprise Application Integration

Historical Data

Extraktion, Transformation, Laden

Quelldatenbank

Abb. 5–3

Separierung von Right Time Data

5.2 Problemstellen und Lösungsansätze hinsichtlich der Datenqualität

5.2.3

79

Datenhaltung

Datenstrukturen

Die Datenstrukturen von Quelle und Ziel sind nach anderen Gesichtspunkten definiert: Leitlinie für die operativen Quellsysteme ist es, redundanzarme Strukturen aufzustellen. Ein Data Warehouse hingegen orientiert sich an den Informationsanforderungen der Endanwender. Dabei spielen u.a. Übersichtlichkeit, Darstellung von Hierarchien, Verdichtung sowie der Zeitbezug eine wichtige Rolle. Datenelemente werden in Kennzahlen und Dimensionen kategorisiert und nach einem Schema gezielt angeordnet. Die Übertragung der Dateninhalte von der Quell­ in die Zielstruktur kann schnell sehr komplex werden. Nicht immer kann der Designer der Transformation die hintergründigen oder unzureichend dokumentierten fachlichen Ideen der Quellstrukturen nachvollziehen. Spread Marts

Aus IT­Sicht werden die im Data Warehouse oder in Data Marts vorgehaltenen Informationen über BI­Frontends wie Reporting­ und Analyse­Tools direkt für den Endanwender bereitgestellt. In der Praxis ist es jedoch häufig so, dass Endanwender die angebotenen Daten lediglich als Rohdaten ansehen und in MS Excel oder Access weiterverarbeiten. Die in Excel gehaltenen Daten bezeichnet man als Spread Marts. Typische Ursachen dafür sind mangelnde Kenntnis des BI­Frontends sowie eine nicht hundertprozentige Abdeckung der für die Auswertung erforderlichen Daten. Diese Datenverarbeitung durch den Endanwender senkt nicht nur die Wirtschaftlichkeit der Business­Intelligence­Anwendung, sondern ist Quelle für Datenverfälschungen. Zudem wird die Idee des Single Point of Truth damit ad absurdum geführt. Schlussendlich verstoßen Spread Marts auch gegen die Compliance­Richtlinien. Filesystem

Dateisysteme werden im Gegensatz zu klassischen Data Warehouses meistens sehr zeitnah und ohne umfassende Transformation sowie Datenqualitätsbehandlung beladen. Sie können deutlich größere Datenvolumina fassen. Ein bewährter Ansatz ist, die hier bereitgestellten Daten explorativ zu betrachten und die Datenausschnitte von hoher Analyserelevanz zu ermitteln, diese dann auf geordnete Art und Weise in das Data Warehouse zu laden und die Qualität der Daten zu sichern, um danach auf valider Datenbasis wichtige Analysen zu initiieren.

80

5.2.4

5 Referenzarchitektur für Business-Intelligence-Anwendungen

Informationsbereitstellung

Interpretation von Dateninhalten

Selbst wenn das Data Warehouse korrekte Daten enthält, können Anwender die bereitgestellte Information mitunter fehlerhaft interpretieren. Häufig sind Daten nicht selbstsprechend, sondern brauchen eine Erklärung; diese zusätzlichen Informationen werden häufig auch als fachliche Metadaten bezeichnet. Dazu gehören beispielsweise Angaben zur Aktualität der Daten, eine eindeutige fachliche Beschreibung, die Ableitungsformel oder die Angabe von Synonymen (siehe Kap. 14). Data Mining

Neben Reporting und Analyse ist Data Mining ein Weg, um aus den bereitgestellten Informationen Wissen zu extrahieren. Im Gegensatz zu Reporting und Analyse ist Data Mining jedoch zum größten Teil ein maschineller Prozess, d.h. kaum unter der Kontrolle eines Anwenders. Deswegen ist es für Data Mining besonders wichtig, dass die bereitgestellten Daten bzw. Informationen eine ausreichend hohe Qualität haben, damit es nicht zu Fehlinterpretationen kommt. Aus diesem Grund bieten einige Data-Mining-Tools auch eine eigene Data­Profiling­Funktionalität an. Auf diese Weise kann sich derjenige, der die Daten für den DataMining­Prozess bereitstellt, ein Bild über die Qualität der Quelldaten machen. Self Service Business Intelligence

Ein Problem des IT-getriebenen Data-Warehouse-Ansatzes ist die große Zeitspanne zwischen der Formulierung fachlicher Anforderungen und dem Rollout der betreffenden Lösungen bzw. Änderungen an den Lösungen. Häufig wird diese Zeitspanne von den Fachanwendern nicht länger akzeptiert. Die Fachanwender stehen unter dem Zeitdruck eines sich sehr rapide ändernden Markts. Sie suchen nach mehr Agilität in der Bereitstellung von Daten und Informationen für ihre Analysen. Einige Anbieter von BI-Frontend-Werkzeugen bieten die inzwischen etablierte Funktionalität für sogenanntes Self Service BI. Dabei können Fachanwender selbst die Datenquellen – Data Warehouses, Dateisysteme, informelle Daten u.a. – festlegen. Meistens verfügen diese Werkzeuge über eigene Datenhaltungen, redundant zum Data Warehouse. Durch den Einsatz von In-MemoryTechnologien lassen sich dabei Antwortzeiten auf explorative Abfragen erzielen, die häufig deutlich besser sind als die klassischer BI-Plattformen auf Data Warehouses. Der wesentliche Nachteil dieses Self-Service-BI-Ansatzes ist, dass durch die Verknüpfung mit ungesicherten Daten Probleme mit der Datenqualität entstehen können, unter anderem:

5.3 Architektur für Datenqualitätsmanagement

■ ■ ■ ■

81

Probleme bei der Nachvollziehbarkeit von Ergebnissen Dokumentation der Lösungen Zuständigkeiten im Vertretungsfall unterschiedliche Sichtweise zu standardisierten Kennzahlen

5.3

Architektur für Datenqualitätsmanagement

Zur Unterstützung des Datenqualitätsmanagements gibt es eine Reihe sehr spezialisierter Werkzeuge und anderer Infrastrukturkomponenten. Die im Folgenden dargestellte Referenzarchitektur für Datenqualitätsmanagement (siehe Abb. 5–4 und 5–5) gibt darüber einen Überblick. Detaillierte Beschreibungen der Funktionalität und Möglichkeiten der Werkzeugunterstützung folgen im zweiten Teil des Buches. Die Referenzarchitektur für Datenqualitätsmanagement bettet sich in die Gesamtarchitektur für Business Intelligence ein, größtenteils in die Schicht der Datenintegration. Die Referenzarchitektur deckt einerseits den Entwicklungsprozess, andererseits den Prozess zur Laufzeit von Datenintegration mit Datenqualitätsmanagement ab. In den frühen Phasen der Entwicklung können Data­Profiling­Werkzeuge zum Einsatz kommen, um die Quelldaten hinsichtlich ihrer Inhalte und Qualität automatisiert zu explorieren. Eigenschaften wie Struktur, Formatierung, Muster, Wertelisten, Wertebereiche, Referenzen, Vollständigkeit u.a. werden dabei betrachtet. Daneben ist auch die Möglichkeit der manuellen Datenexploration zu berücksichtigen. In der Folge werden aus Profilen Datenregeln abgeleitet oder auch manuell definiert. Schließlich werden Kennzahlen zur Messung der Datenqualität aufgestellt. Darüber hinaus kann Data Profiling auch bei laufenden Data Warehouses sinnvoll sein, um den Status der Datenqualität festzustellen.

Exploration

Definition der Datenregeln

Definition von DQKennzahlen

Reference Data

Data Integration

Repository Data Quality

Data Sources

Data Profiles

Data Rules

Standardization Rules

Custom Cleanse Rules

Match Rules

Merge Rules

Quality Measures

Monitoring Results

Mappings

Abb. 5–4

Profiling

Data Targets

Names

Addresses

Companies

…

Referenzarchitektur für Datenqualitätsmanagement während der Entwicklung

82

5 Referenzarchitektur für Business-Intelligence-Anwendungen

Die Laufzeitdienste des Datenqualitätsmanagements sind in die Schicht der Datenintegration der Referenzarchitektur (siehe Abb. 5–1) eingebettet. Beim heutigen Stand der Technik trifft das jedoch nur auf die ETL­Technologie zu, weniger bis gar nicht auf die Enterprise Service Bus bzw. Enterprise Information Integration. Zur Laufzeit eines Datenintegrationsprogramms werden die gelesenen Daten gegen die aufgestellten Datenregeln geprüft. Im Rahmen der Datenbereinigung werden die Quelldaten zuerst standardisiert. Anschließend werden Name, Adresse und ggf. weitere Datenfelder bereinigt, ehe es zur Duplikaterkennung kommt. Clustering ist ein optionaler Schritt. Häufig wird diese Methode zur Bildung von Haushalten eingesetzt. Haushaltsbildung basiert technisch auf der Match­and­Merge­Funktionalität. In einem späteren Schritt können Daten auch angereichert werden. Ein Beispiel für Anreicherungen ist das Zuordnen externer geografischer und demografischer Daten. Alle Teilschritte protokollieren Informationen über die Qualität der gelesenen Daten. Zudem werden die definierten DQ­Kennzahlen auf die verarbeiteten Daten angewendet, sodass am Ende ein DQ­Bericht erstellt werden kann. Dieser löst eine Analyse der DQ­Probleme aus, die zu adäquaten DQM­Maßnahmen führt.

Data Integration Data Sources

Data Targets

Mappings

Validierung

Standardisierung

Reference Data

Repository Data Quality Data Profiles

Data Rules

Standardization Rules

Match Rules

Merge Rules

Quality Measures

Bereinigung Name, Adresse, ...

Custom Cleanse Rules Monitoring Results

Duplikate Vergleichen, Zusammenführen

Names

Addresses

Companies

…

Clustering

Monitoring Prozess

Anreicherung

DQBericht, Problemanalyse, Maßnahme

API

Abb. 5–5

Referenzarchitektur für Datenqualitätsmanagement zur Laufzeit

Die Laufzeitdienste (Runtime Services) von der Validierung bis zur Anreicherung lassen sich in Prozessen kombinieren und auch über Schnittstellen von externen Services, Prozessen oder Anwendungen aufrufen. Alle Schritte des DQM vom Data Profiling bis hin zur Überwachung der Datenqualität legen ihre Ergebnisse in Form von Metadaten ab. Idealerweise sind diese Metadaten in einem zentralen Repository integriert. Zudem macht auch die Nähe zum Repository für Datenintegration viel Sinn. Es gibt viele Querbezüge zwischen Datenintegration und DQM. So beziehen sich Data Profiles auf die

5.4 Serviceorientierte Architektur

83

zugrunde liegenden Quellsysteme. Mappings wenden Datenregeln an und binden Regeln zu Standardisierung, Bereinigung sowie Match­and­Merge ein. Die zentral abgelegten DQM-Metadaten können offline zum Qualitätsmanagement verwendet werden, indem bspw. Analysen über Laufzeiten und Umfang der Daten mit entsprechenden Prädiktionsverfahren durchgeführt und im Sinne eines Frühwarnsystems frühzeitig für DQM-Aufgaben eingesetzt werden. Neben diesem Repository gibt es noch eine Sammlung von Referenzdaten für gebräuchliche Namen im Kontext von Sprachräumen, Adressen innerhalb eines Landes mit Postleitzahlen und Orten sowie ggf. weiteren Domänen. Diese Referenzdaten werden von einigen Anbietern gesammelt, aktualisiert und kostenpflichtig zur Einbindung in Funktionen der Datenintegration und ­qualität angeboten. Die Bereinigung von Namen und Adressen benötigt Referenzdaten. Auch die Duplikaterkennung lässt sich mit Referenzdaten unterstützen. Die Schnittstellen zum Zugriff auf die Referenzdatenbasen sind meistens proprietär. Deswegen muss geprüft werden, welche Referenzdatenbasen sich vom eingesetzten DQMWerkzeug einbinden lassen. Folgende Trends bestehen im Zuge der Produktstandardisierung, Marktkonsolidierung und funktionalen Fortentwicklung bei den Werkzeugen für Datenqualitätsmanagement: ■ Die meisten Produkthersteller bieten heute integrierte Suiten bzw. Plattformen für Datenqualitätsmanagement an, die die verschiedenen Funktionalitäten in Summe abdecken. ■ Aufgrund der starken Abhängigkeit des Datenintegrationsprozesses vom Datenqualitätsmanagement haben die Produkte beider Produktkategorien einen hohen Integrationsgrad erreicht und werden selbigen auch weiter erhöhen. Es gibt jedoch auch andere Bereiche in der IT, die sich in zunehmendem Maße von Datenqualitätswerkzeugen unterstützen lassen: Master Data Management bindet DQ­Produkte ebenfalls ein. Operative Anwendungen binden von DQ­Produkten bereitgestellte Services wie z.B. Adressprüfung ein. ■ Für ausgewählte Domänen wie z.B. Kundendaten bieten einige Hersteller bereits Lösungen oder zumindest Frameworks an, die sie basierend auf vielen verschiedenen Projekten erarbeitet haben. Dazu gehören vordefinierte, domänenspezifische DQ­Kennzahlen wie auch Regeln für Match­and­Merge, z.B. für Kundenduplikate, sowie Regeln zur Validierung von Daten, z.B. für ausgewählte Datenformate wie Telefonnummern.

5.4

Serviceorientierte Architektur

Das Konzept der serviceorientierten Architektur (SOA) stellt die Datenebene zwar nicht in den Mittelpunkt, durch das Domänenmodell einer SOA (siehe Abb. 5–6) gibt es jedoch Berührungspunkte zum Thema Datenqualität, die im Folgenden dargestellt werden.

84

5 Referenzarchitektur für Business-Intelligence-Anwendungen

Domänen werden durch fachliche Anforderungen bestimmt. Sie gruppieren fachlich eng zusammenhängende Geschäftsprozesse, Geschäftsfunktionen und eben auch Geschäftsdaten. In einer Domäne liegt die Datenhoheit für die ihr zugeordneten Informationsobjekte. Informationsobjekte repräsentieren zusammenhängende Informationen im fachlichen Modell einer Domäne.

Abb. 5–6

Subdomäne

Subdomäne

Informationsobjekt

Informationsobjekt

Genutzte Services

Angebotene Services

Domäne

Domänenmodell einer SOA

Um eine bestehende IT­Anwendungslandschaft in eine serviceorientierte Architektur zu überführen, gibt es verschiedene alternative Ansätze. Ein Ansatz ist die Domänenbildung, also der Schnitt einer Anwendungslandschaft in Domänen (siehe Abb. 5–7). Dieser datenzentrierte Ansatz zu einer SOA löst die fachlich zusammenhängenden Daten­ bzw. Informationsobjekte aus den IT­Anwendungen – meistens mehrere – heraus und bringt sie in einer Domäne zusammen. Somit wird zumindest auf Modellebene eine Integration der Daten erzielt, d.h., Ursachen schlechter Datenqualität wie redundante, verteilte Datenhaltung werden adressiert. Domäne: Geschäftspartner

Domäne: Konten

Geschäftspartner

Rechnungskonto

Erreichbarkeit

Geschäftspartnerrolle Geschäftspartnerbeziehungen

Domäne: Vereinbarungen Vertrag

Abb. 5–7

Bonuskonten

Domäne: Assets

Domäne: Produkte

Gebäude

Produkt

Lagerbestand

Dienstangebot

Beispiel für eine datenzentrierte Domänenbildung

Durch das Prinzip der Datenhoheit und die Festlegung von Domänenverantwortlichen werden zwei organisatorische Aspekte angesprochen, die sich sinnvoll mit Datenqualitätsmanagement verknüpfen lassen.

5.5 Master Data Management

5.5

85

Master Data Management

Master Data Management (MDM) hat mehrere enge Bezüge zur Integration und zum Management der Qualität von Daten. Aus diesem Grunde beschreibt dieser Abschnitt kurz das Thema Master Data Management und stellt die Bezugspunkte von MDM zur Datenintegration und zum Datenqualitätsmanagement her. Master Data Management bezeichnet eine zentrale, qualitätsgesicherte Verwaltung von Stammdaten, um system­ und anwendungsübergreifende Konsistenz und Integrität sicherzustellen. Häufig anzutreffende Domänen von Stammdaten sind Kunde, Produkt, Lieferant, Konto oder Einwohner. Master Data Management umfasst einerseits technische Komponenten, andererseits aber auch eine Sammlung von Best Practices und schließlich auch die Data Governance. Es gibt eine Reihe von Problemstellungen, die den Einsatz von Master Data Management motivieren: ■ Stammdaten zu Kunden, Produkten u.a. sind über mehrere IT­Systeme des Unternehmens verteilt. Sie werden redundant gehalten. Die Redundanz führt unweigerlich zu Inkonsistenzen. ■ Stammdaten sind in den verschiedenen Systemen uneinheitlich abgelegt. ■ Verschiedene IT­Anwendungen arbeiten mit unterschiedlichen Stammdaten. Die Funktionen zum Datenzugriff sind redundant und uneinheitlich. ■ Die Qualität der Stammdaten ist mangelhaft. Es gibt Duplikate. Namen und Angaben zu Adressen von Kunden sind nicht korrekt erfasst worden oder wurden bei der weiteren Verarbeitung, ggf. auch bei Datenmigrationen, verfälscht. ■ Stammdaten liegen nicht aktualisiert vor. Aus den vorgängig dargestellten Problemen leiten sich die Zielsetzungen von Master Data Management ab. Diese sind vor allem: ■ Es wird eine zentrale Stammdatensicht bereitgestellt. Dies kann eine persistente, zentrale Stammdatenhaltung sein, jedoch gibt es auch andere Varianten. ■ Stammdaten werden den Services und Anwendungen in einer einheitlichen, konsistenten Sicht bereitgestellt. ■ Die Qualität der Stammdaten wird verbessert durch Datenbereinigung sowie Duplikaterkennung und ­behandlung (teilweise automatisiert, teilweise manuell). ■ Änderungen an Stammdaten werden zeitnah zwischen den betreffenden Anwendungen bzw. einer ggf. vorhandenen zentralen Stammdatenhaltung abgeglichen (vgl. [Scheuch/Gansor/Ziller 2012]).

86

5.5.1

5 Referenzarchitektur für Business-Intelligence-Anwendungen

Architektur

Die grundsätzlichen Komponenten einer Lösung für Master Data Management sind in der folgenden Referenzarchitektur (siehe Abb. 5–8) dargestellt. Die Services der Datenintegration werden in Online­Services (Komponenten zur Laufzeit) und Offline­Services unterschieden. Sie sind in hohem Maße vergleichbar mit den Services in den Bereichen Datenintegration und Datenqualitätsmanagement, die im vorangegangenen Abschnitt beschrieben wurden. Präsentationsdienste bieten einerseits Möglichkeiten für Recherche und Navigation in Stammdaten, andererseits aber auch Unterstützung zur manuellen Datenbereinigung, insbesondere zum manuellen Auflösen (Merge) von automatisiert (Match) erkannten Duplikatkandidaten. Natürlich ist IT­Unterstützung für Datenbereinigung erwünscht. Aber nicht immer lässt sich hundertprozentig verlässlich mit Regeln beschreiben, wie Daten zu bereinigen sind. Aus diesem Grund ist eine Arbeitsteilung zwischen IT­System und Data Steward häufig sehr sinnvoll. Im Prozess der Datenintegration werden dabei Datenverunreinigungen ermittelt und zur manuellen Weiterverarbeitung an den Data Steward gegeben. Ein Beispiel hierfür ist der Dialog zur manuellen Auflösung von Duplikaten (siehe Abb. 5–9). Anwender und Rollen

Administrator

Präsentation

Data Steward

Search & Edit

Merge Duplicates

Reporting

Master Data Master Data Model

Offline

Match & Merge Cleansing Mapping Adapters

Datenquellen/ -ziele

Abb. 5–8

Anwendungen

Data Import

Data Export

Externe Daten

Referenzarchitektur für Master Data Management

Process Management

Online

Runtime Management

Datenintegration

Communication Services

Master Data Base

5.5 Master Data Management

Abb. 5–9

87

Beispielhafter Dialog zur manuellen Auflösung von Duplikaten

Für die Umsetzung einer Lösung zum Master Data Management gibt es in der Praxis verschiedene Architekturvarianten. Die drei gebräuchlichsten werden im Folgenden kurz beschrieben: ■ Bei der Architekturvariante »Registrierung« (siehe Abb. 5–10) werden die Stammdaten weiterhin dezentral durch verschiedene Anwendungen gepflegt. Die zentrale Stammdatensicht ist quasi virtuell und wird erst zum Zeitpunkt der Anfrage dynamisch erstellt. Auf sie kann nur lesend zugegriffen werden. Vorab werden die Stammdatensätze durch Match­and­Merge zugeordnet. Globale Schlüssel für Stammdateneinträge werden definiert und Verweise auf die zugehörigen Datensätze in den Spokes (dezentralen Anwendungen) registriert. Nur diese Metadaten werden zentral und persistent abgelegt.

Anwendung

Anwendung R

Virtuelle Master Data View R

R

Datenhaltung

Datenföderation

Datenhaltung

Anwendung 1

Master Data Management

Anwendung 2

Abb. 5–10

Architekturvariante Registrierung

■ Bei der Architekturvariante »Koexistenz« (siehe Abb. 5–11) werden die Stammdaten zeitversetzt konsolidiert. Die Stammdaten können weiter durch verschiedene Anwendungen gepflegt werden. Änderungen der Stammdaten werden durch Datenkonsolidierung mit einer gewissen Latenz in die zentrale Stammdatensicht (Master Data Base) eingearbeitet. Es besteht eine Koexis-

88

5 Referenzarchitektur für Business-Intelligence-Anwendungen

tenz (auch Redundanz) zwischen zentraler Stammdatenanwendung/­datenhaltung und dezentraler Stammdatenpflege/­haltung.

Anwendung

Anwendung R

Master Data Base R

R

Datenhaltung

Datenkonsolidierung

Datenhaltung

Anwendung 1

Master Data Management

Anwendung 2

Abb. 5–11

Architekturvariante »Koexistenz«

■ Bei der Architekturvariante »Transaction Hub« (siehe Abb. 5–12) wird auf die Stammdaten über Services zugegriffen. Die Stammdaten werden ausschließlich in der zentralen Stammdatenhaltung gepflegt. Alle Lese­/Schreibzugriffe von Anwendungen auf Stammdaten erfolgen über Services, die auf der zentralen Stammdatenhaltung basieren und durch die Master-DataManagement-Anwendung bereitgestellt werden. Bei dieser Variante sind die Paradigmen der Serviceorientierten Architektur in Gänze umgesetzt.

Anwendung 1

Anwendung 2

Abb. 5–12

Architekturvariante »Transaction Hub«

R Master Data Base Master Data Management

5.5 Master Data Management

89

Die wesentlichen Unterschiede der genannten Varianten bestehen in folgenden Aspekten: ■ Werden die Stammdaten zentral oder dezentral gepflegt? ■ Sind Lese­ und Schreibzugriffe auf die Masterdatenbasis gleichermaßen möglich? ■ Wie konsequent sind die Paradigmen der Serviceorientierten Architektur umgesetzt? Die verschiedenen Varianten ermöglichen es den Unternehmen, je nach ihrem spezifischen Entwicklungsstand eine passende Master-Data-Management-Lösung zu etablieren.

5.5.2

Umsetzung

Die Umsetzung einer serviceorientierten Architektur in der IT­Anwendungslandschaft eines Unternehmens erfordert zwangsläufig eine Master­Data­Management­Lösung. Benötigt ein Prozess oder Service Stammdaten für seine Verarbeitung, bedarf es dazu genau eines anwendungsneutralen MDM­Service, der diese Stammdaten in konsolidierter, konsistenter Form bereitstellt. Master Data Management ist eine Konsequenz der Umsetzung des Domänenschnitts einer SOA. Eine Domäne umfasst die fachlich eng zusammengehörenden Daten, z.B. Kundendaten. Für jede Domäne gibt es einen Domänenverantwortlichen. Datenintegration ist ein elementarer Bestandteil einer Lösung für Master Data Management. Die hier verwendeten Datenintegrationstechnologien sind EAI und ETL. Der erstmalige Aufbau der Master Data Base erfolgt häufig mittels Datenkonsolidierung (ETL) im Batch Mode mit großen Datenvolumen. Die fortlaufende Synchronisierung der Stammdaten wird häufig mittels Datenübertragung im Push­Ansatz mit beiderseitigem Datenfluss mit begrenzten Datenvolumen realisiert. Wichtig für MDM ist die Sicherstellung der Datenqualität (Duplikatbehandlung, Namen und Adressen). Die Datenintegration zur Master Data Base ist vergleichbar mit der Datenintegration für Data Warehouses und Operational Data Stores. Bei MDM liegt aber eine Bidirektionalität vor, d.h., es gibt einen Rückfluss der Daten in die Quellanwendungen. Darin macht sich eine wesentliche zusätzliche Komplexität fest – nicht nur technisch, sondern vor allem fachlich. Wenn es eine zentrale Stammdatenhaltung gibt, dann kann sich das Data Warehouse daraus bedienen, statt wie bisher selbst die Stammdaten zu konsolidieren.

90

5.6

5 Referenzarchitektur für Business-Intelligence-Anwendungen

Empfehlungen

Es steht eine Reihe von Werkzeugen zur Verfügung, um Datenqualität zu ermitteln und zu behandeln. Mit Data Profiling können Data Stewards und Entwickler offline die Qualität von Daten feststellen und darauf basierend Datenregeln definieren, die zentral abgelegt und allen Datenverarbeitungsprozessen gleichermaßen zur Verfügung gestellt werden. In den Daten verarbeitenden Prozessen wie z.B. dem Ladevorgang für ein Data Warehouse werden eingehende Daten auf Regelkonformität geprüft. Zahlreiche Datenqualitätsprobleme wie z.B. Dubletten, Verweise zwischen Informationsobjekten, Normierung können mit speziellen Ansätzen auch behandelt werden. Leitlinien dabei sind, Probleme möglichst früh im Datenfluss der Anwendungslandschaft zu lösen sowie einmal integrierte, bereinigte Daten zentral für viele Anwender und Anwendungen bereitzustellen.

91

6

Big Data

Big Data bringt eine Vielzahl neuer Herausforderungen an das Datenmanagement. Für die Welt der Business Intelligence stellt Big Data eine neue Evolutionsstufe dar. Deswegen wird in diesem Kapitel auf die Auswirkungen von Big Data auf das Datenqualitätsmanagement eingegangen. Der Leitsatz »Der Prozess bestimmt die Datenqualität« gilt bei Big Data gleichermaßen wie beim klassischen Data Warehouse. Aber die Herangehensweise an das Datenqualitätsmanagement ist in einigen Aspekten anders als beim klassischen Data Warehouse. Aufgrund der Vielzahl an Datenquellen ist eine Konsistenz aller Daten über alle Datenquellen hinweg mit akzeptablem Aufwand nicht mehr sicherzustellen.

6.1

Definitionen von Big Data

Es gibt verschiedene Sichtweisen auf Big Data. Der Anfang von Big Data sind Datenquellen. Und zwar solche, die bislang wenig bis gar nicht analytisch betrachtet wurden. Und das Ende ist ein überzeugender Business Use Case. Extrem vereinfacht: »Mit welchen neuartigen Daten, Informationen, Wissen kann ich meinem Fachbereich einen geschäftlichen Mehrwert bringen?« Neuartige Datenquellen lassen sich in die folgende Bereiche clustern: ■ Internet: u.a. soziale Netzwerke, Foren von Konsumenten, Blogs ■ Internet der Dinge: u.a. vernetztes Fahrzeug, Smart-Meter, RFID ■ Logfiles: u.a. Server Logs, Maschinen-Logs ■ unstrukturierte Daten: u.a. Dokumente, E-Mails, Sprache und Bilder

92

6 Big Data

Neue Datenquellen ■ Video, Bild, Dokumente ■ Logfiles, Sensordaten ■ Klima-, Satellitendaten ■ Soziale Netzwerke ■ Open Data

Enabler ■ Advanced Analytics ■ In-Memory ■ Big-Data-Architektur (Hadoop, NoSQL, ...)

Geschäftliche Anwendungsfälle ■ Missbrauchs-/ Risikoerkennung ■ Sentimentanalyse ■ Vorausschauende Wartung von Anlagen ■ Vorausschauendes Katastrophenmanagement

Herausforderungen ■ Variety – Vielfalt ■ Velocity – Geschwindigkeit ■ Volume – Volumen

Bedenken ■ Datenschutz ■ Datenqualität ■ Data-Scientist-Fähigkeiten

Abb. 6–1

Framework für Big Data

Die Enabler der Big-Data-Technologien sind größtenteils bekannt und werden im folgenden Abschnitt näher beschrieben. Die typischen technischen Herausforderungen an Big-Data-Vorhaben hat Gartner definiert (s.a. folgender Abschnitt) und propagiert. Je nach gewähltem Business Use Case trifft eine oder mehrere dieser Herausforderungen – Datenvielfalt, Geschwindigkeit bei der Informationsverarbeitung, Datenvolumen – zu. Wichtig sind daneben aber auch die Bedenken, die gegen Big-Data-Ideen ins Feld geführt werden. Insbesondere hierzulande ist geschichtlich bedingt der Schutz der Privatdaten des Einzelnen, also des Privatkunden oder des Einwohners, sehr schwergewichtig. Und offenkundig ist das in Deutschland der primäre Showblocker für Big Data. Weitere Bedenken gegen Big Data fallen hinsichtlich der Qualität der verwendeten Daten an. Die neuartigen Datenquellen sind einerseits neu, andererseits häufig von extern, also fremdbestimmt. Das ist naturgemäß wenig vertrauenswürdig. Es liegt in der Verantwortung des Big-Data-Vorhabens, idealerweise in Verbindung mit einer bereits bestehenden Data-Governance-Organisation, die Qualität der Daten zu ermitteln, ihre Verwendbarkeit für Analyse zu bewerten und fortlaufend zu monitoren. Diese Verantwortung lässt sich meist nicht auf den Datenlieferanten abwälzen. Und schließlich gibt es auch ein Problem mit den Kenntnissen und Fertigkeiten. Big-Data-Vorhaben schöpfen in den meisten Fällen ihren Erfolg aus dem Ein-

6.1 Definitionen von Big Data

93

satz von Business Analytics, also statistischen Verfahren von Sentimentanalyse über Text Mining bis hin zu klassischen Data-Mining-Ansätzen. Um Big-DataAnsätze erfolgreich und hinreichend schnell anzugehen, braucht es die Rolle des Data Scientists, der sowohl Verständnis für die Geschäftsprozesse des Unternehmens, die internen wie externen Datenquellen als auch für klassische und neuartige Analytics-Ansätze mitbringt. Diese Spezies ist rar. Ohne Business Use Case gibt es kein Sponsoring für Big-Data-Ideen. Business Use Cases sind vielfältig. Viele sind branchenübergreifend und beziehen sich eher auf Geschäftsfunktionen. Typische Zielgruppen sind Marketing, Vertrieb, Service und Qualitätsmanagement, Maintenance, Supply Chain. Die meisten Business Use Cases lassen sich clustern zu: ■ Vorhersage von Wartungsintervallen von Maschinen, Anlagen, Netzwerkkomponenten u.a. ■ Erkennung von Missbrauch und Risiken ■ Erkennung von Meinungsbildern und -trends, Problemen bei Qualität von Produkten und Services ■ ganzheitliche Sicht auf Kunden ■ Erkennung von Problemen in Lieferketten Einige Business Use Cases helfen die Geschäftsprozesse zu verbessern. Andere werden maßgeblich dazu beitragen, neue Geschäftsmodelle zu etablieren oder bestehende umzuwälzen. Zum Beispiel liegen im Konzept des vernetzten Fahrzeugs für die Automobilhersteller unzählige Business Cases, die auf Big Data basieren.

6.1.1

Fachlich-datenbezogene Sicht

Aus einer eher fachlich-datenbezogenen Sicht bedeutet Big Data die Erschließung neuartiger Datenquellen zum Zwecke der Analyse und Gewinnung neuartiger geschäftlicher Information. Ein wesentlicher Treiber für Big Data ist die Entwicklung des Internets, insbesondere soziale Netzwerke, Foren, Blogs u.Ä. Ein anderer wesentlicher Treiber sind die Sensoren, die immer mehr Verbreitung finden. Sensoren geben Informationen über Lokation, Verhalten und das Umfeld von Konsumenten oder Gütern preis. Sensoren finden sich u.a. im »Vernetzten Fahrzeug« (Telematik), in Smartphones, in Smart Meters sowie in RFIDChips. Man spricht in diesem Zusammenhang auch häufig vom »Internet der Dinge«. Eine weitere Datenquelle sind Logfiles von Webservern, Netzwerkelementen u.a., die Interaktionen zwischen Unternehmen und Kunde auf Detailebene mehr oder weniger kryptisch protokollieren.

94

6 Big Data

Aber auch auf weitere unstrukturierte Datenobjekte wie E-Mails, Dokumente, Audio, Video und Bildmaterial legen die Informationsanalysten immer mehr ihr Augenmerk.

6.1.2

Gartner-Sicht

Der Begriff »Big Data« wurde sehr stark durch die Analysten von Gartner geprägt, bekannt durch die 3 Vs Volume, Variety, Velocity (vgl. [Gartner 2011]): Das weltweite Informationsvolumen wächst jährlich um wenigstens 59%. Wenngleich das Volumen eine signifikante Herausforderung im Management von Big Data ist, müssen Fach- und IT-Leiter Volumen (Volume), Vielfalt (Variety) und Geschwindigkeit (Velocity) berücksichtigen. • Volume: Das erhöhte Datenvolumen innerhalb der unternehmensweiten IT Systeme ist hervorgerufen durch Transaktionsvolumina und weitere herkömmliche Arten von Daten sowie auch neuartige Daten. Zu viel Datenvolumen ist ein Problem für die Datenspeicherung, aber zu viele Daten sind auch ein massives Problem für die Analyse der Daten. • Variety: IT-Leiter haben seit jeher ein Problem damit, große Volumina an Transaktionsdaten in geschäftliche Entscheidungen zu übersetzen. Mittlerweile gibt es noch mehr Arten von Information zu analysieren, vor allem aus sozialen Medien und von mobilen Endgeräten (context aware). Vielfalt (Variety) steht für tabellarische Daten in Datenbanken, hierarchische Daten, Dokumente, E-Mails, Metering-Daten (z.B. Smart Meters), Video, Bilder, Audio, Börsentickerdaten, Finanztransaktionen und vieles mehr. • Velocity: Geschwindigkeit bezieht sich auf die Datenströme (Data Streaming), die Erstellung strukturierter Information und die Verfügbarkeit der Information für den Zugriff und die Bereitstellung. Geschwindigkeit bedeutet, dass Daten einerseits schnell erzeugt und andererseits schnell verarbeitet werden müssen, um den geschäftlichen Anforderungen zu entsprechen. Wenngleich Big Data ein signifikantes Problem darstellt, meinen die GartnerAnalysten, dass das eigentliche Problem darin besteht, aus Big Data geschäftliche Information und Wissen zu erzeugen und Muster zu finden, die den Unternehmen und Organisationen helfen, bessere geschäftliche Entscheidungen zu fällen.

6.2 Bedeutung der Datenqualität bei Big Data

6.1.3

95

Technisch-infrastrukturelle Sicht

Die eher technisch-infrastrukturelle Sicht wird vor allem vertreten durch die Anbieter von Hard- und Software. Sie fokussieren in erster Linie auf das Datenwachstum und bieten diverse innovative Lösungsansätze zum Umgang damit, die technisch gesehen schon revolutionär sind. Einige wesentliche Ansätze sind hierbei: ■ der Einsatz von In-Memory-Technologie, einerseits für Datenhaltung, andererseits für die Ausführung komplexer Datenanalyse (advanced predictive analytics) und Business Intelligence (Analyse von Daten). Mit In-MemoryAnsätzen lassen sich die Laufzeiten von Schreib- und Lesezugriffen gegenüber klassischer Technologie um Faktoren beschleunigen. ■ Datenkomprimierung, um die großen Datenvolumina handhabbarer zu machen ■ das Management von Daten in spaltenbezogener statt zeilenbezogener Sichtweise (columnar database) ■ das Management unstrukturierter Daten (Not only SQL (NoSQL) Database, u.a. Hadoop-Filesystem) ■ Graph-Datenbanken, mit denen sich Netzwerke adäquater abbilden lassen als mit relationalen Datenhaltungen ■ massiv parallele Verarbeitung ■ neuartige Formen der Datenvisualisierung ■ Kosteneinsparung bei Datenhaltung und -analyse durch den Einsatz von OpenSource-Lösungen (insbes. Hadoop) in Kombination mit Commodity Hardware ■ Cloud-basierte Ansätze, um neue Lösungen schneller, kostengünstiger oder besser skalierbar umzusetzen ■ Appliances für Data Warehouses, Business Intelligence und Business Analytics zur Senkung von Aufwänden für Tuning, Administration, Konfiguration und Betrieb

6.2

Bedeutung der Datenqualität bei Big Data

Allgemeinhin werden Datenqualität und Datenschutz in Deutschland als erhebliche Herausforderungen beim Einsatz von Big Data gesehen. Die unter mehr als 100 IT-Leitern in Deutschland durchgeführte Umfrage »In-Memory-Datenanalyse in Zeiten von Big Data« der Analysten von PAC vom September 2012 (siehe Abb. 6–2) weist auf die Brisanz der Datenqualität hin.

96

Abb. 6–2

6 Big Data

Herausforderungen für Datenanalyse und Reporting durch Big Data (vgl. [PAC 2012])

Der Mehrheit der Unternehmen ist bewusst, dass der Datenqualität bei Big Data Analytics eine hohe Bedeutung zukommt. Allerdings fühlen sie sich auch unsicher, worin genau die Herausforderungen hierbei bestehen (siehe Abb. 6–3).

Abb. 6–3

Bedeutung von Datenqualität für Big Data (vgl. [Omikron 2012])

6.3 Herausforderung externe Daten

97

Gegenüber klassischer Business Intelligence bringt Big Data einige neuartige Herausforderungen an die Sicherstellung der Datenqualität mit sich. Die folgenden Abschnitte gehen auf diese Aspekte im Einzelnen ein.

6.3

Herausforderung externe Daten

Während die herkömmlichen Datenquellen für Business Intelligence in der Regel unternehmensinterne, von der IT verantwortete Systeme sind, bekommen wir es bei Big Data des Öfteren mit externen Daten zu tun, deren Erstellung, Verarbeitung und Qualität zunächst weder bekannt ist noch aktiv beeinflusst werden kann. Mit dem klassischen DQM-Ansatz – Datenqualitätsprobleme möglichst früh im Datenfluss, am besten bei der Erfassung zu lösen – kommt man bei der Verwendung externer Daten meist nicht weiter. Dies trifft insbesondere bei der Anbindung sozialer Medien zu. Für viele Unternehmen, die ihre Produkte und Services den Kunden anbieten, ist es sehr interessant, anonymes Feedback der Kunden in branchengängigen Internetforen (z.B. motor-talk.de, hunny.de für Automobilhersteller) aufzuspüren. Abnehmer der Information sind Marketing, Produktentwicklung und Service bzw. Qualitätsmanagement. Dabei geht es einerseits um die Verteidigung der Marke, andererseits um die Optimierung der Qualitätskosten. Im Gegensatz zur Feedbackschleife über den unternehmenseigenen Service hat das Feedback aus dem Internetforum hier die folgenden Vorteile: ■ Das Feedback ist viel schneller verfügbar – das ist insbesondere sehr wichtig beim Launch neuer Produkte und Services. ■ Das Feedback ist ungefiltert und originär. Dem stehen aber auch Nachteile gegenüber: ■ Das Feedback ist nicht normiert und nicht strukturiert. ■ Das Feedback hat keine Qualitätskontrolle des hauseigenen Servicemitarbeiters erfahren. ■ Missbräuchlich abgegebenes Feedback ist schwer zu erkennen. Zusammenfassend lassen sich daraus folgende Grundregeln für das Datenqualitätsmanagement externer Daten ableiten: ■ Die Verantwortung für die Datenqualität muss im Unternehmen liegen und damit nicht mehr beim Datenlieferanten, sondern beim Datenkonsumenten. ■ Die Data-Governance-Organisation muss erweitert werden und zusätzlich die Verantwortung für externe Datenquellen übernehmen. ■ Der verantwortliche Data Steward muss, z.B. mittels Data Profiling, bewerten, ob eine interessant erscheinende Datenquelle die erforderliche Mindestdatenqualität erreicht. Gegebenenfalls lassen sich externe Daten durch Ver-

98

6 Big Data

knüpfung mit internen Daten (z.B. Stammdaten) validieren, anreichern und für Analysezwecke verwendbar machen. ■ Die Datenqualität kann nicht immer zentral für alle Gruppen von Informationskonsumenten einheitlich bestimmt werden, sondern muss mitunter differenziert im Kontext des Geschäftsprozesses bewertet werden, der die Information für eine bestimmte Entscheidung verwenden soll (vgl. »fitness for purpose« in Abschnitt 1.2). ■ Das Metadatenmanagement als wichtige Säule des Datenqualitätsmanagements muss neben den bekannten strukturellen Metadaten zusätzlich verschiedene semantische Metadaten bereitstellen. ■ Das Stammdatenmanagement muss sich zusätzlich auch mit den Sichtweisen der externen Datenquellen auseinandersetzen. Ansätze wie Identity Resolution können dabei unterstützen. Identity Resolution ist ein softwareunterstützter Matching-Ansatz, um über mehrere Datensilos hinweg Verbindungen zwischen Identitäten (häufig Personen) zu ermitteln, basierend auf verschiedenen Informationen wie Name, Adresse, Geburtsdatum, Geschlecht u.a. Dabei wird die Wahrscheinlichkeit der Verbindung angegeben und es werden die Beziehungen der Identitäten beschrieben, die eben nicht so offensichtlich sind wie beispielsweise Kundennummern. Anwendungsfälle für Identity Resolution sind das Screening nach Terroristen über verschiedene Datenquellen hinweg oder auch die Identifikation von intern bekannten Kunden mit deren an sich unbekannten Facebook-Accounts. Folgende Datenqualitätskriterien erfordern hierbei besondere Beachtung: ■ Zeitbezug: Häufig ist der Zeitpunkt der Erstellung der Information nicht oder schwer oder nur indirekt zu erkennen. ■ Aktualität: Sind die Informationen noch relevant und gültig oder bereits durch neue Information überholt? ■ Metadaten: z.B.: In welcher Maßeinheit wurden die Daten gemessen? ■ Identifizierbarkeit: Lassen sich die externen Daten den für das Unternehmen gültigen und bekannten internen Stammdaten (Kunde/Person, Produkt, Service) zuordnen?

6.4 Herausforderung unstrukturierte Daten

6.4

99

Herausforderung unstrukturierte Daten

Unstrukturierte Daten sind alle Daten, die sich nicht adäquat in herkömmlichen Datenbanken mit Zeilen und Spalten abbilden lassen, allenfalls in BLOBs1. Die Vielfalt unstrukturierter Daten ist immens, und dementsprechend gibt es auch sehr viele unterschiedliche Ansätze zu ihrer Verarbeitung. Allein für textuelle Daten besteht eine große Bandbreite: E-Mails, Winword-Dokumente, Webseiten, XML, EDIFACT2 sind einige verschiedene Formate. Aber auch der Kontext der Daten ist sehr wichtig bei der Erschließung. So sind legale Dokumente (z.B. Verträge) grundverschieden von Bestellungen oder eher umgangssprachlichen E-Mails, SMS oder Tweets. Die Verfahren der Sentimentanalyse können für einige Fragestellungen bei der Erschließung von Information aus unstrukturierten, textuellen Daten (z.B. Meinungen von Kunden zu Produkten und Services in Internetforen) unterstützen. Dabei ist die Einbindung in die Erstellung der Analyselösung und spätere Kontrolle durch einen Data Steward mit Kontextwissen unerlässlich. Die Sentimentanalyse bewertet das Meinungsbild, das der Autor eines Textes abgibt. Das Ergebnis ist in der Regel positiv, negativ oder neutral. Sentimentanalyse setzt auf einer Whitelist auf, die relevante Suchwörter definiert. Dabei sind sprachliche Missverständnisse zu beachten. So ist es mitunter üblich, in Fachforen in einem bestimmten Jargon zu kommunizieren oder Insider-Begriffe zu verwenden, die dem Produkthersteller bzw. Serviceanbieter selbst fremd sind. Zum Beispiel berichten Fahrer eines BMW nicht über ihren BMW, sondern über ihren »Bimmer«. Für die Sentimentanalyse gibt es im Wesentlichen zwei grundverschiedene Ansätze. Einerseits Machine-Learning-basiert und andererseits wörterbuchbasiert. Herausforderungen für die Datenqualität entstehen u.a. durch Dialekte, Slang, Sarkasmus und Rechtschreibfehler. In der Regel lassen sich kurze, knappe Texte eindeutiger und sicherer einem Sentiment zuordnen. Längere Texte enthalten oft sowohl Für als auch Wider oder widersprechen sich in ihrer Meinung. Klassische DQ-Prüfungen fokussieren meist auf einen Abgleich der Daten gegen Wertelisten, Formate und Muster. Bei unstrukturierten Daten muss man die Bedeutung des Inhalts im Kontext sehen. Beispielsweise verwenden einige Quellen (z.B. Twitter) exzessiv Abkürzungen – hier kann es bei der Auflösung der Abkürzungen in einer Big-Data-Anwendung schnell zu Missinterpretationen kommen. Ganz generell besteht bei der Verarbeitung von Texten und Sprache das Problem der syntaktischen Mehrdeutigkeit der Information. Hier braucht es einerseits semantische Zusatzinformation zur richtigen Deutung der Daten. Andererseits kann auch statistische Zusatzinformation bei der Deutung hilfreich sein. 1. 2.

Binary Large Object, z.B. Bild, Video Electronic Data Interchange For Administration, Commerce and Transport, ein branchenübergreifender internationaler Standard für das Format elektronischer Daten im Geschäftsverkehr

100

6 Big Data

Hierzu gibt es Ansätze in den Disziplinen der Sprachlinguistik bzw. National Language Processing. Ein wichtiges Element textueller Analyse ist die Kategorisierung von Texten innerhalb von Taxonomien oder Ontologien. Folgende Datenqualitätskriterien erfordern bei der Verarbeitung unstrukturierter Daten besondere Beachtung: a) Vollständigkeit: Wo fängt eine unstrukturierte Information an und wo hört sie auf? b) Semantische Konsistenz: Ist die Information inhaltlich und im Kontext sinnvoll?

6.5

Herausforderung Geschwindigkeit

Neue technische Ansätze wie Data Streaming ermöglichen die zeitnahe und kontinuierliche Bereitstellung von Daten. Bei der Unterstützung operativer und taktischer Entscheidungen kann Big Data im Sinne von Operational Business Intelligence große Hilfe leisten. Latenzzeiten müssen hierbei gering gehalten werden, für die Datenbeschaffung, Informationsgewinnung sowie auch für die Entscheidung. Information für das operative Geschäft verliert mit der Zeit enorm an Wert und wird irgendwann wertlos. Diese Daten müssen also sehr zeitnah verarbeitet und analysiert werden. Häufig wird hier die Automatisierung der Entscheidung angestrebt. Laut der von Capgemini beim Economist in Auftrag gegebenen Studie »The Deciding Factor: Big Data & Decision Making« (vgl. [Economist 2012b]) glauben zwei Drittel der europäischen C-Level-Manager, dass es gerade bei der Automatisierung geschäftlicher Entscheidungen große Potenziale gibt. Erfahrungsgemäß führt Zeitdruck beim Laden und Verarbeiten der Daten häufig dazu, dass Datenqualitätsprüfungen als geschwindigkeitshemmender Faktor sehr schnell über Bord geworfen werden. Der Konflikt zwischen Geschwindigkeit und Qualität muss fachlich bewertet werden: ■ Was gewinne ich dadurch, dass ich eine Information mit einer bestimmten kleinen Latenz bereitstellen kann? ■ Was verliere ich aber dadurch, dass die so zeitnah bereitgestellte Information falsch ist? Bei der Bewertung ist die Tragweite der Entscheidungen relevant. Operative Entscheidungen haben häufig nicht die große Tragweite wie strategische Entscheidungen. Folgende Datenqualitätskriterien erfordern hierbei besondere Beachtung: ■ Zeitliche Konsistenz: Passen die Daten zweier zu verknüpfender Datenquellen zeitlich zusammen, insbesondere bei Verknüpfung externer Streaming-Daten mit internen tagesaktuellen Daten?

6.6 Herausforderung Volumen

6.6

101

Herausforderung Volumen

Einige der neuartigen Datenquellen, die mit Big Data assoziiert werden, produzieren erheblich größere Datenvolumina als bei klassischen Data Warehouses gewohnt. Beispielsweise Sensordaten in Fahrzeugen der heutigen Generation, das Internet mit seinen sozialen Netzwerken und Foren oder auch Dokumente wie E-Mail und Text. Bei extrem großen Datenvolumina funktioniert der klassische Ansatz zur Verarbeitung nicht mehr. Man kann diese Daten nicht in pauschaler Weise persistent speichern, ohne sicher zu sein, ob bzw. wann sie für Analyse, Reporting, Compliance o.a. gebraucht werden. Die Verarbeitung der Daten muss weitaus differenzierter sein als bislang üblich. Einige der anfallenden Daten verlieren sehr schnell an Informationswert. Hier ist eine rasche Verarbeitung – Prüfung der Datenqualität sowie Extraktion von Information und Wissen – erforderlich. Diese Daten kann man dann recht schnell wieder löschen. Einige Daten müssen bei Bedarf zugreifbar sein, wobei der Fall sehr selten auftritt – hier muss man eine geeignete, kostengünstige Art der Archivierung finden. Bei einigen Daten wird man erst nach einer initialen Analyse herausfinden, dass und wie sie analyserelevant sind. Das Hadoop-Framework kann die meisten dieser Anforderungen sehr gut erfüllen. Aufgrund seiner sehr günstigen Kosten sowie der parallelen Verarbeitungsmöglichkeiten lassen sich in Hadoop große Datenvolumina ablegen bzw. zwischenspeichern. Die meisten Anbieter für ETL, Data Warehousing und Business Intelligence bieten Konnektoren zum Hadoop-Filesystem oder darauf basierenden weiteren Hadoop-Komponenten an, um gezielt die analyserelevanten Daten zu extrahieren. Hadoop als System der Datenablage ist für die meisten Unternehmen vergleichsweise neu. Die heutigen Werkzeuge für Datenintegration und -qualität können aber bereits jetzt sehr gut lesend und schreibend darauf zugreifen. Und die meisten Werkzeuge bieten auch hier in etwa denselben hohen funktionalen Umfang bezogen auf Datenqualität. Die Empfehlung zum Umgang mit großen Datenvolumina lautet daher, in folgenden Schritten vorzugehen: 1. Ablage der großvolumigen Daten in einem Hadoop-Filesystem (HDFS) mit einem sehr leichtgewichtigen Datenqualitätsmanagement 2. Exploration der im HDFS abgelegten Daten 3. Auswahl der analyserelevanten Daten aus dem HDFS 4. Extraktion der analyserelevanten Daten aus dem HDFS mit bekannten ETLQ-Werkzeugen und striktere Anwendung des Datenqualitätsmanagements mit Bezug auf die Anforderungen des betreffenden Anwenders

102

6.7

6 Big Data

Empfehlungen

Im Big-Data-Umfeld sind viele Datenquellen externer Natur. Die Messung der Qualität der eingeholten Daten ist erfolgskritisch. Die Bewertung der Nutzbarkeit der Daten kann je nach Business Use Case verschieden sein. Für den einen Use Case mag die Qualität hinreichend sein, für den anderen nicht. Bei der Verwendung von Inhalten aus sozialen Medien ist die Vertrauenswürdigkeit der Beiträge zu bestimmen. Zudem müssen Methoden aus der Erkennung und Verarbeitung natürlicher Sprache eingesetzt werden. Zahlreiche Use Cases erfordern eine sehr zeitnahe Bereitstellung von Information für die Entscheidungsfindung im operativen Geschäft. Ein allumfassender Datenqualitätsprozess wie im Batchgetriebenen Data Warehouse lässt sich hier nicht mehr durchsetzen. Der erfolgreiche Einsatz von Big Data erfordert noch mehr eine zentrale Organisation für Datenqualität und Governance im Unternehmen, die nun auch externe Daten verantworten muss. Eine zentrale Bedeutung gewinnen die Stammdaten als Schlüssel für die Verknüpfung der verschiedenen internen und externen Datenquellen.

103

7

Kennzahlen zur Messung der Datenqualität

Wie in den einführenden Kapiteln 1 und 2 bereits näher ausgeführt, wird der Qualitätsbegriff speziell im Umfeld von Business­Intelligence­Projekten aus Sicht der Anforderungen der Anwender betrachtet. Die Bewertung der Qualität der Daten erfolgt dabei unter Zuhilfenahme sogenannter Datenqualitätskriterien, wie sie in den zuvor erwähnten Kapiteln initial definiert wurden. In diesem Kapitel wird eine Teilmenge der in Kapitel 2 beschriebenen Datenqualitätskriterien (Zeitnähe, Relevanz, Konsistenz, Zuverlässigkeit, Korrektheit sowie Vollständigkeit) verwendet. Die Nutzung von Kennzahlen stellt gerade im Umfeld von Business­Intelligence­Anwendungen eine Möglichkeit dar, die Datenqualität zu einem gewissen Grad, basierend auf diesen Kriterien, messbar zu machen. Es ist dabei allerdings zu beachten, dass Kennzahlen nur für klar definierte Bereiche bzw. abgegrenzte Problemstellungen sinnvoll anwendbar sind. Die Berechnung von Kennzahlen zur Messung und Überwachung der Datenqualität kann einerseits über einfache statistische Auswertungen einzelner Attribute, Entitäten oder Domänen erfolgen, andererseits über komplexe Abbildungen von Geschäftsregeln, die die Zusammenhänge zwischen den Attributen bzw. zwischen den Entitäten und Domänen darstellen. Dementsprechend sind auch die Vor­ und Nachteile bei der Anwendung von Kennzahlen zu berücksichtigen. Abschnitt 7.1 geht auf diese Themenstellung näher ein. Das Thema der Verwendung von Kennzahlen im Berichtswesen wird in Kapitel 15 (Data Quality Monitoring) behandelt. Im Rahmen der in Kapitel 5 eingeführten Referenzarchitektur für BI­Anwendungen gibt es eine Reihe von Möglichkeiten, um die Berechnungen dieser Kennzahlen durchzuführen und die Ergebnisse aufzubereiten. Die Darstellung dieser potenziellen Datenqualitätsmesspunkte innerhalb der BI­Architektur sind der Inhalt von Abschnitt 7.2. Um eine quantitative Analyse dieser Messpunkte durchführen zu können, müssen Metriken definiert werden. Wie diese im BI-Umfeld aussehen können, zeigt Abschnitt 7.3. Die Definition möglicher Kennzahlen sowie Kennzahlenbäume für ausgewählte Datenqualitätskriterien beschreiben die Abschnitte 7.4 und 7.5.

104

7 Kennzahlen zur Messung der Datenqualität

Abschließend wird ein Formular zur Erfassung von Kennzahlen dargestellt (Abschnitt 7.6). Ein standardisiertes Formular ist insbesondere in größeren Unternehmen mit dezentraler Definition von Kennzahlen eine Voraussetzung für deren effiziente und konsistente Verwaltung.

7.1

Anwendungsmöglichkeiten von Kennzahlen

Bevor eine Implementierung von Kennzahlen zur Messung (vgl. [Redman 2001, S. 107ff.]) und Überwachung der Datenqualität erfolgen kann, ist es notwendig, eine klare Vorstellung darüber zu bekommen, was Kennzahlen leisten und nicht leisten können. Von diesem Verständnis der Leistungsmöglichkeiten hängen letztendlich der Erfolg von Kennzahlen sowie die Akzeptanz der Anwender bei einem Einsatz von Kennzahlen ab. Dieser Abschnitt gibt einen Überblick über die Vorund Nachteile, die im Zuge einer Implementierung von Kennzahlen zu beachten sind. Der wesentliche Vorteil in der Verwendung von Kennzahlen zur Messung und Überwachung der Datenqualität liegt in erster Linie in der Quantifizierung klar definierter Problemstellungen. Die Nachteile liegen vor allem darin, dass ihr Einsatz nur eingeschränkt möglich ist und das Bewusstsein für diese Limitationen bei den Anwendern oftmals nicht ausreichend ausgeprägt ist. Mittels der Verwendung von Kennzahlen kann eine regelmäßige Überwachung von Datenqualitätsverbesserungen erfolgen, z.B. das Monitoring laufender Maßnahmen, wie etwa Nachfassaktionen bei der initialen Datenerfassung, Verbesserungen in den Quellsystemen oder die regelmäßige Durchführung von Data­Cleansing­Projekten. Kennzahlen finden auch zur Unterstützung einer Qualitätsplanung Anwendung. Ausgehend von einer konkreten Problemstellung bedarf eine Qualitätsplanung zur Erhöhung der Datenqualität klar definierter Messkriterien und vorgegebener Sollgrößen zur Durchführung von Plan­Ist­Vergleichen. Tabelle 7–1 gibt einen Überblick über die Vor- und Nachteile, die bei einem Einsatz von Kennzahlen zu berücksichtigen sind.

7.1 Anwendungsmöglichkeiten von Kennzahlen

105

Vorteile

■ Kennzahlen basieren im Wesentlichen auf Fakten und eignen sich daher primär als Argumentation zur Initialisierung notwendiger Verbesserungsmaßnahmen zur Erhöhung der Datenqualität. ■ Kennzahlen können für eine generelle initiale Qualifizierung von Daten verwendet werden, z.B. ob die zugrunde liegenden Daten für eine neue Applikation grundsätzlich qualitativ geeignet sind. ■ Kennzahlen können Verbesserungen der Datenqualität durch eine laufende Überwachung mittels Zeitreihen veranschaulichen. Kennzahlen sind dafür geeignet, Problembereiche in den Daten aufzuzeigen, z.B. durch laufende Plan-Ist-Abweichungsanalysen oder durch auffällige Ausreißer in den Zeitreihen. ■ Kennzahlen dienen im Rahmen der regulären Datenbeladungsprozesse dazu, fehlerhafte Datenanlieferungen und Datenverarbeitungen aufzuzeigen, z.B. eine Verletzung einer Formalprüfung oder den Bruch einer Zeitreihe. ■ Kennzahlen finden in einem gewissen Maße Verwendung, um überhaupt ein Bewusstsein für das Thema Datenqualität zu schaffen.

Nachteile

■ Kennzahlen stellen in erster Linie eine Indikation bereit, dass ein Problem bezüglich der Datenqualität besteht. Es wird allerdings nicht das konkrete Problem bzw. dessen Ursache dargestellt. ■ Nicht alle Datenqualitätskriterien können mittels Kennzahlen gemessen werden. Die Verwendung von statistischen Kalkulationen kann nur bis zu einem bestimmten Grad die verschiedenen Datenqualitätsprobleme entsprechend den Datenqualitätskriterien darstellen, z.B. anhand formal messbarer Kriterien. ■ Historische Vergleiche von Kennzahlen sind oftmals irreführend, wenn sich z.B. die zugrunde liegende Betrachtungsweise ändert oder strukturelle Veränderungen, wie z.B. neue Beteiligungen des Unternehmens oder das Auflassen/die Neueinführung eines Produktes, vorliegen. ■ Die Bereitstellung und Kalkulation von Kennzahlen zur Überwachung der Datenqualität darf kein Ziel in sich selbst sein, sondern muss immer der Ausgangspunkt für Verbesserungen in den zugrunde liegenden Daten sein. ■ Kennzahlen dienen im (oftmals monatlichen) Berichtswesen zur Erstanalyse, ob die Quellsysteme korrekt liefern und alle ETL-Prozesse korrekt ablaufen. Sie dienen nicht der Analyse von Fehlerursachen, sondern ausschließlich dem Erkennen potenzieller Problemfelder.

Tab. 7–1

Vor­ und Nachteile der Verwendung von Kennzahlen

Generell sind Kennzahlen in erster Linie von inhaltlich verantwortlichen Personen in den Fachbereichen zu definieren. Diese können am besten einschätzen, welche Daten zu überwachen sind bzw. in welcher Form dies durchzuführen ist. Die Definition dieser Kennzahlen basiert meist auf bestimmten Anforderungen an die Qualität von Daten aus der jeweiligen Sicht der verschiedenen Unternehmensbereiche. Jedoch kann auch das BICC Interesse daran haben, standardisierte Kennzahlen für die DQ zu definieren und durch zentrale Module zu steuern und zu kontrollieren. Große Teile der formalen Überprüfung der Datenqualität im Rahmen von BI­Projekten erfolgen meist schon im Zuge der initialen Datenübernahme in die Staging Area und in das Data Warehouse. Die aus diesen initialen Prüfungen gewonnenen Informationen ermöglichen eine erste Einschätzung, in welchen Bereichen Kennzahlen regelmäßig sinnvoll einzusetzen sind.

106

7 Kennzahlen zur Messung der Datenqualität

Vor einer Implementierung von Kennzahlen ist in jedem Fall auch abzuklären, wo diese Kennzahlen im Rahmen der BI­Architektur zu implementieren sind. Dies kann bereits in den Quellsystemen, dem Data Warehouse oder auch in den fachspezifischen Data Marts bzw. in den Business­Intelligence­Frontend­Werkzeugen und analytischen Anwendungen der Informationsbereitstellungsschicht erfolgen.

7.2

Messpunkte für Datenqualität

Dieser Abschnitt beschreibt mögliche Punkte zur Messung und Überwachung der Datenqualität innerhalb der in Kapitel 5 eingeführten BI­Referenzarchitektur. Dabei werden auch kurz Ansatzpunkte zur Messung bzw. Überwachung der Datenqualität je Messpunkt dargestellt. Abbildung 7–1 zeigt die bereits eingeführte BI­Referenzarchitektur mit den möglichen Messpunkten, auf denen Kennzahlen generell aufsetzen können. Anwender und Rollen

Operative Anwendungen und Prozesse Administrator

Ersteller

Informationsbereitstellung

Data Steward

Empfänger

BI-Anwendungen (Geschäftsfunktionen, Branchen) Risiko Mgmt. BI-FrontendWerkzeuge We W

Analyse

Inf. Discovery

Adv. Analytics

Relationship Mgmt.

Planung

Scorecarding

…

Dashboarding

Alerting

BI BI-Plattform Portal, Suche, Collaboration, Personalisierung, Semantische Zugriffsschicht, Sicherheit, Scheduling, SDK, Services Po P

Data Marts

SQL ODBC JDBC BAPI xQuery

ODBO MDX

XML/A

PMML

R

Hive

MR CWMI

4 Operational Data Store

3

2

Metadaten

Data Profiling

Datenintegration

File System

Laden Enterprise Application Integration

Datenqualität Staging Area

Transformation

Data Streaming

Extraktion ODBC Datenquellen n Strukturierte e Daten

Abb. 7–1

1

Inff Informelle Da a Daten

SQL

JDBC

Operative IT-Systeme Standard-SW, Individual-SW

File

XML

Stammdaten-Hubs Kunden, Produkte, …

BAPI

IDOC

Marktdaten D&B, S&P, …

Big Data Sensor Logs, Social Feeds, Clickstream, Server Logs, Audio, Video, Bilder, Dokumente, …

Datenströme Unstrukturierte Daten

Systemmanagement

Data Warehouse

Prozessmanagement

Datenhaltung

Reporting

Performance Mgmt.

Metadatenmanagement

5

Compliance

Messpunkte innerhalb der BI-Referenzarchitektur (siehe auch Abb. 5–1 auf S. 70)

Die Messpunkte befinden sich innerhalb der Quellsysteme, der Staging Area, dem unternehmensweiten Data Warehouse, den fachbereichsspezifischen Data Marts sowie den BI­Frontend­Werkzeugen. Die automatisierte Berechnung möglicher Kennzahlen ist zudem teilweise in Abhängigkeit von der Verfügbarkeit von Metadaten zu sehen. Eine Reihe der in Abschnitt 7.3 beispielhaft dargestellten Kennzahlen benötigt diverse Metadaten, um entsprechende Berechnungen automatisiert zu ermöglichen. Diese Metadaten beinhalten zuvor definierte Soll­Daten (z.B. die geplanten Anlieferungszeitpunkte von Schnittstellen oder die definierten gültigen Wertebereiche der Attribute), die zur Gegenüberstellung mit den tatsächlichen Ist­Daten Verwendung finden.

7.2 Messpunkte für Datenqualität

107

Der Zugriff auf die Kennzahlen bzw. deren standardisierte Ausgabe kann mittels BI­Anwendungen oder einfachen SQL­Abfragen erfolgen. Die tatsächliche technische Umsetzung bzw. die architektonische Konzeption ist im Rahmen der Definition der gesamten BI­Architektur durchzuführen. Eine der wesentlichen fachlichen Anforderungen ist die Nachvollziehbarkeit der unter Zuhilfenahme von Kennzahlen ermittelten Fehlerindikatoren. Dies bedeutet, dass es möglich sein muss, die mittels Kennzahlen erkannten Fehler bzw. die dahinterliegenden fehlerhaften Datensätze in den Detaildaten ausfindig zu machen, um diese, falls nötig, im Einzelfall verifizieren zu können. Das kann unter Verwendung von BI­Frontend­Anwendungen (oder einer im Rahmen der technischen Konzeption definierten adäquaten Lösung) bei entsprechender Konzeption z.B. mittels hinterlegtem Drill­down oder einer Verlinkung auf die Detaildaten aus Berichten heraus erfolgen. Zudem kann bei Bedarf eine automatische Benachrichtigung der Anwender beim Überschreiten bestimmter Grenzwerte erfolgen, die im Einzelfall durch die fachlich verantwortlichen Personen zu definieren sind. Das Vorhalten der Historie von Kennzahlen bzw. der Fehlerprotokolle vergangener Datenübernahmen ist ebenfalls im Zuge der initialen Definition zu berücksichtigen. Ein Großteil der im Abschnitt 7.3 dargestellten Kennzahlen kann grundsätzlich unter den meisten der nachfolgenden Messpunkte umgesetzt werden. Der jeweilige optimale Messpunkt ist im Einzelfall unter Beachtung der jeweiligen konkreten Anforderungen zu definieren. Wo Kennzahlen zur Messung der Datenqualität letztendlich abgelegt sind, ist im Zuge der Konzeption der BI­Architektur festzulegen. Dies kann einmal zentral für alle Messpunkte in einem eigens dafür definierten Datenbereich im Data Warehouse bzw. in einem dafür entwickelten Data Mart erfolgen oder auch dezentral je Messpunkt in den jeweiligen Systemen auf der entsprechenden Ebene der Architektur. Die nachfolgenden Punkte gehen auf die einzelnen Messpunkte der BI­Architektur kurz ein. Zielsetzung sollte grundsätzlich sein, Datenqualitätsprüfungen so weit vorne wie möglich in der Datenverarbeitungskette (beginnend mit den Quellsystemen bzw. der Datenerfassung) durchzuführen, um eine Ausbreitung von Fehlern in den nachfolgenden Systemen zu minimieren. Messpunkt 1: Quellsysteme

Die Implementierung von Kennzahlen direkt in den Quellsystemen hängt im Wesentlichen von der Machbarkeit innerhalb dieser Systeme ab. Dabei sind neben der Frage nach der grundsätzlichen technischen Machbarkeit in erster Linie Kriterien wie Auswirkung auf die Performance der Quellsysteme (im Sinne von operationalen Risiken) und die Kosten der Implementierung zu berücksichtigen. Andererseits erhöhen Datenqualitätsprüfungen in diesem Bereich die Qualität der Daten in allen nachfolgenden Systemen.

108

7 Kennzahlen zur Messung der Datenqualität

Prüfungen, die im Umfeld der Quellsysteme besonders sinnvoll sind, betreffen bereits die Erfassung der Daten. Dabei wird nur die Eingabe gültiger Wertebereiche und gültiger Formate (z.B. die Datumseingabe im Format JJJJMMTT) bzw. die Auswahl aus vorgegebenen Drop­down­Boxen (z.B. eine Liste mit Kundenkategorien) erlaubt. Oftmals bieten auch die Quellsysteme bereits Statistiken an. Beispielsweise gibt es bei DBMS die technischen Tabellen über Anzahl der Datensätze, bei Flat Files werden diese Informationen ggfs. in Header- oder TrailSätze geschrieben. Messpunkt 2: Staging Area

Messpunkt 2 beinhaltet die Berechnung von Kennzahlen im Zuge der Übernahme von Daten mittels Schnittstellen in die Staging Area. Es werden Statistiken im Rahmen der ETL­Prozesse mitgeschrieben und als Kennzahlen abgelegt bzw. ausgegeben. Der Vergleich kann dabei auf Informationen basieren, die in den Metadaten abgelegt sind. Die Verfügbarkeit entsprechender Metadaten ist somit eine wesentliche Voraussetzung für die Berechnung einer Reihe von Kennzahlen. Zusätzliche Kennzahlen, die bereits bei der initialen Befüllung mitgeschrieben werden können, sind bei Bedarf als Geschäftsregeln durch die jeweiligen fachlich verantwortlichen Personen zu definieren. Darüber hinaus ermöglicht ein automatisierter Vergleich der aktuellen Fehlerliste mit der Fehlerliste der letzten Beladung inklusive einer Ausgabe der Differenzen den fachlich verantwortlichen Personen eine vereinfachte Überprüfung der Daten. Es erfolgt dabei der Vergleich der Unterschiede zwischen den letzten Beladungen. Bereits bekannte Fehler müssen demnach nicht mehrfach analysiert werden. Dies hat vor allem bei der Übernahme umfangreicher Datenvolumen Auswirkungen auf die Effizienz der Datenqualitätsprüfungen und somit auf die benötigten Ressourcen. Dieser Messpunkt ist für die Berechnung einfacher Kennzahlen, wie z.B. die Anzahl der NULL­Werte je Attribut, besonders geeignet. Zudem sind hier erste Prüfungen der Integrität der Daten empfehlenswert. Darunter fallen Themenstellungen wie die Prüfung, ob in den Transaktionsdaten nur Kunden angeliefert werden, die auch bereits in den Stammdaten vorhanden sind. Messpunkt 3: Unternehmensweites Data Warehouse

Messpunkt 3 zur Überwachung und Messung der Datenqualität beinhaltet die Berechnung von Kennzahlen direkt im unternehmensweiten Data Warehouse. Es erfolgt eine automatisierte Berechnung durch Prozeduren; die Ergebnisse werden in dafür vorgesehene Bereiche im DWH geschrieben. Kennzahlen, die auf diesem Messpunkt aufsetzen, basieren auf einer für das gesamte Unternehmen relevanten Geschäftslogik, die im unternehmensweiten DWH abgebildet ist. Im Gegensatz dazu sind fachbereichsspezifische Kennzahlen meist in den entsprechenden spezifischen Data Marts zu berechnen.

7.3 DQ-Metriken

109

Dieser Messpunkt eignet sich besonders für die Berechnung von Kennzahlen, die mehrere Datenbereiche umfassen oder unterschiedliche Quellsysteme betreffen. Dies ermöglicht in erster Linie Konsistenzprüfungen zwischen den verschiedenen Quellsystemen, die Daten an das unternehmensweite Data Warehouse liefern. Messpunkt 4: Data Marts

Diese Kennzahlen beinhalten Informationen, die im Rahmen der Beladung von Data Marts anfallen. Die Berechnung der Kennzahlen basiert in den meisten Fällen auf aggregierten Daten bzw. auf den fachbereichsspezifischen Logiken. Theoretisch sind die gleichen Kennzahlen wie im unternehmensweiten Data Warehouse möglich, jedoch abhängig von der Verfügbarkeit der Detaildaten und der im Data Mart implementierten Geschäftslogik. Messpunkt 5: Business-Intelligence-Anwendungen

Die Umsetzung von Kennzahlen kann ebenso innerhalb von Business­Intelligence­Anwendungen erfolgen. In der einfachsten Form sind dies Berechnungen in den Berichten. Um einen einfachen Abgleich zwischen den Ebenen bzw. zu den operativen Systemen hin durchzuführen, können definierte Summengrößen automatisiert an die Verantwortlichen der Quellsysteme rückgemeldet und mit den Werten aus den operativen Produktionssystemen verglichen werden. Die entsprechenden Größen sowie die Periodizität der Vergleiche sind zwischen den fachlich und technisch verantwortlichen Personen abzustimmen. Die Entscheidung, wo die Implementierung der Kennzahlen letztendlich durchzuführen ist, hängt wesentlich von technischen Kriterien, den Kosten der Implementierung sowie der Verfügbarkeit der Daten ab. Grundsätzlich ist dabei wie erwähnt die Datenqualität so früh wie möglich in der Verarbeitungskette der Daten zu prüfen, um die Auswirkungen und die dadurch entstehenden Kosten schlechter Datenqualität in den nachfolgenden Systemen zu minimieren.

7.3

DQ-Metriken

Der Begriff Metrik kommt aus dem Griechischen und bedeutet »Zählung« oder »Messung«. Man versteht darunter das »Messbarmachen« von komplexen Sachverhalten. Insofern kann eine Metrik auch als Algorithmus zur Berechnung einer Kennzahl verstanden werden. Oftmals bezeichnet eine Metrik die Kennzahl selbst, daher werden die beiden Begriffe »Kennzahl« und »Metrik« im Folgenden synonym verwendet. Dieser Abschnitt beschäftigt sich damit, wie man Datenqualität messbar machen kann. Während Sportler ihre Leistung leicht mittels Maßband oder Stoppuhr messen können, ist die Situation im Bereich Datenqualität ungleich schwerer. Aber auch hier lassen sich geeignete DQ-Metriken definieren.

110

7 Kennzahlen zur Messung der Datenqualität

Für den Einsatz in der Praxis sind gewisse Anforderungen an die Datenqualitätsmetriken zu stellen (vgl. [Heinrich/Klier 2011, S. 51 sowie Hinrichs 2002, S. 69ff.]): ■ Um eine Vergleichbarkeit der Ergebnisse zu gewährleisten, ist eine Normierung notwendig. ■ Die Metriken sollten möglichst kardinalskaliert sein, damit auch eine zeitliche Entwicklung analysiert werden kann (Kardinalität). ■ Die Metrik muss jeweils für eine konkrete Anwendung sensibilisiert sein (Sensibilisierbarkeit). ■ In der täglichen Arbeit reichen eine Normierung und eine Kardinalität jedoch nicht aus: Die Metrikergebnisse müssen auch fachlich interpretierbar und reproduzierbar sein (Fachliche Interpretation). In der Literatur wird eine Reihe von Vorschlägen zur Bildung von Metriken diskutiert (vgl. [Heinrich et al. 2007, Helfert 2002, Heinrich/Klier 2011, S. 51ff.]). Die vorgeschlagenen Metriken bilden üblicherweise den Anteil von verletzten Regeln im Verhältnis zur Gesamtzahl aller Regeln ab. Im Folgenden werden beispielhaft Einsatzmöglichkeiten von Kennzahlen zur Messung der Datenqualität im Umfeld von BI­Projekten aufgezeigt. Dabei wird zwischen formal­technischen, inhaltlichen und qualitativen DQ­Metriken unterschieden. Kennzahlen können einerseits als Verhältniswerte oder Prozentwerte, etwa die Anzahl von Werten außerhalb definierter Gültigkeitsbereiche im Verhältnis zur Gesamtanzahl aller gelieferten Zeilen, Anwendung finden. Andererseits beinhalten Kennzahlen absolute Werte, wie z.B. die Anzahl von Datensätzen, die eine Datenqualitätsregel verletzen, oder aber absolute und relative Abweichungen des Istzustands von einem vordefinierten Sollzustand. Der Sollzustand der Datenqualität kann einerseits ein bestimmter festgelegter Wert oder andererseits ein berechneter Wert (z.B. Mittelwert der letzten 6 Monate, Vormonatswert, Vorjahreswert) sein. Generell sind Kennzahlen so zu definieren, dass sie die Beurteilung der Einhaltung vorgegebener Unternehmensrichtlinien (soweit quantifizierbar) messbar machen. Eine Möglichkeit zur Kategorisierung von Kennzahlen ist die Bildung sogenannter Fehlerklassen für auftretende Datenqualitätsprobleme. Anhand von Fehlerklassen lassen sich diese Probleme je nach Dringlichkeit oder Problemtyp zusammenfassen. Die Fehlerklassen können dabei auf priorisierten Bereichen basieren, wie z.B. auf der Schwere der Auswirkungen auf die Geschäftstreiber (siehe Kap. 2). Tabelle 7–2 beinhaltet eine exemplarische Auflistung von Inhalten möglicher Kennzahlen zur Messung bzw. Überprüfung der Datenqualität. Dabei wird auf die drei Möglichkeiten zur Bestimmung bzw. Berechnung von Kennzahlen eingegangen, die sich im Umfeld von BI­Projekten zur Kategorisierung anbieten:

7.3 DQ-Metriken

111

■ Die Berechnung formal­technischer Kennzahlen erfolgt automatisiert durch einfache Abfragen, die auf den verschiedenen Datenbereichen aufsetzen. Statistiken über Datenbereiche werden dabei mitgeschrieben. ■ Inhaltliche Kennzahlen bilden im Wesentlichen komplexere Geschäftsregeln ab oder unterstützen die fachlich verantwortlichen Personen bei der Analyse von Datenqualitätsthemen. Die Definition der Geschäftsregeln hat dabei durch die fachlich verantwortlichen Personen zu erfolgen, da in den meisten Fällen das entsprechende fachliche Verständnis eine grundsätzliche Voraussetzung für die Definition dieser Kennzahlen ist. ■ Nicht alle Datenqualitätskriterien lassen sich mittels quantitativer Verfahren messen bzw. über berechnete Kennzahlen darstellen. Manche Datenqualitätskriterien benötigen für eine Einschätzung qualitative Maßnahmen, wie z.B. Befragungen von Anwendern. Die Bewertung der Datenqualität erfolgt dann qualitativ durch die für die jeweiligen Daten verantwortlichen Personen mit einer entsprechenden nachvollziehbaren Begründung. Formaltechnisch

■ Anzahl der Werte je Attribut, die den vordefinierten Attributinhalten entsprechen ■ Anzahl der Schlüsselverletzungen je Schnittstelle ■ Anzahl der Regelverletzungen von Datensätzen ■ Anzahl der Inkonsistenzen von zusammenhängenden Datensätzen/ Attributen ■ Kalkulierter Wert als Anzahl der fehlerhaften Sätze/Attribute ■ Kalkulierter Wert als absolute oder relative Abweichung von einer Sollgröße (bspw. durch das Liefersystem kalkulierte Summen- oder Saldensätze) ■ Vergleich mit den Metadaten der Beladung, z.B. • • •

Anlieferungszeitpunkt tatsächlich Anlieferungszeitpunkt erwartet Anlieferungshäufigkeit/Anlieferungsturnus (wie oft wurde die Schnittstelle im Rahmen eines Importprozesses übernommen oder wurde eine monatliche Datei auch monatlich bereitgestellt)

■ Anzahl der NULL-Werte je Attribut bei der Übernahme absolut ■ Anzahl der NULL-Werte im Verhältnis zur Gesamtanzahl der angelieferten Zeilen je Schnittstelle ■ Anzahl der angelieferten Werte je Attribut, die nicht den definierten Attributinhalten entsprechen ■ Verletzungen der referenziellen Integrität für jedes Attribut pro Schnittstelle – Ausgabe der Schlüsselverletzungen je Schnittstelle ■ Ausgabe der Zeilenanzahl der vergebenen Dummy-Werte je Attribut je Schnittstelle ■ Anzahl der • • •

angelieferten Zeilen übernommenen Zeilen nicht übernommenen Zeilen

➝

112

7 Kennzahlen zur Messung der Datenqualität

Inhaltlich

■ ■ ■ ■ ■ ■ ■

Ausgabe von Statistiken über Wertebereiche je Attribut Anzahl der angelieferten Werte je Attribut (Häufigkeitsverteilung) Inhaltliche Vergleiche zu Vorperioden Verteilung der Werte über Wertebereiche Durchschnittswertdarstellungen Zeitreihenvergleiche Min.-/Max.-Validierungen von Werten • • • •

alle angelieferten Werte die übernommenen Werte die nicht übernommenen Werte ausgewählte Felder je Ausprägung der Attribute

■ Summe über alle Werte je Attribut weicht mehr als einen vorgegebenen Schwellwert von einem Sollwert ab ■ Automatisierte/manuelle Prüfungen von Annahmen bezüglich der erwarteten gegenüber den vorhandenen Werten Qualitativ

Tab. 7–2

■ Visuelle Prüfungen durch die Anwender ■ Feedback von Anwendern basierend auf den Inhalten der operativen Systeme ■ Inhaltliche Prüfungen durch fachlich Verantwortliche in den BusinessIntelligence-Systemen ■ Validierung der zugrunde liegenden Basisdaten

Beispiele für DQ­Metriken

Die hier dargestellten Möglichkeiten zur Definition von Kennzahlen können grundsätzlich auf allen in Abschnitt 7.2 beschriebenen Messpunkten aufsetzen. Es ist im Einzelfall zu entscheiden, wo diese Kennzahlen letztendlich zu implementieren sind. Wie bereits erwähnt, sollten Kennzahlen so früh wie möglich in der Kette der Datenverarbeitung aufsetzen.

7.4

Kennzahlen für ausgewählte Datenqualitätskriterien

Dieser Abschnitt stellt beispielhaft Kennzahlen für ausgewählte Datenqualitätskriterien vor, basierend auf den in Kapitel 2 dargestellten Kriterien. Wie in den vorhergehenden Abschnitten beschrieben, können Kennzahlen quantitativer oder qualitativer Natur sein. Quantitative Kennzahlen lassen sich im Wesentlichen automatisiert berechnen, während qualitative Messverfahren Interviews, Fragebögen und sonstige Rückmeldungen durch die Anwender benötigen. Zielsetzung ist eine Anwendung der eingeführten DQ­Metriken auf die hier verwendeten Datenqualitätskriterien. Tabelle 7–3 beinhaltet Beispiele für eine Definition von Kennzahlen je Datenqualitätskriterium.

7.4 Kennzahlen für ausgewählte Datenqualitätskriterien

Datenqualitätskriterien

Beispiele

Zeitnähe/ Aktualität

■ Aktualität der geladenen Daten • •

113

Letzter Ausführungszeitpunkt wird mitgeschrieben Darstellung geplanter vs. tatsächlicher Ausführungszeitpunkt

■ Datenverfügbarkeit für Anwender •

User-Feedback

■ Vorhandensein von veralteten Datenwerten • • • Relevanz

User-Feedback Überprüfung des letzten Bewertungsdatums Verifizierung der Prüfroutinen in den Quellsystemen

■ Anzahl nicht verwendeter Daten • •

Auswertung von Zugriffsstatistiken User-Feedback

■ Anzahl abgelaufener Daten, z.B. • Konsistenz

verlorene oder gekündigte Kunden

■ Konsistenz von Datendefinitionen in unterschiedlichen Systemen • • •

User-Feedback Konzeptreview Schnittstellenreview

■ Vergleichswerte zum Abgleich zwischen Systemen • •

Summen über Attribute wie etwa Umsatz Kundenanzahl in unterschiedlichen Kategorien

■ Zusammenhänge zwischen Systemen • Zuverlässigkeit

Geburtsjahr in einem System ist konsistent mit Alter in einem anderen System

■ Anzahl dokumentierter Transformationen • •

User-Feedback Konzeptreview

■ Anzahl durchgeführter standardisierter Abgleiche von Daten zwischen Systemen • Korrektheit

regelmäßige Konsistenzprüfungen

■ Darstellung der Werte •

Anlieferung falsches Datumsformat, z.B. US-Format

■ Anzahl falscher Werte • •

User-Feedback Prüfregeln, z.B. Aktivseite = Passivseite in der Bilanz

■ Anzahl ungültiger Werte • •

Vergleich der angelieferten Werte mit den Definitionen Vergleich der angelieferten Werte mit Vorperioden

➝

114

7 Kennzahlen zur Messung der Datenqualität

Datenqualitätskriterien

Beispiele

Vollständigkeit

■ Vollständigkeit der implementierten Konzepte • •

User-Feedback Konzeptreview

■ Anzahl fehlender Datenwerte • •

Anzahl der NULL-Werte Anzahl der gesetzten Default-Werte

■ Anzahl der nicht geladenen Schnittstellen/Datensätze • •

Tab. 7–3

7.5

Verhältnis der übernommenen Datensätze zu angelieferten Datensätzen je Schnittstelle Vergleich der Anzahl der Ist-Anlieferungen zu Soll-Anlieferungen der Schnittstellen

Beispiele für Kennzahlen je Datenqualitätskriterium

Kennzahlenbaum

Ein Kennzahlensystem oder Kennzahlenbaum stellt Einzelkennzahlen in sachlogischen Zusammenhang und ermöglicht diese im Kontext zu bewerten. In diesem Abschnitt wird ein einfaches Beispiel abgebildet, das das Prinzip eines Kennzahlenbaums für Datenqualität anschaulich darstellt. Der Baum in diesem Beispiel stellt das DQ­Kriterium Korrektheit dar. Dabei erfolgt eine Definition von Kennzahlen auf Ebene der einzelnen Attribute bzw. eine Definition von entitäts- oder auch domänenübergreifenden Kennzahlen. Wesentlich in diesem Zusammenhang ist, dass die Zusammensetzung der Kennzahlen nachvollziehbar und interpretierbar bleibt. Die Definitionen der Kennzahlen sind dabei analog zu den zuvor beispielhaft dargestellten Kennzahlen bzw. den Kennzahlen je Datenqualitätskriterium zu verstehen. Abbildung 7–2 stellt eine Möglichkeit eines Kennzahlenbaums für das Datenqualitätskriterium Korrektheit dar. Generell ist zu beachten, dass die Kennzahlen, die sich innerhalb eines Kennzahlenbaums hochaggregieren, konsistent und vor allem nachvollziehbar definiert sind. Es ist zu entscheiden, ob sich der Kennzahlenbaum automatisiert berechnen lässt oder ob manuelle Bewertungen hinzugefügt werden müssen. Diese Entscheidung ist von den beabsichtigten Inhalten abhängig, wie z.B. von der Notwendigkeit, qualitative Messungen zu integrieren. Der hier dargestellte beispielhafte Kennzahlenbaum beinhaltet eine Reihe von einzelnen Kennzahlen, die sich auf unterschiedlichen Ebenen berechnen lassen und verschiedene Aggregationen bilden. Es ist dabei zu beachten, dass alle Kennzahlen vergleichbare Resultate liefern, z.B. die Darstellung von Verhältniswerten als Prozentwerte.

7.6 Kennzahlenformular

DQ-Kriterium

115

Domäne

60 % Kunde

Entität

Attribut 30 % Kundenname

Kennzahl 1

70 % Kunde

30 % Kundentyp

Kennzahl 2

20 % Kundenseg.

40% Adresse

Kennzahl 3

10 % Kundenhistorie Kennzahl m Korrektheit

30 % Produktname

Kennzahl n

70 % Produkttyp

Kennzahl n+1

30 % Produkt 20 % Produkt

70 % Produktgruppe Kennzahl m+1 Kennzahl 20 % Organisation

Abb. 7–2

Kennzahl t

Aggregation

Beispiel für einen Kennzahlenbaum

Der Kennzahlenbaum beinhaltet vier Ebenen, beginnend bei den einzelnen Attributen über die Entitäten hin zu den Domänen, und verdichtet sich in das Datenqualitätskriterium Korrektheit. Das Kriterium Korrektheit misst im Wesentlichen, ob die angelieferten Daten mit den vorgegebenen Formaten übereinstimmen und die Daten inhaltlich korrekt sind. Auf der Ebene der Attribute berechnen sich die Kennzahlen basierend auf den einzelnen Attributen. Auf den Ebenen der Entitäten und Domänen bestehen die Kennzahlen aus Kombinationen verschiedener Attribute, die auch miteinander in Beziehung gesetzt werden können. Die Prozentzahlen neben den einzelnen Kennzahlen geben noch zusätzlich eine Gewichtung an, mit der sich die unterschiedlichen Kennzahlen nach oben hin in das DQ­Kriterium Korrektheit verdichten. Die Gewichtungsfaktoren der einzelnen Kennzahlen sind von den fachlich verantwortlichen Personen gemeinsam abzustimmen und festzulegen. Wesentlich bei der Verwendung von Kennzahlenbäumen ist, wie schon erwähnt, dass die Nachvollziehbarkeit und die Konsistenz der einzelnen Kennzahlen gewährleistet bleibt, um auch entsprechende Aussagen treffen zu können.

7.6

Kennzahlenformular

Abschließend soll beispielhaft ein Formular zur standardisierten Definition und Erfassung von Kennzahlen mit einer Reihe von Bereichen dargestellt werden (siehe Tab. 7–4).

116

7 Kennzahlen zur Messung der Datenqualität

Bereich

Beschreibung

1. Name

Name der Kennzahl

2. Beschreibung

Beschreibung der Kennzahl

3. Version

Version der Kennzahl

4. Datum

Datum der Definition der Kennzahl

5. Datenqualitätskriterium

Kriterium, das mittels der Kennzahl gemessen wird

6. Messpunkt

M1– M5

7. Priorität

Möglichkeit zur Hinterlegung von Prioritäten

8. Schnittstelle

Bezeichnung der Schnittstelle (Datenherkunft)

9. Domäne

Datenbereich, auf den die Kennzahl aufsetzt

10. Entität

Entitäten, die durch die Kennzahl betroffen sind

11. Attribut

Durch die Kennzahl betroffene Attribute

12. Einschränkungen

Einschränkungen, die in den Daten getroffen werden

13. Berechnungsformel

Formel, nach der sich die Kennzahl berechnet

14. Typ

P … Prozentsatz

W … Absolutwert

15. Periodizität

t … täglich

m … monatlich

16. Kommentar

Etwaige Kommentare

17. Verantwortlich

Verantwortliche Person für die Definition der Kennzahl

18. Verantwortliche Stelle

Unternehmensbereich/Abteilung

Tab. 7–4

Formular zur Erfassung von Kennzahlen

Speziell in größeren Unternehmen, die Kennzahlen dezentral durch die Fachbereiche definieren und zentral im Rahmen eines BI Competence Center konsolidieren lassen, ist die Verwendung eines Standardformulars notwendig, um eine konsistente Kennzahlendefinition sicherzustellen. Die Ablage der Kennzahlen erfolgt dabei zentral in einem Repository, mittels dessen die Definitionen der Kennzahlen allgemein zugänglich sind.

7.7

Empfehlungen

Wie in diesem Kapitel dargestellt, eignen sich Kennzahlen im Umfeld von BI­Projekten, um die Datenqualität zu messen bzw. zu überwachen. Allerdings ist bei der Verwendung von automatisch berechneten Kennzahlen zu beachten, dass nur begrenzt Aussagen über den tatsächlichen Zustand der Datenqualität gemacht werden können. Um einen gesamten Überblick über die Datenqualität zu erhalten, sind neben quantitativen auch qualitative Methoden einzusetzen. Nur eine Kombination beider Methoden führt letztendlich auch zu einer nachhaltigen Verbesserung der Datenqualität.

117

Teil II 8

Verbesserung der Datenqualität im Quellsystem

123

9

Data Profiling

131

10

Erfolgreiche Datenvalidierung und -filterung

175

11

Standardisierung und Bereinigung

187

12

Datenanreicherung

219

13

Verbesserung der Datenqualität in der Bereitstellung und Visualisierung

233

14

Wertschöpfung durch Metadaten

253

15

Data Quality Monitoring

269

16

Produktauswahl und -integration

285

118

119

Einleitung

Im ersten Teil des Buches wurde beschrieben, was Datenqualitätsmanagement ausmacht. Ursachen und geschäftliche Konsequenzen schlechter Datenqualität wurden benannt. Organisatorische Aspekte zum Management der Datenqualität wurden diskutiert. Es wurde dargestellt, an welchen Punkten der IT­Architektur wichtige Weichen für Datenqualität gestellt werden. Und schließlich wurden Wege zur Messung der Datenqualität aufgezeigt. Die theoretischen Grundlagen für das Management der Datenqualität sind damit gelegt. In dem nun folgenden zweiten Buchteil wird beschrieben, wie sich Datenqualitätsmanagement in der Praxis umsetzen lässt. Dazu gehören technische Hilfsmittel, Verfahren, Methoden und Werkzeuge. Die meisten Kapitel des zweiten Buchteils beziehen sich auf einen Ausschnitt des Datenflusses von der Erfassung über die Datenintegration bis hin zur Informationsbereitstellung in einem Bericht. Einige Kapitel diskutieren Querschnittsthemen wie z.B. Metadatenmanagement oder Data Quality Monitoring. Metadatenmanagement

Datenintegration

Anreicherung

Datenschnittstelle

Bereinigung

Operative Anwendung

Informationsbereitstellung Standardisierung

Data Profiling Validierung

Manuelle Datenerfassung

DQ-Monitoring

Operative Datenhaltung

Abb. II–1

Data Warehouse

Aufgaben des Datenqualitätsmanagements entlang des Datenflusses

120

Einleitung

Fachlich korrekte Metadaten sind ein wichtiges Mittel, um Bedeutung, Inhalt, Qualität, Aktualität und Kontext von Daten zu beschreiben. Das ist einerseits eine unerlässliche Voraussetzung, um innerhalb einer BI­Lösung aus Daten Informationen zu generieren. Es ist andererseits auch Voraussetzung, um den Verantwortlichen der IT­Systeme entlang eines Datenflusses ein gemeinsames Verständnis für die fließenden Daten zu verschaffen. Metadaten helfen, Brüche in der Datenqualität zwischen IT­Systemen zu vermeiden. Bevor die Datenqualität einer BI­Anwendung mühsam verbessert wird, sollten idealerweise Möglichkeiten zur Verbesserung der Datenqualität in den vorgelagerten Quellsystemen ausgeschöpft werden. In der Regel gilt: Je früher im Datenfluss der IT­Anwendungslandschaft sich Probleme vermeiden oder beheben lassen, desto weniger Aufwand wird insgesamt über die ganze IT­Anwendungslandschaft zur Behebung des Datenqualitätsproblems verursacht. Bei der Erstellung eines Datenintegrationsprogramms zum Laden von Quelldaten in ein Zielsystem (z.B. ein Data Warehouse) wird jeder Entwickler die zu verarbeitenden Quelldaten näher betrachten. Je früher er dies tut, desto schneller werden die erstellten Programme mit der real existierenden Datenqualität umgehen können. Die Aufgabe der Exploration der Quelldaten ist aufwendig, mühsam und wenig spannend. Data Profiling beschreibt, wie dieser Vorgang umfassend, systematisch und effizient angegangen werden kann. Zur Laufzeit eines Datenintegrationsprogramms fallen typischerweise folgende Schritte im Sinne des Datenqualitätsmanagements an, die in der Regel auch in dieser Reihenfolge abgearbeitet werden: 1. 2. 3. 4.

Datenvalidierung Datenstandardisierung Datenbereinigung Datenanreicherung

Im ersten Schritt werden die Quelldaten gegen vorab definierte Regeln (z.B. Datentyp, Wertebereich, referenzielle Integrität) geprüft. Valide Daten werden in die weitere Verarbeitung gegeben. Fehlerbehaftete Daten hingegen werden gefiltert und von der weiteren Verarbeitung ganz ausgenommen oder zumindest speziell behandelt. Im zweiten Schritt werden die Daten in eine einheitliche Struktur bzw. ein einheitliches Format konvertiert sowie die vorhandenen Werte auf die Werte einer normierten Werteliste abgebildet. Durch diesen Schritt sind die Daten untereinander vergleichbar, was Voraussetzung für den nachfolgenden Schritt ist. Im dritten Schritt werden die Daten bereinigt. Dieser Schritt hat verschiedene Facetten: angefangen mit der Korrektur in einem Datenfeld bis hin zur Ermittlung von Duplikaten und ihrer automatisierten Auflösung.

Einleitung

121

Nachdem die Daten bis zu diesem Punkt ein ordentliches Qualitätsniveau erreicht haben, können sie im optionalen vierten Schritt durch Anreicherung veredelt werden. Durch Einbeziehen von Angaben wie der Bonität einer Person oder Institution, demografischen und geografischen Aspekten lassen sich die vorhandenen Daten in wertvolle Information verwandeln. Flankiert wird der Datenintegrationsprozess vom Data Quality Monitoring (DQ­Monitoring), das über alle Schritte des Prozesses die vorhandene Datenqualität sowie erfolgte Maßnahmen protokolliert und letztlich in einem DQ­Bericht oder ­Dashboard darstellt. Darüber hinaus erfolgt durch das Data Quality Monitoring die Freigabe der Daten des ETL­Prozesses (Schritte Datenvalidierung bis ­anreicherung), also die Freischaltung der Daten für Anwender im Tagesbetrieb. Meistens bringt man die Qualität von Daten in Zusammenhang mit den Programmen der Datenintegration entlang des Datenflusses sowie den Datenbanken, die die Daten halten. In einer BI­Anwendung endet der Datenfluss aber sehr häufig erst an der Stelle, wo Daten für den Anwender im Fachbereich als Information dargestellt werden: in einem Bericht, bei der Ad­hoc­Analyse, in einem Dashboard oder weiteren Varianten der Präsentation und Visualisierung von Informationen. Wesentliche Kriterien der Datenqualität wie Verständlichkeit, Glaubwürdigkeit, Zugänglichkeit und Verfügbarkeit spielen hier eine Rolle. Um an dieser Stelle die erforderliche Informationsqualität herzustellen, werden technische Hilfsmittel wie beispielsweise Glossare, Darstellung von Metadaten, Plug­ins für Suchmaschinen oder Ergonomie von Berichten verwendet. Die vorgängig beschriebenen Verfahren, Methoden und Mittel des Datenqualitätsmanagements lassen sich zum größten Teil mit Softwareprodukten bzw. ­werkzeugen unterstützen. Zum Abschluss des zweiten Buchteils wird darauf eingegangen, was bei der Auswahl derartiger Produkte zu beachten ist und wie die Produkte der verschiedenen Kategorien vom Data Profiling bis zum Data Quality Monitoring integriert werden können.

122

Einleitung

123

8

Verbesserung der Datenqualität im Quellsystem

Dieses Kapitel zeigt, wie sich die Datenqualität direkt in den Quellsystemen der BI­Anwendung verbessern lässt und warum nur wenige Unternehmen diesen einfachen und zudem kostengünstigen Weg erfolgreich gehen. Unternehmen, die Datenfehler schon in den Quellsystemen vermeiden, kommen am schnellsten und preiswertesten zu mehr Datenqualität. Haben die Quelldaten keine Fehler, können in der BI­Anwendung nur noch Fehler auftreten, die dort selbst verursacht wurden (z.B. durch fehlerbehaftete ETL­Prozesse). Die Konsequenz: Datenfehler müssen nur einmalig und nur an einer Stelle behoben werden, weshalb der Projektaufwand und der Abstimmungsbedarf sinken. Hinzu kommt, dass es grundsätzlich wesentlich günstiger ist, fehlerhafte Daten in den Quellsystemen zu vermeiden, als sie in den BI­Anwendungen zu korrigieren und zu reparieren. Profitieren werden alle Systeme, die auf die Daten der Quellsysteme zugreifen. Da die BI­Anwendung die gleichen Daten verwendet wie die Quellsysteme, steigt die Vergleichbarkeit der Ergebnisse zwischen den Systemen, weshalb Inkonsistenzen und Nachfragen der Anwender abnehmen werden. Die Projektverantwortlichen vermeiden Datenqualitätsprobleme proaktiv am Ursprung und müssen später nicht reaktiv agieren. Um die Datenqualität in den Quellsystemen zu verbessern, sind zwei Schritte zu gehen, die parallel oder sequenziell ablaufen können: ■ die fehlerhaften Daten korrigieren und ■ neuen Datenqualitätsproblemen vorbeugen. Wurden bereits vor der Verbesserung der Datenqualität in den Quellsystemen fehlerhafte Daten in die BI­Anwendung geladen, sind diese Daten einmalig zu korrigieren. Die Prozesse und Maßnahmen zur Datenkorrektur in den Quellsystemen entsprechen denen in der BI­Anwendung und werden detailliert in Kapitel 11 dargestellt. Der Schwerpunkt in diesem Kapitel liegt in der Beschreibung der vorbeugenden Maßnahmen.

124

8 Verbesserung der Datenqualität im Quellsystem

8.1

Vorbeugung vor neuen Datenqualitätsproblemen

Um nicht ständig die Korrektur der Daten wiederholen zu müssen, sollten die Ursachen für diese Datenqualitätsprobleme gesucht und anschließend an der Wurzel (d.h. am Ort des Entstehens) behoben werden. Die meisten Datenfehler entstehen in fehlerhaften Prozessen (z.B. Eingabeund Verarbeitungsprozesse). Geradezu prädestiniert für Fehler sind Eingabeprozesse (siehe Abschnitt 2.3). Nur selten sind die Daten absichtlich manipuliert worden. In diesem Fall sind die Ursachen allerdings weitaus schwieriger zu finden. Definition bzw. Anpassung von Zielwerten für die Datenqualität Identifikation/ Priorisierung der Datenqualitätsprobleme

Definition Zielwerte

Analyse Bewertung der Prozessverbesserung anhand der Zielwerte

Bewertung

Analyse der Ursachen der Datenqualitätsprobleme und Identifikation der verursachenden Prozesse

DQM

Prozessverbesserungen Verbesserung der Datenqualitätsprobleme verursachenden Prozesse

Abb. 8–1

Verbesserung der Prozesse in den Quellsystemen

In fünf Schritten lassen sich die Prozesse in den Quellsystemen (siehe Abb. 8–1) verbessern: 1. Die Datenqualitätsprobleme eindeutig identifizieren und auf Grundlage einer Kosten­Nutzen­Betrachtung priorisieren 2. Messbare Zielwerte für die Qualität der Daten definieren 3. Die Gründe für die Datenqualitätsprobleme analysieren und die verursachenden Prozesse identifizieren 4. Die Prozesse ändern, um die Datenqualitätsprobleme zu beheben 5. Die Prozessänderungen in einem Vergleich mit den Zielwerten bewerten Sind nach Schritt 5 die Zielwerte nicht erreicht, wird der Prozess wiederholt. Dabei kann man ggf. die Zielwerte anpassen oder durch eine wiederholte Analyse in der Regel weitere Fehlerursachen und Prozesse identifizieren.

8.1 Vorbeugung vor neuen Datenqualitätsproblemen

125

Die Maßnahmen und Ergebnisse der einzelnen Schritte werden nachfolgend ausführlich erläutert. Da hierbei Daten und Prozesse verändert werden, müssen zwingend im Einzelfall bestehende gesetzliche Auflagen zur Compliance und Revisionssicherheit eingehalten werden. Identifikation und Priorisierung der Datenqualitätsprobleme

Sind die Datenqualitätsprobleme identifiziert, z.B. durch Datennutzerbefragungen (siehe Kap. 17), technische Datenanalysen (siehe Kap. 9) oder die Auswertung von Fehlerdatenbanken oder Wikis1, muss man diese priorisieren, da sie sich aus Ressourcengründen meistens nicht auf einmal beheben lassen. Grundlage hierfür ist eine Kosten­Nutzen­Betrachtung. Denn allein aus der Fehleranzahl kann man nicht auf die verursachten Kosten schließen: Eine Datenquelle mit wenigen Fehlern kann unter Umständen höhere Kosten verursachen als eine andere mit vielen Fehlern. So verursacht eine Tabelle mit ehemaligen Kundendaten und hoher Fehleranzahl nur Kosten, wenn ein ehemaliger Kunde wieder etwas bestellt. Hingegen kann eine Tabelle mit aktuellen Bestellungen sehr hohe Kosten verursachen, obwohl sie nur wenige Fehler enthält. Können nämlich die Bestellungen keinem Kunden zugeordnet und deshalb nicht ausgeliefert werden, stornieren die Kunden oder wandern sogar ab. Deshalb müssen für die Kosten­Nutzen­Betrachtung die aus Datenqualitätsproblemen resultierenden Kosten nach dem spezifischen Kostensatz berechnet oder geschätzt werden (siehe hierzu Kap. 3). Ergebnis dieses Schrittes ist eine Auflistung der ausgewählten, zu behebenden Datenqualitätsprobleme einschließlich aller dazu vorliegenden Informationen. Definition der Zielwerte

Um später exakt feststellen zu können, ob die Maßnahmen zur Verbesserung der Datenqualität wirksam sind, werden entsprechende Messwerte (Kennzahlen) und Messpunkte2 definiert (siehe hierzu Kap. 6). Zu Beginn des Projekts dokumentiert das Team die aktuellen Werte der Kennzahlen. Zusätzlich definiert es die Zielwerte, die mit den Verbesserungen erreicht werden sollen. Diese Zielwerte dienen auch als Vorgaben für die Auswahl einer geeigneten Lösung. Ergebnis dieses Schrittes ist eine Liste mit Kennzahlen, den zugehörigen Messpunkten, den jeweiligen Kennzahlwerten vor und den Zielwerten nach der Änderung der Prozesse.

1. 2.

Wiki: einfaches, webbasiertes Content-Management-System, in dem Webseiten mit dem Browser angezeigt und einfach editiert werden können Messpunkte geben an, an welcher Stelle oder nach welchem Prozessschritt die Messung durchgeführt wird.

126

8 Verbesserung der Datenqualität im Quellsystem

Analyse der Datenqualitätsprobleme und Identifikation der verursachenden Prozesse

Sobald das Team weiß, welche Datenqualitätsprobleme behoben werden müssen und welche der Datenquellen betroffen sind, analysiert es die Gründe für die Probleme und identifiziert die verursachenden Prozesse. Häufig ist der Dateneingabeprozess für Kundendaten fehlerhaft. So haben die Sachbearbeiter beispielsweise keine Möglichkeit, die vorhandenen Daten zu korrigieren oder zu aktualisieren. Dadurch nimmt die Aktualität der Daten ständig ab. Oder sie müssen aufgrund einer fehlerhaften Reihenfolge im Eingabeprozess die Daten zu einem Zeitpunkt eingeben, an dem ihnen die Daten noch nicht vorliegen. Die Sachbearbeiter tragen dann oft NULL­Werte ein, wodurch die Vollständigkeit der Daten sinkt. Das System verwendet unzweckmäßige Dummy-Werte als Default (z.B. 999 als Alter). Die Richtigkeit der Daten sinkt, wodurch Auswertungen verfälscht werden können. Eine Maschine erkennt aufgrund der fehlenden Logik z.B. nicht wie ein Mensch auf den ersten Blick, dass ein Lebensalter von 999 Jahren unmöglich ist, und verwendet diesen Wert für Auswertungen. Oft sind auch die bestehenden Zielvereinbarungen für Callcenter­Agenten kontraproduktiv: Die Tantiemen der Agenten werden ausschließlich nach der Geschwindigkeit berechnet, nicht nach der Qualität der eingegebenen Daten. Aus diesem Grunde erfassen die Agenten die Daten oft nicht vollständig, tragen Dummy­Werte ein und schalten evtl. vorhandene Validierungsfunktionen der Anwendung zur Beschleunigung der Eingabe einfach ab. Wieder nimmt die Korrektheit dieser Daten ab. Datenfehler resultieren aber nicht nur aus den zugehörigen Dateneingabeprozessen: System­Upgrades, Prozessautomatisierungen, Datenmigrationen und fehlerhafte Datenkorrekturen verursachen ebenfalls Fehler. So denken viele Teams bei Datenmigrationsprozessen zur Ablösung von Altsystemen zu spät über Datenqualität nach − nämlich erst, wenn die Daten schon im neuen System angekommen sind und die Qualität nicht ausreicht. Gründe hierfür gibt es viele: Häufig ist die Abbildung des alten auf das neue Datenmodell fehlerhaft, sodass die Objekte nicht richtig zugeordnet werden. Das Gleiche gilt für die Konvertierung der alten auf die neuen Datenwerte, wenn z.B. Dummy­Einträge nicht erkannt und als valide Werte interpretiert werden oder Umschlüsselungen in neue Domänen (z.B. Farben wie Rot, Grün, Blau in RAL­Nummern) fehlerhaft oder unvollständig sind. Zusätzlich können Datensätze bei der Migration unbemerkt und unbeabsichtigt verloren gehen, sodass der Datenbestand anschließend unvollständig und inkonsistent ist. Deswegen ist es wichtig, direkt mit den Datenverantwortlichen (Produzenten und Benutzern) zu sprechen. In Workshops sind die wahren Gründe für diese Datenfehler zu finden. Nötigenfalls muss man den Fokus der Untersuchung erweitern. Ein unbeteiligter Moderator sollte diese Workshops leiten. Das alleinige Ziel dieser Workshops ist, die Fehler zu finden und zu beseitigen. Es geht nicht darum, einen Schuldigen zu finden.

8.1 Vorbeugung vor neuen Datenqualitätsproblemen

127

In diesen Gesprächen ist immer wieder nach der Ursache zu fragen, um sich stufenweise dem ursprünglichen Grund zu nähern. Dabei lohnt es sich, dem Datenverantwortlichen den Fehler direkt in den betreffenden Datensätzen zu zeigen. Je anschaulicher und verständlicher der Fehler für ihn ist, desto besser und schneller kann er den Grund dafür herausfinden und benennen. In einem Projekt gab es beispielsweise sehr viele Personen mit einem unvorstellbar hohen Monatseinkommen von 99.999.999€. Zunächst hat man einen Fehler in der Berechnungsformel vermutet. Als dort trotz intensiver Suche aber kein Fehler zu identifizieren war, fiel dem Datenverantwortlichen bei der Betrachtung der betreffenden Datensätze auf, dass es sich hierbei ausschließlich um interne Mitarbeiter des Unternehmens handelte. Bei diesen war das tatsächliche Einkommen durch einen Dummy­Wert ersetzt worden – die Metadaten enthielten hier aber keinen Hinweis darauf. Wird in diesen Gesprächen festgestellt, dass ein darunterliegendes Quellsystem den Fehler verursacht hat, so sind die Analyse und Befragung auf dieses System auszuweiten. Weitere wichtige Hilfsmittel für diesen Schritt sind: ■ ■ ■ ■ ■

Metadaten, Prozessmodelle, Informationsmodelle, Architekturmodelle und Anwendungslandschaftsmodelle.

Ergebnis dieses Schrittes ist ein Dokument, in dem die gefundenen Datenqualitätsprobleme den verursachenden Prozessen zugeordnet sind. Jeder betroffene Prozessschritt wird nebst den daraus resultierenden Auswirkungen dokumentiert. Zudem ist es sinnvoll, die gewonnenen Informationen in einem Informations­ und Prozessmodell (falls noch nicht vorhanden) für weitere Verwendungen zu dokumentieren oder vorhandene Modelle zu aktualisieren und zu erweitern. Außerdem erstellt das Projektteam eine Liste, in der steht, welcher Datenverantwortliche für welche der analysierten Daten zuständig ist. Am besten fügt man auch gleich die Kontaktdaten bei, damit man die Verantwortlichen in den weiteren Projektphasen oder nachfolgenden Datenqualitätsprojekten leichter identifizieren und befragen kann. Änderung der Prozesse

Sind die Ursachen für die Datenqualitätsprobleme identifiziert, muss der Projektleiter die Änderung der betroffenen Prozesse planen. Dazu werden in Workshops mit allen Prozessbeteiligten Lösungsmöglichkeiten erarbeitet und bewertet. Der Fokus liegt auf dem Ziel, die Datenqualität zu verbessern. Es geht nicht darum, die Prozesse hinsichtlich anderer Ziele zu vervollkommnen, so beispielsweise bezüglich Geschwindigkeit oder Zuverlässigkeit. Außerdem sollte das Projekt-

128

8 Verbesserung der Datenqualität im Quellsystem

team darauf achten, dass sich die Zielvorgaben für die Datenqualitätskennzahlen (siehe S. 125) durch die beschlossenen Änderungen erreichen lassen. Allerdings sollte man die Zielvorgaben auch nicht übererfüllen, da die Kosten hierfür ohne relevanten Mehrwert sehr stark ansteigen. Die beschlossenen Änderungen werden in einem Projektplan festgehalten. Handelt es sich um technische Maßnahmen (z.B. Integration einer Adressvalidierungskomponente in eine CRM­Anwendung), sollte das Projektteam vor der Realisierung weitere Maßnahmen wie Toolsichtung oder Entwicklung eines Prototyps planen. Steht der Plan, werden die Prozessänderungen technisch umgesetzt und anschließend getestet. Sind an diesen Prozessen nicht nur Maschinen, sondern auch Mitarbeiter aus den Fachabteilungen beteiligt, sind zusätzlich Schulungen und Trainings zu planen. Schließlich müssen die Mitarbeiter aus den Fachabteilungen erfahren, was sich geändert hat und wie sie selbst die Datenqualität verbessern können. Um die Mitarbeiter zu sensibilisieren, wird ihnen deutlich gemacht, welche Auswirkungen Datenfehler haben. Hinzu kommen weitere Hilfsmittel wie verbesserte Dokumentationen, Online­Hilfen, Checklisten etc. Ergebnis dieses Schrittes ist zunächst ein Projektplan. Beendet ist dieser Schritt, sobald alle organisatorischen Maßnahmen zur Prozessverbesserung erfolgreich abgeschlossen sind und der Rollout der geänderten Anwendungen erfolgt ist. Bewertung der Prozessänderungen

Nachdem die Prozesse geändert worden sind, überprüft das Team, inwieweit die Zielwerte (siehe S. 125) erreicht wurden. Dazu erhebt es die Kennzahlen an den vereinbarten Messpunkten und vergleicht sie mit den Zielwerten. Auch die organisatorischen Maßnahmen werden bewertet: Hat beispielsweise eine Schulung die Fehlerhäufigkeit bei den Fachanwendern auf das vorgegebene Maß reduziert? Neben der technischen Analyse der neuen Daten auf Datenfehler kann man auch die Fachanwender überprüfen. Dabei wird eine repräsentative Auswahl von Anwendern bei ihrer Arbeit beobachtet und die Ergebnisse werden dokumentiert. So lässt sich z.B. prüfen, ob die Anwender neue, als Muss­Felder bei der Eingabe definierte Datenattribute korrekt eingeben oder ob sie unbeabsichtigt neue Fehler produzieren. Auf diese Weise lässt sich auch feststellen, wie oft und wie schnell sie auf die neue Online­Hilfe zugreifen und welche Auswirkungen dies auf die Fehleranzahl hat. Sind alle Zielvorgaben vollständig erreicht, ist der Verbesserungsprozess beendet. Ist das nicht der Fall, so ist in der nächsten Iterationsstufe der gesamte Prozess ab Schritt 2 zu wiederholen. Bei Bedarf werden die Zielwerte den neuen Erkenntnissen und den damit verbundenen neuen Erfordernissen angepasst. Ergebnis dieses Schrittes ist eine Übersicht über die Zielerreichung für die verschiedenen Kennzahlen und eine Beurteilung des Projekterfolgs.

8.2 Empfehlungen

8.2

129

Empfehlungen

So überzeugend dieser Ansatz in der Theorie erscheint, so selten ist er in der Praxis erfolgreich! Denn dieser Ansatz funktioniert in der Regel nur im Rahmen eines unternehmensweiten Datenqualitätsprogramms. Sind die Projekte nicht in ein Datenqualitätsprogramm integriert, fehlen meist Interesse und Engagement des oberen Managements. Dadurch hat das BI­Projekt keine Einflussmöglichkeiten auf die Quellsysteme. Das Team ist ausschließlich auf die im Projekt verwendeten Daten fokussiert und erzielt dadurch nur suboptimale Lösungen. Strittige Punkte bleiben strittig, da kein Eskalationsverfahren zwischen Quellsystem­ und BI­Projektverantwortlichen existiert. Schnell reichen Zeit, Budget und geeignetes Personal im BI­Projekt nicht mehr aus. Häufig wird darüber hinaus die Entwicklung neuer Funktionen in operativen Anwendungen höher priorisiert als BI­ oder DQ­Themen. Hinzu kommen technische Restriktionen in den Quellsystemen, die es unmöglich machen, Fehler an dieser Stelle zu verhindern. Ein Beispiel sind fehlende Validierungsmöglichkeiten in Legacy­Systemen. Auch können Maßnahmen in den zumeist operativen Quellsystemen unbeabsichtigte Seiteneffekte verursachen und/oder die operativen Prozesse verlangsamen, was zu hohen Mehrkosten oder noch schwerwiegenderen Folgen für das Unternehmen führen kann. Kurz: Das Projekt ist damit zum Scheitern verurteilt! In der Praxis entscheiden sich viele Unternehmen trotzdem häufig für den autonomen Ansatz ohne ein Datenqualitätsprogramm. Die Projektteams mildern dann häufig die fehlende Unterstützung des Managements und das fehlende Eskalationsverfahren durch ein gezieltes Selbstmarketing ab. Auch hilft es, wenn sich die Projektteams gegenseitig motivieren. Beispielsweise können die Benutzer der in der BI­Anwendung bereinigten Daten den für die liefernden, operativen Quellsysteme verantwortlichen Mitarbeitern in einem Jour fixe demonstrieren, wie sich der Nutzwert dieser Daten erhöht hat oder welche negativen Konsequenzen fehlerhafte Daten und Prozesse für das Unternehmen haben. Die für die operativen Systeme Verantwortlichen können andererseits über anstehende Änderungen informieren, um gemeinsame Lösungswege zu finden. Hilfreich ist es auch, Mitarbeiter aus dem BI­Team in jedes IT­Projekt zu integrieren, in dem Daten verarbeitet oder verwendet werden. Falls das aus Ressourcengründen nicht möglich ist, sollte die Integration zumindest in jedes wichtige Projekt erfolgen. Alternativ kann auch ein Datenqualitäts­Board (ähnlich einem Architektur­Board) eingerichtet werden, das jedem Projekt eine Freigabe erteilen muss. Um den Kenntnisstand der Mitarbeiter aus den Quellsystemen in Bezug auf Datenqualitätsmanagement zu steigern, sollten Schulungen und Workshops angeboten werden − gilt es doch, das Bewusstsein dieser Mitarbeiter im Hinblick auf die negativen Folgen schlechter Datenqualität zu schärfen und diese zu befähigen, Datenqualitätsprobleme selbst zu erkennen, zu beheben und – noch viel

130

8 Verbesserung der Datenqualität im Quellsystem

wichtiger – im Vorfeld zu vermeiden! Zusätzlich sollten die für die BI­Anwendung zuständigen Mitarbeiter anbieten, die Projektteams der Quellsysteme direkt vor Ort zu unterstützen. Die Fokussierung auf den in der BI­Anwendung verwendeten Teilbestand der Daten kann man aufheben, indem man den Projektfokus auf komplette Einheiten (z.B. auf ein Quellsystem, eine Datenbankinstanz oder einzelne, zusammenhängende Datenobjekte) verbreitert. Anstatt sich beispielsweise nur auf einige wenige, nicht zusammenhängende Daten zu beschränken, könnte sich das Datenqualitätsmanagement auf alle Daten eines bestimmten Geschäftsprozesses beziehen. Auswahlgrundlage ist eine Kosten­Nutzen­Analyse. Liefervereinbarungen zwischen dem Daten liefernden Quellsystem und dem Data Warehouse sind empfehlenswert. Diese Liefervereinbarungen werden initial einmalig aus verschiedenen Bereichen generiert. Aus den Metadaten des DWH erfolgt das Feststellen der Tabellen- bzw. Dateinamen der Liefersysteme. Mit diesen Informationen können aus der Job-Automation (bspw. Tivoli, OPC) die Jobs und Eingabestrukturen der Daten sowie über eine IT-Produktdatenbank die Zuständigkeiten der Produktionssysteme automatisiert ermittelt werden. Darüber hinaus wird der Bereitstellungszyklus sowie ggfs. Besonderheiten wie ErrorHandling, Wiederholungsläufe etc. ermittelt. Im einfachen Falle wird hieraus ein PDF-Dokument generiert, das vom Liefersystem gegenzuzeichnen ist. Dies kann darüber hinaus bspw. einmal jährlich zur Auffrischung geschehen. In einer etwas komplexeren Variante kann diese Information parallel über ein Frontend bereitgestellt werden, und die Unterschrift erfolgt durch Kennzeichnung in einem entsprechenden Datenfeld, das automatisiert ausgewertet wird. Eine weitere Möglichkeit ist, bei automatisiertem Programmeinsatzverfahren des Liefersystems die Programmversion des Liefersystems in den Metadaten des DWH zu speichern und bei jeder Versionsänderung einerseits automatisiert nachzufragen, ob eine DWH-relevante Änderung stattgefunden hat und andererseits die Datenlieferung als suspekt zu kennzeichnen. Bei sequenziellen Dateien kann diese Information auch durch Header- und Trailer-Sätze mitgegeben werden, ggfs. können sie auch über Steuerkarten der Job-Automation in den ETL-Prozess geschleust werden. Für suspekte Datenlieferungen kann eine Nachricht über das E-Mail-System an die Verantwortlichen erfolgen. Alternativ werden Frontends für den Zugriff auf die Metadatensysteme eingesetzt, in denen eine (zusätzliche) Kommentierung und Freigabe erfolgt. Aus den o.g. Prozessen lassen sich darüber hinaus zur Laufzeit des ETL-Jobs Kontrollen durchführen (bspw. Uhrzeit des Job-Starts und des Job-Endes/Dauer des Jobs) und mit Sollwerten in den Metadaten vergleichen, um ggfs. präventiv einzugreifen, wenn es zu Abweichungen kommen sollte. Die Aufwände für diese automatisierten Qualitätssicherungen im BI-Umfeld halten sich in Grenzen, teilweise kann auf Standardmodule und Schnittstellen der IT zurückgegriffen werden. Sie sind Grundlage, wenn die ETL-Prozesse im Rahmen von Operational BI eingesetzt werden.

131

9

Data Profiling

Dieses Kapitel zeigt, wie man mit Data Profiling erfolgreich die Datenqualität verbessern kann. Es werden die einzelnen Data­Profiling­Verfahren vorgestellt. Viele praktische Beispiele zeigen, wie man diese richtig einsetzt, die Ergebnisse verwendet und typische Stolperfallen umgeht. Außerdem werden Tipps gegeben, wie man das Data­Profiling­Team richtig zusammenstellt. Data Profiling ist ein weitgehend automatisierter Prozess zur Analyse vorhandener Datenbestände. Verschiedene Analysetechniken liefern Informationen über Inhalt, Strukturen und Qualität der Daten. Durch das Data Profiling (siehe Abb. 9–1) werden in erster Linie die existierenden Metadaten an den vorhandenen Echtdaten validiert und neue Metadaten gefunden. Zusätzlich erhält man Informationen über bestehende Datenqualitätsprobleme, die verursachenden Daten und die Datenqualität der analysierten Daten. Dabei werden keine Qualitätsprobleme in den Daten behoben, sondern nur die zugehörigen Metadaten korrigiert. Wer sein Projekt realistisch planen möchte, benötigt verlässliche Aussagen über die Qualität der Daten aus den Quellsystemen. Dementsprechend ist das Data Profiling möglichst früh einzusetzen. Nur so ist man vor unliebsamen Überraschungen sicher, die den Aufwand stark vergrößern und den Projekt­Endtermin weit nach hinten verschieben können. Man sollte sich grundsätzlich niemals auf die Qualitätsaussagen anderer verlassen, da diese häufig auf Wunschdenken oder Unkenntnis beruhen. In welchen Projektphasen das Data Profiling wie eingesetzt werden sollte, wird in Teil III dieses Buches detailliert beschrieben. Es lohnt sich, für das Data Profiling entsprechende Werkzeuge (siehe Kap. 16) einzusetzen, die den Ressourcenaufwand erheblich reduzieren. Insbesondere bei wiederholter Anwendung ist der Aufwand wesentlich geringer als bei manuellen Verfahren. Zudem lassen sich die gewonnenen Ergebnisse schnell und einfach an anderen Stellen wie dem Monitoring während der ETL­Prozesse oder dem Datenqualitäts­Reporting (siehe Kap. 15) verwenden.

132

9 Data Profiling

Vorher

Data Profiling

Nachher

Metadaten (richtig)

Metadaten (richtig/falsch)

Daten (richtig/falsch) Daten (richtig/falsch)

Infos zu falschen Daten

Die Korrektur der Daten erfolgt erst in nachfolgenden Prozessen.

Abb. 9–1

9.1

Aufgaben des Data Profiling

Data-Profiling-Prozess

Der Ablauf einer Data­Profiling­Analyse ist ein iterativer Prozess (siehe Abb. 9–2), der in folgenden vier Einzelschritten abläuft: 1. 2. 3. 4.

Daten integrieren, integrierte Daten analysieren, Ergebnisse darstellen und fachlich bewerten.

 Extraktion

 Attributseigenschaften

1

 Transformation

 Beziehungen

Integration

 Anreicherung

Analyse

 Bereitstellung

 Statistiken  Datenregeln (einfach bis komplex)  …

4

Data Profiling

2

Bewertung  Semantische Bewertung der Ergebnisse

Ergebnisdarstellung

3

 Tabellen-/Spaltenname  Verletzte Regeln  Liste invalider Werte + Häufigkeit in %  Tabellen-/RowID der invaliden Werte  Anzahl überprüfter Rows  …

Abb. 9–2

Der iterative Data-Profiling-Prozess

9.1 Data-Profiling-Prozess

9.1.1

133

Schritt 1: Integration der Daten

Zuerst extrahiert das Projektteam die Daten für die Data­Profiling­Analyse aus den Quellsystemen. Kopiert das Team diese Daten zunächst in einen eigenen Staging­Bereich für das Data Profiling, hat das mehrere Vorteile: ■ Erstens wird die zusätzliche Last auf den Quellsystemen vermieden. Da der Data­Profiling­Prozess große Datenbestände analysiert, ist der Bedarf an Rechnerressourcen sehr hoch. Eine Entkopplung verhindert, dass diese unnötig stark belastet werden und sich die operativen/dispositiven Prozesse verlangsamen. ■ Zweitens wird so die Analyse von Änderungen in den Quellsystemen entkoppelt. Data Profiling ist ein iterativer Prozess. Die einzelnen Schritte können sehr lange dauern. Während der Dauer dieses Prozesses ändern sich die Daten in den Quellsystemen ständig. Deshalb können die Wiederholungen nicht auf einem konstanten Datenbestand durchgeführt werden, was die Ergebnisse verfälscht. Nur wenn der Datenbestand während des gesamten Prozesses konstant bleibt, sind die Ergebnisse reproduzierbar. ■ Drittens wird die Laufzeit des Data­Profiling­Prozesses kürzer. Für das Data Profiling werden typischerweise Daten aus verschiedenen Systemen über Systemgrenzen hinweg analysiert. Dadurch können sich die Laufzeiten des Data­Profiling­Prozesses bei einem direkten Zugriff stark erhöhen, insbesondere bei schmalbandigen Netzwerkverbindungen. Bei Verbindungsabbrüchen muss der gesamte Analyseschritt wiederholt werden. Um bessere Ergebnisse zu erzielen, werden die Daten vor der Data­ProfilingAnalyse noch weiter aufbereitet. Beispielsweise werden als Freitextfelder definierte Attribute mit zusammengesetztem Inhalt aufgespalten (Parsing): So trennt man Name = »Dr. Friedrich Müller« in Titel = »Dr.«, Vorname = »Friedrich« und Nachname = »Müller« auf. Außerdem entfernt man für die Analyse nicht benötigte Attribute und fügt Referenzdatenbestände (z.B. für Adressdaten) hinzu. Besitzen die zu analysierenden Daten referenzielle Beziehungen zu anderen, nicht in die Analyse einbezogenen Daten, sollte man diese Beziehungen auflösen und die Schlüsselwerte durch die »richtigen« Werte ersetzen. Alternativ werden die verbundenen Daten auch zusätzlich mit in die Analyse einbezogen. Die so aufbereiteten Daten stellt man anschließend für die Analyse bereit.

9.1.2

Schritt 2: Analyse der integrierten Daten

Sind die Daten bereitgestellt, werden sie mithilfe der verschiedenen Verfahren des Data Profiling analysiert. Obwohl dies weitestgehend automatisch mithilfe eines Werkzeugs passiert, muss der Data­Profiling­Analyst interagieren. So muss er die

134

9 Data Profiling

geeigneten Analyseverfahren auswählen und konfigurieren. Eine Übersicht der vorhandenen Verfahren und weitere Informationen dazu enthält Abschnitt 9.3. Wie der gesamte Prozess ist auch dieser Analyseschritt hochgradig iterativ. Der Analyst wählt ein geeignetes Verfahren, analysiert damit die Daten und begutachtet die Ergebnisse. Darin identifiziert er erste Auffälligkeiten und weitere Fragen, denen er dann nachgeht. Dazu wechselt er in der Regel mehrfach die Verfahren, bis sich am Schluss die Erkenntnisse verfestigt haben. Für diese Aufgabe ist detektivischer Spürsinn gefragt.

9.1.3

Schritt 3: Darstellung der Ergebnisse

Ergebnisse, offene Fragen und Vermutungen bereitet er in geeigneter Form auf und bespricht sie im Nachgang mit dem Business­Analysten. In der Praxis hat sich gezeigt, dass der Business­Analyst diese nur richtig und vollständig bewerten kann, wenn sie verständlich und nicht zu IT­lastig dargestellt sind. Meist fehlen dem Business­Analysten die notwendigen IT­Kenntnisse, um mit den Begriffen »Referenzielle Integrität«, »Eindeutigkeit« etc. etwas anfangen zu können. Deshalb ist es erfolgversprechender, bei der Darstellung der Ergebnisse für den Fachexperten verständliche Begriffe zu verwenden. Beispiel: Versuche, dem Business­Analysten zu erklären, dass »in der Tabelle BESTELLUNGEN 3,2 Prozent Waisen ohne Vater in der Tabelle KUNDEN existieren«, scheitern. Zielführender sind die Fragen: Warum sind 3,2 Prozent aller Bestellungen keinem Kunden zuzuordnen? Wohin sind diese Bestellungen geliefert worden und wer hat die Rechnung bekommen? Außerdem ist es hilfreich, die entsprechenden Datensätze dem meist überraschten Business­Analysten gleich mit zu präsentieren. Denn in vielen Fällen kann der Fachexperte erst anhand der zugehörigen Datensätze die mögliche Ursache identifizieren. Wer die Reporting­Funktionalitäten des verwendeten Werkzeugs benutzt, kann den Aufwand für die aufbereitete Darstellung meist deutlich reduzieren. Viele Werkzeuge verfügen bereits heute über ein umfangreiches Berichtswesen, das zu den üblichen tabellarischen häufig auch grafische Darstellungen bietet. Außerdem ermöglichen sie den direkten Zugriff und die Darstellung der betroffenen Datensätze.

9.1.4

Schritt 4: Fachliche Bewertung der Ergebnisse

Nachdem der Daten­Analyst dem Business­Analysten die Ergebnisse verständlich präsentiert hat, führt dieser eine fachliche Bewertung durch. Diese geschieht in der Praxis in mehreren Workshops. Auch der Daten­Analyst ist anwesend, um Rückfragen zu beantworten, Ergebnisse zu präzisieren und für eine Bewertung notwendige, zusätzliche Informationen zur Verfügung zu stellen. Die Bewertung ist und bleibt aber die originäre Aufgabe des Business­Analysten, schließlich ist

9.2 Zusammensetzung des Data-Profiling-Teams

135

hierfür ausgeprägtes Wissen über die Geschäftsprozesse und die Fachlichkeit nötig. Der Daten­Analyst unterstützt lediglich, kann diese Aufgabe aber nicht selber übernehmen. Beispiel: Der Daten­Analyst hat in einer Data­Profiling­Analyse herausgefunden, dass für das Attribut KUNDENSTATUS 98,7 Prozent der Werte durch die Domänenwerte INTERESSENT oder KUNDE abgedeckt sind. Die restlichen 1,3 Prozent verteilen sich auf die Werte NULL, NOCH KEIN KUNDE bzw. EXKUNDE. Der Business­Analyst muss jetzt bewerten, ob die Domäne so fachlich richtig definiert ist. Außerdem klärt er, ob die diskreten Werte INTERESSENT und KUNDE tatsächlich die einzigen erlaubten Werte sind, wie die anderen vorhandenen Werte bei der Bereinigung und den nächsten Ladeläufen auf diese beiden zulässigen Werte abgebildet werden sollen und woher diese anderen Werte stammen. Außerdem muss er festlegen, ob das Attribut ein MUSS­Feld ist oder ob auch die gefundenen NULL­Werte zulässig sind. Dazu liefert der Daten­Analyst ihm die Datensätze mit den anderen Werten, die nachfolgend analysiert und im Quellsystem überprüft werden. Reichen dem Business­Analysten die vorhandenen Informationen nicht oder sind noch Fragen offen, wird der gesamte Prozess mit geänderten Daten und neuen Fragen wiederholt gestartet. Erst wenn alle Fragen geklärt sind, wird der Prozess beendet.

9.2

Zusammensetzung des Data-Profiling-Teams

In der Praxis hat sich für die Data­Profiling­Analyse ein kleines Team mit zwei bis drei Personen bewährt, das nicht nur aus Mitarbeitern der IT­Abteilung besteht. Dieses Team kann virtuell sein und vom Data Steward oder dem BICC/DWH geleitet werden. Wichtig ist, dass die Teammitglieder unterschiedliche Skills besitzen. So reicht das Fachwissen in den IT­Abteilungen sehr häufig nicht aus, um die gefundenen Auffälligkeiten zu erkennen und die Geschäftsregeln zu identifizieren und zu validieren. Hierfür sind Experten aus der Fachabteilung nötig, die die Geschäftsprozesse und ­regeln sehr genau kennen. Zusätzlich sollten sie für ein besseres Verständnis der Data­Profiling­Ergebnisse auch Kenntnisse in Datenstrukturen und ­modellierung haben. Für jeden der vier Prozessschritte sind andere Skills notwendig (siehe Abb. 9–3). Neben seinen technischen Skills sollte ein Daten­Analyst auch Team­, Präsentations­ und Moderationsfähigkeiten haben. Nur so ist gewährleistet, dass er die Ergebnisse dem Business­Analysten verständlich präsentieren kann.

136

9 Data Profiling

IT-Abt.

 Datenstrukturen  Datenarchitekturen

 Data-Profiling-Werkzeug

1

Integration

Daten-Analyst

DatenAnalyst

 Datenmodelle  Anwendungslandschaften

Analyse

 Anwendungen  Geschäftsprozesse  Business Rules

2

Skills

Bewertung

Ergebnisdarstellung

BusinessAnalyst

Daten-Analyst

3

 Datenarchitekturen

9.3

 Datenstrukturen

IT-Abt.

4

Abb. 9–3

 Analyseverfahren

 Data-Profiling-Werkzeug  Moderation  Präsentation  Analyseverfahren

Zusammensetzung und Skills eines Data-Profiling-Teams

Vorgehensweise beim Data Profiling

Grundsätzlich lassen sich die verschiedenen Data­Profiling­Verfahren in Attribut­, Datensatz1­ und Tabellen2­Analyse einteilen. Diese Verfahren liefern aber nur einzelne Mosaiksteinchen vom Bild der Datenqualität – erst die richtige Kombination ergibt ein vollständiges Bild und sichert den Erfolg. Die Auswahl erfolgt nach den spezifischen Anforderungen im Projekt, deshalb kann an dieser Stelle keine allgemein gültige Empfehlung gegeben werden. In der Attributanalyse werden alle Werte in einer Spalte (= Attribut) sowie die Eigenschaften der Attribute einer Tabelle analysiert, in der Datensatzanalyse alle Datensätze einer Tabelle und in der Tabellenanalyse alle Beziehungen zwischen verschiedenen Tabellen. Hinter jeder dieser drei Analysearten stehen wiederum viele unterschiedliche Data­Profiling­Verfahren. Die vorwiegend technisch orientierten und aktuell gut durch Werkzeuge unterstützten Standardverfahren beschränken sich häufig auf die formalen Prüfungen (z.B. Vollständigkeit) und beinhalten kaum inhaltliche Prüfungen (z.B. auf Korrektheit). Deshalb bleiben die Ergebnisse unvollständig. Daher sind diese Verfahren um fachliche Geschäftsregeln zu erweitern und die Prozess­ und Fachkenntnisse der Experten aus dem Fachbereich in maschinell prüf- und auswertbare Geschäftsregeln zu überführen. Diese Regeln müssen sich

1. 2.

Datensatz wird als Synonym für eine Struktur verwendet. Tabelle wird als Synonym für eine Sammlung gleicher Strukturen verwendet.

9.4 Data-Profiling-Verfahren zur Analyse von Attributen

137

einerseits anhand der Daten validieren lassen, andererseits müssen die Daten damit automatisiert und wiederholbar geprüft werden können. Diese in einem Repository verwalteten Geschäftsregeln kann man auch in den ETL­Prozessen nutzen, damit die den Regeln widersprechenden Daten abgewiesen und bereinigt werden. Gleichzeitig werden sie auch beim Reporting der Prozessabläufe verwendet, indem z.B. Berichte mit der Anzahl abgewiesener Sätze und der zugehörigen Geschäftsregel erstellt werden. Standardwerkzeuge bieten diese Möglichkeit kaum, sodass man überwiegend auf Nischenanbieter oder Eigenentwicklungen zurückgreifen muss. Die Standardwerkzeughersteller bieten an, dass man ihnen die Daten zum Data Profiling schicken soll. Sie versprechen, dass man einen realistischen Eindruck von der Qualität seiner Daten erhalte. Neben den rechtlichen Problemen bezüglich der Weitergabe von hochsensiblen Daten an Dritte gibt es noch ein inhaltliches Problem: Wie angesprochen, können nur fachliche Experten mit ausgeprägten Prozesskenntnissen die Ergebnisse und Hinweise der Standardverfahren bewerten. Hinzu kommt, dass diese sehr spezifischen Geschäftsregeln bei diesem Check­up naturgemäß nicht verwendet werden. Woher soll der Werkzeughersteller auch die Geschäftsregeln des ihm fremden Unternehmens kennen? Aus diesem Grund ist das Ergebnis in höchstem Maße unvollständig und gibt keinen realistischen Eindruck über die Datenqualität. Solche Check­ups sind allerhöchstens ein erster Schritt; nur harte Arbeit führt zu verwendbaren Ergebnissen. Ein Werkzeug ist und bleibt eben nur ein Werkzeug – auch beim Data Profiling.

9.4

Data-Profiling-Verfahren zur Analyse von Attributen

Für das Data Profiling auf Attributebene werden verschiedene Methoden eingesetzt, die einzeln oder kombiniert verwendet werden.

9.4.1

Standardanalysen auf Attributebene

Attributnamenanalyse

Bei der Attributnamenanalyse handelt es sich um eine einfache, eher fachlich orientierte Analysemethode. Die Namen der Attribute werden auf Verständlichkeit geprüft, da sprechende Namen (z.B. KUNDE_ID) mehr über das Attribut aussagen als kryptische Bezeichnungen (z.B. KDID1). Dabei ist zu beachten, dass der Name KUNDE_ID verständlicher ist als nur ID, insbesondere wenn sich noch weitere Attribute mit IDs (wie z.B. der des zuständigen Vertriebsmitarbeiters) in der gleichen Tabelle befinden. Enthält ein Attributname einen Hinweis auf den Datentyp (z.B. EINKOMMEN_NR) oder die Funktion (z.B. KUNDE_ID), so sollte dieser auch richtig sein. Beispielsweise können mit ID bezeichnete, aber nicht eindeutige Attribute

138

9 Data Profiling

genauso zu einem falschen Verständnis führen wie solche mit NR und nichtnumerischem Inhalt. Ein Beispiel hierfür ist in Abbildung 9–4 das Attribut BERUFSGRUPPEN_NR, dessen Werte nur zu 72,5 Prozent numerisch sind. Zusätzlich wird analysiert, ob die Namen eindeutig sind oder Synonyme3/Homonyme4 existieren. Der Business­Analyst kann entweder die Attribute und deren Werte betrachten oder den Hinweisen einer Domänenanalyse nachgehen: Findet er unterschiedlich benannte Attribute mit der gleichen Domäne, so deutet das auf Synonyme hin; entdeckt er hingegen unterschiedliche Domänen in gleichnamigen Attributen, so ist das ein Hinweis auf Homonyme. Synonyme kann er berichtigen, indem er einen eindeutigen Namen festlegt. In der Praxis kommt es öfter vor, dass nicht mehr genutzte Attribute für neue Inhalte zweckentfremdet werden, ohne den Namen ebenfalls anzupassen. Die möglichen Gründe sind: Man hat es schlichtweg vergessen, oder man hat, um den Aufwand zu reduzieren, die Abfragen auf dieses Attribut und die dieses Attribut verwendenden Prozesse nicht aktualisieren wollen. Ein Indiz hierfür ist, dass die Werte eines Attributs nicht mit den anhand des Attributnamens erwarteten Werten übereinstimmen. Ein Beispiel: In einem Attribut STATUS werden mithilfe der Muster­ oder Domänenanalyse Telefonnummern gefunden. Meist ist es aber sehr schwierig, diese zweckentfremdeten Attribute zu finden, da in der Regel diese Attribute gemischt alte und neue Werte enthalten. So sind in dem Beispiel mit dem Attribut STATUS passende Statusinformationen und unpassende Telefonnummern enthalten. Datentypanalyse

Die Datentypanalyse ist eine einfache, eher technisch orientierte Analysemethode, die insbesondere bei unbekannten Daten angewendet wird. Bei Textdateien oder Quellen mit abweichenden Datenformaten (z.B. beim Zugriff auf ein anderes Datenbanksystem) lässt sich damit der passende, fachlich korrekte Datentyp für die Speicherung im Data Warehouse identifizieren. Zunächst stellt der Daten­Analyst den in den Metadaten (z.B. im Data Dictionary einer Datenbank) dokumentierten physikalischen Datentyp fest. Anschließend analysiert er alle zu diesem Datentyp gehörenden Attributwerte und leitet daraus den tatsächlichen, korrekten physikalischen Datentyp (wie z.B. NUMBER) ab. Zusätzlich zum Datentyp analysiert der Analyst auch noch die Länge, Genauigkeit (z.B. bei NUMBER die Stellen vor und nach dem Komma), den vorherrschenden Datentyp sowie die davon abweichenden Werte. Weicht der dokumentierte von dem dominanten Datentyp ab, ist der dokumentierte Datentyp in der Regel ein alphanumerischer. Denn in einem alphanu3. 4.

Synonyme: unterschiedliche Begriffe mit gleicher Bedeutung Homonyme: gleiche Begriffe mit unterschiedlicher Bedeutung

9.4 Data-Profiling-Verfahren zur Analyse von Attributen

139

merischen Datentyp lassen sich fast alle Werte der anderen Datentypen abspeichern. Die Ursachen sind vielfältig: Nicht alle Quellsysteme (z.B. Legacy­Systeme) unterstützen jeden Datentyp (z.B. DATE), insbesondere kommaseparierte Textdateien lassen nur alphanumerische Datentypen zu. Oder die Werteliste enthält nicht zum originären Datentyp passende »Ausreißer« zur Kennzeichnung besonderer Werte. Zum Beispiel bedeutet in einem Datentyp ENDEDATUM der für ein Datum nicht zulässige Wert 33.33.3333, dass der Zeitraum offen ist und noch kein Ende­Datum festgelegt wurde. Oder die Abweisung nicht zum Datentyp passender Werte ist ausgeschaltet, um auch die unzulässigen Werte zu speichern. Diese werden dann erst in einem nachfolgenden Prozess bereinigt oder zum Nachweis archiviert. Auch wenn diese Gründe im Einzelfall nachvollziehbar sind, korrumpieren sie das Data Warehouse und umgehen die vorhandenen Validierungsprüfungen. Damit die Datenqualität nicht leidet, sollte der Daten­Analyst diese Zweckentfremdung verhindern, indem er in die ETL­Prozesse eine Datentyp­Validierung nebst zugehörigem Datenfehlermanagement integriert.

Abb. 9–4

Ergebnis einer Datentypanalyse (Beispielausschnitt)

Die in Abbildung 9–4 dargestellten Ergebnisse einer Datenanalyse lassen sich folgendermaßen interpretieren: Zunächst werden die Attribute betrachtet, bei denen der dokumentierte und der dominante (= häufigste) Datentyp voneinander abweichen. Die Attribute BERUFSGRUPPEN_NR und BILDUNGS_NR sind als Text (VARCHAR2) definiert, enthalten aber zu 72,5 bzw. 97,1 Prozent Zahlen (NUMBER). Man überprüft deshalb, ob es sich fachlich tatsächlich um Attribute dieses Datentyps handelt (wie der Attributname vermuten lässt) und warum es auch Werte gibt, die keine Zahlen enthalten. Dürfen diese Attribute ausschließlich Zahlen enthalten, so ist der dokumentierte Datentyp zu aktualisieren. Außerdem sollte man in Betracht ziehen, bei der Verarbeitung dieser Daten die Attributwerte auf den korrekten Datentyp zu überprüfen. Auch bei den anderen Attributen gibt es Auffälligkeiten: So bestehen bei der ANREDE nur 99 Prozent der Werte aus Text, was unplausibel erscheint. Die weitere Analyse der abweichenden Werte zeigt, dass es Datensätze mit unkorrekten Werten (hier Zahlen 1 bis 3) gibt. Dies bestätigt auch ein Wert für die minimale

140

9 Data Profiling

Länge von 1, der unplausibel für eine Anrede erscheint. Unplausibel ist auch, dass das Attribut ANZ_KINDER 2,3 Prozent nichtnumerische Werte enthält. Die BERUFSGRUPPE enthält hingegen 12,3 Prozent nicht alphanumerische Zeichen, weshalb die abweichenden Werte ebenfalls überprüft und validiert werden. Entsprechendes gilt für die Attribute BILDUNG, BRANCHE und EINKOMMENSGRUPPE. Sehr oft vertreten Entwickler und Analysten die Meinung, dass der physikalische auch immer der fachlich korrekte Datentyp ist. Das ist so nicht richtig: Der physikalische Datentyp gibt lediglich an, wie die Werte technisch abgespeichert werden sollen; er ist abhängig von den in der jeweiligen Umgebung (z.B. Datenbank) unterstützten Datentypen. Mithilfe einer Überprüfung der physikalischen Datentypen werden ausschließlich Werte validiert. Sie sind aber zu unspezifisch, um damit inkorrekte Werte zu identifizieren. Dazu muss diese Analyse durch weitere Methoden, wie eine Musteranalyse, ergänzt werden. Die Analyse der zusätzlichen Eigenschaften eines Datentyps wie Länge und Genauigkeit scheint auf den ersten Blick zweitrangig, führt aber bei bestimmten Fragen oft zu wichtigen Hinweisen. Insbesondere die Länge eines alphanumerischen Datentyps sollte man beachten. Weicht die dokumentierte Länge sehr stark von der maximalen oder dominanten Länge ab, so liegt vermutlich eine Zweckentfremdung dieses Attributs vor. Ist z.B. das Attribut LANGBESCHREIBUNG eines Artikels mit einer Länge von 100 Zeichen dokumentiert, hat die Analyse hingegen eine maximale Länge von drei Zeichen ergeben, so ist das sehr verdächtig. Diese Werte sind dann näher zu betrachten und mit dem Fachbereich zu diskutieren. Entweder wurde das Attribut seit Betriebsbeginn zur Speicherung anderer Informationen zweckentfremdet oder es liegt ein Datenfehler vor, da z.B. ein fehlerhafter Prozess nur die ersten Zeichen in das Attribut gespeichert hat. Ergibt die Analyse hingegen eine maximale Länge von 98 Zeichen, 70 Prozent der Werte haben aber die dominante Länge von drei Zeichen, lässt das auf einen anderen, ansonsten sehr schwer zu findenden Fehler schließen: Bis zu einem bestimmten Zeitpunkt enthielt das Attribut tatsächlich Beschreibungstexte, anschließend wurde es zweckentfremdet und andere Informationen wurden darin gespeichert. 25,00 20,00 15,00 10,00 5,00 0,00 NULL

Abb. 9–5

1–3

4–10

11–15

15–20

21–30

31–40

Prozentuale Verteilung der Länge des Attributs NAME (Beispiel)

41–50

> 50

9.4 Data-Profiling-Verfahren zur Analyse von Attributen

141

Passen die durch Analyse ermittelte maximale, minimale und dominante Länge mit der dokumentierten zusammen, so kann man durch Analyse der Verteilung der Längen noch Fehler finden. Beispielsweise ist in Abbildung 9–5 zu sehen, dass 7 Prozent der Werte für das Attribut NAME eine Länge zwischen ein und drei Zeichen haben. Da dieser Anteil auf den ersten Blick zu hoch erscheint, müssen nachfolgend die zugehörigen Werte näher analysiert und auf fehlerhafte Einträge überprüft werden. Auch bei der Genauigkeitsanalyse deutet eine Abweichung zwischen dokumentierter und vorhandener Genauigkeit auf eine Zweckentfremdung hin. Sie zeigt aber auch, ob die Genauigkeit den fachlichen Ansprüchen gerecht wird. Soll in einem Unternehmen z.B. die Kennzahl UMSATZ auf den Cent genau berechnet werden, so müssen alle an der Berechnung dieser Kennzahl beteiligten Werte die dafür erforderliche Genauigkeit besitzen. Ansonsten kommt es bei der Berechnung zu unerwünschten Rundungsfehlern, die die Korrektheit der Kennzahl vermindern. Es reicht also nicht aus, dass nur die Kennzahl UMSATZ die erforderliche Genauigkeit besitzt. Auch die Berechnungsformeln und die Herkunft der verwendeten Werte müssen bekannt sein. Zudem lassen sich mit der Genauigkeitsanalyse auch Rundungen von Werten identifizieren. In der Praxis findet sich das gelegentlich bei Geldbeträgen, die auf volle Beträge gerundet werden. Das Beispiel in Tabelle 9–1 zeigt, dass nur diskrete Werte für das Attribut JAHRESEINKOMMEN im Bereich von 0,01 bis 1.000.000 existieren; die Werte steigen stetig um den konstanten Faktor von 100, andere Zwischenwerte fehlen. Das lässt darauf schließen, dass die Werte gerundet wurden – z.B. auf volle hundert Euro. Wert

# Zeilen

% Zeilen

0,01

3.345

00,87%

0,10

256

00,07%

1,00

1.356

0,35%

10,00

3.899

01,01%

100,00

45.656

11,87%

1.000,00

325.678

84,71%

10.000,00

3.421

00,89%

100.000,00

865

00,22%

1.000.000,00

2

00,00%

Gesamt:

Tab. 9–1

384.478 Zeilen

Ergebnis einer Genauigkeitsanalyse für JAHRESEINKOMMEN (Beispiel)

142

9 Data Profiling

Wertebereichsanalyse

Eine einfache, eher fachlich orientierte Analysemethode ist die Wertebereichsanalyse. Sie ermittelt den minimalen, den maximalen und den durchschnittlichen Wert, die statistische Verteilung der einzelnen Werte und verschiedene andere statistische Kennzahlen (z.B. Standardabweichung). Die ermittelten Werte werden fachlich plausibilisiert; es wird also überprüft, ob sie mit den Erwartungen übereinstimmen. Liegt der Wertebereich für das Attribut ANZAHL KINDER der KUNDEN z.B. zwischen 0 und 3, wobei es eine Gleichverteilung (siehe Abb. 9–6) der Häufigkeit der Werte 1, 2 und 3 gibt, so widerspricht das dem Erwartungswert. Es ist auf den ersten Blick unplausibel, warum es nur Kunden mit maximal drei Kindern gibt und genauso viele Kunden mit einem wie mit drei Kindern. Auch eine hohe Häufigkeit einzelner Werte (meistens am Rande des Wertebereichs) ist verdächtig und muss fachlich untersucht werden. Werte am Rand des Wertebereichs werden gerne für die Kennzeichnung spezieller Fälle verwendet. So steht der Wert 999.999.999 im numerischen Attribut MONATSEINKOMMEN oft für unbekannte Werte (da sich Unbekannt nicht im numerischen Datentyp abspeichern lässt). Eine mögliche Ursache für die Häufung von Werten innerhalb des Wertebereichs ist, dass das System den Datenerfasser zwingt, einen Wert einzutragen, den er nicht kennt. Oft tragen Datenerfasser in einem solchen Fall Standardwerte ein, wie z.B. das eigene Geburtsdatum, was zu einer Häufung dieser speziellen Werte führt. Da es sich um zulässige Werte im erlaubten Wertebereich handelt, finden die üblichen Validierungsfunktionen diese nicht.

Abb. 9–6

Häufigkeitsverteilung Anzahl Kinder bei einer Wertebereichsanalyse

Zusätzlich zeigen Wertebereichsanalysen für Datumsattribute, ob die benötigte Historie für die Auswertung im DWH vorhanden ist. Ist das minimale Datum zu groß, müssen historische Daten nachgeladen werden; ist das maximale Datum zu klein, so fehlen noch die aktuellen Daten. Die Verteilung zeigt auch Lücken in der Historie.

9.4 Data-Profiling-Verfahren zur Analyse von Attributen

143

Musteranalyse

Die Musteranalyse sucht nach Mustern (Patterns) in den Attributwerten und wird hauptsächlich bei Attributen mit standardisierten Werten angewendet. Sie zeigt die häufigsten Zeichenmuster einschließlich ihrer statistischen Verteilungen. Wegen der damit verknüpften erhöhten Eindeutigkeit sind standardisierte Attribute weit verbreitet, z.B. die Renten­ und Krankenversicherungsnummer, die Bankleitzahl oder der EAN­Code zur Artikelkennzeichnung. Aufgrund der Standardisierung können diese Werte leicht auf Korrektheit überprüft, maschinell verarbeitet und Duplikate leicht erkannt werden. Dies ist besonders wichtig, wenn Daten aus verschiedenen Bereichen oder Ländern miteinander verknüpft werden sollen. Beispiele sind internationale Telefonnummern (siehe Tab. 9–2) oder Warennummern.

Tab. 9–2

Telefonnummer

Standardisierte Telefonnummer

(02345) 5678

+49 2345 5678

02345/5678

+49 2345 5678

02345/5678

+49 2345 5678

+4923455678

+49 2345 5678

0049 (0)2345 5678

+49 2345 5678

Standardisierung von Telefonnummern

Die mithilfe eines Werkzeugs identifizierten Muster werden in der Regel über reguläre Ausdrücke dargestellt. In dem Beispiel zur Musteranalyse des Attributs GEBDAT (siehe Abb. 9–7) ist zu sehen, dass 97,1 Prozent der Werte dem Muster ^(9{2}.9{2}.9{2})$ (= Datum im Format DD.MM.YY, z.B. »25.09.66«) entsprechen. Die abweichenden Werte haben alle das Datumsformat DD­MMM­YY (siehe Abb. 9–7, »Bereich für die Datenaufgliederung«, »Eindeutige Werte«). Diese Informationen muss man bei der Konvertierung in ein Datumsformat beachten, da ansonsten Abbrüche bei den Ladeprozessen auftreten oder Daten falsch konvertiert werden.

144

9 Data Profiling

Abb. 9–7

Ergebnis einer Musteranalyse (Beispiel)

Ein anderes Anwendungsbeispiel für die Musteranalyse ist die Suche nach versteckten Zeichen. Verstecken sich in den Werten Leerzeichen am Anfang oder Ende, so sind diese in der Anzeige kaum zu entdecken. Gleiches gilt für Werte aus Leerzeichen, die in der Anzeige wie NULL­Werte aussehen. Solche versteckten Zeichen führen bei Auswertungen häufig zu Fehlern, da sie bei Abfragen unbemerkt nicht berücksichtigt werden. Die Musteranalyse identifiziert solche Fälle zielsicher und macht sie sichtbar, sodass diese Werte anschließend korrigiert werden können. Domänenanalyse

Die Domänenanalyse identifiziert zulässige Werte innerhalb der Attribute, wobei sie nur mehrfach5 auftretende Werte berücksichtigt. Einfach vorkommende Werte müssen manuell auf Domänenzugehörigkeit geprüft werden. Würde die maschinelle Analyse auch diese Werte anzeigen, wäre der Unterstützungsgrad bei der Suche nach unzulässigen Werten gering. Domänen bestehen im einfachsten Fall aus einer Liste zulässiger Werte, können aber auch komplexer aufgebaut sein. Aus den Ergebnissen können die Business­Analysten wichtige Rückschlüsse auf die Prozesse und die darin enthaltenen Geschäftsregeln ziehen. Ein einfaches Beispiel ist die Domäne GESCHLECHT. Die darin enthaltenen Werte sind beispielsweise MANN, FRAU und UNBEKANNT. Mithilfe dieser Domäne können Regeln abgeleitet und die erlaubten Werte eingeschränkt werden. Das erleichtert die Aggregation und erhöht die Korrektheit der Daten, da 5.

In den meisten Systemen ist der Wert »2« als Voreinstellung definiert.

9.4 Data-Profiling-Verfahren zur Analyse von Attributen

145

unzulässige Werte (z.B. KIND) oder andere Domänen (z.B. 1, 2, 3 für Frau, Mann, Unbekannt) abgewiesen werden. Überdies identifiziert diese Analyse auch Fehler, die durch die Zusammenlegung unterschiedlicher Domänen aus verschiedenen Quellsystemen in ein Attribut passieren können. So findet man häufig Attribute mit sich überschneidenden Domänenwerten, wie z.B. in einer BERUFSGRUPPE die gleichbedeutenden Werte A, B, C, D, E und 1, 2, 3, 4, 5. Die Domäne A, B, C, D, E entstammt ursprünglich dem Quellsystem A, die Domäne 1, 2, 3, 4, 5 hingegen dem Quellsystem B. In solchen Fällen wird eine gemeinsame Domäne gebildet und die abweichenden Werte darauf abgebildet (1 = A, 2 = B, 3 = C, 4 = D, 5 = E). Ein Beispiel für eine komplexer aufgebaute Domäne ist die Domäne DATUM. In ihr könnte man festlegen, dass sie aus einem Datum im Format »dd.mm.yyyy« (mit dd als zweistellige Tagesangabe des Monats, mm als zweistellige Monatsangabe des Jahres und yyyy als vierstellige Jahreszahl) besteht. Fügt man hinzu, dass nur Datumswerte ab dem 01.01.1800 zulässig sind, besteht diese Domäne nicht aus einer Liste diskreter Werte, sondern aus einer Format­ und Wertebereichsdefinition. Noch schwieriger wird es, wenn ein Unternehmen weltweit operiert und internationale Daten besitzt, da sich die Datumsformate in unterschiedlichen Ländern sehr stark unterscheiden. So wird in den USA im Datumsformat zuerst der Monat, dann der Tag und anschließend das Jahr angegeben. Außerdem wird noch ein anderes Trennzeichen (»/«) verwendet. Damit nicht genug: Noch komplexer wird es, wenn unterschiedliche Anforderungen in verschiedenen Abteilungen eines Unternehmens existieren. Der Wertebereich ab dem 01.01.1800 reicht der Vertriebsabteilung, um das Geburtsdatum eines Kunden einzugeben. Das Errichtungsdatum eines Gebäudes lässt sich aber vielleicht nicht mehr erfassen. Das Beispiel zeigt, wie eng die Domänen­ und Musteranalyse zusammengehören. Wer Domänenwildwuchs vermeidet, leistet einen wichtigen Beitrag zur Standardisierung und hilft fehlerhafte Werte zu vermeiden. Erst wenn Unternehmen Domänen zentral festlegen und verwalten, dokumentieren und pflegen, zeigen sie ihre volle Leistungsfähigkeit. So ist es wenig verständlich und erfordert einen hohen Integrationsaufwand, wenn ein Unternehmen ohne besonderen Grund für ein und dasselbe Objekt verschiedene Domänen in unterschiedlichen Systemen oder Bereichen verwendet. Populär sind für das Attribut GESCHLECHT folgende Werte: ■ ■ ■ ■ ■ ■

MANN, FRAU, UNBEKANNT MANN, FRAU MÄNNLICH, WEIBLICH 0, 1, 2, 3 M, F, 0 …

146

9 Data Profiling

Besonders unübersichtlich wird es, wenn in einem System 1 = MANN und 2 = FRAU bedeutet, in dem anderen hingegen 1 = FRAU und 2 = MANN. Hier schafft nur eine gemeinsame Domäne mit eindeutig verständlichen Werten Abhilfe und verhindert Fehler. Selbstredend ist auch zentral zu kontrollieren, dass die zentral festgelegten Domänen in den Projekten tatsächlich benutzt werden. In dem Beispiel aus Abbildung 9–8 liefert die Domänenanalyse folgende Auffälligkeiten: Für das Attribut BERUFSGRUPPEN_NR enthält die Domäne sowohl Buchstaben­ als auch Zahlenwerte. Das lässt auf eine Zusammenlegung aus unterschiedlichen Quellen schließen, deshalb sind Überschneidungen naheliegend. Die Domäne für das Attribut BILDUNG erscheint auf den ersten Blick sinnvoll, eine genaue Prüfung ergibt jedoch u.a. Folgendes: Es sind nicht alle möglichen Abschlüsse enthalten, und die Werte »Grundschule« und »Studium« sind keine Abschlüsse. Gleiches gilt für das Attribut BILDUNGS_NR. Beim Attribut BRANCHE enthält die Domäne Synonyme wie die Werte »Telco« und »Telekommunikation«, weshalb die Domäne entsprechend bereinigt werden sollte. Schaut man sich die nicht zur Domäne passenden Werte an, findet man mögliche Kandidaten für eine Erweiterung der Domäne (z.B. Staat, Bund, Keine), aber auch offensichtlich fehlerhafte Werte (z.B. 0).

Abb. 9–8

Ergebnis einer Domänenanalyse (Beispiel)

Anmerkung: In diesem Beispiel hat das Werkzeug die Werte Staat, Bund, Keine und 0 nicht in die Domäne integriert, weil deren Häufigkeit nicht den konfigurierten Mindestwert erreichte.

9.4 Data-Profiling-Verfahren zur Analyse von Attributen

147

Eindeutigkeitsanalyse

Die Eindeutigkeitsanalyse bestimmt für die Attribute den Grad der Eindeutigkeit der enthaltenen Werte. Nur eindeutige Attribute können als Schlüsselattribute verwendet werden und unterschiedliche Tabellen verknüpfen. Normalerweise garantieren relationale Datenbanksysteme und normalisierte Datenmodelle diese Eindeutigkeit. Trotzdem existieren in der Praxis Probleme mit nicht eindeutigen Datensätzen; betroffen sind insbesondere die BI­Anwendungen. Die Gründe sind vielschichtig: Im DWH werden Daten aus verschiedenen Quellsystemen integriert, wobei dort jeweils eindeutige Schlüssel nach einer eigenen Systematik existieren. Durch die Integration treffen diese unterschiedlichen Schlüsselsysteme zusammen, sodass die Eindeutigkeit über den Gesamtbestand verloren gehen kann. Bei der Integration aus verschiedenen Quellen können Duplikate aufgrund eines fehlenden eindeutigen Schlüssels nicht identifiziert werden. Der Versuch, diese Duplikate aufgrund der Werte aus den Nicht­Schlüsselattributen zu identifizieren, ist schwierig, da die Quellen unterschiedliche Attribute mit unterschiedlichen Domänen für die einzelnen Objekte verwenden. Auch in Quellsystemen gibt es häufig Probleme mit nicht eindeutigen Datensätzen. Diese treten z.B. dann auf, wenn die Schlüssel nicht unabhängig definiert wurden. Häufig bestehen diese Schlüssel aus zusammengesetzten Teilen, beispielsweise wenn die Artikelnummer auch die übergeordnete Artikelgruppe enthält. Ändert sich für die Artikel die zugehörige Artikelgruppe, so ändert sich damit auch die Artikelnummer. Gibt es für diesen Fall kein passendes Historisierungskonzept, so existieren nach der Umgruppierung zwei verschiedene Artikelnummern für den gleichen Artikel, woraus Fehler z.B. bei Bestellungen und im DWH bei der Aggregation und Auswertung entstehen. Die bei der Eindeutigkeitsanalyse gefundenen Problemfälle mit nicht eindeutigen Schlüsselattributen lassen sich in vier Gruppen einteilen: 1. Das Schlüsselattribut ist nicht gefüllt (= NULL). 2. Die Datensätze mit identischem Schlüssel sind hundertprozentig identisch, d.h., alle Attributwerte stimmen überein. 3. Die Datensätze mit identischem Schlüssel sind nicht hundertprozentig identisch, gehören aber trotzdem zum selben Objekt. 4. Die Datensätze besitzen nur einen identischen Schlüssel, d.h., die anderen Attributwerte unterscheiden sich voneinander und gehören nicht zum gleichen Objekt. Der Business­Analyst teilt die Datensätze mit nicht eindeutigem Schlüsselattribut in diese vier Gruppen ein. Da hierfür fachliche Kenntnisse notwendig sind, ist dieser Schritt schlecht automatisierbar. Um die Datenfehler zu beheben, gibt es für jede Gruppe ein angepasstes Verfahren: Bei den Datensätzen der Gruppe 1 werden neue Schlüssel vergeben, bei der Gruppe 2 werden die überzähligen Datensätze gelöscht, bei der Gruppe 3

148

9 Data Profiling

werden die Datensätze zu einem zusammengefasst und bei der Gruppe 4 neue Schlüssel vergeben. Aus Gründen der Nachvollziehbarkeit ist es besser, wenn man die überzähligen Datensätze nicht physikalisch löscht, sondern entsprechend markiert (sodass sie nicht weiterverwendet werden) und eine Referenz auf den gültigen Datensatz hinzufügt. Ansonsten ist z.B. der Nachweis schwierig, wo ein gesuchter eingeladener Datensatz in der weiteren Datenverarbeitung abgeblieben ist. Man sollte eine Regel zwingend beachten: Es ist sicherzustellen, dass Benutzer diese markierten Datensätze grundsätzlich nicht auswerten können (z.B. bei der Ad­hoc­Analyse). Zusätzlich muss der durch dieses Verfahren erhöhte Bedarf an Speicherplatz eingeplant werden. In dem Beispiel in Abbildung 9–9 liegt die Eindeutigkeit für das Attribut KUNDEN_ID nur bei 99,8 Prozent, obwohl dieses dem Namen nach ein eindeutiges Schlüsselattribut sein sollte. Bei der weiteren Analyse der zugehörigen, nicht eindeutigen Datensätze entdeckt man drei Datensätze, bei denen das Attribut nicht gefüllt ist (= Gruppe 1), und weitere drei Datensätze mit gleicher KUNDEN_ID (= Gruppe 2, 3 oder 4). Untersucht man diese vier Fälle genauer, so erkennt man drei vollständige Duplikate für den Kunden »Meiser« (= Gruppe 2) und einen Datensatz mit gleicher KUNDEN_ID, der aber zum Kunden »Peter« gehört (= Gruppe 4).

Abb. 9–9

Ergebnisse der Eindeutigkeitsanalyse (Beispiel)

Um diese Fehler zu bereinigen, erhalten die drei Datensätze der Gruppe 1 sowie der eine Datensatz der Gruppe 4 jeweils eine neue KUNDEN_ID. Die zwei überzähligen Datensätze der Gruppe 2 werden gelöscht, da es sich um komplett identische Datensätze handelt. Anschließend sichert man die Eindeutigkeit dieses Attributs über einen Datenbankmechanismus (Unique Constraint) für neu geladene Daten ab.

9.4 Data-Profiling-Verfahren zur Analyse von Attributen

149

NULL-Werte-Analyse

Die NULL­Werte­Analyse bestimmt für die Attribute, wie viele Werte (NULLWerte) fehlen. Oft stören gerade NULL­Werte einige der anderen Analysetypen (siehe Eindeutigkeitsanalyse). NULL­Werte haben verschiedene Ursachen: Bei der Dateneingabe war kein Wert vorhanden, das Attribut wird ab einem Zeitpunkt nicht mehr gefüllt und verwendet, das Attribut ist neu und für historische Datensätze wurden NULL­Werte eingetragen, der Wert wird erst in einem nachfolgenden Datenverarbeitungsprozessschritt gefüllt oder das Attribut ist für den Datensatz irrelevant. Bei vielen NULL­Werten in einem Attribut ist zu prüfen, ob das Attribut überhaupt benötigt wird, da die wenigen vorhandenen Werte auf das Gegenteil schließen lassen. Wird das Attribut benötigt, ist weiterhin zu prüfen, ob und wie diese NULL­Werte verhindert, weiterverarbeitet oder durch reale Werte ersetzt werden können. Grundsätzlich gilt, dass fehlende Werte nicht nur durch NULL­Werte identifiziert werden. Je nach Datentyp des Attributs kursieren in der Praxis die unterschiedlichsten Ersatzwerte: So wird bei numerischen Datentypen gerne die 0 verwendet, bei Zeichenketten das Leerzeichen. Diese Ersatzzeichen verschleiern die Ursache und erschweren die Auswertung dieser Datensätze. Eine 0 im Attribut ANZAHL KINDER kann heißen, dass die Person keine Kinder hat oder die Angabe schlicht und einfach fehlt. Für eine Auswertung ist es jedoch essenziell, welcher der beiden Fälle vorliegt. Um solche versteckten NULL­Werte zu finden, wird die Wertebereichs­ und die Musteranalyse eingesetzt. Zeigen sich Häufungen bei fachlich nicht sinnvollen Werten oder finden sich Muster mit Leerzeichen, so lässt das auf solche Fälle schließen.

Abb. 9–10

Ergebnisse einer NULL-Werte-Analyse (Beispiel)

150

9 Data Profiling

In dem Beispiel in Abbildung 9–10 ist das Attribut KUNDENART zu 99,4 Prozent mit NULL­Werten gefüllt, lediglich drei Sätze enthalten den Wert 8 und weitere drei Sätze den Wert 5. Deshalb ist zu prüfen, ob das Attribut überhaupt fachlich verwendet wird.

9.4.2

Analyse der Attribute mit Geschäftsregeln

In diesem Verfahren wird auf das fachliche Expertenwissen in Form von vordefinierten Geschäftsregeln zurückgegriffen. Gemeinsam mit den Experten werden diese Regeln validiert. Anschließend wird anhand der vorhandenen Daten geprüft, ob diese Regeln eingehalten werden. Dabei beziehen sich die hier beschriebenen Geschäftsregeln genau auf ein Attribut. Die komplexeren Geschäftsregeln auf Datensatz­ und Tabellenebene werden später in den zugehörigen Abschnitten dargestellt. Ausgangspunkt zur Ermittlung solcher Geschäftsregeln können die zugehörigen Metadateninformationen liefern, z.B. die vorhandenen Datenmodelle, Data Dictionaries, COBOL­Copybooks oder Look­up­Tabellen. Bei diesen Metadaten sollte man aber Vorsicht walten lassen, da sie in der Praxis sehr häufig unvollständig, veraltet oder unkorrekt sind. Die Geschäftsregeln auf Attributebene lassen sich in neun Gruppen einteilen, die nachfolgend genauer beschrieben werden. Regeln zu Domänen

Die Regeln zu Domänen definieren die zulässigen, diskreten Werte für ein Attribut. Entweder werden diese zulässigen Werte über eine Domänenanalyse bestimmt oder eigenständig erstellt. Auch eine Kombination beider Ansätze ist möglich: Dabei wird die bei der Domänenanalyse gefundene Werteliste entweder um zulässige, aber noch nicht vorhandene Werte ergänzt oder andere gefundene, aber nicht zulässige Werte werden daraus entfernt. Welcher dieser Ansätze gewählt wird, hängt stark vom Kontext ab und wie gut diese fachlichen Wertelisten definiert sind. Einfache Wertelisten (wie z.B. für das Attribut GESCHLECHT) lassen sich sehr gut vorab definieren und überprüfen, komplexere (wie z.B. für das Attribut BESTELLSTATUS) lässt man sich besser über eine Domänenanalyse aus den Daten extrahieren. Egal für welchen Ansatz man sich schlussendlich entscheidet – die Wertelisten müssen immer anhand der Daten überprüft werden! Denn in der Praxis kommt es sehr häufig vor, dass neben den dokumentierten Werten auch andere gefunden werden. Zwei Ursachen sind zu nennen: Erstens wurden im Laufe der Zeit weitere zulässige Werte definiert, aber die Dokumentation nicht entsprechend aktualisiert. Zweitens kommt es vor, dass bei der Eingabe keine Validierung erfolgte, sodass unzulässige Werte gespeichert wurden. Im ersten Fall ist die Domäne um die weiteren zulässigen Werte zu ergänzen, im zweiten sind die unzulässigen Werte auf zulässige abzubilden und zu ersetzen. In beiden

9.4 Data-Profiling-Verfahren zur Analyse von Attributen

151

Fällen ist das Data Profiling anschließend mit den geänderten Regeln zu den Domänen zu wiederholen. Ein Beispiel für einen kombinierten Ansatz ist in Abbildung 9–11 zu sehen. Die Domänenanalyse der Kundentabelle ergab eine Domäne für das Attribut BUNDESLAND. Alle Werte entsprechen dieser Domäne (hundertprozentig kompatibel). Auf den zweiten Blick erkennt man aber, dass die Domäne unvollständig ist und nur elf der insgesamt 16 Bundesländer enthält. Ein möglicher Grund hierfür ist, dass das Unternehmen noch keine Kunden in den fehlenden fünf Bundesländern besitzt. Da es aber höchstwahrscheinlich auch Kunden aus diesen fehlenden Bundesländern geben wird, wäre es fatal, die Domäne nach dem heutigen Stand mit nur elf Bundesländern zu bilden. Deshalb wird die Domäne erweitert auf die 16 Bundesländer Baden-Württemberg, Bayern, Berlin, Brandenburg, Bremen, Hamburg, Hessen, Mecklenburg-Vorpommern, Niedersachsen, Nordrhein-Westfalen, Rheinland-Pfalz, Saarland, Sachsen, Sachsen-Anhalt, Schleswig-Holstein und Thüringen. Die Kompatibilität bleibt hundertprozentig, da alle gefundenen Werte weiterhin Bestandteil dieser neuen, erweiterten Domäne sind. Für fünf Werte der Domäne werden aktuell nur keine entsprechenden Datensätze gefunden. Diskrete Wertelisten bestehen in der Regel aus realen Wörtern. Die Namen der Bundesländer aus Abbildung 9–11 könnten aber auch aus Kennzeichen oder ­ziffern bestehen.

Abb. 9–11

Beispiel zur Erweiterung von Domänenanalyse-Ergebnissen

152

9 Data Profiling

Ein Beispiel für Kennzeichen ist das Attribut NATIONALITÄT in einer Kundentabelle. Statt der ausgeschriebenen Bezeichnung der Länder sind die zugehörigen Nationalitätskennzeichen (z.B. D für Deutschland) enthalten. Selbstredend ist es hilfreich, wenn als Kennzeichen bekannte Standards (wie z.B. das Kfz­Nationalitätskennzeichen oder der ISO­Ländercode) verwendet werden, da ansonsten die Bedeutung des Kennzeichens für die Benutzer nicht auf den ersten Blick verständlich ist. Für die Verwendung von Kennzeichen und ­ziffern sprechen der damit verbundene niedrigere Speicherplatzbedarf, eine Standardisierung von Textfeldern oder eine schnellere, eindeutigere Abfragemöglichkeit. Reine Textfelder sind aus ihrer Natur heraus sehr anfällig für Schreibfehler, sodass sich leicht und unbemerkt Duplikate bilden. Insbesondere schwierig zu schreibende Begriffe erhöhen die Fehlerquote: So können bei dem Bundesland Nordrhein-Westfalen schon kleine Abwandlungen in der Schreibweise (Nordrhein-Westphalen, NordrheinWestfahlen, ...) zu Fehlern führen, die bei dem Kennzeichen NRW nicht so häufig auftreten. Gleiches gilt für Abfragen: Eine Auswertung aller Kunden aus Nordrhein-Westfalen findet die Datensätze mit Nordrhein-Westphalen und NordrheinWestfahlen nicht. Allerdings sind Kennzeichen schwieriger zu verstehen, so ist Brandenburg für die meisten Benutzer verständlicher als das Kennzeichen BRB. Regeln zu Wertebereichen

Diese Regeln definieren die zulässigen Wertebereiche für ein Attribut. Wie die Regeln zu Wertelisten werden sie entweder über eine Wertebereichsanalyse bestimmt oder eigenständig erstellt. Natürlich lassen sich beide Ansätze auch kombinieren. Ausgangspunkt ist in der Regel eine Wertebereichsanalyse, da es sehr viel einfacher ist, aus den Ergebnissen die Regeln für valide Bereiche zu entwickeln, als diese »auf der grünen Wiese« neu zu erstellen. Anschließend werden die bei der Analyse gefundenen Wertebereiche um zulässige, bis jetzt aber noch nicht vorhandene Bereiche ergänzt. Andere gefundene oder nicht zulässige Bereiche werden entfernt. Wertebereiche werden hauptsächlich für Datumswerte festgelegt. Beispielsweise kann eine Regel für das Attribut GEBURTSDATUM lauten: »Das GEBURTSDATUM muss zwischen dem 01.01.1850 und dem aktuellen Datum liegen.« Wer das Beginn­Datum noch dynamischer gestalten will, erstellt folgende Regel: »Das GEBURTSDATUM muss zwischen dem (aktuellen Datum – 150 Jahre) und dem aktuellen Datum liegen.« Damit ist es im Gegensatz zu dem statischen Beginn­Datum auch in 50 Jahren unmöglich, ein Geburtsdatum einzutragen, das mehr als 150 Jahre zurückliegt. Es gibt auch viele rein statische numerische Wertebereiche. So könnte eine Regel für das Attribut MONATSEINKOMMEN lauten: »Das MONATSEINKOMMEN muss größer gleich 0 und kleiner als 9.000.000 sein«, um invalide Jahresgehälter von über 10.000.000 auszuschließen.

9.4 Data-Profiling-Verfahren zur Analyse von Attributen

153

Ein Beispiel für eine nur einen Ausschnitt des Attributwerts betreffende Regel ist ein Artikelkennzeichen, für das folgende Regel definiert ist: »Das ARTIKELKENNZEICHEN muss an der vierten Stelle einen Großbuchstaben aus dem Bereich R bis Z haben.« Regeln zu Werteauschlussbereichen

Eine Sonderform der Regeln zu Wertebereichen sind solche zu Ausschlussbereichen, hierdurch werden einzelne Wertebereiche gezielt ausgeschlossen. Ein Beispiel aus der Praxis ist das Attribut BEARBEITUNGSDATUM, für das Datumswerte an Wochenenden und Feiertagen ausgeschlossen werden: »Der Wochentag des Bearbeitungsdatums darf nicht zwischen Samstag und Sonntag oder auf einem Feiertag liegen.« Diese Regeln findet man aber relativ selten, da sie schwer zu formulieren sind und sensibel auf Änderungen (wenn z.B. in dem Unternehmen Arbeit am Wochenende eingeführt wird) reagieren. Deshalb wird diese Art von Regeln nur dann eingesetzt, wenn hohe Anforderungen an die Korrektheit eines Werts gestellt werden, die den damit verbundenen Aufwand und die Unflexibilität rechtfertigen. Regeln zur Genauigkeit

In der Praxis gibt es keine Regeln zu Datentypen, da es sich hierbei um eine rein technische Eigenschaft der Attribute handelt. Häufig existieren aber fachliche Regeln zur Genauigkeit, die zum Datentyp gehört. Wie bei den anderen Regeln können diese durch eine Datentypanalyse identifiziert, selbst entworfen oder über eine Kombination dieser beiden Ansätze definiert werden. Wert

% Zeilen

0,50

13

06,95%

0,83

02

01,07 %

1,00

32

17,11%

1,25

04

02,14%

1,49

01

00,53%

1,50

23

12,30 %

2,00

45

24,06%

3,00

65

34,76%

3,33

Tab. 9–3

# Zeilen

02

01,07%

Gesamt:

187 Zeilen

Ergebnis einer Genauigkeitsanalyse für das Attribut STUNDEN (Beispiel)

154

9 Data Profiling

Ein Beispiel für diese Regel ist das Attribut STUNDEN in der Tabelle ABRECHNUNGEN, in das die aufgewendeten Stunden in einem Projekt gebucht werden. Eine Geschäftsregel besagt, dass nur auf volle 15 Minuten gebucht werden darf; die Granularität der Werte beträgt damit 0,25. In dem Beispiel aus Tabelle 9–3 lässt sich erkennen, dass drei Werte (0,83; 1,49; 3,33) die geforderte Genauigkeit von 0,25 verletzen. Es wurde hier nicht auf die volle Viertelstunde gebucht. Regeln zu Mustern

Müssen die Werte eines Attributs einem bestimmten Muster entsprechen, sind auch Regeln zu diesen Mustern zu definieren. Ein Beispiel für ein solches Attribut ist die Rentenversicherungsnummer, in der die ersten acht Stellen numerisch, die neunte Stelle ein Großbuchstabe und die restlichen drei Stellen wieder numerisch sein müssen (z.B. »65170839J008«). Wie immer werden diese Regeln entweder aus den Ergebnissen einer Musteranalyse abgeleitet, eigenständig definiert oder aus einer Kombination beider Ansätze gebildet. In der Praxis hat sich die Ableitung aus einer Musteranalyse bewährt, da diese Muster meistens nicht dokumentiert sind und deshalb aus den Daten extrahiert werden müssen. Durch ein Profiling der vorhandenen Daten mithilfe dieser Regeln können invalide Datensätze sehr schnell und einfach identifiziert, Ansätze für eine Bereinigung gefunden und invalide Datensätze bereinigt werden. Beispiel: »Die Werte für die deutsche Rentenversicherungsnummer im Attribut RENTENVERSICHERUNGSNR müssen dem Muster 9{8}[A­Z]9{3}6 entsprechen.« Regeln zu Textattributen

Für Textattribute können ebenfalls Regeln festgelegt werden, obwohl das in der Praxis schwierig ist und nicht oft genutzt wird. Zu beachten ist, dass sich diese Regeln auf »wirkliche« Textattribute beziehen. Oft werden Textattribute zur Speicherung anderer Datentypen verwendet, dort sind aber die für den eigentlichen Datentyp geltenden Regeln anzuwenden. Der Inhalt von Textattributen kann mit ansteigender Komplexität in folgende Gruppen eingeteilt werden: 1. Das Textattribut enthält ein einzelnes Wort. 2. Mehrere Wörter werden jeweils durch Leerzeichen getrennt. 3. Wertpaare existieren als Kombination von Schlüsselwort und zugehörigem Wert. 4. Alle Bestandteile sind ohne Einschränkungen kombiniert. 6.

8}[A-Z]9{3}: acht Zahlen (9{8}), gefolgt von einem Großbuchstaben ([A-Z]) und drei Zahlen (9{3})

9.4 Data-Profiling-Verfahren zur Analyse von Attributen

155

Attribute der Gruppe 1 mit einzelnen Wörtern findet man häufig als Ersatz für Domänen (Wertelisten), z.B. wenn die Anzahl der Werte für eine Auswahlliste zu groß ist oder die Werte vorab nicht abschließend definiert werden können. Ein Beispiel ist das Attribut ARTIKELNAME: In einem Unternehmen gibt es so viele unterschiedliche Artikel, dass die Anzahl für eine Werteliste üblicherweise zu groß ist. Außerdem kommen immer neue Artikel hinzu, sodass eine Werteliste ständig erweitert werden müsste und bis dahin der Artikel nicht in den Geschäftsprozessen zur Verfügung stehen würde. In der Regel bestehen die einzelnen Wörter in diesen Attributen aus alphanumerischen Zeichen und enthalten keine Sonder­ oder Leerzeichen. Dieser Umstand kann über Regeln validiert, unkorrekte Werte können darüber identifiziert werden. Textattribute der Gruppe 2 mit mehreren Wörtern enthalten im Gegensatz zur Gruppe 1 wenige, klar definierte Sonderzeichen: Leerzeichen, Komma oder Semikolon werden zur Trennung der Wörter eingesetzt; andere Sonderzeichen wie z.B. @ sind hingegen nicht erlaubt. Werte mit nicht erlaubten Sonderzeichen können über entsprechende Regeln identifiziert und anschließend bereinigt werden. Über Regeln zu den erlaubten Schlüsselwerten können Textattribute der Gruppe 3 validiert werden. In der Praxis findet man diese Fälle, wenn versucht wurde, möglichst viel Information in möglichst wenig Speicherplatz unterzubringen. Häufig sind in dem Attribut KONFIGURATION viele einzelne Konfigurationsparameter gespeichert: »PARALLEL = 5; BULK_SIZE = 5000; COMMIT_ RATE = 10.000« … Solche Textattribute lassen auf ein schlechtes Design schließen, da die einzelnen Parameter besser separat gespeichert werden sollten. Trotzdem findet man auch heute noch solche Fälle, insbesondere in Legacy­Systemen. Für Textattribute der Gruppe 4 können in den allermeisten Fällen keinerlei Regeln festgelegt werden. Diese Attribute können alles enthalten, auch Sonderzeichen wie @ und Ausgabeformatzeichen wie »CR-LF« (»Carriage Return – Line Feed«). Beispiel für ein solches Attribut ist die DIAGNOSE eines Arztes, die aus dem entsprechenden Formular einschließlich Formatierung in ein Textfeld gespeichert wurde. Insbesondere bei Attributen der Gruppe 4, aber auch bei den anderen Gruppen muss man bei der Überprüfung der Regeln zwingend auf den verwendeten Zeichensatz achten. Je nach Zeichensatz unterscheiden sich die Codes für die Zeichen, sodass bei Nichtbeachtung die gesuchten Zeichen nicht erkannt werden. Schlimmstenfalls bricht sogar die gesamte Verarbeitung ab, falls ein Zeichen falsch interpretiert wird. In einem Projekt wurde z.B. ein in einer Textdatei enthaltenes Sonderzeichen als Dateiende­Zeichen fehlinterpretiert, sodass nur ein Teil der Datensätze validiert und geladen wurde. Um dieses Problem grundsätzlich zu lösen, sollte der internationale Standard »Unicode« verwendet werden. Dieser hat das Ziel, alle gebräuchlichen Schriftsysteme und Zeichen einheitlich zu codieren.

156

9 Data Profiling

Die Regeln können wie so oft entweder manuell vorab festgelegt, aus einer Domänen­ oder Musteranalyse extrahiert oder aus einer Kombination beider Ansätze entwickelt werden. Für Attribute der Gruppe 1 empfiehlt sich aus der Praxis der Weg über eine Domänenanalyse, bei Gruppe 2 und 3 der über eine Musteranalyse. Sollen Regeln zur Gruppe 4 aufgestellt werden, so liegt es nahe, diese manuell festzulegen, da diese Regeln meistens nicht durch ein Data Profiling identifiziert werden können. Regeln zu fehlenden Werten

Diese Regeln legen fest, ob für ein bestimmtes Attribut NULL­Werte erlaubt sind oder nicht. Ob ein Attribut zwingend gefüllt oder optional ist, wird sehr häufig durch die Geschäftsprozesse festgelegt. Beispiel: Beim Geschäftsprozess »Einstellung eines Mitarbeiters« ist das Attribut EINSTELLUNGSDATUM zwingend zu füllen, ein NULL­Wert ist dort nicht erlaubt. Der Grund ist, dass die nachfolgenden Geschäftsprozesse (z.B. für die Beschaffung eines Arbeitsplatzes oder die Einrichtung von Benutzerkonten) zwingend ein Einstellungsdatum brauchen. Andernfalls wäre nicht klar definiert, bis zu welchem Termin diese nachfolgenden Geschäftsprozesse abzuschließen sind. Wie bei den anderen Regeln werden auch hier bei der Festlegung entweder die Ergebnisse einer NULL­Werte­Analyse verwendet, die Regeln vorab durch fachliche Experten festgelegt oder es wird ein kombinierter Ansatz aus beidem gewählt. Haben fachliche Experten die Regeln zu NULL­Werten vorab festgelegt, so sind diese anschließend zwingend anhand der Daten zu validieren. In der Praxis zeigt sich häufig, dass sich in den Daten dann trotzdem NULL­Werte befinden. Zwei Ursachen sind möglich: Entweder kann in einem Geschäftsprozess zum Zeitpunkt der Speicherung noch kein Wert für das Attribut angegeben werden (Fall 1), oder für das spezielle, durch den Datensatz bestimmte Objekt lässt sich das Attribut nicht sinnvoll füllen (Fall 2). Im ersten Fall könnte das Attribut erst durch nachfolgende Geschäftsprozesse gefüllt werden. Ein Beispiel ist das Attribut LIEFERDATUM in der Tabelle BESTELLUNGEN. Zum Zeitpunkt der Bestellung ist das Lieferdatum natürlich leer, da noch nicht geliefert wurde. Erst im nachfolgenden Geschäftsprozess LIEFERUNG wird dieses mit dem zugehörigen Datum gefüllt. Ein Beispiel für den zweiten Fall ist die Tabelle KUNDEN, in der Firmen und Privatpersonen gespeichert werden. Für Privatpersonen kann ein sinnvoller Wert für das Attribut GESCHLECHT eingetragen werden, bei Firmen hingegen nicht. Bei Firmen enthält das Attribut GESCHLECHT deshalb richtigerweise den Wert NULL. Um trotzdem eine Regel festzulegen, müsste alternativ die Tabelle aufgesplittet und die Datensätze müssten nach Privatpersonen und Firmen aufgeteilt

9.4 Data-Profiling-Verfahren zur Analyse von Attributen

157

werden. Anschließend können dann NULL­Werte für das Attribut GESCHLECHT in der neuen Tabelle PRIVATKUNDEN ausgeschlossen werden – natürlich nur, sofern diese Information zwingend erforderlich und immer vorhanden ist. In Abbildung 9–12 ist ein Beispiel für die technische Realisierung einer Regel zu fehlenden Werten zu sehen, mit der keine NULL­Werte (Typ) für das Attribut GESCHLECHT zugelassen sind. Diese Regel wurde für eine bessere generelle Verwendbarkeit nur logisch definiert und dann im rechten Teil unter »Binding« mit dem physikalischen Attribut GESCHLECHT verknüpft. Somit kann die eine logische Regel ohne Redundanz mehrfach in unterschiedlichen Datenobjekten angewendet werden, wodurch z.B. die Wartbarkeit und die Übersichtlichkeit stark steigt.

Abb. 9–12

Regel zu fehlenden Werten (Beispiel)

Multiple Regeln

In den meisten Fällen wird für Attribute ein Satz von verschiedenen Regeln angewendet, z.B. aus der Muster­ und der Domänenanalyse. Diese Regeln werden bei der Validierung über eine UND­Verknüpfung miteinander verbunden. Beispiel: »Die Personenkennziffer eines Soldaten hat immer die Länge von 12, besteht aus alphanumerischen Zeichen, die ersten sechs Zeichen bestehen aus Ziffern und stellen das Geburtsdatum im Format ›ddmmyy‹ (Tag, Monat, Jahr) dar.« In manchen Fällen gibt es aber multiple Regeln, die nicht über ein UND, sondern über ein ODER miteinander verknüpft sind. Ein Beispiel dazu ist das Attribut POSTLEITZAHL: Für dieses Attribut existieren multiple Regeln zu Mustern für die unterschiedlichen Länder. In Deutschland besteht eine Postleitzahl aus genau fünf Ziffern, in den Niederlanden hingegen aus vier Ziffern und zwei Buchstaben. Die Regel zu Mustern für Postleitzahlen aus Deutschland und den Niederlanden muss eine ODER­Verknüpfung für die Validierung verwenden: »Eine Postleitzahl besteht aus fünf Ziffern oder aus vier Ziffern gefolgt von zwei Buchstaben.« Eigene Regeln

Neben den Regeln zu diesen vordefinierten Regeltypen können auch eigene, nicht in diese Gruppen passende Regeln definiert werden. In der Praxis hat es sich bewährt, diese Regeln modular aufzubauen. Kleinere, atomare Regeln können somit individuell zusammengestellt werden, womit die Verwend­ und Änderbarkeit erheblich gesteigert wird.

158

9.5

9 Data Profiling

Data-Profiling-Verfahren zur Analyse von Datensätzen

Im Gegensatz zur Analyse von Attributen werden auf dieser Ebene alle Datensätze einer Tabelle analysiert, um funktionale Abhängigkeiten zu identifizieren. Bei der Analyse funktionaler Abhängigkeiten sucht man nach Abhängigkeiten zwischen den Attributen eines Datensatzes. Das Ziel ist es, die Existenz von Beziehungen und Korrelationen zwischen den Werten zu entdecken. Dabei unterscheidet man zwischen uni­ und bidirektionalen Zusammenhängen. Bei unidirektionalen Zusammenhängen kann von dem Wert eines Attributs (oder einer Gruppe) auf den Wert eines anderen Attributs geschlossen werden, aber nicht wie bei bidirektionalen auch zurück. Ein Beispiel für eine unidirektionale Abhängigkeit ist der Artikel und die Artikelgruppe. Ein Artikel ist genau einer Artikelgruppe zugeordnet (z.B. »Waschmaschine Ökostar PLUS 1401« gehört zur Gruppe »Haushaltsgroßgeräte«). Da zu einer Artikelgruppe aber mehr als ein Artikel gehört, ist der Weg zurück von der Gruppe auf den Artikel nicht eindeutig zu bestimmen. Ein Beispiel für eine bidirektionale Verbindung ist die Rentenversicherungsnummer und die Person in Deutschland: Eine Rentenversicherungsnummer ist genau einer Person zugeordnet, eine Person darf nur genau eine Rentenversicherungsnummer besitzen. Dadurch kann über die Rentenversicherungsnummer auf die zugehörige Person geschlossen werden und von der Person wieder eindeutig zurück auf die Rentenversicherungsnummer. Für die Analyse bietet sich der Einsatz von Werkzeugen an, da die manuelle Analyse aufgrund der vielen zu untersuchenden Attribute und der dadurch sehr hohen Anzahl möglicher Kombinationen zu schwierig und aufwendig ist. Funktionale Abhängigkeiten können sich in zwei Gruppen (Schlüsselattribute, abgeleitete Attribute) gliedern, deren Analyseverfahren nachfolgend näher beschrieben werden.

9.5.1

Analyse auf Schlüsselattribute

Die Schlüsselattribute identifizieren eindeutig einen Datensatz innerhalb einer Tabelle und besitzen ebenfalls eine funktionale Abhängigkeit zu allen anderen Attributen dieses Satzes. In der Praxis findet man häufig neben den technischen Schlüsselattributen auch alternative, fachliche Schlüssel. Die technischen Schlüssel bestehen in der Mehrzahl aus eindeutigen, künstlich generierten numerischen Werten und beschränken sich auf ein Attribut (z.B. das Attribut KUNDEN_ID in der Tabelle KUNDEN). Die fachlichen Schlüssel bestehen meist aus einer Kombination vorhandener natürlicher Attribute (z.B. NAME, VORNAME, GEBURTSDATUM, ADRESSE). Eindeutig identifizieren diese einen Datensatz und darüber das zugehörige, reale Geschäftsobjekt (z.B. KUNDE, BESTELLUNG). Es gibt aber auch fachliche Schlüssel, die nur aus einem Attribut bestehen. Beispiel hierfür ist wieder die Rentenversicherungsnummer.

9.5 Data-Profiling-Verfahren zur Analyse von Datensätzen

159

Kandidaten für fachliche Schlüssel lassen sich oft über den Attributnamen identifizieren, wobei hierfür aber fachliches Know­how über die in den Tabellen abgelegten Geschäftsobjekte benötigt wird. Attribute mit der Bezeichnung PRODUKT_NAME, KUNDEN_NAME etc. sind aufgrund des Namensbestandteils _NAME typische Kandidaten für einen natürlichen Schlüssel. In den allermeisten Fällen reicht dieses eine Attribut aber nicht für eine fachliche Eindeutigkeit aus, sodass weitere zugehörige Attribute gefunden werden müssen. Beispielsweise reicht der Kundenname bei großen Unternehmen nicht für eine Eindeutigkeit aus, da es in Deutschland viele Personen mit gleichem Namen (z.B. »Peter Müller«) gibt. Deshalb muss in diesem Beispiel der fachliche Schlüssel um das Geburtsdatum und die Adresse erweitert werden. Durch das Geburtsdatum werden z.B. der Vater und der Sohn mit dem gleichen Namen unterschieden, mit der Adresse zwei verschiedene Personen mit gleichem Namen und Geburtsdatum. Nachdem die Kandidaten für die fachlichen Schlüssel identifiziert worden sind, werden diese anhand der Daten überprüft. Am Ende dieses Prozesses bleiben nur die Kandidaten übrig, für die eine hinreichende Eindeutigkeit auch im Datenbestand gefunden wurde. In der Praxis wird die analysierte Eindeutigkeit meistens nicht bei 100 Prozent liegen, da diese durch Duplikate verringert wird. Je nach Ursache lassen sich die gefundenen Duplikate in zwei Arten einteilen: ■ Es handelt sich um das gleiche reale Geschäftsobjekt, das mehrfach in die Tabelle eingetragen wurde. ■ Es handelt sich um verschiedene reale Geschäftsobjekte, die Werte der verwendeten Schlüsselattribute sind aber identisch. Im ersten Fall müssen alle Duplikate gelöscht werden, sodass nur noch ein Datensatz übrig bleibt. Im zweiten Fall muss die Kombination der verwendeten Schlüsselattribute erweitert werden, bis eine hinreichende Eindeutigkeit erzielt wird. In Abbildung 9–13 ist ein Beispiel für den zweiten Fall dargestellt. Es wurden zwei fachliche Schlüsselattribute KUNDENNAME und GEBURTSDATUM in der Tabelle KUNDEN mithilfe der Analyse identifiziert (UK_434), die Eindeutigkeit in der Tabelle ist aber kleiner 100 Prozent. Lässt man sich die nicht eindeutigen Werte für diese Attribute anzeigen, so findet man für KUNDENNAME = »Karl Müller« und das GEBURTSDATUM = »25.09.1966« zwei Datensätze, für die Werte KUNDENNAME = »Tabea Schmidt« und das GEBURTSDATUM = »09.07.1998« drei Datensätze. In der Anzeige aller Attributwerte für den Kunden »Karl Müller« erkennt man, dass diese beiden Datensätze sich in der ADRESSE und dem ORT unterscheiden. Nach der fachlichen Prüfung stellt sich heraus, dass es sich um zwei verschiedene Kunden handelt, nicht um den gleichen mit einer veralteten Anschrift. Aus diesem Grunde muss die Kombination fachlicher Schlüsselattribute für diese Tabelle um die Attribute ADRESSE und ORT erweitert und anschließend die Eindeutigkeit neu gemessen werden.

160

9 Data Profiling

Eindeutiger Schlüssel

Dokumentiert?

Ermittelt?

Lokales Attribut

% Rows

UK_434

Nein

Ja

KUNDENNAME, GEBURTSDATUM

99,5

Nicht eindeutige Datensätze: KUNDENNAME

GEBURTSDATUM

# Rows

% Rows

Karl Müller

25.09.1966

2

0,2%

Tabea Schmidt

09.07.1998

3

0,3%

Nicht eindeutige Datensätze zum Kunden »Karl Müller« und Geburtsdatum: KUNDENNAME

GEB_DATUM

ADRESSE

ORT

Karl Müller

25.09.1966

Im Mühlengarten 3

Mechernich

Karl Müller

25.09.1966

Kommerner Straße 8

Euskirchen

Abb. 9–13

Ergebnis einer Analyse auf Schlüsselattribute (Beispiel)

Technische Schlüssel werden in den Systemen gerne benutzt, um in allen denkbaren Fällen eine Eindeutigkeit für das Attribut zu garantieren. Da sie aus nur einem Attribut bestehen, sind technische Schlüssel kürzer und verbrauchen damit z.B. für die Duplikatsuche weniger Ressourcen (Zeit, CPU, …). Fachliche Schlüssel hingegen unterliegen auch oft unerwünschten Änderungen – z.B. wenn sich der Name einer Person nach der Heirat ändert – mit negativen Auswirkungen auf das System. Oder sie enthalten Personaldaten, die aus datenschutzrechtlichen Bestimmungen nicht verwendet werden dürfen. Aus diesen Gründen sind technische Schlüssel sehr beliebt, wobei meistens die fachlichen Schlüssel ebenfalls parallel existieren. Technische und fachliche Schlüssel aus nur einem Attribut lassen sich mit der Eindeutigkeitsanalyse auf Attributebene sehr leicht identifizieren. Technische und fachliche Schlüssel aus mehr als einem Attribut werden hingegen mit der Analyse auf Schlüsselattribute gefunden. Diese Analyse entspricht im Grundsatz ebenfalls einer Eindeutigkeitsanalyse; sie ist lediglich auf mehr als ein beteiligtes Attribut ausgeweitet. Aus diesem Grunde gelten die gleichen Hinweise wie bei der Eindeutigkeitsanalyse. Allerdings besteht bei der Analyse die Gefahr der Überbestimmung. Wenn eine Tabelle KOSTENSTELLE aus den Attributen KOSTENSTELLE, KOSTENRECHNUNGSKREIS und anderen Attributen besteht, ist jeder Datensatz eindeutig durch die beiden Schlüsselattribute KOSTENSTELLE und KOSTENRECHNUNGSKREIS definiert. Die Kostenstelle allein reicht hierfür nicht aus, weil es z.B. die Kostenstelle »100« sowohl im Kostenrechnungskreis »2000« für den Verkauf als auch im Kostenrechnungskreis »1000« für den Vertrieb gibt. Wenn die Schlüsselattribute KOSTENSTELLE und KOSTENRECHNUNGSKREIS jeden Datensatz eindeutig definieren, so tun das auch alle anderen mögli-

9.5 Data-Profiling-Verfahren zur Analyse von Datensätzen

161

chen Kombinationen dieser Schlüsselattribute mit den anderen Attributen der Tabelle, beispielsweise KOSTENSTELLE, KOSTENRECHNUNGSKREIS und KOSTENSTELLENNAME. Der KOSTENSTELLENNAME ist aber für die Eindeutigkeit nicht erforderlich, damit ist in diesem Fall die Eindeutigkeit überbestimmt. Diese überbestimmten Kombinationen sind nicht weiter zu betrachten, wichtig und richtig sind nur die für die Eindeutigkeit zwingend erforderlichen Schlüsselattribut­Kombinationen. Eindeutiger Schlüssel

Dokumentiert?

Ermittelt?

Lokales Attribut

UK_123

Nein

Ja

KOSTENSTELLE, KOSTENRECHNUNGSKREIS

UK_124

Nein

Ja

KOSTENSTELLE, KOSTENRECHNUNGSKREIS, KOSTENSTELLENNAME

Tab. 9–4

Ergebnis der Analyse auf Schlüsselattribute (Beispiel)

In dem Beispiel in Tabelle 9–4 ist nur der eindeutige Schlüssel UK_123 zu verwenden, bei UK_124 ist das Attribut KOSTENSTELLENNAME überflüssig und nicht zu beachten. Leicht identifizieren lassen sich solche überbestimmten Kombinationen, wenn man sich die eindeutigen Schlüssel absteigend sortiert nach dem Prozentsatz der eindeutigen Attributkombinationen und der Anzahl der beteiligten Attribute anzeigen lässt. In den meisten Fällen besitzen die überbestimmten Kombinationen den gleichen Prozentsatz wie die minimal notwendige Kombination und finden sich somit in der sortierten Darstellung gleich dahinter (oder zumindest in der Nähe davon). Bei manchen Data­Profiling­Werkzeugen muss die Konfiguration für die Analyse von Schlüsselattributen angepasst werden, da diese häufig als DefaultEinstellung nur ein einzelnes Attribut auf Eindeutigkeit untersuchen.

9.5.2

Analyse auf abgeleitete Werte

Mithilfe dieser Analysetechnik werden abgeleitete Attribute entdeckt, bei denen aus dem Wert eines Attributs (oder mehrerer) auf den des anderen geschlossen werden kann. Die Beziehungen zwischen abgeleiteten Attributen werden in mathematische oder regelbasierte Gruppen eingeteilt. Bei mathematischen Beziehungen kann der Zusammenhang über eine mathematische Formel definiert werden. Ein Beispiel hierfür ist der von EINZELPREIS und BESTELLMENGE abhängige GESAMTPREIS in der Tabelle BESTELLUNG. Im Gegensatz zur Korrelationsanalyse beim Data Mining wird aber lediglich das Vorhandensein einer Beziehung identifiziert, nicht die explizite Formel (z.B. EINZELPREISBESTELLMENGE=GESAMTPREIS) für die Korrelation.

162

9 Data Profiling

Bei regelbasierten Beziehungen wird die Regel über eine Geschäftsregel definiert. Ein Beispiel: »Wenn das Beschäftigungsverhältnis gleich FREIBERUFLER ist, so ist die Abrechnungseinheit gleich STUNDEN.« Diese Regel gibt die Geschäftsregel wieder, dass in dem Unternehmen Freiberufler ausschließlich nach Stunden bezahlt werden. Neben den einfachen Beziehungen (Attribut B hängt von Attribut A ab) können auch komplexere Beziehungen zwischen mehreren Attributen (Attribut D hängt von Attribut A, B, und C ab) existieren (siehe Tab. 9–5). Determinant

Dependent

# Defects

% Compliant

Type

Einzelpreis, Bestellmenge

Gesamtpreis

3

99,8

uni-directional

Einzelpreis, Bestellmenge, Rabatt_Status

Rabatt

9

99,4

uni-directional

Tab. 9–5

Ergebnis einer Analyse auf abgeleitete Attribute (Beispiel)

Das größte Problem bei der Analyse abhängiger Attribute aus den Daten sind in der Praxis falsch erkannte Abhängigkeiten. Diese werden dadurch verursacht, dass die Abhängigkeiten von den Werkzeugen einzig und allein auf Grundlage der Attributwerte identifiziert werden. So werden z.B. in der Tabelle KUNDEN fälschlicherweise Abhängigkeiten zwischen den Attributen ANZAHL_KINDER, KUNDENSTATUS und GESCHLECHT gefunden. Jedes dieser Attribute ist numerisch: Die ANZAHL_KINDER liegt zwischen 0 und 4, der KUNDENSTATUS zwischen 1 und 3 und das Geschlecht zwischen 1 und 2. Statistisch gesehen lassen sich hier tatsächlich Abhängigkeiten zwischen diesen Attributen finden, obwohl diese fachlich überhaupt nichts miteinander zu tun haben. Aus diesem Grunde müssen diese falsch erkannten Abhängigkeiten zusammen mit dem Business­Analysten identifiziert und von der weiteren Betrachtung ausgeschlossen werden. Ein Indiz für falsch erkannte Abhängigkeiten ist, wenn eine hohe Anzahl von Abhängigkeiten entdeckt wird.

9.5.3

Analyse von Datensätzen mit Geschäftsregeln

In diesem Verfahren wird wie bei der Analyse mit Geschäftsregeln auf Attributebene auf das vorhandene fachliche Expertenwissen in Form von vordefinierten Geschäftsregeln zurückgegriffen. Dabei beziehen sich in diesem Fall die Geschäftsregeln auf genau einen Datensatz. Um Regeln für funktionale Abhängigkeiten festzulegen, kann man entweder die vorhandenen Informationen zu den Daten verwenden oder die Daten direkt analysieren. Zu den vorhandenen Informationen zählen die Dokumentation (z.B. DVKonzept), das Metadaten­Repository, die Datenmodelle (fachlich und technisch)

9.6 Data-Profiling-Verfahren zur Analyse von Tabellen

163

und das Data Dictionary der Datenbank. Leider sind diese Daten in der Praxis häufig veraltet. Insbesondere die Datenmodelle werden zu Beginn eines Projekts zwar aufgestellt, während des Betriebs und der darin stattfindenden Wartung und Pflege aber selten aktualisiert. Deshalb sind die aus vorhandenen Informationen abgeleiteten Abhängigkeiten mit größter Vorsicht zu verwenden. In der Praxis hat sich die Kombination beider Herangehensweisen bewährt. Aus den vorhandenen Informationen werden bekannte Abhängigkeiten wesentlich schneller und einfacher identifiziert, und mit den Ergebnissen der zugehörigen Datenanalyse kann man anschließend deren Aktualität messen. Ist beispielsweise bei einem Automobilhersteller in der Dokumentation festgelegt, dass bei einem neuen Auto ein Radio vom »TYP CR­2567 mit CD­Wechsler« nur in Verbindung mit einem Lautsprechersystem mit acht Boxen bestellt werden kann, die Datenanalyse findet aber 15 Prozent nicht dieser Regel entsprechende Datensätze, so ist diese fachliche Festlegung zu verifizieren und ggf. anzupassen. Weiter findet die Datenanalyse auch bisher undokumentierte Abhängigkeiten, die andernfalls niemals identifiziert werden könnten.

9.6 9.6.1

Data-Profiling-Verfahren zur Analyse von Tabellen Analyse von Tabellen auf referenzielle Abhängigkeiten

Bei der Analyse auf Tabellenebene wird versucht, referenzielle Abhängigkeiten innerhalb von Tabellen zu identifizieren. Die Analyse referenzieller Abhängigkeiten sucht nach Beziehungen zwischen Attributen in verschiedenen Tabellen oder zwischen Datensätzen innerhalb einer Tabelle. Sie ermittelt neben den Abhängigkeiten auch die Kardinalität der Beziehung, identifiziert Eltern- und Kind­Beziehungen und findet Waisen (Kinder ohne Eltern) und Eltern ohne Kinder. Aus der Kardinalität der Beziehung können z.B. Hierarchien aufgedeckt werden, in denen Eltern und Kinder eine Kardinalität von [1; … ; n] besitzen. Die referenzielle Integrität garantiert die Existenz einer Verknüpfung zwischen den verbundenen Tabellen und dass für jede Referenz in der einen auch ein zugehöriger Datensatz in der anderen Tabelle vorhanden ist. Nur damit ist eine Verknüpfung dieser Tabellen (z.B. für eine Auswertung) möglich. Insbesondere bei unbekannten und schlecht dokumentierten physikalischen Datenmodellen gibt diese Analyse wichtige Hinweise über die Zusammenhänge zwischen den Tabellen, besonders wenn die Verbindungen nicht mit Datenbankmitteln (z.B. Fremdschlüsselbeziehungen) realisiert oder deaktiviert wurden. In der Praxis treffen leider viele Unternehmen keine Maßnahmen, um die referenzielle Integrität mithilfe des relationalen Datenbanksystems sicherzustellen. Gründe für die Nichtverwendung sind entweder die Performance­Anforde-

164

9 Data Profiling

rungen, die Notwendigkeit des Ladens unzulässiger Datensätze oder die Realisierung dieser Maßnahmen innerhalb der Applikationen. Aus Performance­Gründen schaltet man häufig diese Schutzmaßnahmen aus, damit das Laden schneller durchgeführt und nicht jeder Datensatz einzeln validiert werden muss. Zu Beginn des Ladevorgangs schaltet man die Datenbank­Constraints7 aus und danach wieder ein. Sind dabei diesen Constraint verletzende Datensätze geladen worden, lässt sich dieser anschließend nicht mehr aktivieren. Die invaliden Datensätze verbleiben dann in der Tabelle, sofern sie nicht anschließend bereinigt werden. Oder aber es kommt zu einem Abbruch während des Ladeprozesses, sodass die vorgesehene Reaktivierung der Constraints unterbleibt. Insbesondere beim Laden aus den Quellsystemen besteht häufig die Anforderung, alle Datensätze zur Nachweisführung zu laden und dabei keinen Satz durch referenzielle Constraints abzuweisen. Bei einem schlechten Design der Ladeprozesse werden deshalb diese Constraints nicht definiert. Die bessere Alternative ist, den Constraint zu aktivieren und die von diesem abgewiesenen Datensätze entweder in einer Fehlertabelle abzulegen oder einer Nachverarbeitung und Korrektur zu unterziehen. Werden die referenziellen Constraints nicht in der Datenbank definiert, sondern ausschließlich programmtechnisch in einer Applikation oder in den ETL­Prozessen selbst realisiert, so sollte man auf ein funktionierendes, sicheres Transaktionskonzept achten. Ein versehentliches Schreiben unzulässiger Datensätze in die Zieltabellen ist unbedingt zu verhindern oder diese sind durch einen geeigneten Rollback­Mechanismus rückstandsfrei zu entfernen. Vor Auslieferung ist das zwingend vollständig für alle möglichen Fälle zu testen. Bewährt hat sich das Vorgehen, die Constraints auf der Datenbank zur Absicherung der Programmlogik zu definieren.

7.

definierte Integritätsbedingung

9.6 Data-Profiling-Verfahren zur Analyse von Tabellen

165

Fehler in referenzieller Integrität

Eine Bestellung ohne zugehörige Kunden

Orphans 1

Abb. 9–14

499 Bestellungen mit zugehörigen Kunden

Joins 499

624 Kunden ohne dazugehörige Bestellung

UK_5 Childless 624

Referenzielle Integrität zwischen den Tabellen KUNDEN_STAMM und BESTELLUNG (Beispiel)

In dem Beispiel in Abbildung 9–14 wurde in den Daten ein Kandidat für eine referenzielle Integrität zwischen der analysierten Tabelle BESTELLUNG und der Tabelle KUNDEN_STAMM identifiziert. Es handelt sich um eine Fremdschlüsselbeziehung (Type = Foreign Key), die auf der Datenbank selbst nicht eingerichtet wurde (Documented? = No): Der lokale Primärschlüssel KUNDENCODE wird in dem Attribut KUNDEN_ID der Tabelle KUNDEN_STAMM als Fremdschlüssel verwendet. Die referenzielle Integrität besteht in den Daten nur zu 99,8 Prozent, es existiert eine Bestellung für den KUNDENCODE = 1009, für den kein Datensatz mit der gleichen KUNDEN_ID in der Tabelle KUNDEN_STAMM zu finden ist. Eine grafische Darstellung der Beziehung ergibt, dass ■ für einen Kundencode kein passender Datensatz in der Tabelle KUNDEN_ STAMM existiert (Orphans = Waisen), ■ für 499 Bestellungen die Referenz zu den Kunden existiert (Joins = Verbindungen) und ■ für 624 Kunden aus der Tabelle KUNDEN_STAMM kein passender Datensatz in der Tabelle BESTELLUNG existiert (Childless = Eltern ohne Kinder), vermutlich weil diese aktuell noch keine Bestellung getätigt haben. Werden wie hier Waisen oder kinderlose Eltern gefunden, so ist das an sich noch kein Fehler. Es muss dann weiter analysiert werden, ob das fachlich richtig oder falsch ist. Findet man wie in dem Beispiel eine Beziehung zwischen Bestellungen und Kunden, in der nur 99,8 Prozent der Bestellungen (Kind) einem Kunden (Eltern) zugeordnet sind, so müssen die verbleibenden 0,2 Prozent fachlich hinterfragt werden. Gibt es eine Geschäftsregel, dass alle Bestellungen einem Kunden zugeordnet sein müssen, so stellen diese Datensätze einen Fehler dar. Enthalten

166

9 Data Profiling

die Bestellungen aber z.B. auch Warenkörbe aus dem Online­Shop, bevor die Kunden sich identifiziert und ihre Bestellungen abgeschickt haben, so handelt es sich dabei nicht um einen Fehler. Kardinalitäten

Anzahl

Bei dieser Analyse wird die Anzahl der an einer referenziellen Beziehung beteiligten Instanzen in den beteiligten Tabellen bestimmt. Ein Beispiel: Bei der referenziellen Beziehung zwischen Bestellung und Bestellpositionen handelt es sich in der Regel um eine 1:n­Beziehung, d.h., eine Bestellung besteht aus mehreren Bestellpositionen. Anders herum betrachtet gehören eine oder mehrere Bestellpositionen zu genau einer Bestellung. 350 300 250 200 150 100 50 0

1

2

3

4

Kardinalität

Abb. 9–15

Verteilung der Kardinalitäten zwischen KUNDEN und BESTELLUNG (Beispiel)

Während sich die Analyse auf referenzielle Integrität nur darum kümmert, die Existenz solcher Beziehungen zu finden, geht die Analyse der Kardinalitäten einen Schritt weiter. Sie bestimmt aus den analysierten Daten deren genaue Anzahl, in diesem Beispiel, wie viele Bestellpositionen eine Bestellung besitzt. Mithilfe dieser Informationen lassen sich nach der fachlichen Bewertung Regeln ableiten. Findet man wie in dem Beispiel aus Abbildung 9–14 anhand der Daten eine Kardinalität zwischen der Tabelle KUNDEN und BESTELLUNG von 1:4 (Cardinality Range), so lässt das auf eine fachliche Regel schließen: »Kunden müssen immer mindestens eine Bestellung getätigt haben.« Eine Übersicht über die Verteilung der Kardinalitäten dieser Beziehung in Abbildung 9–15 zeigt, dass die meisten Kunden zwischen ein und zwei Bestellungen getätigt haben. Redundante Attribute

Bei der Analyse auf redundante Attribute sucht man nach Attributen, die redundant zu einer vorhandenen Fremdschlüsselbeziehung existieren. Ein Beispiel (siehe Abb. 9–16) ist das Attribut WARENGRUPPE, das zusätzlich zu dem Attribut mit der Fremdschlüsselbeziehung zur übergeordneten Warengruppe (WARENGRUPPE_ID) in einer Produkttabelle existiert. Diese redundanten Attribute können zu einer Inkonsistenz führen, wenn die Attributwerte nicht übereinstimmen. Mögliche Ursachen für solche redundanten Attribute sind einer-

9.6 Data-Profiling-Verfahren zur Analyse von Tabellen

167

seits unvollständige Modelländerungen während des Betriebs oder absichtliche Denormalisierungen zur Performance­Optimierung. Produkte ■ ■ ■ ■

Warengruppen

Produkt_ID Bezeichnung Warengruppe_ID Warengruppe

■ Warengruppe_ID ■ Bezeichnung

Tabelle Produkte Produkt_ID

Bezeichnung

Warengruppe_ID

Warengruppe

1

Rohr, 501000

1

Rohre

2

Rohr, 751000

1

Rohre

3

Muffe, 501000

2

Muffen

Tabelle Warengruppen Warengruppen_ID

Bezeichnung

1

Rohre

2

Muffen

Abb. 9–16

Redundante Attribute bei Warengruppen und Produkten (Beispiel)

Anzahl Datensätze

Bei diesem Verfahren wird die Anzahl der Datensätze in einer Tabelle gezählt, um damit z.B. die Vollständigkeit zu validieren. Typischerweise erfolgt dieses Verfahren in der Praxis nicht nur auf allen Datensätzen einer Tabelle, sondern es werden auch Gruppierungen der Daten berücksichtigt. In dem Beispiel in Tabelle 9–6 werden in einem monatlich geladenen DWH die Datensätze pro Lademonat gezählt. Aus den Messungen für die verschiedenen Monate des ersten Halbjahrs 2008 ergibt sich eine durchschnittliche Anzahl von Datensätzen pro Monat in Höhe von 225.341 Datensätzen. Für den Juli 2008 werden hingegen nur 123.546 Datensätze gezählt, was eine starke Abweichung von der durchschnittlichen Anzahl von Datensätzen pro Monat darstellt. Dies könnte ein Indiz auf eine unvollständige Datenlieferung oder ­verarbeitung sein.

168

9 Data Profiling

Gruppierung

Tab. 9–6

Wert?

# Zeilen

Zeilen

Monat

Januar 2008

214.222

214.222

Monat

Februar 2008

237.123

225.673

Monat

März 2008

227.528

226.291

Monat

April 2008

214.789

223.416

Monat

Mai 2008

241.927

227.118

Monat

Juni 2008

216.456

225.341

Monat

Juli 2008

123.546

210.799

Ergebnis einer Messung der Datensatzanzahl (Beispiel)

In einem Projekt deckte dieses Verfahren einen ansonsten nur sehr schwer zu findenden Fehler auf: Es wurden dort mehrere Millionen Datensätze in einer Datei über einen ftp­Transfer von einem Host­System auf den DWH­Server transferiert. Bei der Prüfung auf Korrektheit stellten die Anwender fest, dass die berechneten Kennzahlen aus diesen Daten für einzelne Monate nicht korrekt waren. Die Messung der Anzahl der Datensätze zu den einzelnen Monaten ergab, dass in den unkorrekten Monaten deren Anzahl sehr viel niedriger war als in den korrekten Monaten. Daraufhin hat man gezielt den ftp­Prozess für die Datenübertragung vom Host­ in das DWH­System überprüft. Das Ergebnis: Bei den unkorrekten Monaten waren Sonderzeichen in den Datensätzen vorhanden, die der ftp­Prozess als Dateiende­Zeichen missinterpretiert hat. Dadurch wurde der ftp­Prozess ohne Fehlermeldung beendet, obwohl nur ein Teil der Daten tatsächlich übertragen worden war. Aus dem Teilbestand wurden dann die Kennzahlen berechnet, die auf dieser Basis natürlich nicht korrekt sein konnten.

9.6.2

Analyse von Tabellen mit Geschäftsregeln

Wie bei der Analyse mit Geschäftsregeln auf Attributebene greift man auch in diesem Verfahren auf das fachliche Expertenwissen in Form von vordefinierten Geschäftsregeln zurück. Dabei beziehen sich die Geschäftsregeln auf die Menge aller Datensätze einer oder mehrerer Tabellen. Regeln zur Anzahl von Datensätzen

Wie schon angesprochen, können die zugehörigen Regeln zur Anzahl der Datensätze im Vorfeld fachlich definiert und festgelegt werden. Diese Vorgehensweise bietet sich insbesondere an, wenn die Vollzähligkeit der Datensätze zu verifizieren ist. Aus dem Beispiel in Tabelle 9–6 könnte die statische abgeleitete Regel lauten: »Pro Monat müssen zwischen 200.000 und 250.000 Sätze angeliefert werden.« Ein anderes Anwendungsbeispiel aus der Praxis ist die Überwachung der Vollständigkeit der angelieferten Quellsystemdateien. Soll z.B. diese angelieferte Datei die Datensätze aller Organisationseinheiten eines Unternehmens enthalten,

9.6 Data-Profiling-Verfahren zur Analyse von Tabellen

169

kann man die Regel zur Validierung folgendermaßen statisch definieren: »Die Anzahl der Datensätze pro Organisationseinheit des Unternehmens in der Datei muss größer 0 sein.« In großen Data Warehouses ist die manuelle Pflege dieser statischen Grenzwerte sehr aufwendig. Deshalb kann es sinnvoll sein, diese dynamisch mithilfe von Regressionsanalysen oder anderen statistischen Verfahren automatisch adjustieren zu lassen. Beispiel: »Die Veränderung der Datensätze darf monatlich maximal +/–10 Prozent betragen«, d.h., durch einen Trend in den Daten kann das Maximal­Limit im ersten Beispiel auf 275.000 Sätze angehoben werden. Dieses dynamische Verfahren ist ebenfalls sinnvoll, wenn sich die Gesamtzahl der Datensätze durch Anhängen regelmäßig erhöht (siehe auch »Regeln für zeitabhängige Attribute«, folgender Abschnitt). In allen Fällen muss vorab konzeptionell festgelegt werden, ob man im Falle einer negativen Validierung den Prozess weiterlaufen lässt oder abbricht. Die Validierung auf Vollständigkeit kann aber nicht nur auf die Datenlieferungen aus den Quellsystemen angewendet werden. Oft werden diese Regeln auch innerhalb des DWH beim Laden in einen Data Mart oder eine Faktentabelle angewendet. Dabei wird z.B. geprüft, ob für jede fachlich notwendige Dimensionsausprägungskombination ein Datensatz geladen wird. Beispielsweise könnte beim Laden in einen Data Mart mit den Verkaufszahlen einer Supermarktkette pro Monat und pro Markt validiert werden, ob für jeden Markt und jeden Monat ein Datensatz mit den Kennzahlen VERKAUFTE_MENGE und VERKAUFSBETRAG vorhanden ist. In diesem Beispiel ist es fachlich nicht möglich, dass in einem Markt in einem Monat überhaupt nichts verkauft wird. Hier ist eher zu vermuten, dass ein Fehler im ETL­Prozess das Fehlen dieser Datensätze verursacht hat. Auch in diesem Fall ist vorher konzeptionell festzulegen, wie der Ladeprozess bei einem negativen Ergebnis der Regelvalidierung reagieren soll. Regeln für zeitabhängige Attribute/Objekte

Mithilfe dieser Regeln lässt sich die zulässige Veränderung von sich zeitabhängig ändernden Attributwerten oder Objekten festlegen. Die meisten Attribute von real existierenden Objekten ändern ihren Wert im Laufe der Zeit, sodass zusätzlich zu dem konkreten Wert auch der zugehörige Zeitpunkt der Messung gespeichert werden muss. Ein Beispiel hierfür ist der Wert einer Aktie, der sich im Laufe der Zeit in beide Richtungen verändern kann. Neben dem Wert einer Aktie muss deshalb zusätzlich auch der Zeitpunkt (z.B. Datum und Uhrzeit) pro Wert abgespeichert werden. Die Attributwerte werden nicht immer nur zu bestimmten Zeitpunkten gemessen und gespeichert, häufig empfiehlt sich die Speicherung für einen Zeitraum, beispielsweise für den Aktienkurs als Mittelwert über einen Tag. Diese Zeiträume müssen im Regelfall disjunkt sein und dürfen keine Lücken haben. In dem Beispiel in Tabelle 9–7 werden die Mitarbeitereinkommen pro Jahr gespeichert. Die Zeiträume in der Tabelle

170

9 Data Profiling

umfassen immer ein komplettes Jahr, sind vollzählig bis zum aktuellen Jahr und weisen keine Lücken oder Überschneidungen auf. Mitarbeiter_ID

Tab. 9–7

Zeitraum_Beginn

Zeitraum_Ende

Gehalt_EURO

127

01.01.2006

31.12.2006

57.200

127

01.01.2007

31.12.2007

58.490

127

01.01.2008

31.12.2008

60.345

Historisierte Zeiträume für Attributwerte (Beispiel)

Solche sich zeitabhängig ändernden Attribute findet man häufig in BI­Anwendungen, z.B. in Merkmalen als »Slowly Changing Dimensions (SCD)«. Zeitabhängige Attribute sind sehr stark verbreitet und extrem fehleranfällig, weshalb sie häufig im Mittelpunkt eines Data Profiling stehen. Außerdem sind aufgrund des hohen Gefährdungspotenzials die Auswirkungen schlechter Datenqualität besonders hoch. Dem gegenüber stehen die Probleme, dass das formale Profiling für diese Attribute nur sehr schwer und nur für wenige Teilbereiche automatisiert möglich ist. Aus diesem Grunde kommen in der Praxis sehr häufig fachliche Regeln zum Einsatz, um damit die Qualität der vorhandenen Daten zu analysieren und die Regeln gleichzeitig zu validieren. Regeln für zeitabhängige Attribute/Objekte

Regeln für Zeitreihen

Regeln für die Werteentwicklung

Aktualität

Richtung

Vollständigkeit

Steigung

Kontinuität

Volatilität

Regeln für Ereignisse

1. Stufe

2. Stufe

Granularität

Abb. 9–17

Arten der Regeln zu zeitabhängigen Attributen/Objekten (Übersicht)

Die Regeln für zeitabhängige Attribute und Objekte gliedern sich in zwei Stufen (siehe Abb. 9–17).

9.6 Data-Profiling-Verfahren zur Analyse von Tabellen

171

Regeln für Zeitreihen

Diese Regeln für Zeitreihen gelten für Attribute und Objekte mit einem durch ein Beginn­ und Ende­Datum begrenzten Gültigkeitszeitraum, z.B. für das Attribut PREIS_NETTO den zugehörigen Geltungszeitraum mit PREIS_GUELTIG_VON und PREIS_GUELTIG_BIS. In den nachfolgenden Abschnitten werden die vier unterschiedlichen Arten von Regeln für Zeitreihen näher erläutert. Die Regeln zur Aktualität legten die notwendige Aktualität der vorhandenen Zeitreihen fest, d.h. bis zu welchem Zeitpunkt diese vorhanden sein müssen. Häufig findet man in der Praxis die einfache Vorgabe, dass immer alle Zeiträume bis zum aktuellen Zeitpunkt existieren müssen. Ein Beispiel ist der Preis der aktuellen Verkaufsartikel, der neben der erforderlichen Historie auch den aktuellen Preis enthalten muss. In dem Beispiel in Tabelle 9–8 wird diese Regel vom Artikel »256« eingehalten, beim Artikel »257« fehlt hingegen der aktuelle Preis für das Jahr 2010. Artikel_ID

Preis_Gueltig_von

Preis_Gueltig_bis

Preis_Netto

256

01.01.2001

15.03.2003

45,34

256

16.03.2003

05.11.2005

46,12

256

06.11.2005

23.08.2007

48,67

256

24.08.2007

31.12.2010

49,50

257

01.01.2001

25.09.2006

12,84

257

26.09.2006

12.12.2007

13,88

257

13.12.2007

30.07.2009

14,29

Tab. 9–8

Ergebnis der Regelprüfung auf Aktualität (Beispiel)

Die Regeln lassen sich auch variabler definieren, z.B. muss für jeden Mitarbeiter das Jahreseinkommen bis zu seinem Entlassungszeitpunkt vorhanden sein. Hier ist der Zeitpunkt, bis zu dem die Zeitreihen existieren müssen, individuell für jeden Mitarbeiter und nicht wie in dem vorigen Beispiel einheitlich für alle Artikel vorgegeben. In manchen Fällen müssen Zeitreihen vollständig sein, d.h. einen bestimmten, vorher festgelegten Zeitraum abdecken. Daher werden zugehörige, fachliche Regeln zur Vollständigkeit definiert und die Daten damit validiert. Ein Anwendungsbeispiel sind gesetzliche Regelungen für die Aufbewahrung und Speicherung bestimmter Datenobjekte nach dem Sarbanes­Oxley­Gesetz. Auch hier existieren ähnlich wie bei der Aktualität in der Praxis häufig variable Regeln, die individuelle Aufbewahrungsfristen für einzelne Datenobjekttypen vorgeben. Mit den Regeln zur Kontinuität wird festgelegt, ob die Zeitreihen Lücken oder Überlappungen besitzen dürfen. Oft müssen die Zeitreihen disjunkt sein und dürfen keine Lücken aufweisen. Andernfalls kann es z.B. bei Aggregation leicht

172

9 Data Profiling

zu unkorrekten Werten kommen. In dem Beispiel in Tabelle 9–9 überlappen sich die beiden letzten Zeiträume für den Mitarbeiter »56566«. Werden die Gehälter aller Mitarbeiter summiert, wird für diesen Mitarbeiter das Gehalt für das Jahr 2002 doppelt berücksichtigt – und dadurch die Summe verfälscht. Mitarbeiter_ID

Beschaeftigung_von

Beschaeftigung_bis

Gehalt_EURO

56566

01.01.2001

31.12.2001

45.344,50

56566

01.01.2002

31.12.2002

46.125,00

56566

01.01.2002

31.12.2004

94.350,00

Tab. 9–9

Analyse der Kontinuität von Gehältern (Beispiel)

In manchen Fällen wird der Wert eines Attributs nicht für einen bestimmten Zeitpunkt, sondern über einen bestimmten Zeitraum gespeichert. Ein Beispiel hierzu ist der Wert einer Aktie, für den der Mittelwert des Kurses pro Tag gespeichert wird. Mithilfe der Regeln zur Granularität wird für solche Attribute festgelegt, dass die Zeiträume die gleiche Granularität (z.B. pro Tag) besitzen müssen. Regeln für die Werteentwicklung

Mithilfe dieser Regeln kann die Werteentwicklung zeitabhängiger Attribute definiert werden. Die drei unterschiedlichen Arten dieser Regeln werden in den nachfolgenden Abschnitten näher erläutert. Mit den Regeln zur Richtung wird die Richtung der zeitlichen Werteentwicklung vorgegeben. Ein Beispiel aus der Praxis sind die Messwerte für die Größe eines Babys in der Entbindungsstation eines Krankenhauses. Diese sollten bei normaler Entwicklung des Kindes von Messung zu Messung ansteigen, andernfalls handelt es sich wahrscheinlich um einen Messfehler (siehe Messung 6 in Abb. 9–18). Größe in cm

58 56 54 52 50 48 46

1

2

3

4

Messung

Abb. 9–18

Werteentwicklung für die Größe eines Babys

5

6

7

9.6 Data-Profiling-Verfahren zur Analyse von Tabellen

173

Für einige Attribute können Spannbreiten und damit die Regeln zur Steigung von Messpunkt zu Messpunkt bei der Werteveränderung festgelegt werden. Für einen Artikelpreis könnte z.B. die Regel vorgegeben werden, dass dieser pro Jahr nicht um mehr als 50 Prozent steigt oder fällt. Je enger diese Spannbreite angesetzt wird, umso weniger kann grundsätzlich daraus direkt auf einen Datenfehler geschlossen werden. Natürliche Schwankungen (z.B. beim Ölpreis) können auch zur erlaubten Verletzung dieser Regel führen. Zu große Spannbreiten finden im Gegensatz zu wenige fehlerhafte Abweichungen, sodass hier ein sinnvolles Maß auf Grundlage fachlicher Erfahrungen gefunden werden muss. Verläuft die Werteentwicklung eines Attributs von Messpunkt zu Messpunkt nicht stetig in eine Richtung, so kann man in solchen Fällen eine Regel zur Volatilität (Sprunghaftigkeit) definieren. Hierbei wird festgelegt, ob und welche Sprünge in der Werteentwicklung erlaubt sind. Beispielsweise kann in einer Regel definiert werden, dass keine Erhöhung direkt gefolgt von einer Reduzierung des Attributwerts erlaubt ist. Anwendung findet eine solche Regel beispielsweise bei Artikelpreisen: Eine Preisreduzierung direkt nach einer vorangegangenen Preiserhöhung lässt auf eine fehlerhafte Eingabe bei der Erhöhung schließen. Regeln für Ereignisse

Darüber hinaus lassen sich auch Regeln für die Historie von Ereignissen (Events) festlegen. Diese werden in der Praxis fast immer mit ihrem Zeitpunkt historisiert gespeichert, häufig auch mit ihrer Dauer. Ein typisches Beispiel sind die Beratungsgespräche mit einem Krankenversicherten. Diese werden historisiert mit ihrer Dauer gespeichert, um z.B. für nachfolgende Beratungen die Historie nachvollziehbar zu gestalten, oder als Arbeitsnachweis für die einzelnen Sachbearbeiter. Verschiedene Ereignisse sind oft voneinander abhängig, da sie sich häufig auf die gleichen Datenobjekte beziehen. Ein Versicherter kann z.B. erst in Rente gehen, wenn er zuvor einen Rentenantrag gestellt hat. Oder Ereignisse sind abhängig von anderen Parametern: Eine Raumfähre kommt erst dann zu einer Generalüberholung, wenn sie eine festgelegte Anzahl von Starts und Landungen durchgeführt und ein bestimmtes Alter überschritten hat. Regeln für Events sind in der Praxis schwierig zu identifizieren, da sie meist sehr komplex sind. Deshalb müssen diese durch Fachleute vorab definiert werden; eine Analyse mit technischen Werkzeugen ist in den meisten Fällen nicht möglich.

174

9 Data Profiling

9.7

Empfehlungen

Dieses Kapitel zeigt die große Komplexität des Data Profiling, das sehr viel mehr ist als ein »Herumstochern im Nebel«. Aufgrund dieser Komplexität sollte man hierfür geeignete Werkzeuge einsetzen. Die Analysen lassen sich zwar auch manuell durchführen, dieser Ansatz hat für ein Projekt aber entscheidende Nachteile: Der Aufwand für manuelle Untersuchungen ist zu groß, die Wiederholbarkeit nur sehr eingeschränkt und die Darstellungsmöglichkeiten für die Ergebnisse reichen nicht aus, um diese für den Fachexperten verständlich präsentieren zu können. Weiterhin spart die Wiederverwendung der Regeln und Ergebnisse innerhalb einer Werkzeugsuite durch die vorhandene Integration in andere Bereiche (z.B. Monitoring) zusätzlichen Aufwand. Bei der Durchführung des Projekts sollten die wichtigsten Faktoren für ein effizientes und erfolgreiches Data Profiling beachtet werden: ■ ■ ■ ■

fundierte Kenntnisse über die Fachlichkeit und die zugehörigen Prozesse, methodisches Vorgehen, richtige Kombination und Einsatz der verschiedenen Verfahren und optimale Zusammensetzung und Erfahrung des Teams.

175

10 Erfolgreiche Datenvalidierung und -filterung

Die Verwendbarkeit der Daten zu prüfen und fehlerhafte Daten auszufiltern – das sind die Aufgaben von Validierung und Filterung. Im Folgenden werden die verschiedenen Ebenen und Elemente der Validierung genauso dargestellt wie die Verfahren der Filterung. Weiterhin wird diskutiert, welche Vor­ und Nachteile eine Validierung bei der Extraktion und beim Laden hat und wie man die verschiedenen Verfahren sinnvoll kombiniert. Die Validierung weist nach objektiven Gesichtspunkten nach, ob sich die Daten für den vorgesehenen Zweck verwenden lassen. Die nicht verwendbaren Daten mit unzureichender Datenqualität werden dabei ausgefiltert. Man kann auf vier Ebenen validieren und filtern: auf der Attributs­, der Datensatz­, der Datenobjekt­ und der Bestandsebene.

10.1 Validierung auf vier Ebenen Auf Attributsebene werden einzelne Datenelemente einer Struktur, beispielsweise eines Datensatzes, validiert und gefiltert. So wird z.B. geprüft, ob das Attribut EINSTELLUNGS_DATUM in dem Datensatz für einen neuen Mitarbeiter mit einem validen Datum gefüllt ist. In der Praxis erfolgt die Validierung eines Attributs üblicherweise mit mehr als einer Regel. Beispiele für diese Regeln sind in Abschnitt 9.4 aufgeführt. Auf Datensatzebene überprüft die Validierung eine Struktur. Eine typische Prüfung: Ist der Wert für das Attribut GESAMT_PREIS das Produkt der Werte der Attribute EINZEL_PREIS und MENGE? Weitere Beispiele enthält Abschnitt 9.5. Auf Datenobjektebene werden Regeln für eine Sammlung von gleichartigen Strukturen (z.B. einer Tabelle) überprüft. Eine mögliche Prüfregel: Ist das Geburtsdatum aller Kunden in der Tabelle KUNDEN zu 98 Prozent mit einem gültigen Datum gefüllt? In Abschnitt 9.6 sind weitere Beispiele beschrieben. Eine Validierung auf Bestandsebene bezieht sich auf den Gesamtbestand (z.B. ein gesamtes Quellsystem) oder einen definierten Teilbestand der Daten (z.B. eine spezielle Ladedatei). Ein Beispiel: Haben alle Organisationseinheiten jeweils eine Datei mit den Verkaufszahlen für den aktuellen Monat angeliefert?

176

10 Erfolgreiche Datenvalidierung und -filterung

10.2 Filterung fehlerhafter Daten Hat die Validierung fehlerhafte Daten erkannt, so werden diese ausgefiltert und gesondert behandelt. In der Praxis sind drei Verfahren mit jeweils zwei Varianten gebräuchlich: Abweisung, Zurückhaltung, Verarbeitung (siehe Abb. 10–1). Validierung

Abweisung

Zurückhaltung

Validierung

Validierung Quelle

Valide ? Ja

Nein

Nein Speicher

Verarbeitung Bericht*

Ziel

Validierung Quelle

Valide ? Ja

Verarbeitung

Verarbeitung mit Bereinigung

Quelle Valide ? Ja

Nein

Verarbeitung

Bereinigung**

Bericht*

Ziel

Ziel

* = optional ** = mit Kennzeichnung (optional)

Abb. 10–1

Verfahren zur Validierung und Filterung von Daten

Abweisung der fehlerhaften Daten

Dieses sehr einfache Verfahren weist nicht verwendbare Daten ab, verarbeitet sie nicht weiter und protokolliert die Abweisung auch nicht. Werden einzelne Attributwerte abgewiesen, so werden diese in der Regel auf NULL gesetzt und anschließend mit dem validierten Rest geladen. Fehlerhafte Datensätze, Datenobjekte und Datenbestände werden komplett abgewiesen. In der Praxis kommt dieses Verfahren selten zum Einsatz, weil es gravierende Nachteile hat: ■ Inkonsistenzen zwischen Quelle und Ziel: Die fehlenden Daten sind nach der Abweisung noch an der Quelle (z.B. in der CRM1­Anwendung) vorhanden, fehlen aber in der BI­Anwendung. Vergleicht man diese Daten, kommt es zu Inkonsistenzen.

1.

CRM: Customer Relationship Management

10.2 Filterung fehlerhafter Daten

177

■ Fehlender Nachweis: Die abgewiesenen Daten werden nicht protokolliert. Das widerspricht ggf. vorgegebenen Compliance­Anforderungen, außerdem kann der Verbleib der fehlenden Daten im Nachgang nicht nachvollzogen werden. ■ Fehlende Information: Die Benutzer der nicht abgewiesenen Daten wissen nicht, wie viele und welche Daten abgewiesen wurden. Die Datenqualität der verbliebenen Daten lässt sich somit nicht quantifizieren – die Nutzbarkeit der Daten sinkt. ■ Probleme bei Deltaladeläufen: Werden nur die geänderten Daten in einem Deltaverfahren verarbeitet, werden diese bei einer erfolgten Abweisung verfälscht. Wurde der initiale Datensatz abgewiesen, fehlt dieser bei den nachfolgenden Aktualisierungen – diese können dann ebenfalls nicht verarbeitet werden. Wird eine Aktualisierung oder Stornierung abgewiesen, entspricht der Datenbestand nicht mehr der Realität. ■ Verminderte Datenqualität: Selbst kleine, schnell und einfach behebbare Datenfehler führen zur Abweisung. In der Praxis ist die Anzahl der abgewiesenen Daten so hoch, dass die Vollständigkeit abnimmt und damit die Datenqualität stark sinkt. ■ Fehlende Korrekturmöglichkeiten: Die ausgefilterten Daten können in der BI­Anwendung nicht korrigiert und nachgeladen werden. Die einzige Möglichkeit zur Korrektur existiert an der Quelle (siehe Kap. 8), anschließend werden die korrigierten Daten erneut in die BI­Anwendung geladen. ■ Großer Zeitverzug: Durch die Abweisung der fehlerhaften Daten, deren Korrektur an der Quelle und das Nachladen dauert es sehr lange, bis auch diese Daten im Ziel verfügbar sind. Stehen die Daten an der Quelle nicht mehr zur Verfügung, müssen diese zuerst aufwendig erneut erzeugt werden. Abweisung der fehlerhaften Daten mit Bericht

Im Gegensatz zur reinen Abweisung erfasst man bei diesem Verfahren die abgewiesenen Daten in einem Bericht. Die fehlerhaften Daten selbst werden nicht gespeichert. Das Verfahren hat die gleichen Nachteile wie die Abweisung. Allerdings gibt es einen gedruckten oder elektronischen Nachweis für die abgewiesenen Daten. In der Praxis zeigt sich leider häufig, dass die Adressaten (die Datenlieferanten an der Quelle) diese Berichte nicht lesen. Die Folge: Die fehlerhaften Daten werden nicht korrigiert, sodass diese in der Regel niemals in die BI­Anwendung geladen werden. Entweder man spart sich den Aufwand für deren Erstellung von

178

10 Erfolgreiche Datenvalidierung und -filterung

Anfang an oder man regelt, wer die Berichtsinformationen umsetzt und die notwendigen Korrekturen durchführt. Zurückhaltung der fehlerhaften Daten

Eine weitere Möglichkeit: Man speichert die fehlerhaften Daten in einem gesonderten Bereich. Dort stehen sie für nachfolgende Fehleranalysen und eine manuelle Weiterverarbeitung und Korrektur zur Verfügung. Dieses Verfahren hat weniger Nachteile als das Abweisen: Zwar bleiben die Inkonsistenzen zwischen Quelle und Ziel und die fehlende Information der Nutzer bestehen, dafür werden die fehlerhaften Daten eindeutig nachgewiesen und können (wenn auch nur manuell) korrigiert werden. Die Probleme mit den Deltaladeläufen, der verminderten Datenqualität und dem Zeitverzug werden abgemildert, da die fehlerhaften Daten im Nachgang zumindest teilweise korrigiert und nachgeladen werden. Vollständig lassen sich diese Probleme aber nicht lösen, da es aufgrund der Beziehungen zwischen den fehlerhaften und den validierten Daten sehr schwierig ist, diese getrennt voneinander zu korrigieren. Dadurch ist diese Korrektur zumeist unvollständig – und ein nennenswerter Rest fehlerbehafteter Daten bleibt. Darüber hinaus ist mit diesem Verfahren ein schwerwiegender Nachteil verbunden, nämlich ein hoher Ressourcenbedarf: Das Speichern der fehlerhaften Daten verbraucht Speicherplatz, der im Laufe der Zeit kontinuierlich zunimmt. Selbst wenn ein Teil der Daten korrigiert, weiterverarbeitet und dann hier gelöscht wird, verbleibt ein nicht unerheblicher Restbestand. Diese erhöhte Datenmenge verlangsamt auch die Lade­ und Zugriffszeiten und kann daher für das gesamte Data Warehouse problematisch sein. Um diese Problematik zu minimieren, sollte man folgende Punkte beachten: ■ Jeden Datensatz nur einmal abspeichern, auch wenn er mehrfach in mehreren Validierungsläufen zurückgehalten wurde. ■ Nicht für jede nicht erfüllte Validierungsregel den Datensatz duplizieren. Soll die Ursache für das Zurückhalten im Datensatz dokumentiert werden, so werden in einem Datensatz alle verletzten Validierungsregeln gemeinsam angehängt. ■ Nach der Aufbewahrungsfrist Altdaten regelmäßig archivieren oder löschen. ■ Ausreichend Platz für die Daten bereitstellen, dabei das Wachstum berücksichtigen. Zurückhaltung der fehlerhaften Daten mit Bericht

Bei diesem Verfahren wird zusätzlich ein gedruckter oder elektronischer Bericht erzeugt. Dieser enthält eine Übersicht über die zurückgehaltenen Daten und erleichtert somit die Weiterverarbeitung und die Korrektur. Gleichzeitig kann man den Bericht für das Berichtswesen verwenden. Die Nachteile für das Zurückhalten der Daten gelten auch hier. Außerdem lehrt die Praxis, dass nur wenige Benutzer diesen Bericht auch lesen (siehe S. 177).

10.2 Filterung fehlerhafter Daten

179

Verarbeitung der fehlerhaften Daten mit Bereinigung

In diesem Falle werden die fehlerhaften Daten weder abgewiesen noch zurückgehalten, sondern in der BI­Anwendung weiterverarbeitet. Dort werden sie automatisch bereinigt. Fehler, die sich nicht automatisch beheben lassen, werden einem Sachbearbeiter zugeführt, der diese dann manuell bearbeitet. In der Praxis ist dieses Verfahren sehr gebräuchlich. Die Nachteile dieses Verfahrens sind: ■ Fehleranfälligkeit: Durch die automatisierte Bereinigung können neue Datenfehler entstehen, die die Datenqualität vermindern statt erhöhen. ■ Komplexität, Laufzeit: Die Bereinigung ist in der Praxis sehr komplex und laufzeitintensiv. Schnell beeinträchtigt sie die reguläre Verarbeitung der validen Daten und verlangsamt die Verarbeitungsprozesse insgesamt. ■ Fehlende Information: Die bereinigten Daten lassen sich nicht von den nicht bereinigten unterscheiden, sodass die korrigierten Werte für den Benutzer nicht eindeutig als solche gekennzeichnet werden können. Mehr Informationen zur Bereinigung von Daten enthält Kapitel 11. Verarbeitung der fehlerhaften Daten mit Bereinigung und Kennzeichnung

Während der Verarbeitung mit Bereinigung kennzeichnet die Anwendung die fehlerhaften Daten. Dabei ist es sogar möglich, einen Wert für die Qualität an die jeweiligen Datenelemente anzufügen. Diese zusätzlichen Informationen lassen sich vielfältig verwenden: ■ Der Benutzer kann die fehlerhaften Daten direkt und eindeutig identifizieren und über ihre Verwendung selbstständig entscheiden. ■ Die nachfolgenden Verarbeitungsprozesse können abhängig von der Qualität der Fehler individuell gesteuert werden (z.B. Daten mit einer Qualität unter einem Grenzwert werden nicht weiterverarbeitet). ■ Es können sehr einfach Berichte über Art und Umfang der Fehler erstellt werden. ■ Wurden die fehlerhaften Daten nach dem Laden auch an der Quelle korrigiert, lassen sich die zugehörigen, in der BI­Anwendung korrigierten Daten sehr leicht zuordnen und durch die an der Quelle korrigierten Daten ersetzen. Der Nachteil: Das Verfahren ist sehr komplex, der Aufwand dementsprechend hoch. Obwohl das Verfahren die besten Ergebnisse liefert, kommt es in der Praxis selten zum Einsatz.

180

10 Erfolgreiche Datenvalidierung und -filterung

10.3 Validierung bei Extraktion oder Laden An welcher Stelle im Datenladeprozess sollen die Daten validiert und gefiltert werden? Grundsätzlich sind zwei Stellen möglich: bei der Extraktion und/oder beim Laden der Daten (siehe Abb. 10–2). In beiden Fällen ist zu verhindern, dass bei der Validierung als fehlerhaft erkannte Daten unkorrigiert in die Datenbereiche des Data Warehouse (z.B. Data Marts, Core Data Warehouse, ODS2-Objekte) gelangen.

Ziel

OK Validierung beim Laden

Laden

Fehler STOPP Transformation

OK Validierung bei Extraktion

Extraktion

Fehler Quelle STOPP

Abb. 10–2

Mögliche Stellen für die Validierung im ETL3-Prozess

Validierung bei der Extraktion

Die Daten werden direkt bei der Extraktion in den zugehörigen Prozessen aus den Quellen validiert, sodass fehlerhafte Daten frühzeitig erkannt und ausgefiltert werden. Da in den meisten Projekten die fehlerhaften Daten abgewiesen werden (siehe S. 176), erreichen sie die BI­Anwendung nicht und können deren Qualität nicht beeinträchtigen. Allerdings bleiben die Nachteile einer Abweisung bestehen. Wird bei der Extraktion validiert, kommen die komplexeren Verfahren (siehe Abb. 10–1) selten zum Einsatz. Schließlich sind die verfügbaren Möglichkeiten bei der Extraktion sehr eingeschränkt. So lassen sich z.B. Inkonsistenzen in der Regel erst durch einen Vergleich mit den in anderen Prozessen extrahierten oder den historischen Daten aus der BI­Anwendung validieren. In der Praxis kommen bei der Extraktion nur vergleichsweise einfache Validierungsarten wie Datentyp­, Domain­ und einfache Integritätsvalidierungen zum 2. 3.

ODS: Operational Data Store ETL: Extraktion, Transformation, Laden

10.3 Validierung bei Extraktion oder Laden

181

Einsatz. Diese erkennen aber nur einen kleinen Teil der fehlerhaften Daten, da z.B. Transaktionsdatensätze von Natur aus (fast) immer integer sind und dadurch Integritätsvalidierungen hierin kaum Fehler finden können. Dafür sind die Verfahren sehr einfach und der damit verbundene Aufwand ist vergleichsweise gering. Validierung beim Laden

Werden die Daten beim Laden in die Ziele (z.B. Core Data Warehouse, Data Marts) validiert, befinden sie sich bereits in der BI­Anwendung und sind schon transformiert. Eingesetzt wird diese Validierung insbesondere beim Laden in diejenigen abhängigen Data Marts, die spezifische Regeln für die Validierung besitzen. Hier kann die Validierung nicht vorher erfolgen, da diese spezifischen Regeln nicht für das übergreifend genutzte Data Warehouse und andere Data Marts gelten. Aufgrund der während der Transformation durchgeführten Standardisierung (siehe Kap. 11) lassen sich bei dieser Validierung vorhandene Duplikate besser und eindeutiger erkennen. Da alle geladenen und historisierten Daten aus dem Data Warehouse (inklusive Data Marts) verwendet werden, sind auch umfassendere und komplexere Validierungen möglich. Auf der anderen Seite steigt die Gefahr, mit der Validierung unbeabsichtigt an sich korrekte Daten auszufiltern und die Datenqualität zu verringern anstatt zu erhöhen. Dieser Gefahr muss man mit einem ständigen Data Quality Monitoring (siehe Kap. 15) entgegenwirken. Möchte man diesen Nachteil minimieren, so kann man eine Kopie der benötigten Tabellen inklusive Daten aus der BI­Anwendung erstellen. Die neuen Daten werden nach der Transformation zunächst in diese Kopie gespeichert. Dadurch ist es möglich, genauso viele Fehler zu finden wie beim direkten Laden in das Ziel. Da es sich um eine Kopie handelt, beeinträchtigen die Fehler die Qualität des originären Zieles nicht. In das richtige Ziel gespeichert werden nur die nach der Validierung als fehlerfrei identifizierten Daten. Die fehlerhaften Daten lassen sich mit diesem Wissen anschließend besser bereinigen. Diese Vorgehensweise bietet die umfassendsten Validierungs­ und Korrekturmöglichkeiten. Leider sind die Kosten für die Implementierung höher, die Laufzeiten der ETL­Prozesse länger und der Ressourcenverbrauch durch die doppelte Speicherung größer. Deshalb ist dieses Verfahren in der Praxis sehr selten. Validierung bei der Extraktion und beim Laden

Egal ob Validierung bei der Extraktion oder beim Laden: Beide Verfahren haben ihre Vor­ und Nachteile und sind je nach Problem besser oder schlechter geeignet. Aus diesen Gründen empfiehlt sich ein kombinierter, auf die jeweiligen Anforderungen ausgerichteter Ansatz: Validierungen, die bei der Extraktion vorteilhaft und möglich sind, werden direkt am Anfang bei der Extraktion durchgeführt. Validierungen, die sich erst nach der Transformation erfolgreich durchführen las-

182

10 Erfolgreiche Datenvalidierung und -filterung

sen, erfolgen erst beim Laden. Damit verringern sich auch die Laufzeit und der Ressourcenbedarf des ETL­Prozesses, weil die schon bei der Extraktion als fehlerhaft identifizierten und anschließend aussortierten Daten nicht erst durch den nachfolgenden Transformations­ und Ladeprozess mitgeführt und verarbeitet werden müssen.

10.4 Arten der Datenvalidierung Nun stellt sich noch die Frage: Wie und womit wird die Validierung durchgeführt? Die besten Ergebnisse liefert in der Regel eine Validierung, die formale Daten­ und fachliche Geschäftsregeln (siehe auch Kap. 9) kombiniert. Die formalen Datenregeln werden beim Data Profiling aus der Analyse erstellt. Beispiele sind die abgeleiteten Datenregeln aus der Datentyp­ oder Domänenanalyse in Kapitel 11. Die Geschäftsregeln resultieren aus dem fachlichen Wissen der Experten und nutzen dieses für eine inhaltliche Validierung. Die formalen Datenregeln setzt man in der Praxis überwiegend zur Validierung bei der Extraktion ein, da diese relativ einfach zu realisieren sind und auch allein auf einzelne Attribute und Datensätze angewendet werden können. Sie benötigen für die Validierung keinen Zugriff auf andere Datenobjekte oder historisierte Daten aus der BI­Anwendung. In dem Beispiel aus Abbildung 10–3 wird das Attribut GEB_DATUM (= Geburtsdatum) mithilfe von zwei formalen Datenregeln geprüft: Liegen die Werte in dem geforderten Format vor? Und handelt es sich um ein gültiges, real existierendes Datum? Für den Kunden mit der ID 103 sind beide Regeln erfüllt, die Validierung endet mit einem positiven Ergebnis. Für die Kunden mit den IDs 104 und 105 wird jeweils eine der Regeln verletzt, die Validierung endet mit einem Fehler. Validierung: 1.) Format dd.mm.yyyy? 2.) Datum existiert? Kunden_ID Name Geb_Datum … 103 Kunden_ID Name Geb_Datum … 103

Lustig 10.04.1966 …

104

Krause

105

07.12.01 … Peters 29.02.2007 …

Validierung: 1.) Format dd.mm.yyyy? 2.) Datum existiert?

Validierung: 1.) Format dd.mm.yyyy? 2.) Datum existiert?

Abb. 10–3

Validierung mit formalen Datenregeln (Beispiel)

Lustig 10.04.1966 … Positiv validiert

Kunden_ID Name Geb_Datum … 104 Krause 07.12.01 … 105 Peters 29.02.2007 … Fehler

10.4 Arten der Datenvalidierung

183

Die Validierung mit fachlichen Geschäftsregeln findet gelegentlich bei der Extraktion statt, aber hauptsächlich beim Laden. Damit können Daten auch mit komplexen Regeln validiert werden, wozu auch historische Daten aus der BI­Anwendung oder andere Datenobjekte verwendet werden können. Beispiele zu fachlichen Geschäftsregeln sind ebenfalls in Kapitel 9 dargestellt, z.B. in den »Regeln zu Wertebereichen« auf Seite 152 oder den »Regeln für Zeitreihen« auf Seite 171. In dem Beispiel aus Abschnitt 10.4 lautet die fachliche Geschäftsregel: »Freelancer werden ausschließlich nach Stunden bezahlt.« Das Attribut BESCHÄFT_ART enthält die Information, ob ein Mitarbeiter Freelancer ist; das Attribut EINHEIT gibt die Einheit für die Bezahlung an. Die Validierung für die Mitarbeiter 103 und 104 ist erfolgreich, da der Mitarbeiter 103 ein Festangestellter ist und die Abrechnungseinheit für den Mitarbeiter 104 (Freelancer) tatsächlich Stunde ist. Die Validierung für den Mitarbeiter 105 meldet folgerichtig einen Fehler, da die Beschäftigungsart Freelancer und die Einheit nicht Stunde ist. Hinweis: Die Validierung allein kann nicht entscheiden, welcher der beiden Einträge (Freelancer, Stunde) fehlerhaft ist. Sie erkennt nur, dass die zugehörige Geschäftsregel verletzt wurde. Positiv validiert

Mitarbeiter Name Beschäft_Art … 103

Lustig

fest

Krause

Freelancer

…

105

Peters

Freelancer

…

Einheit

…

2345

103

Monat

…

2346

104

Stunde

…

2347

105

Tag

…

Kunden_ID Name Lustig

fest

…

104

Krause

Freelancer

…

Validierung: Wenn Beschäftigungsart = »Freelancer«, Einheit = »Stunde«

Einheit

…

2345

10 3

Monat

…

2346

104

Stunde

…

Fehler Validierung: Wenn Beschäftigungsart = »Freelancer«, Einheit = »Stunde«

Mitarbeiter Name 105

Peters

Abrech_ID MA_ID 2347

Abb. 10–4

Beschäft_Art …

10 3

Abrech_ID MA_ID

…

104

Abrech_ID MA_ID

Validierung: Wenn Beschäftigungsart = »Freelancer«, Einheit = »Stunde«

105

Beschäft_Art … Freelancer

…

Einheit

…

Tag

…

Validierung mit fachlichen Geschäftsregeln (Beispiel)

Möglich ist ebenfalls eine Validierung mit Referenzdaten. Auch sie kann sowohl beim Laden als auch bei der Extraktion eingesetzt werden. Referenzdaten sind vertrauenswürdige Daten mit hoher Reputation, sie können aus internen oder externen Quellen stammen. Ein Beispiel sind Adressdaten, die von externen Anbietern wie der Deutschen Post bezogen werden. Die vorhandenen Daten werden bei der Validierung mit diesen Referenzdaten verglichen, wobei die Referenzdaten

184

10 Erfolgreiche Datenvalidierung und -filterung

den Master darstellen. Abweichungen werden als Fehler interpretiert, anschließend werden üblicherweise die Werte mithilfe der Referenzdaten korrigiert. Die nachfolgende Bereinigung der fehlerhaften Daten ist Thema in Kapitel 11.

10.5 Erstellung der Validierungsregeln und Speicherung der Ergebnisse Nun ist noch zu klären, womit die Validierungsregeln erstellt und wo die Ergebnisse gespeichert werden sollen. Grundsätzlich kommen für die Erstellung der Regeln vier unterschiedliche Ansätze (siehe Abb. 10–5) in Frage. Regeln für die Validierung

mit Standardwerkzeugen

Regel-Engines

Abb. 10–5

Datenqualitätswerkzeuge

mit Eigenentwicklung

Individualsoftware

Parametrisierte Regeln

Ansätze zur Erstellung der Regeln für die Validierung (vgl. [Maydanchik 2008])

Einerseits erstellen und validieren Standardwerkzeuge diese Regeln. In Frage kommen entweder spezielle Engines für Daten­ und Geschäftsregeln oder aber Datenqualitäts­Werkzeugsuiten, die teilweise diese Funktionalität enthalten. Allerdings sind die Möglichkeiten dieser Standardwerkzeuge noch eingeschränkt, sodass nicht alle Regeln mit ihrer Hilfe definiert werden können. Außerdem sind sie teilweise schwer zu bedienen und decken nicht alle Anforderungen (z.B. Gruppierung von Regeln, Bildung von Fehlerklassen) ab. Allerdings entwickeln sich diese Werkzeuge rasch weiter. Ein starker Trend zu kompletten, leistungsstarken Datenqualitätssuiten ist erkennbar, weshalb bereits heute verwendbare Lösungen verschiedener Anbieter verfügbar sind. Da diese Suiten in der Regel auch ETL­, Monitoring­ und Berichtsfunktionalitäten anbieten, die eine vollständige Integration und Wiederverwendung der Regeln ermöglichen, sollte man den aktuellen Einsatzstand und die Verwendung der Suiten vor Projektbeginn überprüfen. Andererseits können Projektteams diese Regeln individuell erstellen und validieren. Entweder entwickeln sie eigenständige Programme (z.B. SQL­Skripte) oder parametrisierbare Regel­Engines. Diese Individualentwicklungen decken alle speziellen Anforderungen ab, doch bleiben die Nachteile für Individualsoftware: der hohe Aufwand und die schlechte Wiederverwendbarkeit in anderen Projekten. Außerdem muss man zusätzliche Anforderungen (wie z.B. Integration in ETL­Prozesse für das Monitoring) selbst realisieren – sofern die verwendeten Werkzeuge überhaupt offene Schnittstellen für diese Integration zur Verfügung stellen.

10.6 Empfehlungen

185

Es bietet sich an, diese Regeln und die Ergebnisse der Validierungen in einem eigenen Repository zu speichern. Hat man kommerzielle Werkzeuge im Einsatz, ist man leider meistens auf die vom Hersteller gewählte Lösung angewiesen. Sieht diese keine Speicherung in einem Repository vor, kann eine solche nur mit hohem Aufwand individuell realisiert werden. In der Praxis sind damit häufig Funktionseinschränkungen und eine verminderte Bedienbarkeit verbunden. Weiter sollte man darauf achten, dass andere Werkzeuge das Repository ebenfalls benutzen. Ansonsten können weder diese Regeln z.B. im ETL­Prozess für die Fehlererkennung und ­bereinigung (siehe Kap. 11) noch die Validierungsergebnisse für das Monitoring (siehe Kap. 15) verwendet werden.

10.6 Empfehlungen Es gibt keine generelle Antwort auf die Frage, welches Verfahren an welcher Stelle in welcher Art bei der Validierung in einem Projekt eingesetzt werden soll. Genauso wenig gibt es eine überall verwendbare »Musterlösung«. Alle möglichen Kombinationen sind denkbar und können je nach Aufgabe auch das beste Ergebnis liefern. Erfahrene Datenqualitätsexperten können mit den vielfältigen Auswahlmöglichkeiten eine maßgeschneiderte Lösung entwerfen. Damit das funktioniert, müssen sich diese Experten vor der Durchführung Gedanken über die Aufgaben des speziellen Projekts machen, die richtige und zweckmäßigste Kombination unter den gegebenen Randbedingungen (z.B. Projektlaufzeit, Budget, Gefährdungspotenzial) identifizieren, diese planen und dann realisieren lassen. Das Projektteam sollte sich aber immer die Nachteile der gewählten Lösung vor Augen halten und den damit verbundenen Risiken aktiv entgegenwirken.

186

10 Erfolgreiche Datenvalidierung und -filterung

187

11 Standardisierung und Bereinigung

Um den Benutzer vor fehlerhaften Daten zu schützen, müssen diese vorher automatisch oder manuell bereinigt werden. In diesem Kapitel werden die notwendigen Hilfsmittel, Verfahren und Metriken erklärt und an praktischen Beispielen dargestellt. Auf die Theorie wird nur so weit wie nötig eingegangen. Der Prozess besteht aus den zwei aufeinander folgenden Schritten (siehe Abb. 11–1): 1. Standardisierung und 2. Bereinigung. Daten

Methoden

1. Standardisieren

2. Bereinigen

Abb. 11–1

› Strukturieren › Normieren

› › › › › ›

Entfernen Ersetzen Ableiten Defaults verwenden Duplikate entfernen Auftrennen

Prozess der Standardisierung und Bereinigung von Daten

11.1 Standardisierung Am besten lassen sich Daten bereinigen, die vorher standardisiert wurden. Um Daten zu standardisieren, muss man sie strukturieren und anschließend normieren. Bei der Strukturierung werden die Daten in ein einheitliches Format gebracht. So kann man z.B. das Datum in das gleiche Format 01.01.2015 bringen. Bei Bedarf spaltet man die Daten in kleinere Bestandteile auf (siehe auch Musteranalyse auf S. 143). So wird beispielsweise der Kundenname in die Bestandteile Anrede, Titel/Grad, Vor-, Mittel- und Nachname aufgeteilt oder die Telefonnummer in Ländervorwahl, Ortsvorwahl und Rufnummer zerlegt. Meist sind Struk-

188

11 Standardisierung und Bereinigung

turierungen nicht trivial, da die zu strukturierenden Daten in vielen unterschiedlichen Formaten vorliegen (siehe Abb. 11–2). Deshalb benutzt man in der Praxis komplexe Parser1, die mit Referenzdaten unterstützt werden können. Beispiel: Um Namen zu strukturieren, werden u.a. Referenzdaten in Form von länderspezifischen Vor- und Nachnamen-Listen verwendet, mit denen sich die Bestandteile im Namen sicher identifizieren und zuordnen lassen. 089/638120

Ländervorwahl 0049 0049 0049

+49(0)2241-97370

Ortsvorwahl 089 02241 0211

Rufnummer 638120 97370 566230

0049(211)566230

Abb. 11–2

Strukturierung der Daten bei der Standardisierung (Beispiel)

Zumindest für Namen, Adressen und Telefonnummern liefern die Werkzeughersteller die Parser und Algorithmen für die Strukturierung. Da viele Unternehmen diese Daten verwenden, lohnen sich die vorgefertigten Lösungen der Hersteller. Theoretisch sind die möglichen Formatierungen z.B. bei internationalen Adressen hinlänglich bekannt, jedoch bietet nicht jeder Hersteller Lösungen für alle Länder an. Gerade bei internationalen Adressen und Namen gibt es große Unterschiede: In China steht beispielsweise der Nachname vor dem Vornamen. Für andere Kontexte (z.B. für individuelle Artikelnummern) muss das Projektteam die Parser und Algorithmen selbst realisieren. Die Normierung bildet die vorhandenen Werte von Attributen auf eine vorgegebene, normierte Werteliste ab (siehe auch Wertebereichsanalyse, S. 142). Diese Normierung erfolgt beispielsweise für die Anrede, akademische Titel oder Firmenzusätze. In Abbildung 11–3 werden deshalb die Bezeichnungen e. Kfr. für eingetragene Kauffrau und Kfm. für Kaufmann auf den normierten Wert e. K. für eingetragenen Kaufmann abgebildet. Firma Petershagen Franken sd&m Gebauer

Firmenzusatz e. Kfr. Kfm Aktienges. Gmbh & Co.

Normierung

Firma Petershagen Franken sd&m Gebauer

Firmenzusatz_Norm e. K. OHG AG KG

Abb. 11–3

1.

Normierung der Daten bei der Standardisierung (Beispiel)

Parser = Software zur Zerlegung und Formatumwandlung

Firmenzusatz e. K. e. K. AG GmbH & Co. KG

11.2 Datenbereinigung

189

In der Praxis erstellt das Projektteam diese Wertelisten selbst, nur sehr selten kommen externe Referenzdaten zum Einsatz. Eine solche Ausnahme ist beispielsweise das Länderkürzel nach ISO 316612 (DEU = Deutschland).

11.2 Datenbereinigung Sind die Daten erfolgreich standardisiert, müssen die bei der Validierung (siehe Kap. 10) als fehlerhaft erkannten Daten bereinigt werden. Doch lässt sich damit die Datenqualität nur in einigen der Datenqualitätskriterien (siehe Kap. 1) verbessern. Für die anderen Kriterien (z.B. Glaubwürdigkeit) muss das Projektteam andere, nicht technisch realisierbare Maßnahmen treffen. Die Bereinigung ist kein einmaliger Prozess, sondern muss mehrfach wiederholt werden. Das ist wie in einem Kinderzimmer: Auch wenn man es mit viel Aufwand aufgeräumt hat, herrscht ein paar Tage später wieder Chaos. Aus diesem Grunde empfiehlt es sich, die Bereinigungsprozesse in den Workflow der ETLProzesse zu integrieren. So gelangen keine Daten unbereinigt in das Data Warehouse, und überdies lassen sich Synergien bei der Extraktion, der Transformation und dem Laden nutzen. In dem Beispiel aus Abbildung 11–4 wird innerhalb des ETL-Prozesses zum Laden der neuen Mitarbeiterdaten validiert, ob für jeden neuen Mitarbeiter ein Einstellungsdatum eingetragen wurde. Bei negativer Validierung werden diese Datensätze in die Fehlertabelle T_MITARBEITER_FEHLER ausgesteuert. Bereinigt werden die Daten, indem für diese Mitarbeiter das Einstellungsdatum auf das aktuelle Datum gesetzt wird. Ein Workflow steuert den Ablauf: Zuerst erfolgt der ETL-Prozess mit integrierter Validierung und anschließend die Bereinigung.

2.

vgl. ISO 3166-1: Codes for the representation of names of countries and their subdivisions – Part 1: Country codes, Internationale Organisation für Normung (ISO)

190

Abb. 11–4

11 Standardisierung und Bereinigung

ETL- und Bereinigungsprozess mit Workflow-Steuerung

11.2 Datenbereinigung

191

Methoden zur Bereinigung der Daten

Je nach Aufgabe kann das Projektteam sechs Methoden einzeln oder kombiniert einsetzen. ■ Entfernung von fehlerhaften Daten: Bei dieser Methode filtert das System die fehlerhaften Daten aus dem Datenfluss heraus, die Daten werden nicht weiterverarbeitet. Beispielsweise entfernt das System Artikel-Stammdatensätze ohne Artikelnummer und Artikelbezeichnung. Diese Methode kommt zum Einsatz, wenn wie in diesem Beispiel keine Korrektur möglich ist – die restlichen Datensätze aber trotzdem verarbeitet werden müssen. ■ Ersetzung durch andere Daten: Möglich ist auch, die fehlerhaften Daten durch Daten aus anderen Quellen (z.B. Referenzdatenbeständen) zu ersetzen. Neben den externen Referenzdaten lassen sich auch alternative interne Quellen verwenden. Ein praktisches Beispiel: Fehlt bei einer Bestellung die Kundennummer, so wird diese mithilfe des Kundennamens aus der Kunden-Stammdatentabelle bestimmt und eingefügt. Beliebte Referenzdaten sind externe Adressdaten, Organisationsstrukturen von Unternehmen oder Artikelnummern/-bezeichnungen. Weitere Informationen und Quellen zu externen Referenzdaten enthält Kapitel 12. ■ Ableitung aus anderen Daten: Des Weiteren lassen sich Korrekturen für fehlerhafte Daten aus anderen Daten ableiten. Ist beispielsweise der Gesamtpreis einer Bestellung fehlerhaft, so wird dieser mithilfe des Einzelpreises und der Bestellmenge der einzelnen Bestellpositionen berechnet und korrigiert. ■ Verwendung von Default-Werten: In manchen Fällen lassen sich fehlerhafte Werte durch Default-Werte ersetzen. Bedingung ist, dass für jede Situation ein »sinnvoller« Default-Wert vorab definiert werden kann. Fehlt beispielsweise bei einem neuen Mitarbeiter das Einstellungsdatum, wird dieses durch das Default-Datum (erster Tag des aktuellen Monats) ersetzt. ■ Entfernung von Duplikaten: Eine weitere Methode zur Bereinigung redundanter Daten ist das Entfernen von Duplikaten. Vor der Entfernung müssen die redundanten Daten allerdings konsolidiert werden. Ein Beispiel: Existieren Duplikate eines Kunden in der Kunden-Stammdatentabelle, sind die vorhandenen Daten zu konsolidieren und in einem Datensatz zu bündeln. Für die Konsolidierung werden aus einem Datensatz der korrekte Name, aus dem zweiten die korrekte Telefonnummer und aus dem dritten die korrekte Anschrift übernommen. Falsch ist es, nur den Datensatz mit den meisten korrekten Daten zu verwenden und die anderen nicht zu berücksichtigen. Weitere Informationen zu diesem Thema sind auf Seite 195 zu finden.

192

11 Standardisierung und Bereinigung

■ Auftrennung von Zusammenfassungen: Das Gegenteil der Methode »Duplikate entfernen« ist »fehlerhafte Zusammenfassungen auftrennen«. Aufgetrennt werden Datensätze, die Daten zu verschiedenen realen Objekten beinhalten. Beispiel: Ein Datensatz in der Kunden-Stammdatentabelle besteht aus der Adresse des Kunden A und der Telefonnummer des Kunden B. Bei den Kunden handelt es sich um unterschiedliche Personen, die allerdings den gleichen Namen haben − der Datensatz fasst somit zwei unterschiedliche reale Objekte unzulässig zusammen. Der Datensatz wird bei der Bereinigung in zwei verschiedene Datensätze aufgespalten: einen Datensatz zum Kunden A (enthält Namen und Adresse) und einen zum Kunden B (enthält Namen und Telefonnummer). Ablage der Originärdaten

Bevor man die Daten endgültig bereinigt, muss man sich sehr genau überlegen, was man mit den originären Daten macht (siehe Abb. 11–5). Hat man z.B. für den fehlerhaften Wert eines Attributs einen Ersatzwert gefunden, existieren zwei Versionen dieses Attributwerts: einerseits der originäre, fehlerbehaftete Wert und andererseits der neue, korrigierte Ersatzwert. Der Grund für die Korrektur und die zugehörigen, bei der Validierung verletzten Regeln werden nicht in der Zieltabelle gespeichert. Der richtige Platz ist das eigenständige Repository, in dem die Regeln und die Validierungsergebnisse festgehalten sind (siehe Kap. 10).

11.2 Datenbereinigung

193

Artikel_ID Grp_ID

Bezeichnung

100

1

Schlüssel, 13 mm

4,39

102

1

Schlüssel, 15 mm

4,73

202

1

Nuss, VK, 13 mm

3,67

Bezeichnung

Preis_Netto

Artikel_ID Grp_ID

Preis_Netto

100

1

Schlüssel, 13 mm

4,39

102

1

Schlüssel, 15 mm

4,73

202

2

Nuss, VK, 13 mm

3,67

Artikel_ID Grp_ID

Grp_ID_korr

Originäre Tabelle

Überschreiben

Bezeichnung

Preis_Netto

100

1

Schlüssel, 13 mm

4,39

102

1

Schlüssel, 15 mm

4,73

202

1

Nuss, VK, 13 mm

3,67

2

Artikel_ID Grp_ID

Bezeichnung

100

1

Schlüssel, 13 mm

4,39

102

1

Schlüssel, 15 mm

4,73

202

1

Nuss, VK, 13 mm

3,67

202

2

Nuss, VK, 13 mm

3,67

Artikel_ID Grp_ID

Bezeichnung

Preis_Netto

100

1

Schlüssel, 13 mm

4,39

102

1

Schlüssel, 15 mm

4,73

202

1

Nuss, VK, 13 mm

3,67

Bezeichnung

Preis_Netto

Zusätzliche Spalte

Preis_Netto Zusätzliche Zeile

Zusätzliche Tabelle Artikel_ID Grp_ID 100

1

Schlüssel, 13 mm

4,39

102

1

Schlüssel, 15 mm

4,73

202

2

Nuss, VK, 13 mm

3,67

Abb. 11–5

Möglichkeiten zur Speicherung der korrigierten Werte (Übersicht)

Überschreibung des originären Werts

Die einfachste und beliebteste Lösung ist das Überschreiben des originären mit dem korrigierten Wert. Leider hat dieses Verfahren gravierende Nachteile: Erstens fehlt der Nachweis über die fehlerhaften Daten, da diese unwiederbringlich überschrieben werden. Zweitens ist nicht erkennbar, dass die Daten korrigiert wurden. Drittens ist kein Vergleich zwischen originärem und korrigiertem Wert möglich. Viertens ist beim erneuten Laden der originären, unkorrigierten Daten die eindeutige Zuordnung zu den zugehörigen korrigierten Daten schwierig.

194

11 Standardisierung und Bereinigung

Insgesamt betrachtet kann mit diesem Verfahren die Datenqualität sogar sinken, da trotz verbesserter Korrektheit Verständlichkeit und Nachvollziehbarkeit leiden. Hinzufügung einer Spalte

Eine weitere Möglichkeit: Das Projektteam fügt eine zusätzliche Spalte ein, in der die korrigierten Werte gespeichert werden. So bleiben die korrigierten und die originären Werte erhalten. Allerdings steigt mit den zusätzlichen Spalten der Speicherbedarf. Außerdem sinkt die Verständlichkeit für die Benutzer beim Erstellen von Ad-hoc-Abfragen: Sie wissen nicht, welches Datenattribut sie für ihre Abfrage verwenden sollen. Deshalb ist dieses Verfahren in der Praxis nur zu empfehlen, wenn in einer Tabelle wenige Attribute zu korrigieren sind. Hinzufügung einer Zeile

Bei einer mittleren bis hohen Anzahl an zu korrigierenden Attributen lassen sich die korrigierten Werte in einer zusätzlichen Zeile (Datensatz) speichern. Hierbei stehen wie bei dem zusätzlichen Attribut sowohl der originäre als auch der korrigierte Wert zur Verfügung. Der zusätzliche Platzbedarf ist durch die Extrazeile aber noch höher als bei der zusätzlichen Spalte, sodass sich dieses Verfahren nur bei einer geringen Anzahl zu korrigierender Zeilen empfiehlt. Ein weiterer Nachteil ist, dass einfache Aggregationen nicht mehr möglich sind. Da sowohl die korrigierten als auch die originären Werte vorhanden sind, werden bei einer einfachen Summation beide Werte verwendet. Das Problem lässt sich beheben, indem man in einem zusätzlichen Attribut die zu verwendende Zeile mit einem Flag kennzeichnet (siehe Tab. 11–1). So können auch unerfahrene Benutzer die Tabelle leichter auswerten, und das Fehlerrisiko sinkt.

Tab. 11–1

Artikel_ID

Bezeichnung

Bestand

auswertbar

100

Schlüssel, 13 mm

152

J

102

Schlüssel, 15 mm

630

J

202

Nuss, VK, 13 mm

67

N

202

Nuss, VK, 13 mm

670

J

Kennzeichnung der auswertbaren Zeilen durch ein Flag

Sind in der originären Zeile (Zeile 3) rein numerische Werte zu korrigieren, kommt eine weitere Möglichkeit (siehe Abb. 11–6) in Betracht. Es wird eine Kopie der Zeile (Zeile 4) mit den originären Werten gespeichert, wobei die numerischen Werte dort das umgekehrte Vorzeichen erhalten (also 67 statt +67). Dazu kommt dann eine Zeile (Zeile 5) mit den korrigierten Werten. Dadurch heben sich bei der Summation die Zeilen 3 und 4 gegenseitig auf, sodass nur der

11.2 Datenbereinigung

195

korrigierte Wert aus Zeile 5 verwendet wird. Das funktioniert allerdings nur bei der Summation, nicht bei anderen Aggregationsformen (z.B. Minimum, Maximum, Anzahl Zeilen). Deshalb ist dieses Verfahren für die Benutzer noch fehleranfälliger. Es ist also zu vermeiden, falls Benutzer Ad-hoc-Abfragen auf dieser Tabelle ausführen. Artikel_ID Bezeichnung

Bestand

100

Schlüssel, 13 mm

152

102

Schlüssel, 15 mm

630

202

Nuss, VK, 13 mm

67

202

Nuss, VK, 13 mm

– 67

202

Nuss, VK, 13 mm

670

fehlerhafte, originäre Zeile Kopie mit umgekehrtem Vorzeichen

korrigierte Zeile Summe Artikel_ID202: 670

Abb. 11–6

Bereinigung durch zusätzliche Zeile mit umgekehrtem Vorzeichen

Hinzufügung einer Tabelle

Sind mittelmäßig viele bis viele Attribute und Zeilen zu korrigieren, werden die zu korrigierenden Werte in der Regel in einer zusätzlichen Tabelle gespeichert. In diese kommen auch die nicht zu korrigierenden Zeilen aus der originären Tabelle. Dieses Verfahren hat den Vorteil, dass es im Gegensatz zu den anderen Verfahren universell einsetzbar ist. Der Nachteil ist wieder ein erhöhter Speicherbedarf. Erkennung und Konsolidierung von Duplikaten

Typische Beispiele für Duplikate sind in Kunden, Lieferanten oder Artikelstammdaten zu finden. Sie stellen ein großes Problem für ein Data Warehouse dar, wobei es grundsätzlich zwei Ursachen für diese Duplikatbildung gibt: Einerseits können Duplikate schon aus den Quellsystemen bei der Extraktion in das Data Warehouse gelangen, andererseits können sie auch erst durch fehlerhafte ETLProzesse oder Bereinigungen im Data Warehouse entstehen. Die Duplikate aus einem Quellsystem müssen idealerweise auch dort erkannt und konsolidiert werden, da sie in der Regel auch die Qualität im Quellsystem beeinträchtigen. Ist das Quellsystem dazu nicht in der Lage, so werden zumindest die konsolidierten Daten nach der Duplikaterkennung und -konsolidierung im Data Warehouse in das jeweilige Quellsystem zurückgeführt. Davon ausgenommen sind solche Duplikate, die erst bei der Integration im Data Warehouse aus verschiedenen Quellsystemen entstehen. Ein geeignetes Design und eine Validierung verhindern das Entstehen von Duplikaten bei den ETL-Prozessen. Jedoch gibt es in der Praxis auch die Situation, dass sich Duplikate erst während oder nach der Transformation erkennen

196

11 Standardisierung und Bereinigung

lassen. So kann man beispielsweise Artikelduplikate erst nach der Standardisierung der Artikelnummern und -bezeichnungen erkennen. Grundsätzlich sind dabei zwei Arten von Duplikaten zu unterscheiden: identische Duplikate, bei denen alle Attributwerte übereinstimmen, und nichtidentische Duplikate, bei denen ein bis mehrere Werte voneinander abweichen. Im ersten Fall ist die Erkennung trivial: Die Konsolidierung entfällt – die überzähligen Datensätze werden einfach gelöscht. Weitaus schwieriger und komplexer ist dieser Prozess bei nichtidentischen Duplikaten, da diese nicht über einen trivialen IstGleich-Vergleich aller Attributwerte (wie im ersten Fall) erkannt werden können. Alle zur Erkennung von Duplikaten eingesetzten Methoden verfolgen zwei Ziele [Leser/Naumann 2007, S. 331]: ■ Effektivität: Das Ergebnis der Duplikaterkennung muss eine hohe Qualität aufweisen, d.h., es sollten so viele Duplikate wie möglich gefunden werden. ■ Effizienz: Um die Laufzeit der Duplikaterkennung im Rahmen zu halten, muss die Anzahl der Vergleichsoperationen möglichst klein gehalten werden. Um beiden Zielen möglichst gerecht zu werden, umfasst der Prozess zur Erkennung und anschließenden Konsolidierung von Duplikaten in Anlehnung an den Prozess von Batini und Scannapieco (vgl. [Batini/Scannapieco 2006, S. 101ff.]) die folgenden vier Schritte (siehe Abb. 11–7): ■ ■ ■ ■

Vorverarbeitung der Daten, Reduzierung des Suchraums, Erkennung von Duplikaten und Konsolidierung zu einem Datensatz.

11.2 Datenbereinigung

Vorverarbeitung

197

Name

PLZ

The Data Warehouse Institute e. V.

53842

Datawarehouse Institute

53842

Kölsch Brauerei Hannes AG

50067

Autohaus Garfield OHG

53767

Holzschnitzer Huber Kfm.

50789

Name

Rechtsform

Vergleich_Name

The Data Warehouse Institute 53842

PLZ

e. V.

datawarehouseinstitute

Datawarehouse Institute

53842

Null

datawarehouseinstitute

Kölsch Brauerei Hannes

50067

AG

koelschbrauereihannes

Autohaus Garfield

53767

OHG

autohausgarfield

Holzschnitzer Huber

50789

e. K.

holzschnitzerhuber

Partitionierung Name

Rechtsform

Vergleich_Name

The Data Warehouse Institute 53842

PLZ

e. V.

datawarehouseinstitute

Datawarehouse Institute

53842

Null

datawarehouseinstitute

Autohaus Garfield

53767

OHG

autohausgarfield

Name

Rechtsform

Vergleich_Name

Kölsch Brauerei Hannes 50067

PLZ

AG

koelschbrauereihannes

Holzschnitzer Huber

e. K.

holzschnitzerhuber

50789

Erkennung Name

Rechtsform

Vergleich_Name

Ahnlich

The Data Warehouse Institute 53842

PLZ

e. V.

datawarehouseinstitute

89 %

Datawarehouse Institute

53842

Null

datawarehouseinstitute

89 %

Autohaus Garfield

53767

OHG

autohausgarfield

12 %

Name

Konsolidierung

Abb. 11–7

Rechtsform

Vergleich_Name

Kölsch Brauerei Hannes 50067

AG

koelschbrauereihannes

9%

Holzschnitzer Huber

e. K.

holzschnitzerhuber

9%

Name

PLZ 50789

PLZ

Rechtsform

Reputation

The Data Warehouse Institute 53842

e. V.

88 %

Autohaus Garfield

OHG

96 %

53767

Kölsch Brauerei Hannes

50067

AG

99 %

Holzschnitzer Huber

50789

e. K.

95 %

Prozess zur Erkennung und Konsolidierung von Duplikaten

Ahnlich

198

11 Standardisierung und Bereinigung

Vorverarbeitung der Daten

Die Vorverarbeitung der Daten legt den Grundstein für den Erfolg der nachfolgenden Schritte. Werte aus Textattributen werden einheitlich in Groß­ oder Kleinschreibung umformatiert und in einem zusätzlichen Attribut für die Vergleichsoperation gespeichert: The Data Warehouse Institute wird zu the data warehouse institute. Das eliminiert unterschiedliche Groß­/Klein­Schreibweisen von identischen Objekten, da der Vergleich von The Data Warehouse Institute mit The data warehouse Institute andernfalls keine hundertprozentige Übereinstimmung liefert. Entfernt man zusätzlich die Leerzeichen und anhand einer Stoppwortliste die Füllwörter, erhöht sich die Vergleichbarkeit weiter. In dem Beispiel wird the data warehouse institute zu datawarehouseinstitute. Weiterhin werden Umlaute und der deutsche Buchstabe ß im Text aufgelöst, z.B. wird aus dem Namen rößler ein roessler. Diakritische Zeichen (Akzente etc.) reduziert man auf den entsprechenden Buchstaben: Aus é wird ein normales e. Nun folgt die auch für andere Bereinigungen übliche weitere Standardisierung (siehe Abschnitt 11.1). Wichtig ist, dass die vorverarbeiteten Werte in einem zusätzlichen Attribut gespeichert werden. Wie das Beispiel zeigt, wird der korrekte Name The Data Warehouse Institute für den Vergleich zu datawarehouseinstitute; im Data Warehouse soll aber weiterhin der korrekte Name The Data Warehouse Institute angezeigt werden. Das schließt ein einfaches Überschreiben aus, zudem wird der Name datawarehouseinstitute nach Abschluss des Vergleichs in der Regel nicht mehr benötigt. Reduzierung des Suchraums

Um Duplikate zu erkennen, muss jeder Datensatz (Anzahl: n) einer Tabelle jeweils mit allen anderen Datensätzen (Anzahl: n–1) verglichen werden. Da zwei Tupel nur einmal miteinander verglichen werden müssen, beträgt die Anzahl der 2 insgesamt dafür notwendigen Vergleichsoperationen n 2−n . Um also eine Tabelle mit 10.000 Kundennamen zu vergleichen, sind ungefähr 10 Millionen Operationen notwendig. Soll mehr als ein Attribut verglichen werden, erhöht sich die Anzahl der Vergleichsoperationen proportional zur Anzahl der Attribute. Um die Anzahl der notwendigen Vergleichsoperationen und dadurch den Ressourcenbedarf (Rechenleistung, Laufzeit) zu minimieren, sollte man in einem vorgelagerten Schritt den erforderlichen Suchraum reduzieren, d.h. die Datensätze partitionieren. Der gesamte Suchraum wird in geeignete Partitionen unterteilt, sodass in einer Partition alle möglichen Duplikate zusammengefasst und die anderen Datensätze ausgeschlossen werden. Eine Reduzierung des Suchraums lässt sich insbesondere durch zwei unterschiedliche Methoden erreichen (vgl. [Batini/Scannapieco 2006, S. 104]): ■ Blocking ■ Sorted-Neighbourhood-Methode

11.2 Datenbereinigung

199

Blocking-Methoden partitionieren die Datensätze in disjunkte Teilmengen. Für den Erfolg entscheidend ist daher die optimale Wahl von differenzierenden Partitionierungsschlüsseln und ­einteilungen. Als Partitionierungsschlüssel wird ein Attribut oder eine Kombination aus mehreren Attributen gewählt, mit denen potenzielle Duplikate in Gruppen (Partitionen) eingeteilt werden können. Innerhalb einer Partition befinden sich alle Datensätze, die potenziell gleich sein können. In den anderen Partitionen sind hingegen mit hoher Wahrscheinlichkeit keine potenziellen Duplikate enthalten. Ein denkbarer Partionierungsschlüssel für Adressaten ist die Postleitzahl. Die Partionierungseinteilung legt die Schwellwerte der Partitionen fest. In dem Beispiel ist eine Einteilung anhand der ersten beiden Stellen der Postleitzahl denkbar: Alle Adressdaten mit den gleichen Ziffern am Anfang der Postleitzahl kommen in die gleiche Gruppe. In der Praxis ist es für das Projektteam oft schwierig bis unmöglich, die Schlüssel und deren Einteilung festzulegen. Hinzu kommt, dass gerade aufgrund der Partitionierung auch Duplikate unerkannt bleiben. In Abbildung 11–8 ist zu erkennen, dass die Partitionierung der Adressdaten anhand der ersten Ziffer der Postleitzahl erfolgt. Obwohl es sich bei den zwei Datensätzen zum Kunden Meier offensichtlich um Duplikate (mit einem Zahlendreher in der Postleitzahl) handelt, werden diese in zwei unterschiedliche Partitionen aufgeteilt. Damit wird es in den nachfolgenden Vergleichsoperationen unmöglich, diese Duplikate zu erkennen. Der Grund hierfür ist, dass der Vergleich ausschließlich innerhalb einer Partition erfolgt. Mit der Anzahl der Partitionen steigt in der Regel die Gefahr von dadurch unerkannten Duplikaten, dafür sinkt der Ressourcenverbrauch für die Vergleichsoperationen. Will man erfolgreich sein, muss man die richtige Balance einhalten. Das Problem lässt sich auch lösen, indem man eine Duplikaterkennung über den Gesamtbestand nachschaltet. Dazu werden im ersten Schritt die Datensätze partitioniert, innerhalb der Partitionen verglichen, die überzähligen Duplikate werden entfernt (und damit die Anzahl der Datensätze reduziert) und anschließend zu einem (kleineren) Gesamtbestand zusammengeführt. Über diesen Gesamtbestand wird dann in einem zweiten Schritt die Duplikaterkennung wiederholt. Wurden Duplikate zunächst in verschiedene Partitionen aufgeteilt und dadurch nicht erkannt, können diese anschließend im Gesamtbestand sicher identifiziert werden. Da der Gesamtdatenbestand durch die Duplikaterkennung im ersten Schritt bereits reduziert wurde, ist der Ressourcenverbrauch im zweiten Schritt im Vergleich zu einem Prozess ohne Schritt 1 geringer. Insgesamt betrachtet sinkt die Gefahr unerkannter Duplikate auf Kosten eines erhöhten Ressourcenverbrauchs.

200

Name

11 Standardisierung und Bereinigung

Name

Postleitzahl Ort

Telefon

Meier

53894

Mechernich

02256/99564

Meier

35894

Mechernich

02256/99564

Schmitz

37077

Göttingen

0551/234547

Krüger

53840

Troisdorf

02241/32936

Postleitzahl Ort

Telefon

Name

Postleitzahl Ort

Telefon

Meier

53894

Mechernich

02256/99564

Meier

35894

Mechernich

02256/99564

Krüger

53840

Troisdorf

02241/32936

Schmitz

37077

Göttingen

0551/234547

Vergleich

Abb. 11–8

Vergleich

Durch Partitionierung unerkannte Duplikate (Beispiel)

Eine Möglichkeit, die Unzulänglichkeiten der vorgestellten Partitionierungsmethode zumindest teilweise zu vermeiden, ist der Einsatz der Sorted­Neighborhood­Methode. Bei der Sortierten Nachbarschaft ([Hernandéz/Stolfo 1995, S. 127ff.] und [Hernandéz/Stolfo 1998, S. 11ff.]) wird anhand eines definierten Schlüssels sortiert, der aber weder eindeutig sein noch für die Ähnlichkeitsmetrik verwendet werden muss. Nachdem der Schlüssel für alle Datensätze berechnet ist, wird iterativ ein Fenster der Größe g über die anhand dieses Schlüssels sortierten Datensätze geschoben. Innerhalb dieses Fensters werden die darin enthaltenen Datensätze paarweise mithilfe der Vergleichsfunktion analysiert; anschließend wird anhand des Ergebnisses entschieden, ob es sich um Duplikate handelt oder nicht. In dem Beispiel aus Abbildung 11–9 wird die Sortierte Nachbarschaft auf die Datensätze von Mitarbeitern angewendet. Das Fenster hat die Größe g = 3, der Schlüssel für die Sortierung wird gebildet aus den ersten drei Buchstaben des Namens, den ersten drei Buchstaben des Vornamens und den ersten drei Ziffern der Personalnummer. Im ersten Schritt werden die ersten beiden Paare KRÜNOR737 und MEICHR100 miteinander verglichen, im zweiten die Paare MEICHR100 und MEICHR553. Wie man durch den Vergleich der Attribute sieht, handelt es sich beim zweiten Paar um Duplikate. Diese liegen wie erwartet in der sortierten Liste direkt nebeneinander.

11.2 Datenbereinigung

201

Personal_Nr

Name

Vorname

Ort

Telefon

Schlüssel

73721

Krüger

Norbert

Troisdorf

02241/32936

KRÜNOR737

Block, 10007 g=3

Meier

Christian

Mechernich

02256/99564

MEICHR100

55364

Meier

Chris

Mechernich

02256/99564

MEICHR553

37564

Schmitz

Peter

Göttingen

0551/234547

SCHPET375

…

…

…

…

…

–

Abb. 11–9

1. Vergleich 2 . Vergleich

Sortierte Nachbarschaft (Beispiel)

Die Güte der Sorted­Neighborhood­Methode hängt im Wesentlichen von zwei Faktoren ab: ■ der richtigen Wahl des Schlüssels: Wie bei der Partitionierung steht und fällt der Erfolg dieses Verfahrens mit der Wahl des richtigen Schlüssels, da nur direkt nebeneinander liegende Duplikate erkannt werden können. ■ der ausgewählten Fenstergröße: Untersuchungen haben gezeigt, dass Fenstergrößen von 20 ausreichen, um eine vernünftige Qualität bei der Duplikaterkennung zu gewährleisten. Eine Verbesserung der Methode bietet das Multipass­Verfahren, bei dem die Sortierte Nachbarschaft mit verschiedenen Schlüsseln mit einer relativ kleinen Blockgröße mehrfach angewendet wird. Bei jeder Anwendung werden die Datensätze anhand des jeweiligen Schlüssels sortiert, miteinander verglichen und Gruppen mit direkten Duplikaten werden gebildet. Aus den Ergebnissen wird anschließend die transitive Hülle3 gebildet, die neben den direkten Duplikaten innerhalb einer Sortierten Nachbarschaft auch die indirekten Duplikate aus den anderen Läufen enthält. In dem Beispiel aus Abbildung 11–10 erfolgt im ersten Schritt eine Sortierung der Datensätze anhand eines Schlüssels, der aus den jeweils ersten drei Zeichen der Attributwerte für Name, Vorname und Personalnummer gebildet wurde. Die Datensätze zu Personalnummer 10007 und 55364 liegen bei der Sortierung nach diesem Schlüssel nebeneinander und werden als direkte Duplikate erkannt. Im zweiten Schritt werden die Datensätze mithilfe eines Schlüssels sortiert, der aus den ersten vier Zeichen der Personalnummer besteht. In diesem Fall liegen die Datensätze zu den Personalnummern 55364 und 55365 nebeneinander und werden im Vergleich als direkte Duplikate identifiziert. Die transitive Hülle wird anschließend im dritten Schritt gebildet: Die Duplikate aus Schritt 1 und 2 werden zusammengefasst, der Datensatz zur Personalnummer 55365 ist damit ein indirektes Duplikat zu dem Datensatz mit der Personalnummer 10007, obwohl dieser Zusammenhang im Schritt 1 aufgrund des dabei verwendeten Schlüssels nicht erkannt wurde.

3.

Erweiterung einer Relation, enthält neben den direkt erreichbaren zusätzlich alle indirekt erreichbaren Paare

202

11 Standardisierung und Bereinigung

1. Sortierte Nachbarschaft: Schlüssel aus Name, Vorname und Personal-Nr. 1. (jeweils die ersten drei Zeichen) Personal_Nr 73721

Name

Vorname

Ort

Telefon

Schlüssel

Krüger

Norbert

Troisdorf

02241/32936

KRÜNOR737

Block, 10007 g=3

Meier

Christian

Mechernich

02256/99564

MEICHR100

55364

Meier

Chris

Mechernich

02256/99564

MEICHR553

…

…

…

…

…

–

1. Vergleich 2. Vergleich

Duplikate 10007

Meier

Christian

Mechernich

02256/99564

MEICHR100

55364

Meier

Chris

Mechernich

02256/99564

MEICHR553

2. Sortierte Nachbarschaft: Schlüssel aus Personal-Nr. (die ersten vier Zeichen) Personal_Nr

Name

Vorname

Ort

Telefon

Schlüssel

55363

Lux

Jürgen

Düsseldorf

0211/556230

5536

55364

Meier

Chris

Mechernich

02256/99564

5536

Block, 55365 g=3

eMier

Christian

Mechernich

02256/99564

5536

73721

Krüger

Norbert

Troisdorf

02241/32936

7372

…

…

…

…

…

…

1. Vergleich 2. Vergleich

Duplikate 55364

Meier

Chris

Mechernich

02256/99564

5536

55365

eMier

Christian

Mechernich

02256/99564

5536

3. Transitive Hülle (Multipass-Verfahren) 10007

Meier

Christian

Mechernich

02256/99564

55365

Meier

Chris

Mechernich

02256/99564

55365

eMier

Christian

Mechernich

02256/99564

Abb. 11–10

Direkte und indirekte Duplikate

Beispiel für das Multipass-Verfahren

Einen Vergleich der hier dargestellten Blocking- und Sorted-Neighbourhood-Verfahren findet sich in [Draisbach 2012, S. 41ff.]. Erkennung von Duplikaten

Für die Erkennung von Duplikaten müssen die einzelnen Datensätze zunächst paarweise miteinander verglichen werden. Anschließend wird entschieden, ob es sich dabei um Duplikate handelt (siehe Abb. 11–11). Die Grundlagen für diesen Prozess gehen auf das abstrakte Modell von Fellegi und Sunter [Fellegi/Sunter 1969] zurück, in dem die verschiedenen Ansätze verallgemeinert wurden. Werden zwei Mengen (A, B) von Datensätzen zu der gemeinsamen Menge AB zusammengeführt, so existieren die zwei Mengen M (Menge der Duplikate) und U (Menge der Nicht­Duplikate).

11.2 Datenbereinigung

203

Um die Duplikate zu bestimmen, muss man zunächst einen Vergleichsraum definieren, der durch vorab festgelegte Kriterien aufgespannt wird. Beispiel: »Die Artikelgruppe stimmt überein«, »Die Artikelnummer weicht maximal um den Wert 100 ab« und »Die Artikelbezeichnung ist ähnlich«. Die Ähnlichkeit der Datensätze setzt sich aus der Ähnlichkeit der einzelnen Attribute zusammen, wobei eine Gewichtung der Attribute möglich ist. Mithilfe einer beliebigen Vergleichsfunktion werden für jedes Tupel (a, b) die zumeist domänenabhängigen Kriterien bewertet. a

Artikel_Nr

Artikel_Gruppe

Artikelbezeichnung

100

1

DIN 933 – M 10 x 20

101

2

DIN 1587 – M 10 x 18

b

Vergleichsfunktion

»Die Artikelgruppe stimmt überein« »Die Artikelgruppe weicht maximal um den Wert 100 ab« »Die Artikelgruppe ist ähnlich«

Duplikate

Entscheidungsfunktion

100

1

DIN 933 – M 10 x 20

101

2

DIN 1587 – M 10 x 18

Nicht-Duplikate

nicht klassifizierbar

Abb. 11–11

Vergleichsfunktion zur Bestimmung von Duplikaten (Beispiel)

Anschließend wertet eine Entscheidungsfunktion e (v) die Ergebnisse der Vergleichsfunktion v (a, b) aus und klassifiziert die Tupel (a, b) nach zwei Schwellwerten in drei Mengen: Duplikate (M), Nicht­Duplikate (U) und nicht eindeutig klassifizierbare Tupel (MU):

e(v) =

M, falls v(a,b) > oberer Schwellwert soben U, falls v(a,b) < unterer Schwellwert sunten MU, falls sunten ≥ v(a,b) ≤ soben

204

11 Standardisierung und Bereinigung

Häufig wird in der Praxis auf die Menge MU verzichtet, dadurch existiert in diesen Fällen nur ein Schwellwert s. Der Verzicht auf die Menge MU hat einen entscheidenden Nachteil: Die Datensätze in der Grauzone zwischen Duplikaten und Nicht­Duplikaten können nachfolgend nicht identifiziert werden und verschmelzen mit der Menge der eindeutigen Nicht­Duplikate. Oft lohnt es sich aber, durch eine weitere Nachverarbeitung diese nicht klassifizierbaren Datensätze noch genauer zu untersuchen (z.B. durch manuelle Inaugenscheinnahme durch einen Sachbearbeiter). Dadurch kann die Menge an richtig erkannten Datensätzen weiter vergrößert werden. Würde man diese Datensätze hingegen in eine Menge mit den eindeutigen Nicht­Duplikaten einordnen, wäre der für eine solche Nachbearbeitung nötige Aufwand größer, insbesondere weil dann auch diese offensichtlichen Nicht­Duplikate wiederholt mit analysiert werden müssten. Deshalb wird neben der qualitativen Mengenzuordnung (M, U, MU) auch immer das quantitative, normierte Ergebnis der Vergleichsfunktion (0 = NichtDuplikat bis 1 = Duplikat) zur Angabe des Grades der Übereinstimmung gespeichert. Anhand dieser Kennzahl können die nachfolgenden Prozesse noch spezifischer gesteuert werden, indem z.B. Tupel aus der Menge MU absteigend sortiert den Sachbearbeitern zur manuellen Überprüfung zugeordnet werden. Die Genauigkeit der Duplikaterkennung hängt von der richtigen Wahl der Schwellwerte ab, jedenfalls sofern es richtig ist, dass die Vergleichsfunktion mit der Wahrscheinlichkeit korreliert, dass die Tupel Duplikate sind. Ist der Schwellwert soben zu hoch, werden nicht alle Duplikate erkannt (Sensitivität = niedrig), fast alle erkannten Duplikate sind aber tatsächlich auch Duplikate (Spezifität = hoch). Ist der Schwellwert zu niedrig, werden fast alle Duplikate gefunden (Sensitivität = hoch), viele Duplikate sind aber keine (Spezifität = niedrig). Aus diesem Grunde sollte man die Genauigkeit der Duplikaterkennung über die genannten Kennzahlen Sensitivität und Spezifität testen und bewerten. Dazu wird ein Testdatenbestand für die automatisierte Duplikaterkennung verwendet. Anschließend analysieren die fachlichen Experten diesen Datenbestand genau und identifizieren die Duplikate. Nun vergleicht das Team deren Ergebnisse mit denen aus der Duplikaterkennung (siehe Abb. 11–12). Expertenanalyse

Duplikaterkennung

Abb. 11–12

Duplikat

Nicht-Duplikat

Duplikat

richtig-positiv (RP)

falsch-positiv (FP)

Nicht-Duplikat

falsch-negativ (FN)

richtig-negativ (RN)

Bewertungsmaßstab zur Genauigkeit der Duplikaterkennung

11.2 Datenbereinigung

205

Die Spezifität und die Sensitivität errechnen sich aus den Formeln:4

Spezifität =

RP RP ; Sensitivität = (RP + FP) (RP + FN)

Beispiel: In einem Testdatenbestand mit 10.000 Datensätzen wurden durch die Duplikaterkennung 95 (= RP) der 100 (= RP + FN) von den Experten klassifizierten Duplikate gefunden, 15 der gefundenen Duplikate (= FP) waren keine und fünf Duplikate (FN) wurden nicht gefunden. Daraus ergibt sich eine Spezifität 95 ~ ~ 86 % und eine Sensitivität von = 95 %. = von (9595 (95 + 5) + 15) Eine hohe Spezifität bedeutet, dass zwei Datensätze nur bei sehr großer Ähnlichkeit als Duplikate ausgewiesen werden. Dies kann zur Folge haben, dass echte Duplikate nicht als solche erkannt werden, da sie nicht »ähnlich« genug sind. Bei einer hohen Sensitivität werden relativ viele Datensätze als Duplikate erkannt, auch solche, die möglicherweise gar keine sind. Um dieses abstrakte Modell in der Praxis umzusetzen, benötigt man Vergleichs- und Entscheidungsfunktionen sowie die darin verwendeten Ähnlichkeitsmetriken. Ähnlichkeitsmetriken

Nach dem Modell von Fellegi und Sunter verwendet die Vergleichsfunktion vorab festgelegte Kriterien. Hierfür wird neben der Äquivalenz (semantische Gleichheit) die Ähnlichkeit zweier Datensätze verwendet, die durch den Grad der lexikalischen und syntaktischen Gleichheit bestimmt wird. Die Ähnlichkeitsmetrik ist eine Funktion, die für beliebige Datensätze a und b die Ähnlichkeit berechnet. Das Ergebnis ist eine reelle Zahl zwischen 0 (keine Ähnlichkeit) und 1 (völlige Gleichheit). In der Praxis werden für die Berechnung mehrere Attribute der Datensätze verwendet, sodass diese Attribute einzeln gewichtet werden. So besitzt z.B. die Artikelnummer als starker Indikator für die Ähnlichkeit in der Regel eine höhere Gewichtung als die Artikelgruppe. Die Attribute sollten so gewichtet sein, dass sie in der Summe 100 Prozent ergeben. Für die erfolgreiche Duplikaterkennung ist es entscheidend, welcher Algorithmus bzw. welche Ähnlichkeitsmetrik zum Vergleich der Attribute herangezogen wird. In den meisten Fällen führt eine einzelne Metrik nicht zu einem optimalen Ergebnis − erfolgversprechender ist, die unterschiedlichen Metriken zu kombinieren [Leser/Naumann 2007, S. 334f.]:

4.

In der Literatur wird Spezifität als Precision und Sensitivität als Recall bezeichnet.

206

11 Standardisierung und Bereinigung

■ Datentyp: Metriken für Zeichenketten, Zahlen oder Datumsangaben sind unterschiedlich. Die meisten Metriken gelten für alphanumerische Textattribute, nur wenige eignen sich für numerische Zahlenwerte. ■ Sprache: Abhängig von der jeweiligen Sprache müssen länder­ und sprachspezifische Eigenheiten berücksichtigt werden. Ähnlichkeitsmetriken für Zeichenketten

Für Textattribute gibt es sehr viele Ähnlichkeitsmetriken, weshalb im Folgenden nur ein kleiner Ausschnitt exemplarisch vorgestellt wird. Abbildung 11–13 gibt eine Übersicht über die verschiedenen Ansätze. Ähnlichkeitsbestimmung

phonetisch Kölner Phonetik

Soundex

Edit-basiert

Levenshtein

Typewriter

DamerauLevenshtein

Jaro-Winkler

Token-basiert JaccardÄhnlichkeit

TFIDF

Smith-Waterman

Abb. 11–13

Übersicht der Ansätze zur Ähnlichkeitsbestimmung für textuelle Attribute

Bei den phonetischen Metriken wird die Ähnlichkeit über die Distanz bei der Aussprache des Textes bestimmt. Somit eignen sich diese Metriken nur für Attribute, die über das Gehör aufgenommen und dann eingegeben wurden. Tippfehler lassen sich damit nicht bewerten. Der Text wird zunächst in seine Wörter zerlegt und jedes Wort entsprechend seiner Aussprache codiert. Die Eingabe in den phonetischen Algorithmus ist eine Zeichenkette mit ihrer orthografischen Repräsentation. Ausgegeben wird üblicherweise ein Code, der aus Ziffern und/oder Buchstaben besteht. Diese Ziffern entsprechen phonetischen Gruppierungen, die sich an den Aussprachemöglichkeiten orientieren. Abschließend wird die Distanz zwischen den einzelnen Codes berechnet. Speziell für den englischen Sprachbereich wurden die Algorithmen Soundex, Phonix und Metaphone entwickelt. Sehr verbreitet ist der Soundex­Algorithmus [Russel 1918], der für jedes Wort einen Code aus dem Anfangsbuchstaben und genau drei Ziffern bildet.5 Außer beim ersten Zeichen werden die Vokale A, E, I, 5.

Soundex wurde von Russell für die Indizierung der Familiennamen der Volkszählung in den USA entwickelt und 1918 patentiert.

11.2 Datenbereinigung

207

O, U sowie die Umlaute Ä, Ö, Ü ignoriert, aus dem ß wird ein einfaches S. Gleiches gilt für die Konsonanten H, W und Y, sie werden ebenfalls ignoriert. Gibt die zu codierende Zeichenkette keine drei Ziffern zurück, wird mit Nullen aufgefüllt. Ergeben sich mehr als drei Ziffern, werden die überzähligen gelöscht. Beispiel: Für Christine und Christiane ergibt sich der gleiche Code C623. Hauptkritikpunkte an dem Soundex­Algorithmus sind einerseits die starke Englischlastigkeit sowie die starke Abhängigkeit vom ersten Buchstaben (Coffein = C150, Koffein = K150), denn damit können Zeichenketten mit unterschiedlichen Anfangsbuchstaben nicht mehr als gleiche bzw. sehr ähnliche Zeichenkette erkannt werden.6 Ein auf die deutsche Sprache abgestimmter und feinerer Algorithmus ist die Kölner Phonetik [Postel 1969]. Es handelt sich hierbei um einen frühen Ansatz, den Soundex-Algorithmus an die deutsche Sprache anzupassen, daher erfolgt auch hier eine Zuordnung auf Ziffern und Buchstaben (vgl. Tab. 11–2). Buchstabe

Kontext

Code

A, E, I, J, O, U, Y

0

H

–

B P

nicht vor H

D, T

nicht vor C, S, Z

F, V, W P

1 2 3

vor H

G, K, Q C

im Anlaut vor A, H, K, L, O, Q, R, U, X

X

nicht nach C, K, Q

L

5

M, N

6

R

7

S, Z nach S, Z C

im Anlaut außer vor A, H, K, L, O, Q, R, U, X nicht vor A, H, K, O, Q, U, X

D, T

vor C, S, Z

X

nach C, K, Q

Tab. 11–2

6.

8

Ersetzungsregeln der Kölner Phonetik

Stark zur Verbreitung des Algorithmus hat die Tatsache beigetragen, dass für die Datenbank Oracle bereits sehr früh ein entsprechender PL/SQL-Standardbefehl entwickelt wurde.

208

11 Standardisierung und Bereinigung

Für die Namen Hoffmann und Heppenheimer ergibt der Soundex­Algorithmus den gleichen Code H155, die Kölner Phonetik ergibt hingegen die zwei unterschiedlichen Codes 036 und 0167. Ein weiterer Ansatz für eine phonetische Suche im Deutschen ist Phonet [Michael 1999]. Die Zeichenkette wird durch ca. 650 phonetisch motivierte Ersetzungsregeln so umgewandelt, dass gleich klingende Wörter auf dieselbe Zeichenkette abgebildet werden. Insbesondere versucht der Algorithmus, der Bedeutung der Vokale im Deutschen Rechnung zu tragen. Edit­basierte Ähnlichkeitsmetriken vergleichen zwei Zeichenketten buchstabenweise. Je ähnlicher sich die Zeichenketten in Bezug auf die Anordnung der Buchstaben sind, desto höher ist die Gesamtähnlichkeit. Man versucht also, die »Entfernung« einer Zeichenkette zu einer Vergleichskette über ein sogenanntes Distanzmaß zu ermitteln. Der Editierabstand (oder Edit-Distanz) besagt, wie viele Operationen (Edits) mindestens notwendig sind, um eine Zeichenkette in eine andere zu überführen. Damit lassen sich nur einzelne Wörter bewerten, nicht längere Texte. Hierbei würden unterschiedliche Reihenfolgen im Text (z.B. »Schraube, Schlitz« und »Schlitzschraube«) zu unrealistischen Werten führen. Es existieren viele unterschiedliche Algorithmen zum Editierabstand. In der Praxis setzt man häufig auf die Levenshtein­Distanz [Levenshtein 1966, S. 845ff.], die die Operationen Ersetzen, Einfügen und Löschen von Textzeichen berücksichtigt. Beispiel: Die Levenshtein­Distanz zwischen Vier und Vor beträgt 2. Die erste Operation ersetzt das i durch ein o (= Voer) und die zweite löscht das e (= Vor). Um die eingangs erwähnte reelle Zahl zwischen 0 und 1 zu bekommen, wird die errechnete Distanz d wir folgt normiert:

ds1, s2 = 1 -

Σa |s1|

a = Operation sn = Zeichenkette n |sn| = Länge der Zeichenkette n Somit ergibt sich anhand des obigen Beispiels folgender Wert:

ds1, s2 = 1 -

2 = 0,5 4

Nachteile dieses Verfahrens sind die fehlende Möglichkeit zur Gewichtung der Operationen, die sehr großen Distanzen bei Abkürzungen (Distanz = 6 zwischen Prof. und Professor) und das Fehlen der Operation zum Vertauschen von zwei Textzeichen. Da in der Praxis aber häufig Buchstaben bei der Eingabe vertauscht werden, würde sich durch die zugehörige Operation die Distanz auf ein realistisches Maß halbieren.

11.2 Datenbereinigung

209

Diese Unzulänglichkeit (Tippfehler durch Buchstabendreher aufgrund falscher Tastenanschläge auf der Tastatur) versucht die »Typewriter­Distanz« (auch Schreibmaschinendistanz genannt) auszugleichen, indem das Ersetzen von Zeichen, die auf einer »QWERTZ«­Tastatur dicht nebeneinander liegen, geringer bewertet wird [Helmis/Hollmann 2009, S. 129]. So ist beispielsweise die Distanz zwischen den Zeichen »s« und »d« geringer als die Distanz zwischen »w« und »k«. Die sogenannte Damerau-Levenshtein-Distanz nimmt sich ebenfalls der Zeichendreher an und erweitert die möglichen Operationen um das Vertauschen. Dadurch reduziert sich der Abstand, um eine Zeichenkette in eine andere zu überführen. Für das Vertauschen von zwei Zeichen sind bei Levenshtein zwei Operationen notwendig, während beim Damerau-Levenshtein-Algorithmus nur eine Operation gebraucht wird [Damerau 1964, S. 171ff.]. Eine weitere Variante der Edit-Distanz ist z.B. der Smith-Waterman-Algorithmus. Er kommt insbesondere dann zum Einsatz, wenn sich ganze Teilstücke einer Zeichenkette unterscheiden: Ein Teilstück der einen Zeichenkette ist das Präfix der anderen Zeichenkette (»Prof. Peter Schmidt« vs. »Peter Schmidt«). Die unterschiedlichen Distanzen resultieren aus der Tatsache, dass bei Levenshtein jedes Zeichen einzeln bewertet wird, während bei Smith-Waterman das Teilstück als Ganzes bewertet wird (vgl. [Smith/Waterman 2001], [Naumann/Herschel 2010, S. 31f.]). Bei der Jaro-Winkler-Distanz werden nicht nur die Operationen bei der Transformation der übereinstimmenden Zeichen gezählt, sondern auch die Übereinstimmungen sowie Unterschiede beider Zeichenketten als Anteile zueinander in Beziehung gesetzt. Um die Jaro-Winkler-Distanz zu berechnen, beginnt man bei der Jaro-Metrik dj:

dj =

1 cs1, s2 cs2, s1 cs1, s2 - t + + 3 |s1| |s2| cs1, s2

cs1,s2 = Anzahl der Zeichen aus s1, die auch in s2 vorkommen. Dabei werden nur die Zeichen gezählt, die nicht weiter als die Hälfte des kürzeren Zeichenkette entfernt sind (abgerundet auf eine ganze Zahl). sn = Zeichenkette n |sn| = Länge der Zeichenkette n t = Anzahl der identischen Zeichen, die nicht an der gleichen Position stehen. Der Wert wird durch 2 geteilt und auf eine ganze Zahl abgerundet. Diese Metrik wird anschließend zur Berechnung der Jaro-Winkler-Distanz dw verwendet:

dw = dj + lp(1 - dj) dj = Jaro-Metrik l = Länge des übereinstimmenden Präfix bis maximal zur Länge 4 p = konstanter Faktor (üblicherweise 0,1)

210

11 Standardisierung und Bereinigung

Am Beispiel der beiden Zeichenketten MATRIX und MAGISTER ergibt sich folgende Distanz:

dj =

1 4 4 4-1 + + = 0,639 3 6 8 4

Wie bereits angesprochen, ist der Editierabstand nicht für Texte, d.h. Zeichenketten mit mehreren Wörtern, geeignet. Um diesen Nachteil auszugleichen, werden die Zeichenketten erst in Wörter (auch Token genannt) zerlegt. Anschließend wird geprüft, welche und wie viele Token die beiden zu vergleichenden Zeichenketten gemeinsam haben. Diese Token­basierten Ähnlichkeitsmetriken sind z.B. für Beschreibungen gut geeignet. Für die Aufteilung der Zeichenketten in einzelne Token gibt es verschiedene Möglichkeiten. Eine Alternative besteht darin, den Text an vorgegebenen Trennzeichen (wie z.B. Leerzeichen, Satzzeichen oder Sonderzeichen) aufzuteilen. Oftmals kommen diese Zeichen jedoch in bestimmten Eigennamen selbst vor (z.B. .NET), sodass diese Variante sehr fehleranfällig sein kann [Leser/Naumann 2007, S. 339ff.]. Eine bessere Alternative sind die n­Gramme. Hierbei werden die Textwerte jeweils in n Teile aufgetrennt und die Ähnlichkeit anhand der gemeinsamen Teile bestimmt. In dem Beispiel aus Abbildung 11–14 wird die Ähnlichkeit der Textwerte Periode und Peroide anhand der weit verbreiteten Bi­Gramme (n = 2) bestimmt. Von den insgesamt neun verschiedenen Bi­Grammen (Pe, er, ri, io, od, de, ro, oi, id) aus beiden Texten haben diese drei gemeinsam (Pe, er, de), daraus ergibt sich eine Ähnlichkeit von 1/3. »Periode«

Pe, er, ri, io, od, de Ähnlichkeit: 3/9 = 1/3

n=2 »Periode«

Abb. 11–14

Pe, er, ro, oi, id, de

Ähnlichkeit von Bi-Grammen (Beispiel)

Eine Erweiterung der n­Gramme sind die q­Gramme, bei denen die gemeinsamen Teile auch noch an der gleichen Position liegen müssen. Oft wird für Token­basierte Ähnlichkeitsmaße die sogenannte Jaccard­Ähnlichkeit verwendet. Sie vergleicht die Token mit den gemeinsamen Eigenschaften mit der Anzahl aller erzeugten Token der Zeichenketten [Leser/Naumann 2007, S. 339]:

11.2 Datenbereinigung

Jaccard - Ähnlichkeit (s1, s2) =

211

|T1 ∩ T2| |T1 ∪ T2|

sn = Zeichenkette n Tn = Token n Darüber hinaus gibt es ein Verfahren, das unter dem Namen TFIDF7 bekannt ist. Hierbei bekommt jedes Token in einer Zeichenkette ein Gewicht, das von seiner Häufigkeit in der untersuchten Zeichenkette und seiner Häufigkeit in allen Zeichenketten abhängt [Baeza­Yates/Ribeiro­Neto 1999, S. 29]. Um Abkürzungen zu vergleichen, bietet sich der einfache Rekursive FeldAbgleich­Algorithmus [Monge/Elkan 1996] an. Hierbei wird der Grad der Übereinstimmung zweier Textwerte berechnet: Er ist 1, wenn beide Textfelder identisch sind oder der eine Wert eine Abkürzung des anderen Werts ist; in allen anderen Fällen ist der Wert 0. Um festzustellen, dass ein Wert die Abkürzung des anderen Werts ist, werden folgende drei Muster geprüft: ■ Die Abkürzung ist ein Präfix der Langform, z.B. D für Deutschland. ■ Die Abkürzung ist eine Kombination aus einem Präfix und einem Suffix der Langform. Beispiel: Hr für Herr. ■ Die Abkürzung ist zusammengesetzt aus den Präfixen der einzelnen Textbestandteile (durch Leerzeichen getrennt), ein Beispiel hierzu ist TDWI für The Data Warehouse Institute. In der Abkürzung müssen nicht die Präfixe aller Textbestandteile enthalten sein, möglich wäre auch DIN für Deutsches Institut für Normung. Mit diesem Algorithmus lassen sich aber keine Abkürzungen erkennen, die nicht aus Prä­ oder Suffixen bestehen (Beispiel: Hbf für Hauptbahnhof), oder wenn in der Langform die Wortreihenfolge vertauscht wurde. Wer Textwerte aus mehreren Wörtern miteinander vergleichen und die Ähnlichkeit bestimmen möchte, kann dazu die Word­based Heterogeneous Information Retrieval Logic (WHIRL) [Cohen 1998] verwenden. Die Reihenfolge der Wörter spielt in diesem Falle im Gegensatz zu den anderen vorgestellten Algorithmen keine Rolle. Wie bei der Dokumentklassifikation beim Text­Mining wird bei WHIRL die Häufigkeit des Vorkommens einzelner Wörter (oder Wortstämme) gezählt, wobei die Wörter unterschiedlich gewichtet werden: Häufig in den Textwerten vorkommende Wörter enthalten eine geringere Gewichtung als seltenere. Die Ähnlichkeit der daraus resultierenden Dokumentenvektoren steigt, je mehr hoch gewichtete Wörter in beiden Vektoren gemeinsam enthalten sind. Die Ähnlichkeit zwischen nominal skalierten8 Werten (z.B. Affe und Schimpanse) lässt sich mit keiner der bisher vorgestellten Metriken korrekt berechnen, 7. 8.

TFIDF steht für »term-frequency/inverse-document-frequency«. diskrete Werte nach ungeordneter Werteskala ohne festen Nullpunkt (z.B. Farbe)

212

11 Standardisierung und Bereinigung

da diese Werte keine lexikalischen oder syntaktischen Ähnlichkeiten besitzen. Hierzu werden beispielsweise ontologiebasierte Ähnlichkeitsmetriken [Kedad/ Métais 2002] eingesetzt. Eine Ontologie ist ein domänenspezifisches Begriffsmodell mit logischen Beziehungen. Abbildung 11–15 zeigt eine Ontologie für Säugetiere, zwischen den einzelnen Begriffen besteht eine logische Subtyp­Beziehung. Säugetiere

Affen

Schimpansen

Abb. 11–15

Gorillas

Orang-Utans

Hunde

Gibbons

Doggen

…

Beispiel für eine Ontologie

Für jeden Begriff wird eine Klasse gebildet, die aus dem Begriff selbst und allen darunterliegenden Kindknoten besteht. Die Klasse für Affen enthält z.B. die Begriffe Affen, Schimpansen, Gorillas, Orang-Utans und Gibbons. Zwei Begriffe sind ähnlich, wenn sie der gleichen Klasse angehören. In dem Beispiel sind demnach die Begriffe Affe und Schimpanse ähnlich, Doggen und Gibbons hingegen nicht. Ähnlichkeitsmetriken für numerische Werte

Für Attribute mit numerischen Werten existieren kaum Ähnlichkeitsmetriken. Für kardinalskalierte9 Werte kann man relativ einfach den Abstand zwischen zwei Werten berechnen: Je geringer der Abstand, desto ähnlicher die Werte. Oder man verwendet den Hamming­Abstand [Hamming 1950], bei dem beide Werte in eine binäre Form überführt, diese Bit für Bit verglichen und die unterschiedlichen Stellen gezählt werden. Für nominalskalierte, numerische Werte (z.B. Umsatzsteuernummer, Telefonnummer) sind diese Metriken nicht geeignet; eine denkbare Alternative hierzu sind die ontologiebasierten Ähnlichkeitsmetriken (siehe voriger Abschnitt). Wegen der eingeschränkten Auswahl an Ähnlichkeitsmetriken konvertiert man in den meisten Fällen die numerischen Werte in Textwerte und verwendet die dazu passenden Ähnlichkeitsmetriken. Duplikate konsolidieren

Sind die Duplikate erkannt, werden diese anschließend konsolidiert. Die Konsolidierung weicht in einigen Punkten von der Bereinigung anderer Datenfehler 9.

stetige Werte nach objektiver, geordneter Werteskala mit festem Nullpunkt (z.B. Kosten)

11.2 Datenbereinigung

213

(siehe S. 191) ab, da nicht nur die überzähligen Datensätze eliminiert, sondern auch die Informationen aus den Duplikaten zusammengeführt werden. Nur wenn die Duplikate vollständig identisch sind (gleiche Attribute, gleiche Attributwerte), kann man sie einfach löschen, da ansonsten Informationen verloren gehen. Bei der Zusammenführung der Informationen unterscheidet man grundsätzlich drei Fälle: Im ersten Fall besitzen die Duplikate die gleichen Attribute und die gleichen Attributwerte. Im zweiten Fall haben sie eine unterschiedliche Anzahl von Attributen, wobei sich mindestens ein Attribut unterscheidet. Im dritten Fall ist mindestens ein Attribut gleich, aber der zugehörige Wert unterscheidet sich. Die Fälle 2 und 3 können auch kombiniert auftreten. In Abbildung 11–16 sind die drei grundsätzlichen Fälle an einem Beispiel illustriert: Im Fall 2 unterscheiden sich die beiden Tabellen bei den Attributen (GRP_ID, PREIS_NETTO, LIEFERANT_ID); im Fall 3 sind die Attribute zwar gleich, die Preise (PREIS_NETTO) für die einzelnen Artikel unterscheiden sich hingegen. Fall 1: ARTIKEL_ID

BEZEICHNUNG

LIEFERANT_ID

100 102

Schlüssel, 13 mm Schlüssel, 15 mm

234 243

=

ARTIKEL_ID 100 102 202

1 1 1

Schlüssel, 13 mm Schlüssel, 15 mm Nuss, VK, 13 mm

ARTIKEL_ID 100 102 202

=

1 1 1

LIEFERANT_ID

Nuss, VK, 13 mm Schlüssel, 15 mm

649 243

BEZEICHNUNG

4,39 4,73

+

3,67

BEZEICHNUNG

1 1

Schlüssel, 13 mm Schlüssel, 15 mm Nuss, VK, 13 mm

1

Schlüssel, 13 mm Schlüssel, 15 mm Nuss, VK, 13 mm

4,39 4,73 3,67

+

LIEFERANT_ID 234 243 649

ARTIKEL_ID 100 102 202

GRP_ID

Fall 3: ARTIKEL_ID GRP_ID BEZEICHNUNG PREIS_NETTO 100 102 202

BEZEICHNUNG

202 102

Schlüssel, 13 mm Schlüssel, 15 mm Nuss, VK, 13 mm

Fall 2: ARTIKEL_ID GRP_ID BEZEICHNUNG PREIS_NETTO 100 102 202

ARTIKEL_ID

+

BEZEICHNUNG LIEFERANT_ID 234 243 649

Schlüssel, 13 mm Schlüssel, 15 mm Nuss, VK, 13 mm

PREIS_NETTO LIEFERANT_ID 4,39 234 4,73 243 3,67

ARTIKEL_ID BEZEICHNUNG PREIS_NETTO 4,39 100 Schlüssel, 13 mm 4,73 102 Schlüssel, 15 mm 202 Nuss, VK, 13 mm 3,67

= Abb. 11–16

649

Unterschiedliche Fälle bei der Zusammenführung von Daten (Beispiel)

5 Alternativen

214

11 Standardisierung und Bereinigung

Die Sätze aus Fall 1 lassen sich durch Löschung eines Datensatzes für den Artikel mit der ARTIKEL_ID 102 trivial zusammenführen. In Fall 2 ist das ebenfalls relativ leicht, indem einfach alle unterschiedlichen Attribute zusammengeführt werden. Problematischer gestaltet sich Fall 3, weil es hier aufgrund der unterschiedlichen Werte für ein und dasselbe Attribut zu einem Konflikt kommt. In diesem Fall sind zwei Verfahrenswege der Zusammenführung möglich: die konfliktvermeidenden und die konfliktlösenden Verfahren [Hartel 2006]. Konfliktvermeidende Verfahren

Wie der Name schon sagt, zeichnen sich diese Verfahren dadurch aus, dass sie den Konflikt zwischen sich widersprechenden Attributwerten vermeiden, aber nicht lösen. Beispiele sind die Maskierung und die mengenbasierte Zusammenführung. Bei der Maskierung werden die den Konflikt verursachenden Attributwerte mit einem speziellen Kennzeichen versehen (maskiert). Bei der Auswertung kann man dann im Einzelfall entscheiden, ob man die maskierten Werte hierfür verwendet oder nicht. Es kommt zwar zu keinem Informationsverlust, einen richtigen Wert für das Attribut erhält man aber nicht. Dieser kann entweder über die mengenbasierte Zusammenführung oder durch konfliktlösende Verfahren bestimmt werden. Damit verschiebt man die Lösung des Konflikts nur auf die nachfolgenden Auswertungsprozesse, was die Komplexität und Fehleranfälligkeit erhöht. Deshalb setzt man dieses Verfahren höchstens in Kombination mit einem konfliktlösenden Verfahren ein. Die mengenbasierte Zusammenführung speichert die den Konflikt verursachenden Werte im Attribut nicht als Einzelwerte, sondern als Wertemengen (siehe Abb. 11–17). In dem Beispiel aus Abbildung 11–16 würde das Attribut PREIS_ NETTO für den Artikel mit der ARTIKEL_ID 100 die Wertemenge {4,39; 3,89} enthalten. Dadurch gehen die Informationen aus den ursprünglichen Daten nicht verloren, wie bei der Maskierung verschiebt sich die Auswahl des zu verwendenden Werts auf die nachfolgenden Auswertungsprozesse. Hinzu kommt ein weiterer Nachteil: Implizit vorhandene Beziehungen zwischen den Werten unterschiedlicher Attribute können verloren gehen. In dem Beispiel aus Abbildung 11–17 wird bei der Zusammenführung die implizite Verbindung zwischen den Attributwerten für VORWAHL und TELEFON durchtrennt. Der zusammengeführte Datensatz enthält für beide Attribute jeweils zwei eigenständige Werte, sodass bei der Abfrage auch unzulässige Kombinationen (z.B. VORWAHL = 030, TELEFON = 6367291) möglich sind.

11.2 Datenbereinigung

215

Mengenbasierte Zusammenführung Vorname Peter Burkhard Edmund

Name Lustig Küpper Hasse

Telefon 742964 6367291 629503

=

Abb. 11–17

Vorwahl 089 040 02256

+

Vorname Name Peter Lustig Burkhard Küpper Edmund Hasse

Telefon 742964 9825141 629503

Vorwahl 089 030 02256

Vorname Name Telefon Vorwahl Peter Lustig 742964 089 Burkhard Küpper 6367291, 9825141 030, 040 Edmund Hasse 629503 02256

Mengenbasierte Zusammenführung von Duplikaten (Beispiel)

Konfliktlösende Verfahren

Im Gegensatz zu den konfliktvermeidenden Verfahren werden bei den konfliktlösenden Verfahren die Konflikte zwischen den sich widersprechenden Attributwerten gelöst. Bekannte Beispiele sind Selektionsverfahren, Aggregationsverfahren sowie konfidenzbasierte Verfahren. Bei den Selektionsverfahren wird aus der Menge an Attributwerten ein einziger als korrekt ausgewählt. Die Auswahl erfolgt über statistische Methoden, z.B. kann über ein Histogramm der am häufigsten auftretende Wert bestimmt und selektiert werden. In dem Beispiel aus Abbildung 11–18 befinden sich in der Tabelle BESTELLUNGEN zwei ähnliche Bestellungen (BESTELL_ID 2884556) von Weizenbier, die sich im Wert für das Attribut EINHEIT unterscheiden. Die Daten zeigen nicht eindeutig, ob der Wert Fass 50l oder Flasche 0,5l korrekt ist. Aus diesem Grunde wird ein Selektionsverfahren eingesetzt, das das Histogramm mit der Häufigkeitsverteilung der Artikel nach Einheiten auswertet. Daraus lässt sich erkennen, dass der Artikel Weizen hauptsächlich in der Einheit Fass 50l bestellt wird. Deshalb werden die beiden ähnlichen Datensätze zusammengefasst, und im konsolidierten Datensatz wird im Attribut EINHEIT der wahrscheinlichere Wert Fass 50l verwendet. Aggregatverfahren berechnen hingegen aus den konfliktären Attributwerten einen neuen Wert. Neben den domänenunabhängigen Aggregatfunktionen (z.B. Durchschnitt, Maximum) kommen in der Praxis auch domänenabhängige zum Einsatz. Diese können kontextbezogene, komplexe Logik zur Identifikation des richtigen Werts enthalten, sind aber dadurch nicht universell verwendbar und aufwendiger zu realisieren. Die domänenunabhängigen Aggregatfunktionen können hingegen in vielen Fällen zu unsinnigen Ergebnissen führen, z.B. kann der Mittelwert von zwei unterschiedlichen Artikelnummern nicht sinnvoll verwendet werden. Weiterhin eignen sich die meisten Funktionen (z.B. der Durchschnitt) in der Regel nur für numerische Datentypen, andere (z.B. das Maximum) hingegen sind auch für alphanumerische Datentypen geeignet. Beispiel: Es wird der Wert für das Attribut STRASSE mit der maximalen Länge als korrekt ausgewählt. Ein

216

11 Standardisierung und Bereinigung

Hauptnachteil dieser Verfahren ist, dass sich aufgrund der (zum Teil komplexen und kontextabhängigen) Berechnung eines neuen Werts aus den bestehenden Werten die Korrekturen im Nachhinein schlecht erkennen und nachvollziehen lassen. Es empfiehlt sich also, die ursprünglichen Werte wie z.B. bei der mengenbasierten Zusammenfassung zusätzlich abzuspeichern. Mit diesen »Rohdaten« lässt sich die Berechnung anschließend jederzeit überprüfen und wiederholen. Die konfidenzbasierten Verfahren verwenden zur Auswahl die Vertrauenswürdigkeit (Konfidenz) des Werts oder Datensatzes. Die Konfidenz liegt zwischen den Werten 0 und 1, wobei 1 die höchste Vertrauenswürdigkeit darstellt. Die Konfidenz der Daten wird durch drei Faktoren bestimmt und beeinflusst: den Wert aus dem Quellsystem, die Einflüsse aus der Vorverarbeitung einschließlich vorhergehender Integration und den Einfluss der Duplikaterkennung. Die Konfidenz aus dem Quellsystem wird anhand der Verarbeitungsprozesse und der Qualität des Quellsystems berechnet. Die Vorverarbeitung kann diesen Wert reduzieren, z.B. durch dabei durchgeführte Korrekturen. Aus dem Ähnlichkeitsmaß der Duplikaterkennung wird dann die daraus resultierende Konfidenz bestimmt. Auf Datensatzebene wird die Konfidenz aus den Konfidenzen der einzelnen Attribute ermittelt. Welches Verfahren in der Praxis eingesetzt wird, hängt stark vom Kontext, den Anforderungen und den jeweiligen Daten ab. In den meisten Projekten wird eine Kombination verschiedener Verfahren eingesetzt, um alle gestellten Anforderungen zu erfüllen. Häufigkeitsverteilung über alle Bestellungen 250.000 BESTELL_ID ARTIKEL_ID BEZEICHNUNG

EINHEIT

200.000

2884556 2884556

100 100

Weizen Weizen

Fass 50 l Flasche 0,5 l

150.000

1846373

103

Kölsch

Flasche 0,3 l

100.000 50.000

Selektionsverfahren

BESTELL_ID ARTIKEL_ID BEZEICHNUNG

0

EINHEIT

2884556

100

Weizen

Fass 50 l

1846373

103

Kölsch

Flasche 0,3 l

Abb. 11–18

Selektionsverfahren nach Histogramm (Beispiel)

Weizen

Kölsch

Pils

Flasche 0,3 l Flasche 0,5 l Fass 50 l

11.3 Standardisierung und Bereinigung im ETL-Prozess

217

11.3 Standardisierung und Bereinigung im ETL-Prozess Die Daten können grundsätzlich an vier Stellen im ETL­Prozess standardisiert und bereinigt werden: an der Quelle, bei der Transformation, beim Laden oder direkt in den Zielen. Bei der Extraktion sollten solche umfangreichen Aktivitäten nicht durchgeführt werden. Die Standardisierung und Bereinigung an der Quelle geschieht außerhalb der BI­Anwendung. Es empfiehlt sich zur Sicherheit trotzdem, wenn auch in eingeschränktem Maße, Validierungen im Data Warehouse durchzuführen. Damit können Änderungen der Daten oder deren Qualität frühzeitig bemerkt werden und die erforderliche Datenqualität im Data Warehouse kann erhalten bleiben. Die bei der Validierung als fehlerhaft erkannten Daten sollten dann aber auch nicht hier bereinigt werden, sondern ebenfalls und ausschließlich direkt an der Quelle (siehe Kap. 10). Im Normalfall erfolgt die Standardisierung und Bereinigung bei der Transformation. Nach der bei der Transformation durchgeführten Homogenisierung und Integration stehen für die Bereinigung in der Regel alle benötigten Daten zur Verfügung. In manchen Fällen können aufgrund bis dahin fehlender Daten die Bereinigungen erst beim Laden ins Datenziel erfolgen. Es gelten die entsprechenden Anmerkungen aus Abschnitt 10.3. Wurden bereits fehlerhafte Daten in die Ziele (z.B. Data Marts) der BI­Anwendung geladen oder können die Bereinigungen erst dort ausgeführt werden, findet die Bereinigung und Standardisierung direkt in den Zielen statt. Das wird eher selten praktiziert, da große Nachteile bestehen: Erstens können dadurch Inkonsistenzen zwischen dem Data Warehouse und den Data Marts entstehen, die bei Reporting und Analysen der Daten zu Fehlern bzw. Widersprüchen führen. Zweitens können die Benutzer bis zur Bereinigung auf die fehlerhaften Daten zugreifen, sofern diese nicht für den Zugriff gesperrt werden. Ein in der Praxis bewährter Grundsatz lautet: Die Bereinigung sollte direkt im Anschluss an die Validierung durchgeführt werden. Erfolgt die Validierung z.B. bei der Transformation, sollte die Bereinigung ebenfalls dort erfolgen. Dadurch existiert eine starke Verbindung und Nähe zwischen diesen beiden Teilen. Bei Änderungen in der Validierung (z.B. durch aktualisierte Regeln) ist es damit wahrscheinlicher, dass auch die Bereinigung entsprechend geändert wird.

218

11 Standardisierung und Bereinigung

11.4 Verfahren für nicht zu bereinigende Daten Egal wie gut man standardisiert und bereinigt – in der Praxis verbleiben noch Fehler im Datenbestand. Es handelt sich hierbei um Fehler, die die vorhandenen Validierungen nicht entdecken konnten. Diese lassen sich durch regelmäßiges Monitoring und verbesserte Regeln im Laufe der Zeit zwar minimieren, aber nicht vollständig vermeiden. Hinzu kommen bei der Validierung identifizierte Fehler, bei denen die zugehörigen Daten nicht automatisch bereinigt werden konnten. Diese Daten müssen die Experten abschließend manuell bereinigen. Trotz ihrer Erfahrung finden diese Experten nicht alle Fehler, es verbleibt ein nicht korrigierbarer Rest an fehlerbehafteten Daten. Das Ziel des Datenqualitätsmanagements muss es sein, diesen verbleibenden, weder automatisch noch manuell zu bereinigenden Anteil so gering wie nötig zu halten – nicht so gering wie möglich. Der Aufwand für eine weitere Reduzierung der Fehlerquote ist extrem hoch und umgekehrt proportional zur verbleibenden Restmenge, deshalb sollte man sich hier auf das notwendige Maß beschränken. Die manuell zu bereinigenden Daten werden im automatisierten Bereinigungsprozess ausgesteuert und gespeichert, beispielsweise in einer Fehlerdatentabelle. Es lohnt sich nicht darauf zu warten, dass die Fachexperten diese Daten selbst bereinigen. Viel besser und effektiver ist es, die Bereinigung aktiv in die Arbeitsprozesse der zuständigen Bearbeiter zu integrieren. So kann man die Bearbeiter per Mail über die aufgetretenen Fehler informieren. Besser, aber aufwendiger ist die Integration in ein Workflow­System, in dem die Fehlerbearbeitung dem Bearbeiter zugewiesen und zusätzlich überwacht wird.

11.5 Empfehlungen Daten zu standardisieren und zu bereinigen ist so komplex, dass entsprechende Werkzeuge eingesetzt werden müssen. Der Aufwand ist zu groß, um diese Programme selbst zu entwickeln, außerdem erzielt man im Normalfall schlechtere Ergebnisse. Erfolgsentscheidend ist es, dass das Projektteam die richtigen Werkzeuge auswählt und auch richtig benutzt. Hilfen hierzu finden sich in Kapitel 16. Einige dieser Werkzeuge besitzen Schnittstellen zu operativen Standardwerkzeugen und können darin eingebunden werden, um die Fehler direkt an der Quelle zu vermeiden und den Aufwand bei der nachträglichen Bereinigung zu minimieren. Der Benutzer sollte am Ende immer eindeutig erkennen können, ob es sich um originäre oder korrigierte Daten handelt: Nur so bleibt die Glaubwürdigkeit erhalten. Werden diese Daten weiterverarbeitet oder aggregiert, sollten die resultierenden Daten mit einer Qualitätskennzahl (z.B. Konfidenz) ergänzt werden. Aus dieser Kennzahl kann der Benutzer die Güte der Daten erkennen. Er kann dann selbst entscheiden, ob dieser Wert für ihn und seine Aufgabe ausreicht – oder eben nicht.

219

12 Datenanreicherung

Nachdem die Daten im Rahmen der Bereinigung, Standardisierung sowie Validierung ein ausreichendes Qualitätsniveau erreicht haben (siehe Kap. 10 und 11), erfolgt oftmals zur Steigerung des Informationswerts eine Anreicherung mit zusätzlichen Informationen (z.B. über Bonität, demografische und geografische Informationen). Die Zeiten, in denen nur die richtige Adresse des Kunden oder Lieferanten ausreichte, um ein effektives Kunden­ oder Lieferanten-Beziehungsmanagement zu betreiben, sind vorbei. Heute werden im Rahmen eines analytischen Customer Relationship Management bzw. Supplier Relationship Management mehr und besser qualifizierte Informationen über Kunden bzw. Lieferanten sowie deren Verhalten benötigt. Fehlende bzw. falsche Informationen verhindern nicht nur korrekte Kunden­ bzw. Lieferantenanalysen im Bereich Business Intelligence, sondern verschlechtern auch operative Aktionen (z.B. Mailing­Kampagnen), da beispielsweise falsche Zielgruppen selektiert und angesprochen werden. So lassen sich Firmen­, aber auch Privatadressen um eine Vielzahl von Merkmalen erweitern. Dieses Kapitel beschreibt die vielfältigen Möglichkeiten der Anreicherung von Kunden­ und Lieferantendaten (im weiteren Verlauf einfach Geschäftspartner genannt) im Rahmen des Datenqualitätsmanagements. Der zunehmende Austausch von Daten macht es notwendig, für die Anreicherung einheitliche Taxonomien beispielsweise für Materialien oder Branchencodes zu verwenden. Die wichtigsten Klassifizierungen werden in diesem Kapitel ebenfalls kurz vorgestellt.

12.1 Wirtschaftsinformationen Es gibt Unternehmen, die auf die Anreicherung von Wirtschaftsinformationen spezialisiert sind. Sie ermöglichen es, einen transparenten und objektiven Überblick über die wirtschaftliche und rechtliche Situation des Geschäftspartners zu erhalten.

220

12 Datenanreicherung

Ein Beispiel hierfür ist Dun & Bradstreet1, ein Anbieter von Informationen über Unternehmen. Basierend auf der DUNS-Nummer2 lassen sich die weltweiten Unternehmensverflechtungen (z.B. Sitz der Muttergesellschaft, Existenz von Schwester- und direkten Tochtergesellschaften) in Form von sogenannten Family Trees darstellen. Ein Beispiel zeigt Abbildung 12–1. Höchste Muttergesellschaft weltweit 123456789 334412345 Höchste inländische Muttergesellschaft Tochter von 123456789 672348763 Tochter von 334412345 224561111 Tochter von 672348763

Abb. 12–1

224562222 Tochter von 672348763

224563333 Tochter von 672348763

Aufbau des D&B Family Trees

Der erweiterte DUNS­Datensatz (der sogenannte 1784­Datensatz) enthält darüber hinaus Informationen über den internationalen Firmensitz, die höchste nationale Gesellschaft, den Branchencode (siehe Abschnitt 12.6), die Unternehmensgröße etc. Dazu kommen Personeninformationen wie beispielsweise die Namen der Geschäftsführer oder Vorstände. Eine zusätzliche Anreicherung erfolgt über Finanzdaten aus der Bilanz und der GuV, um Aussagen zur Bonität der Geschäftspartner treffen zu können. Ein weiterer Anbieter solcher Wirtschaftsinformationen ist Austin­Tetra.3 Mithilfe der sogenannten Austin­Tetra Universal Supplier Identification Number (kurz A­T­Nummer) werden die Unternehmen eindeutig identifiziert. In dem globalen Data Warehouse sind über 50 Millionen Firmen erfasst. Neben den Unternehmensverflechtungen hält die Datenbank zusätzliche Informationen in über 220 Datenelementen verfügbar (z.B. Adresse, Geschäftsfeld, Größe, Bonität, Industriezugehörigkeit (als SIC- oder NAICS­Code)). Seit einigen Jahren bietet auch Bureau van Dijk4 mit seiner Firmendatenbank ORBIS Informationen zu mehr als 50 Millionen Unternehmen weltweit an. Zu

1. 2. 3. 4.

www.dnbgermany.de Die DUNS-Nummer (Data Universal Numbering System) ist ein 9-stelliger Zahlencode, der Unternehmen weltweit eindeutig identifiziert und 1992 von Dun & Bradstreet definiert wurde. www.austintetra.com www.bvdep.com

12.1 Wirtschaftsinformationen

221

den verfügbaren Informationen gehören nationale oder internationale Beteiligungen sowie Gesellschafterdaten (z.B. Beteiligungshöhen, nationale und globale Konzernmütter). Als eindeutige Nummer wird die sogenannte BvD­ID verwendet, die in der Regel auf offiziell gebräuchliche Firmen­Identifikationsnummern aufsetzt. Zusätzliche Hintergrundinformationen wie z.B. Angaben über Unternehmenskäufe und Fusionen, Tätigkeitsbeschreibungen, Ratings, Gewinnschätzungen runden die Menge an abrufbaren Informationen ab. Weitere Anbieter derartiger Informationen sind z.B. AZ Direkt oder Creditreform. Der praktische Einsatz der vorgestellten Nummern im Projekt zeigt, dass der Abdeckungsgrad weltweit gesehen sehr unterschiedlich ist. Während der europäische und der nordamerikanische Raum sehr gut abgedeckt sind, gibt es in Südamerika und vor allem in Asien (mit Ausnahme von Japan) sehr große Lücken. Somit sollte vor einer Nutzung im Projekt geprüft werden, wie die regionale Verteilung der Geschäftspartner im eigenen Unternehmen aussieht. BMW AG DUNS-Nr. 147115678 Bayrische Motorenwerke AG DUNS-Nr. 147115678 Bayrische Motoren Werke AG DUNS-Nr. 147115678

BMW AG DUNS-Nr. 147115678

Bayr. Motoren-Werke AG DUNS-Nr. 147115678

Abb. 12–2

Duplikaterkennung durch Nutzung der DUNS-Nummer

Durch die Anreicherung der Geschäftspartnerdaten mit einer eindeutigen Nummer (wie z.B. der DUNS­Nr. oder der BVD­ID) erhält man eine weitere Möglichkeit zur Duplikatfindung. Geschäftspartnerdaten, die durch die in Abschnitt 11.3 beschriebenen Maßnahmen nicht als solche erkannt wurden, jedoch dieselbe eindeutige Nummer bekommen, sind mit hoher Wahrscheinlichkeit Duplikate. Während die einmalige (initiale) Anreicherung des vorhandenen Datenbestands mit eindeutigen Schlüsseln (wie z.B. DUNS­Nummer oder A­T­Nummer) in einem BI­Projekt oft berücksichtigt wird, besteht die eigentliche Herausforderung in der nachhaltigen Pflege dieser Zuordnungen. Konzernstrukturen ändern sich permanent, neue Geschäftspartner werden in den Datenbestand aufgenommen. Dies führt sehr schnell zu veralteten Daten. Abhilfe schaffen nur regelmäßige Updates/Aktualisierungen der Daten, was in der Regel mit hohen Kosten verbunden ist

222

12 Datenanreicherung

12.2 Geografische Informationen Wo ist die Kaufkraft für welches Produkt am höchsten? Wer gehört zur Zielgruppe für bestimmte Produkte und wo wohnen diese Personen? Wie viel Potenzial haben bestimmte Produkte in definierten Einzugsgebieten? Wo ist der optimale Standort für eine neue Filiale? Wie sollten die Vertriebsgebiete aussehen? Dies alles sind Fragen, die im Allgemeinen durch Vertriebsanalysen beantwortet werden sollen. Um standortbezogene Bewertungen durchführen zu können, reichen die klassischen BI­Anwendungen jedoch nicht aus. Erst die Anreicherung dieser Informationen mit geografischen Koordinaten ermöglicht das Erkennen von räumlichen Zusammenhängen und Phänomenen des Unternehmens und des Markts. Um Kunden­ oder Filialstandorte in einer Karte abbilden zu können, müssen die Adressen dieser Standorte über eine Abgleichvariable, z.B. die Postleitzahl oder die geografischen Koordinaten dieser Punkte, mit der Karte verknüpft werden.5 Diese Koordinaten dienen dem Transfer einer Vielzahl von Informationen (z.B. Umsatz, Gewinn) in die Karte. Der gesamte Vorgang wird Geocodierung genannt und ergänzt die typischen Fragestellungen aus dem BI­Umfeld nach dem Wer und Was und Warum um das Wo. Somit werden geografische Informationstechnologien schrittweise ein integraler Bestandteil von BI­Anwendungen. In diesem Kontext wird häufig der Begriff Geo­Marketing verwendet. In der Literatur findet man viele Definitionen (vgl. [Schüssler 2000, S. 5], [GfK 2010]), im Kontext von Business Intelligence beschreibt die Definition von Feix (vgl. [Feix 2007, S. 45]) den Zusammenhang am besten: »Geo­Marketing bezeichnet die Planung, Koordination, Kontrolle und Visualisierung kundenorientierter Marktaktivitäten von Unternehmen mittels intelligenter und leistungsfähiger Geoinformationssysteme, Statistik­ und DataMining-Systeme. Geo­Marketing ist ein raumbezogener Data­Mining­Prozess (Spatial Data Mining), der unterschiedliche Methoden nutzt, um unternehmensinterne und externe Daten zu strukturieren, Raumbezüge herzustellen, Zusammenhänge und Muster zu erkennen, zu analysieren, zu visualisieren und so entscheidungsunterstützende Ergebnisse für Fragestellungen aus den Bereichen Marketing, Vertrieb, Organisation und Logistik zu liefern.«

5.

Für eine genaue Definition von Geodaten mit primärer und sekundärer Metrik sei auf [Herter/Mühlbauer 2008, S. 34ff.] verwiesen.

12.2 Geografische Informationen

223

Transformation Datenaufbereitung und Geocodierung

Wissen

Muster Selektion

Aufbereitete Daten Zieldaten

Transformierte Daten

Interpretation

(Spatial) Data Mining GIS-Analytik

Interne und externe Daten

Abb. 12–3

Visualisierung

Data-Mining-Prozess mit Geografischen Informationssystemen (GIS) (vgl. [Feix 2007, S. 54])

Feix erweitert den Begriff »Geo-Marketing«: Sie spricht von »Geographical Business Intelligence« und meint damit den Einsatz von Geo-Informationssystemen im BI-Umfeld. Beim Geo­Marketing wird oftmals in den folgenden Schritten vorgegangen (siehe dazu auch Abb. 12–3): ■ Geocodieren von Kundendaten und Standorten (Anreicherung der existierenden Daten) ■ Bildung von Einzugsgebieten anhand von Radien oder Isodistanzen ■ Aggregieren oder Durchschnittsbildung von Daten, die in den Einzugsgebieten erhoben worden sind ■ Diese neu gewonnenen Daten lassen sich für multivariate Verfahren und Data­Mining-Methoden nutzen. ■ Die Visualisierung der Ergebnisse aus den Data­Mining­Prozessen ist der letzte Schritt. Gerade bei großen Datenmengen lassen sich durch die Visualisierung der Daten die Zusammenhänge schneller erfassen. Die Vielfalt der Anwendungen, die mittels Geo-Marketing möglich sind, zeigt die folgende Auflistung, die jedoch keinen Anspruch auf Vollständigkeit erhebt: ■ ■ ■ ■ ■ ■

Standortanalyse und -optimierung (z.B. des Filialnetzes) Wettbewerberanalysen Markt-, Potenzialanalyse Vertriebsgebietsanalyse, Vertriebsoptimierung, Absatzplanung Kunden- und Zielgruppenanalyse Database- und Direktmarketing

224

12 Datenanreicherung

■ Gebietsplanung und -optimierung ■ Zustell-Logistik Für eine ausführliche Beschreibung verschiedener Anwendungen sei auf [Herter/Mühlbauer 2008, S. 203ff.] verwiesen.

12.3 Soziodemografische Informationen Die (Sozio­)Demografie beschreibt und analysiert die Bevölkerungsstrukturen anhand bestimmter Merkmale. Das Ziel solcher Analysen kann u.a. darin bestehen, die eigenen Produkte besser auf die relevanten Zielgruppen abzustimmen. Typische Merkmale, um die die eigenen Daten angereichert werden können, sind: ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Geschlecht Alter/Geburtsdatum Familienstand (z.B. Singles, Paare, Familie mit Kindern) Haushaltsgröße (z.B. 2­Personen­Haushalt) Schul­ und Berufsbildung (z.B. Realschule, Abitur, Studium) Berufstätigkeit (z.B. Vollzeit, Teilzeit) Haushaltsnettoeinkommen Kaufkraft Zahl der Einkommensbezieher im Haushalt soziale Schicht Gebiete (Bundesländer, Nielsen­Gebiete6) Ortsgrößen

Soziodemografische Informationen bilden oft die Grundlage für Auswertungen im Bereich Geo­Marketing (vgl. Abschnitt 12.2). Nicht alle hier genannten Merkmale lassen sich allerdings auf Haushaltsebene abbilden. Gerade in Deutschland schaffen die Datenschutzgesetze Grenzen bei der Erfassung. Der Datenschutz verlangt eine Granularität von vier Haushalten, d.h. mindestens vier Haushalte müssen als Aggregationsebene vorliegen, damit eine ausreichende Anonymisierung möglich ist.7

6.

7.

Nielsen-Gebiete: vom Marktforschungsunternehmen AC Nielsen eingeteilte Gebiete. In Deutschland handelt es sich hierbei um Bundesländer oder Gruppen von zwei bis vier Bundesländern. für weitere Informationen (vgl. [Weichert 2008])

12.4 Haushaltsbildung

225

12.4 Haushaltsbildung Mit dem Begriff Haushaltsbildung (Householding) verbindet man die Gruppierung von Adressdaten mithilfe definierter Attribute wie z.B. Nachname, Anschrift oder Telefonnummer. Das Ziel besteht darin, Personen zu identifizieren, die in einem Haushalt oder einer Wohnung leben, um beispielsweise Kosten für doppeltes Porto bei Mailing­Aktionen zu sparen. Die Datensätze, die zu einem Haushalt gehören, werden um eine eindeutige Haushaltsnummer (HID) angereichert (siehe Tab. 12–1). Je besser die Validierung und die Standardisierung (siehe Kap. 10 und 11) durchgeführt wurden, desto einfacher ist es, geeignete Kandidaten für die Gruppierung zu identifizieren. Dennoch müssen Geschäftsregeln festgelegt werden, die entscheiden, wie ähnlich die Datensätze sein müssen, um zu einem Haushalt zu gehören. ID

Vorname

Nachname

Anschrift

Telefon

HID

1

Susanne

Gutfleisch

Landfriedstr. 19

412136

1

12

Martina

Neudecker

Landfried Straße 19

412136

1

13

Harald

Neudecker

Landfriedstrasse 19

21723

1

2

Michael

Becker

Am Flussufer 1

26673

2

4

Johann

Grün

Flussufer 1

26673

2

11

Ruth

Becker

Flussufer 1a

26673

2

3

Brigitte

Mayer

Klausenpfad 7

12345

3

8

Ulrich

Maier

Clausenpfad 7

12345

3

5

David

Schröder

Unter den Linden 12

3454890

4

6

Caroline

Schroeder

Den Linden 12

0172343265

4

Tab. 12–1

Haushaltsbildung von Adressdaten

Neben dem Ähnlichkeitsmaß muss darauf geachtet werden, dass die richtigen Attribute für den Vergleich verwendet werden. Andernfalls kann es bei der Haushaltsbildung zu unerwünschten Effekten kommen, wie folgendes Beispiel zeigt: Basiert die Gruppierung nur auf der Adresse und der Telefonnummer, so kann die gesamte Etage eines Studentenwohnheims zu einer Familie zusammengefasst werden, wenn die Studenten alle die Telefonnummer des Flurapparats des Wohnheims angeben. Insgesamt wird der Begriff Haushalt heute weiter gefasst als ursprünglich gemeint. Aus Sicht des Database­Marketing können beliebige relevante Zusammenfassungen (Wohnung, Haus, Firma etc.) bei der Haushaltsbildung herangezogen werden.

226

12 Datenanreicherung

Ähnlich wie bei der Anreicherung mit Wirtschaftsinformationen (siehe Abschnitt 12.1) wird die einmalige (initiale) Haushaltsbildung oftmals vorgesehen. Darüber hinaus ist jedoch zu bedenken, dass sich die Zusammensetzung von Gruppen im Zeitverlauf ändern kann. Beispielsweise heiraten Thomas Müller (HID = 7) und Sabine Schmitz (HID = 9). Welche der beiden HIDs soll »überleben«? Eine mögliche Regel beim Zusammenlegen (Merge) von zwei IDs besagt, dass die ältere »überlebt«. Ebenso ist der umgekehrte Fall denkbar: Aus einem Haushalt werden zwei (z.B. durch Scheidung oder Wegzug eines Kindes). In diesem Fall (Split) ist zu entscheiden, welcher Haushalt die alte HID behält und welcher eine neue HID bekommt. Wichtig ist, dass sich die Regeln für die Bildung der neuen HIDs bei einer Zusammenlegung oder Teilung nach dem geschäftlichen Kontext richten. Eine allgemein gültige Definition für derartige Regeln ist an dieser Stelle nicht möglich.

12.5 Standards zur Klassifizierung von Waren und Dienstleistungen Grundlegend für eine automatisierte Beschaffung von Gütern und Dienstleistungen ist ein Standard für den Informationsaustausch zwischen Lieferanten und Kunden. Um die eigenen Güter und Dienstleistungen unternehmensübergreifend zu standardisieren, müssen die Daten um entsprechende Codes ergänzt werden, d.h., die Daten werden vordefinierten Klassen zugeordnet. Im Business­Intelligence­Umfeld ist es u.a. das Spend Management, das auf ein Klassifikations­ oder Ordnungssystem aufsetzt, um entsprechende Bündelungseffekte zu erkennen. Es wird zwischen Systemen unterschieden, die nur für bestimmte Branchen gelten (»Domänenspezifische Klassifikation«), und solchen, die allgemein gültig sind (»Domänenunabhängige Klassifikation«). Im Folgenden werden ausgewählte domänenunabhängige Klassifikationssysteme für Güter­ und Dienstleistungen vorgestellt. UNSPSC

Der UNSPSC8 (United Nations Standard Products and Services Code) ist ein international eingesetztes Klassifikationssystem der Warenwirtschaft. Das UNSPSC­System wird im E­Procurement, insbesondere im amerikanischen Raum, zur unternehmensübergreifenden Klassifikation von Waren und Dienstleistungen aller Art verwendet. Das UNSPSC­System entstand 1998 durch eine Kooperation des United Nations Development Program (UNDP) und Dun & Bradstreet. Der UNSPSC­Kategoriebaum wird regelmäßig für spezielle Branchen erweitert.

8.

www.unspsc.org

12.5 Standards zur Klassifizierung von Waren und Dienstleistungen

227

Hierzu arbeitet das Standardisierungsgremium mit branchenspezifischen Vereinigungen zusammen. 55 Segmente

ca. 350 Familien

ca. 1.900 Klassen 20.000 Kategorien optional: spezifische Erweiterungen

Abb. 12–4

Aufbau des UNSPSC-Kategoriebaums

Das Klassifikationssystem besitzt fünf Hierarchiestufen, von denen die ersten vier standardisiert sind. Jede Stufe wird durch zwei Ziffern codiert, sodass jede Kategorie einen 2­stelligen Code besitzt. Die Benennung dieser Stufen (mit einem Beispiel aus der Informationstechnik) zeigt Tabelle 12–2. Ebene 1 (Segment): Ebene 2 (Familie): Ebene 3 (Klasse): Ebene 4 (Kategorie):

Tab. 12–2

43

Informationstechnik

43–20

Medien- und Computerzubehör

43–20–17

Multimediaspeicher

43–20–17–03

CD-Taschen

Aufbau der UNSPSC-Klassifikationshierarchie

Im Unterschied zu dem im folgenden Abschnitt vorgestellten System eClass umfasst die UNSPSC­Klassifikation keine Merkmale. eClass

Das Klassifikationssystem eClass9 zur Gruppierung von Produkten, Materialien und Dienstleistungen besteht aus den drei Komponenten ■ Materialklassenhierarchie (Taxonomie), ■ Standardmerkmalleisten und ■ Schlagwörtersystem.

9.

www.eclass.de

228

12 Datenanreicherung

Sachgebiete Hauptgruppen

26 564 Klassen

Gruppen

Abb. 12–5

4.982 27.452

32.832

Untergruppen Merkmale zur Produktbeschreibung

14.300

Standardmerkmalleisten

und

51.476

Schlagworte

Aufbau der eClass-Materialhierarchie (Release 6.1)

Die Materialklassenhierarchie ist eine vierstufige Baumstruktur, bei der eine übergeordnete Klasse ihre untergeordneten Klassen umfasst, d.h., sie sind ihr logisch zugeordnet. Die Knoten der Baumstruktur werden zusammen als Materialklassen bezeichnet. Die vier Ebenen werden jeweils durch einen 2­stelligen Schlüssel definiert, sodass die Untergruppe durch einen 8­stelligen Klassifikationsschlüssel eindeutig dargestellt wird: ■ ■ ■ ■

Sachgebiet (Ebene 1), Hauptgruppe (Ebene 2), Gruppe (Ebene 3) und Untergruppe (Ebene 4).

Die zugehörigen Merkmalleisten beschreiben die Merkmale von Produkten und Dienstleistungen und ermöglichen die Suche in den verschiedenen Katalogen. Jeweils angehängte Schlagwörter und Synonyme (z.B. Warengruppe »Stühle« wird auch bei Suchbegriffen wie »Sitz« oder »Bürostuhl« gefunden) dienen dem schnellen, zielgerichteten Auffinden der Produktklassen.

12.6 Branchenklassifizierung

21 Werkzeug

229

Sachgebiet

21 – 17 Messgerät, Länge

Hauptgruppe

21 – 17 – 03 Handmessmittel

Gruppe Untergruppe Merkmale

21 – 17 – 03 – 01 Lineal (Werkzeug) … 21 – 17 – 03 – 07 Messschraube 21 – 17 – 91 Messgerät, Länge (Teile) 21 – 17 – 92 Messgerät, Länge (Zubehör) …

Abb. 12–6

Schlagworte hier: Bügelmessschraube, Einbaumessschraube, Feinzeigermessschraube, Innenmessschraube, Tiefenmessschraube.

Ausführung der Anzeige Ausgabe der Messnorm Messbereich Messgenauigkeit Werkstoff usw.

eClass-Zuordnung am Beispiel einer Messschraube (vgl. [ Schumacher 2007])

eClass wird zunehmend in global agierenden Firmen wie z.B. E.ON AG, RWE AG oder BASF AG eingesetzt. Da diese Firmen zum Teil auch ihre Lieferanten überzeugen, die Materialien nach diesem Standard zu klassifizieren, ist der Verbreitungsgrad entsprechend hoch. Der eClass e.V. ist eine Non­Profit­Organisation, die den gleichnamigen Klassifikationsstandard branchenübergreifend international definiert, weiterentwickelt und verbreitet. Ein genereller Vorteil der hier vorgestellten Klassifizierungen ist sicherlich die Verfügbarkeit in mehreren Sprachen. Sowohl bei UNSPSC als auch bei eClass werden die Warengruppenbezeichnungen mehrsprachig ausgeliefert. Allerdings ist die Qualität der Übersetzungen in jedem Fall zu prüfen, da teilweise wortwörtlichen Übersetzungen der Vorzug vor einer sinngemäßen Übersetzung gegeben wurde.

12.6 Branchenklassifizierung Für eine unternehmensübergreifende Auswertung nach Branchen müssen die eigenen Geschäftspartnerdaten mit Brancheninformationen angereichert werden. Für die Zuordnung von Unternehmen in Branchen gibt es eine Reihe von domänenunabhängigen Klassifikationssystemen. Im Folgenden werden einige wichtige vorgestellt.

230

12 Datenanreicherung

NACE

Die statistische Systematik der Wirtschaftszweige in der Europäischen Gemeinschaft »Nomenclature statistique des activités économiques dans la Communauté Européenne«, meist nur als NACE bezeichnet, ist ein System zur Klassifizierung von Wirtschaftszweigen, das von Seiten der Europäischen Union auf Basis der ISIC Rev. 3 der Vereinten Nationen zur Harmonisierung entworfen wurde. In Deutschland wird der Standard als Klassifikation der Wirtschaftszweige (WZ2008) verwendet. Gliederungsebene

Tab. 12–3

Anzahl

Code

Abschnitte

21

A–U

Abteilungen

88

01–99

Gruppen

272

01.1–99.0

Klassen

615

01.11–99.00

Unterklassen

839

01.11.0–99.00.0

NACE­Gliederungsstruktur

Tabelle 12–4 zeigt eine Branchenzuordnung im Detail aus dem Abschnitt J »Information und Kommunikation«. 62

Erbringung von Dienstleistungen der Informationstechnologie

62.0

Erbringung von Dienstleistungen der Informationstechnologie

62.01

Programmierungstätigkeiten

62.01.1

Entwicklung und Programmierung von Internetpräsentationen

62.01.9

Sonstige Softwareentwicklung

62.02

Erbringung von Beratungsleistungen auf dem Gebiet der Informationstechnologie

62.02.0

Erbringung von Beratungsleistungen auf dem Gebiet der Informationstechnologie

62.03

Betrieb von Datenverarbeitungseinrichtungen für Dritte

62.03.0

Betrieb von Datenverarbeitungseinrichtungen für Dritte

62.09

Erbringung von sonstigen Dienstleistungen der Informationstechnologie

62.09.0

Erbringung von sonstigen Dienstleistungen der Informationstechnologie

Tab. 12–4

Branchenzuordnungen am Beispiel »Information und Kommunikation«

12.6 Branchenklassifizierung

231

SIC

Das US­Pendant zum NACE ist der SIC­Code (Standard Industrial Classification). Er ist ein Klassifikationsschema für unterschiedliche Industriezweige bzw. Branchen in den USA und wurde 1939 in den Vereinigten Staaten zum Zwecke der amtlichen Statistik kreiert. Der SIC ist eine 4­stellige Notation, die hierarchisch aufgebaut ist. Ausgehend von der Notation »A000« ist »AB00« ein Unterbegriff von A und »ABC0« ein Unterbegriff von B und letztlich »ABCD« ein Unterbegriff von C. Die Zeichen A, B, C, D stehen dabei jeweils für Ziffern zwischen 0 und 9. Das folgende Beispiel zeigt den Aufbau anhand von Druckmaschinen: ■ ■ ■ ■

3000 (Herstellung langlebiger Gebrauchsgüter) 3500 (Maschinenbau) 3550 (Maschinenbau – Spezialmaschinen) 3555 (Maschinenbau – Druck)

Der SIC wurde 1997 durch das von den USA, Kanada und Mexiko gemeinsam entwickelte North American Industry Classification System (NAICS) ersetzt. Von einigen Behörden, wie der United States Securities and Exchange Commission (SEC), wird es allerdings weiterhin verwendet. NAICS

Der NAICS­Code auf der Basis des »North American Industry Classification System«10 ist der aktuelle 6­stellige Branchencode für die USA, Kanada und Mexiko. NAICS klassifiziert die Wirtschaftsbranchen mittels eines 6­stelligen Codes in 20 Sektoren und rund 1.170 Branchen. Die ersten beiden Stellen bezeichnen den Hauptwirtschaftssektor (z.B. Maschinenbau), der Aufbau ist hierbei 2­stellig sequenziell (z.B. Einzelhandel mit den Ziffern 44 und 45). Die dritte Stelle repräsentiert die Industrieuntergruppe, die vierte die Branchengruppe und die fünfte die Branche. Ab der dritten Stelle ist auch der NAICS hierarchisch aufgebaut. Während die ersten fünf Ziffern in allen drei Ländern gleich sind, ist die sechste Ziffer länderspezifisch. Stelle 1–2

Industriesektoren

Stelle 3

Industrieuntergruppe

Stelle 4

Branchengruppe

Stelle 5

Industrie

Stelle 6

Nationale Codes (USA, Kanada, Mexiko)

Tab. 12–5

Aufbau des NAICS­Code

10. www.census.gov/epcd/www/naics.html

232

12 Datenanreicherung

12.7 Empfehlungen Auch wenn das Anreichern von Geschäftsdaten auf den ersten Blick recht einfach erscheint, zeigt die Erfahrung aus diversen Projekten, dass es ganz wichtig ist, bereits im Projekt zu definieren, wie die Aktualität der Daten im späteren Betrieb gewährleistet werden kann. In einer Zeit, in der ständig Unternehmen aufgekauft sowie Unternehmensteile wieder verkauft werden, ändern sich Konzernstrukturen, Unternehmensgrößen oder Personalien permanent. Somit ist es auch für die Anbieter solcher Informationen schwierig, zeitnah ihren Datenbestand zu aktualisieren. Daher hat es sich als hilfreich herausgestellt, ergänzend auf das Wissen der Anwender im eigenen Unternehmen zurückzugreifen. Beispiel: Im zentralen Einkauf eines Konzerns sind die Einkäufer bei ihren Verhandlungen mit den Lieferanten auf zuverlässige Informationen über das getätigte Umsatzvolumen angewiesen, um entsprechende Preise zu erzielen. Da sie selbst schneller über Änderungen in der Struktur ihrer Lieferanten Bescheid wissen als ein Anbieter wie beispielsweise Dun & Bradstreet, ist ein entsprechender Feedback­Kreislauf einzurichten. Das bedeutet konkret, dass direkt eine Information an die zentrale Administration gehen sollte, um die zugehörige Stammdatenbank zu aktualisieren. Als Analogie für diesen Ansatz dienen die klassischen Verkehrsnachrichten. Seit einigen Jahren sind die Radiosender mit ihren Mitarbeitern alleine nicht mehr in der Lage, einen aktuellen Verkehrslagebericht zu erstellen. Ergänzend werden die Autofahrer selbst zu sogenannten »Staumeldern«, die Verkehrsbehinderungen und auch Radarfallen an die Redaktion des Radiosenders melden. Damit wird die zentrale Instanz (Radiosender) in die Lage versetzt, zeitnah über Störungen zu berichten. Diese Informationen stehen anschließend allen Verkehrsteilnehmern (Anwendern) zur Verfügung. Aber auch in diesem Szenario gilt: Die Qualität der Meldungen hängt von der Datenqualität der eingehenden Informationen ab.

233

13 Verbesserung der Datenqualität in der Bereitstellung und Visualisierung

Den Benutzern einer BI­Anwendung werden die Daten als Informationen präsentiert – in Form von Tabellen, Grafiken oder Texten. Dabei lässt sich die Datenqualität nicht nur im Data Warehouse selbst erfolgreich steuern, sondern auch bei der Bereitstellung und Visualisierung verbessern.

13.1 Bereitstellung der Daten Gemäß der in Abschnitt 5.1 vorgestellten Referenzarchitektur erfolgt die Bereitstellung der Daten über die Informationsbereitstellungs­Schicht. Dabei werden die Daten für Drittanwendungen (wie z.B. operative Systeme) außerhalb der BI­Anwendungslandschaft meist als relationale Tabellen, Dateien oder BI­Services zur Verfügung gestellt. Es gelten dieselben Regeln, Methoden und Empfehlungen wie für die BI­Anwendung, wobei das Datenqualitätsmanagement für BI­Services in diesem Buch explizit ausgeklammert wurde. Eine Besonderheit ist die Bereitstellung der Daten für die Darstellungswerkzeuge innerhalb von BI­Anwendungen. Die Business­Intelligence­Plattform stellt dazu normalerweise eine semantische Zugriffsschicht1 (Zwischenschicht) als Bindeglied zwischen den technischen Daten und den zumeist fachlichen Benutzern bereit. Die semantische Zugriffsschicht (siehe Abb. 13–1) regelt den Zugriff auf folgende Datenstrukturen: ■ Datencontainer (Datenbanktabellen, ­views, SQL­Statements, Data Marts, Dateien), ■ Datenfelder in Datencontainern, ■ Wertelisten für Datenfelder, ■ Hierarchieinformation für Dimensionen, ■ Relationen zwischen Datencontainern, mithin die Information über Verknüpfbarkeit, und ■ vordefinierte Filter (optional oder obligatorisch).

1.

Synonyme: Endbenutzerebene, Universum

234

13 Verbesserung der Datenqualität in der Bereitstellung und Visualisierung

Um diese semantische Zugriffsschicht zu strukturieren und zu organisieren, sind spezifische Datenqualitätsmaßnahmen nötig. Für den Benutzer sollte die semantische Schicht die einzige Möglichkeit sein, auf die Daten der BI­Anwendung zuzugreifen. So wird verhindert, dass der Anwender versehentlich unzulässige Beziehungen zwischen den Datenstrukturen herstellt. Im Umkehrschritt bedeutet dies, dass in der semantischen Schicht nur zulässige Beziehungen definiert sein dürfen. Die semantische Schicht darf auch nur freigegebene Datencontainer verwenden. Der Zugriff auf nicht für die Darstellung vorgesehene und dafür freigegebene Daten muss verhindert werden. Die Bezeichnungen und Definitionen innerhalb der semantischen Schicht entsprechen den Vorgaben aus der Spezifikation (siehe Abschnitt 18.4). Es werden rein fachliche Bezeichnungen verwendet, da die Bezeichnungen für den fachlichen Benutzer verständlich sein sollen.

Abb. 13–1

Definition einer Zwischenschicht (Beispiel)

Die Konsistenz und Qualität der semantischen Schicht wird über organisatorische Regelungen gewährleistet, die häufig von technischen Maßnahmen unterstützt werden. Ein Beispiel: Nur im Rahmen des Vier­Augen­Prinzips dürfen geschulte und benannte Administratoren die semantische Schicht ändern. In der Praxis findet man häufig dezidierte Freigabeprozesse, z.B. über ein WorkflowSystem.

13.2 Visualisierung der Information

235

13.2 Visualisierung der Information Darstellungsformen

Mithilfe der BI­Frontend­Werkzeuge lassen sich verschiedene Formen der Informationsdarstellung implementieren (siehe auch Abb. 5–1): ■ ■ ■ ■

Berichte (Reports) Analysen Dashboards Scorecards

Berichte stellen die statischen Auswertungsergebnisse für vorgegebene Fragen mit vordefiniertem Inhalt und Layout dar. In der Regel erfolgt eine seitenorientierte Aufbereitung, die für eine spätere Druckausgabe geeignet ist.

Abb. 13–2

Beispiel für ein Dashboard

Die Ergebnisse von Analysen haben zwar einige Gemeinsamkeiten mit Berichten, die Abfrage entwickelt sich jedoch erst im Laufe der Analyse. Mit den jeweiligen Abfrageergebnissen wird im Gegensatz zu den Berichten dynamisch weitergearbeitet. Typischerweise erzeugt man sich über interaktive Navigation (Drill-downs, Slicing und Dicing) detailliertere Sichten auf die Daten. Das Ziel sowohl von Scorecards als auch von Dashboards ist es, wesentliche Informationen in einer komprimierten und prägnanten, oftmals grafischen, aber

236

13 Verbesserung der Datenqualität in der Bereitstellung und Visualisierung

auch tabellarischen Form darzustellen.2 Neben den üblichen Geschäftsgrafiken bedient man sich hierzu insbesondere aller Arten von Tachometeranzeigen (in Analogie zu Flugzeugen oder Automobilen) sowie Landkartendarstellungen. Beide Lösungen setzen idealerweise auf eine vorhandene Data­Warehouse­Infrastruktur auf (vgl. [Eckerson 2006]). Diese Gemeinsamkeiten zeigen, dass eine Abgrenzung von Scorecards und Dashboards nicht immer trennscharf vorzunehmen ist. Daher verwenden viele Menschen die beiden Begriffe als Synonyme. Ein tieferer Blick in die Literatur zeigt jedoch, dass diese Sicht falsch ist (vgl. [Eckerson 2006, S. 9f.]). Während Dashboards (siehe Abb. 13–2) den aktuellen Zustand erfassen (im Fahrzeug beispielsweise die Geschwindigkeit, den Reifendruck oder den Ladestand der Batterie), zeigen Scorecards (siehe Abb. 13–3) die Werte in Bezug zu einem definierten Ziel an (im Fahrzeug wäre dies eine Information, ob man sein Fahrziel pünktlich erreicht). Anders ausgedrückt heißt dies: Dashboards zeigen die Performance an und Scorecards stellen Entwicklungen (Trends) dar. Tabelle 13–1 fasst die Unterscheidungskriterien noch einmal zusammen. Dashboard

Scorecard

Verwendungszweck

Anzeige der Performance

Anzeige von Entwicklungen oder Fortschritten

Bereich

Performance-Monitoring

Performance-Management

Aktualität

Zeitnah, Real Time

Periodische Momentaufnahmen

Daten

Ereignisse

Zusammenfassungen, Aggregationen

Maße

Kennzahlen

Key-Performance-Indikatoren

Kontext

Ausnahmen

Ziele, Grenzwerte

Tab. 13–1

Unterschiede zwischen Scorecards und Dashboards

In dem Beispiel einer Scorecard (siehe Abb. 13–3) sind die Unterschiede gut zu erkennen: Für die aggregierten Key­Performance­Indikatoren wird ausschließlich eine monatliche Bewertung der Zielerreichung dargestellt, einschließlich der Tendenz. Auf die Darstellung der konkreten Werte wird in diesem Fall sogar ganz verzichtet.

2.

Eine detaillierte Darstellung der Eigenschaften findet sich u.a. in [Few 2006, S. 35].

13.2 Visualisierung der Information

Abb. 13–3

237

Beispiel für eine Scorecard

Aufgaben der Visualisierung

Daten in Informationen umzuwandeln ist die wichtigste Aufgabe der Visualisierung. Aus den Informationen generiert der Benutzer sein Wissen und leitet daraus Entscheidungen ab (siehe Abschnitt 1.1). Die Verwendung einer geeigneten Visualisierung trägt somit signifikant zur besseren Entscheidungsunterstützung im Management bei. In der Praxis werden die Darstellungsformen diesem Anspruch jedoch häufig nicht gerecht. Einerseits beschweren sich die Ersteller (z.B. die Controller), dass die Empfänger (z.B. das Management) ihre Informationen nicht nutzen oder zu wenig wertschätzen. Andererseits beklagen sich die Empfänger, dass sie die dargestellten Informationen nicht verstehen oder diese für ihre Aufgabe nicht geeignet sind. Diese nicht verstandenen Informationen sind daher keine Information im engeren Sinn, denn nur die verstandene Information verändert das Wissen des Empfängers und kann damit sein Entscheidungsverhalten beeinflussen (vgl. [Hichert 2003, S. 1]). Hichert (vgl. [Hichert 2008, S. 15]) vergleicht diese Situation mit den Redakteuren einer Tageszeitung, die sich über das fehlende Interesse der Leser beklagen. Er kommt letztendlich aber zu dem Schluss, dass die Verantwortung für den Inhalt und die Form der Aufbereitung bei den Redakteuren bzw. den Berichtserstellern liegt.

238

13 Verbesserung der Datenqualität in der Bereitstellung und Visualisierung

Es reicht nicht, dass eine BI­Anwendung die richtigen Kennzahlen lediglich anzeigt. Weitere fünf Anforderungen sind zu erfüllen: ■ Die Kennzahlwerte müssen korrekt, glaubwürdig und aktuell sein. ■ Die Kennzahlen müssen miteinander in Beziehung gebracht werden, um sinnvolle Vergleiche zu ermöglichen. ■ Die Informationen müssen für den Empfänger leicht und eindeutig verständlich dargestellt sein. ■ Die Informationen müssen dem Empfänger einen Mehrwert bieten. ■ Die Berichte sollen eine klare, eindeutige Aussage treffen und dem Empfänger eine Aktivität oder Maßnahme empfehlen. Natürlich ist es viel einfacher und weit verbreitet, auf möglichst vielen Berichtsseiten möglichst viele Werte und Detailinformationen anzuzeigen, anstatt auf einer Berichtsseite das Wesentliche zusammenzufassen und eine verwertbare Aussage zu treffen. Oft sind die vielen Seiten lediglich ein Rechtfertigungsmittel, ein Nachschlagewerk für die Controller. Der Empfänger ist auf sich allein gestellt: Wie soll er die Informationen richtig interpretieren? Missinterpretationen und falsche Entscheidungen sind die Folge. Regeln für eine bessere Visualisierung

Halten sich Projektteam und Fachbereich an folgende Regeln, können sie die Darstellung der Daten wirksam verbessern. Diese Regeln betreffen die Aspekte Motivation, Ausbildung und Design. Wichtigkeit der Informationsbereitstellung erkennen Unternehmen legen bei der Entwicklung einer BI­Anwendung den Fokus häufig auf die Integration, Bereinigung und Speicherung der Daten. Oft vernachlässigen sie dabei eine für den Empfänger verständliche und effiziente Darstellung. Allen beteiligten Projektmitgliedern muss jedoch bewusst sein, dass erst die Darstellung aus Daten Informationen macht. Sich allein auf die Speicherung der Daten zu konzentrieren ist eine Sackgasse. Denn entscheidend ist, was beim Empfänger ankommt. Leider fehlen den Projektmitarbeitern in der Regel sowohl dieses Bewusstsein als auch die erforderlichen Fähigkeiten. Dem entgegenzuwirken ist Aufgabe des Projektleiters. Oft helfen Workshops, in denen die Mitarbeiter schlechte und gute Beispiele vergleichen. Mitarbeiter schulen Die Teammitglieder wissen nicht, wie sie Informationen optimal darstellen können. Sie haben nicht die notwendigen Grundkenntnisse über die visuelle Informationsverarbeitung und ­speicherung beim Menschen und gutes Design. In einem BI­Projekt gibt es für diese speziellen Fragestellungen keine entsprechende Rolle: Zwar gibt es für die fachliche und physikalische Modellierung fachliche und tech-

13.2 Visualisierung der Information

239

nische (Chef­)Designer, die Rolle Informations­(Chef­)Designer fehlt hingegen. In der Regel fehlen solche Experten im ganzen Unternehmen; aber auch externe Berater werden nur selten damit beauftragt. Wer Darstellungsformen erstellen muss, ist entsprechend zu schulen und sollte anschließend viele Erfahrungen sammeln. Da es bei Designentscheidungen häufig um das richtige Maß geht, ist die Erfahrung besonders wichtig. In jedem Fall ist zu empfehlen, die Rolle eines Informations­Chef-Designers einzuführen. So wird gewährleistet, dass Informationsdarstellungs­Konzept und ­Design im gesamten Projekt durchgängig sind. Ist das nicht möglich, sollte zumindest ein Design­Team das Projekt temporär unterstützen. Informationsbedarf der Empfänger identifizieren Oft hat das Projektteam weder den fachlichen Hintergrund noch die konkreten Informationen, um zu entscheiden, welche Informationen der Empfänger für welche Entscheidungen tatsächlich benötigt. Hier klafft eine Riesenlücke zwischen dem Ersteller und dem Empfänger der Information. Die Konsequenz: Vorsichtshalber werden alle verfügbaren Informationen in der Struktur dargestellt, in der sie gespeichert wurden (z.B. im Data Mart). Natürlich erhalten alle Benutzer alle Navigationsmöglichkeiten (z.B. Drill­downs). Der Empfänger selbst muss die richtige Auswahl treffen, die Informationen verknüpfen und aufbereiten. Wer die Darstellungsformen entwickelt, muss eng mit den zugehörigen Fachbereichen zusammenarbeiten. Gemeinsame Workshops, regelmäßige Meetings, Prototypen etc. verhelfen den Entwicklern zu einem besseren Verständnis des tatsächlichen Informationsbedarfs der Benutzer. Umgekehrt erhalten die Benutzer besser dargestellte und leicht nutzbare Informationen. In manchen Projekten werden »Berichtspaten« aus dem Fachbereich eingesetzt, die den Entwicklern als feste, definierte Schnittstelle zu den anderen Mitgliedern des Fachbereichs dienen. Design vor der Realisierung festlegen Der Empfänger spezifiziert in der Regel nicht, was für ihn einen guten Bericht, ein gutes Dashboard oder eine gute Scorecard ausmacht. Die Spezifikation beschreibt nur, welche Kennzahlen in einem Bericht angezeigt werden − nicht aber wie. Erst die Nutzungsstatistiken, Beobachtungen der Benutzer bei der Arbeit und »Kaffeeküchengespräche« zeigen, ob die Informationsdarstellung gut oder schlecht war. Nur wenn der Benutzer die möglichen Darstellungsformen sieht, kann er sie auch beurteilen. Hier helfen Prototypen weiter. Sie ermöglichen Benutzern viel besser als eine schriftliche Spezifikation, ihre Informationsbedürfnisse zu definieren. Der Prototyp braucht nicht zwingend die gesamte Funktionalität der späteren Lösung abzubilden, oft reicht (zur Reduzierung des Aufwands) ein rein statischer Designprototyp.

240

13 Verbesserung der Datenqualität in der Bereitstellung und Visualisierung

Berichte zusammenfassen In vielen Unternehmen sind so viele Berichte vorhanden, dass die Benutzer oft nur mit Schwierigkeiten den Bericht mit den gesuchten Kennzahlen finden. In einem Unternehmen sollten nur die tatsächlich notwendigen Berichte existieren. Oft lassen sich Berichte zusammenfassen, die lediglich Abwandlungen voneinander sind. Zusammenfassen sollte man auch Berichte, die nur in ihrer Gesamtheit für den Benutzer die notwendigen Informationen liefern. Anstatt dem Benutzer zuzumuten, jeden Bericht einzeln zu öffnen und die Ergebnisse im Kopf, auf einem Papier oder in einem anderen Werkzeug zu integrieren, sollte der Berichtsersteller diese Arbeit erledigen und einen echten Mehrwert bieten. Natürlich müssen die Berichte in der Summe den gesamten Informationsbedarf der Benutzer abdecken – Lücken sind nicht tolerierbar. Damit der Benutzer leicht und zielsicher den für seine Frage relevanten Bericht findet, werden die Berichte mit Metadaten versehen. Weitere Informationen hierzu enthält Kapitel 14. Notation vereinheitlichen Landkarten sind sehr leicht verständlich, weil alle einer einheitlichen Notation folgen: Norden ist oben, Flüsse sind blau und Wälder grün. In Berichten, Scorecards und Dashboards ist das leider nicht so: In einem Bericht bedeutet eine grüne Säule einen Zuwachs, in einem anderen Bericht hingegen die Verkaufszahlen in Europa. Jeder Mitarbeiter, jede Abteilung erfindet eigene Notationen – das Verständnis beim Empfänger bleibt auf der Strecke. Der Hang zur uneinheitlichen Notation ist schwer nachvollziehbar. Warum vereinheitlicht man in einem Data Warehouse nur die Daten (»Single Point of Truth«) – und nicht auch die Darstellung? So muss sich der Empfänger durch die unterschiedlichsten Notationen für den gleichen Inhalt quälen und diese gedanklich selbst vereinheitlichen. Ein Architekt erfindet auch nicht für jeden Hausentwurf eine neue Notation, um die Bauarbeiter damit zu verwirren. Auch Farben werden klare Bedeutungen zugeordnet: So steht z.B. grün immer für Zuwächse, braun immer für Europa. Nach einer kurzen Gewöhnungsphase ist den Benutzern sofort die jeweilige Bedeutung klar, Vergleiche zwischen unterschiedlichen Darstellungen werden stark erleichtert. Um die Eindeutigkeit nicht zu stören, sollte man diese Farben nicht zur Dekoration oder für andere Zwecke verwenden. Gleiche Kennzahlen sollten immer die gleiche Skalierung besitzen. Diese Skalierung legt der Informations­Chef-Designer vorab für jede Kennzahl fest: So wird z.B. der Umsatz auf Ebene Region immer in Tausend Euro angegeben. Dann lassen sich die Umsätze verschiedener Regionen sehr viel leichter vergleichen. Abweichungen sind nur in begründeten Ausnahmefällen zulässig.

13.2 Visualisierung der Information

241

Sprachregelungen einführen In vielen Unternehmen findet man in den verschiedenen Darstellungsformen viele Synonyme und Homonyme: In einem Bericht steht die Abkürzung HR für Human Resources, in einem zweiten für Hire Rate und in einem dritten für Kroatien. Wieder bleibt es dem Benutzer überlassen, jeweils die richtige Bedeutung zu finden. Für die Datenmodellierung und ­integration im Data Warehouse werden Synonyme und Homonyme bereinigt – das muss auch für die Darstellung geschehen. Jeder Begriff sollte immer die gleiche Bedeutung haben. Botschaften formulieren Vielen Berichten (insbesondere den automatisch generierten) fehlt die konkrete Aussage. Sie weisen den Benutzer nicht explizit auf das Wissenswerte hin, er muss es sich selbst aus den Zahlen erarbeiten. Das trifft noch stärker auf Analysen, Scorecards und Dashboards zu. Darstellungsformen sollen etwas aussagen – ihre Botschaft muss klar erkennbar sein. Der Benutzer möchte schnell erkennen, ob der Bericht für ihn nützlich ist. Die Texte müssen Botschaften enthalten. Statt »Umsatzentwicklung 1996– 2004« schreibt man besser »Das durchschnittliche Wachstum von 2001 bis 2004 beträgt 8 Prozent pro Jahr«. Jede Botschaft sollte so konkret wie möglich sein, statt »Die Absatzmenge hat sich erhöht« ist besser »Die Absatzmenge hat sich im Vergleich zum Vorjahr um 12,3 Prozent erhöht«. Abbildung 13–4 zeigt an einem Beispiel, wie das gleiche Diagramm ohne konkrete Botschaft im Vergleich zu einer Darstellung mit unterschiedlichen Botschaften wirken kann. Geschäftsbereich AFG Nettoumsatz in Mio. EUR 402 1996 – 2004 330

307 309

333

366 305

388

327

1996 1997 1998 1999 2000 2001 2002 2003 2004 Budget

Das durchschnittliche Wachstum von 2001 bis 2004 beträgt acht Prozent pro Jahr ø Wachstum 8 % pro Jahr

Geschäftsbereich AFG Nettoumsatz in Mio. EUR 402 1996 – 2004 330

307 309

333

366 305

388

327

1996 1997 1998 1999 2000 2001 2002 2003 2004 Budget

Abb. 13–4

Der Plan von 2004 liegt um ein Prozent niedriger als das Ist 2000 Geschäftsbereich AFG Nettoumsatz in Mio. EUR 402 1996 – 2004 330

307 309

333

366 388 305

327

1996 1997 1998 1999 2000 2001 2002 2003 2004 Budget

Gleiches Diagramm ohne Botschaft im Vergleich mit unterschiedlichen Botschaften (vgl. [Hichert 2004])

–1 %

242

13 Verbesserung der Datenqualität in der Bereitstellung und Visualisierung

Die Darstellungsformen haben einen wirklichen Mehrwert für den Benutzer, wenn (wie bei Expertisensystemen (vgl. [Mertens/Meier 2009, S. 93ff.]) die im Data Warehouse vorhandenen Daten komprimiert, verständlich dargestellt, bewertet, erklärt und Handlungsempfehlungen gegeben werden. Allerdings bieten die aktuell vorhandenen Werkzeuge nur selten die hierfür benötigten Funktionen. Noch ist es zu schwierig, diese automatisch generierten Darstellungsformen mit informativem Mehrwert zu realisieren. Lediglich Workarounds, wie z.B. die nachträgliche Kommentierung, bieten diesen Mehrwert schon heute und sind in vielen Werkzeugen vorhanden. Mit relativ großem Aufwand verbunden sind Lösungen, bei denen über definierte Variablen in den Berichten entsprechende Botschaften aus den Kennzahlwerten generiert werden. Diese besitzen den Vorteil, dass die Erstellung vollautomatisiert (ohne Nachbearbeitung durch einen speziellen Benutzer) und schnell erfolgen kann. Darstellung strukturieren Mehrseitigen Berichten und Scorecards fehlt in der Praxis häufig eine Struktur – Tabellen, Zahlen, Grafiken, Diagramme werden wahllos platziert. Noch schlimmer sind falsche Strukturen, die nicht zusammenhängende Inhalte miteinander verbinden. Wie in einem guten Buch hilft eine gute Strukturierung dem Benutzer, die verschiedenen Darstellungsformen leichter zu lesen und zu verstehen. Ein positives Beispiel ist die Balanced Scorecard (BSC) [Kaplan/Norton 1992] mit ihren vier Perspektiven: Finanzen, Kunden, Prozesse und Potenziale. Innerhalb einer Perspektive sind die Kennzahlen hierarchisch in einem Kennzahlensystem gegliedert. Auch die Elemente innerhalb der gewählten Struktur müssen richtig gegliedert und positioniert werden. Beispiel: Soll der Benutzer in einem Bericht Diagramme miteinander vergleichen, sollten diese möglichst dicht nebeneinander positioniert sein. Die Beziehung zwischen diesen beiden Diagrammen lässt sich noch deutlicher visualisieren, indem man beide Diagramme mit einem Rahmen umschließt. Damit wird für den Benutzer sofort deutlich, dass diese Diagramme miteinander in Beziehung stehen. Falsch ist es, zusammenhängende Elemente künstlich durch einzelne Rahmen voneinander zu trennen. Im Umkehrschluss bedeutet das aber auch, dass nicht zusammenhängende Elemente nicht nebeneinander positioniert und auf gar keinen Fall durch Rahmen verknüpft werden dürfen. Das suggeriert dem Benutzer eine real nicht existierende Verbindung. Informationen priorisieren Häufig sind die Informationen auf dem Bildschirm nicht nach ihrer Wichtigkeit angeordnet. Das liegt daran, dass die Ersteller der Darstellungsformen nicht über eine Priorisierung nachdenken, der Fachbereich keine Vorgaben macht und den Erstellern wiederum das fachliche Wissen fehlt, um diese Priorisierung selbst durchzuführen.

13.2 Visualisierung der Information

243

Der Benutzer betrachtet die Bereiche des Bildschirms mit unterschiedlicher Aufmerksamkeit. In westlichen Ländern fokussieren die Betrachter stark auf den oberen linken Quadranten (siehe Abb. 13–5). Ursache hierfür ist die Schreibrichtung von oben nach unten und von links nach rechts. Dementsprechend wird der rechte untere Quadrant kaum beachtet, die beiden restlichen Quadranten verhalten sich neutral. Starke Aufmerksamkeit

Normale Aufmerksamkeit

Abb. 13–5

Normale Aufmerksamkeit

Keine Aufmerksamkeit

Visuelle Aufmerksamkeit für die verschiedenen Bildschirmbereiche (vgl. [Few 2008, S. 3f.])

Aus diesem Grund sollen die wichtigsten Informationen im oberen linken Bereich stehen. Falsch ist es, Unternehmenslogos, Navigationselemente oder sonstiges »Beiwerk« in diesen Quadranten zu stellen – für diese Elemente ist rechts unten der richtige Platz. Im täglichen Gebrauch nicht so oft benötigte Informationen (z.B. OnlineHilfe, Kennzahlenglossar) sind von häufig benötigten Informationen zu trennen. Selten benötigte Informationen sind zusätzlich und separat nur bei Bedarf einzublenden (z.B. über Links oder ein Menü). Dadurch haben die ständig benötigten Informationen mehr Platz. Dekoration und Beiwerk reduzieren Die vielfältigen Gestaltungsfunktionen der Werkzeuge verleiten die Projektmitarbeiter häufig dazu, die nützlichen Informationen mit nutzloser Dekoration zu »verschönern«.3 Sie gehen fälschlicherweise davon aus, dass die verschiedenen Darstellungsformen den Benutzer mehr unterhalten als informieren müssten – ein Problem, das viele auch aus Präsentationen mit Microsoft PowerPoint kennen. Auch viele Tabellenkalkulationsprogramme wie z.B. Microsoft Excel generieren automatisch dieses Beiwerk, das anschließend mühsam wieder entfernt werden muss. Ein Beispiel zeigt Abbildung 13–6. Wie alles Neue ziehen Dekorationen mit ihrer Attraktivität zunächst die Aufmerksamkeit der Empfänger auf sich, und die Informationen treten in den Hintergrund. Bei der täglichen Arbeit verlieren sie ihre Attraktivität, die Dekoration wird zunehmend als störend empfunden. Typisch sind farbige Hintergründe,

3.

Tufte hat hierfür den Begriff »Chartjunk« geprägt (vgl. [Tufte 1997, S. 107ff.]).

244

13 Verbesserung der Datenqualität in der Bereitstellung und Visualisierung

Umrahmungen, Logos, dekorative Bilder und Grafiken, Schatten, zweckfreie 3­D­Darstellungen und andere bedeutungslose Gestaltungselemente. Schlüssel zum Erfolg ist das richtige Maß: Die Dekoration darf den Benutzer nicht von den wichtigeren Informationen ablenken und zu viel Raum einnehmen. Skala überflüssig und ungenau

unnötiger und störender Hintergrund

Hilfslinien, die nicht helfen

fehlende Zahlenbeschriftung überflüssiger Rahmen

Umsatz 4 500 000 4 000 000

Säulen zu groß, zu breit, überflüssiger Rahmen

3 500 000 3 000 000 2 500 000 2 000 000 1 500 000 1 000 000 500 000 0

Umsatz

Luxusmodelle Sondermodelle Standardmodelle

Abb. 13–6

umständliche Legende Falsches Paradigma, Strukturen gehören in Balken

Beispiel für eine aus Microsoft-Excel erzeugte Grafik (vgl. [Bissantz et al. 2010, S. 445])

Darstellungsformen dienen zur Steuerung und zum Monitoring eines Unternehmens – und nicht eines Autos oder Flugzeugs. Oft versuchen die Ersteller ihre Darstellungen wie bekannte Instrumententafeln aussehen zu lassen, z.B. wie das Armaturenbrett eines Autos. Von diesem Versuch ist abzuraten. Tatsächlich besitzen die meisten Anzeigeelemente (z.B. aus dem Auto) nur eine geringe Informationsdichte: Die Tankanzeige zeigt nur den aktuellen Tankfüllstand an, aber keine Historie, keine Restreichweite und keinen Durchschnittsverbrauch. Dafür verbraucht diese Tankanzeige viel Platz, der sich für anderen Inhalt viel effizienter nutzen lässt. Ein Negativbeispiel für ein solches Dashboard zeigt Abbildung 13–7: Es beinhaltet z.B. Rundinstrumente, die wenig aussagen, aber viel Platz einnehmen, und eine nicht nachvollziehbare Skalierung (vgl. [Hichert 2010]).

13.2 Visualisierung der Information

Abb. 13–7

245

Negativbeispiel für ein Dashboard (Nachahmung eines Armaturenbretts)

Ein anderer Aspekt im Unternehmen ist ein Corporate Design, das oft viele und großformatige Grafikelemente enthält, die auch für die Darstellung in einem BI­Projekt verwendet werden sollen. Das Corporate Design darf jedoch die Arbeit der Mitarbeiter auf keinen Fall behindern. Grundsätzlich sollte es sehr sparsam und auch nur dann verwendet werden, wenn es zum besseren Verständnis beiträgt. Beispiel: Ein großes Unternehmenslogo auf jedem Bericht, jeder Scorecard und jedem Dashboard empfinden die Benutzer nur in der ersten, relativ kurzen Zeit nach der Einführung als gelungenes Design. Anschließend stört es bei der täglichen Arbeit und wird nur noch als Ärgernis empfunden. Möglichkeiten zur Kommentierung schaffen Viele kommerzielle Werkzeuge bieten keine Möglichkeiten zur Kommentierung innerhalb der Darstellungsformen. Damit entfällt z.B. die Möglichkeit zu erklären, warum ein Kennzahlwert so ist, wie er ist. Die Verständlichkeit und Nutzbarkeit für die Benutzer sinken, ganz abgesehen von dem zusätzlichen Aufwand, selbst eine Erklärung dafür zu finden. Erst die Erläuterung von Dateninhalten und deren Interpretation führt zum richtigen Verständnis beim Erstellen und Abrufen von Kennzahlen bzw. Reports. Kommentierungen erhöhen die Qualität in der Darstellung der Daten. Beispiel: In einem Dashboard eines Mobilfunkunternehmens wird ein niedriger Wert für die Kennzahl Netzqualität unterhalb des Sollwerts ausgewiesen, die zugehö-

246

13 Verbesserung der Datenqualität in der Bereitstellung und Visualisierung

rige Ampel ist rot, der Benutzer muss eine Entscheidung über seine Maßnahmen zur Lösung des Problems treffen. Nachdem er mithilfe von Analysen herausgefunden hat, dass die niedrige Netzqualität durch schlechte Werte in einem begrenzten Teil Deutschlands verursacht wurde, ist er damit der Problemlösung nur einen kleinen Schritt näher gekommen. Hätte der Verantwortliche für diese Kennzahl den Kommentar anhängen können, dass in der Region Düsseldorf/Köln/Bonn durch einen Sturm viele Mobilfunkzellen ausgefallen sind, hätte der Benutzer viel Zeit gespart und schneller eine geeignete Maßnahme treffen können. Eine Möglichkeit, Kommentierungen in Frontend-Tools zu integrieren, ist die Verwendung von HTML-Code als Überschrift für Tabellen(-zeilen und -spalten). So können diese Überschriften angeklickt werden und URLs aufrufen. Als Informationssystem sind im einfachsten Falle hier PDF-Dateien mit den Komplettbeschreibungen der Reports und Eingabedaten vorhanden, in denen der Anwender auf die ihn betreffende Inforation scrollen muss. Im komplexeren Falle kann die URL auf ein Content-Management-System verweisen, das diese Informationen in HTML anbietet (und über Sprungmarken zugänglich macht). Informationsdichte erhöhen Sehr oft veranschaulichen Grafiken und Bilder nur Trivialitäten. Der Ersteller ist der Meinung, dass der Empfänger komplexe Sachverhalte nur dann verstehen kann, wenn diese auf möglichst viele, einfache Bilder verteilt werden. Nicht umsonst gilt das Sprichwort: »Ein Bild sagt mehr als tausend Worte.« Komplizierte Sachverhalte lassen sich am besten über Bilder transportieren, da diese im Gegensatz zu Sprache und Schrift erstens parallele Informationen liefern, zweitens über zusätzliche Ausdrucksformen verfügen, drittens Informationen sehr stark verdichten und viertens die Affekte4 stärker ansprechen. Ein Bild sollte deshalb möglichst viele zusammenhängende Informationen, Beziehungen, Ursachen und Wirkungen darstellen. Diese werden durch die hohe Informationsdichte für den Empfänger sehr viel verständlicher. Weiterhin ist es wirkungsvoller, zusammenhängende Bilder auf einer Seite statt auf mehreren darzustellen (siehe Abb. 13–8 und 13–9). Der Empfänger findet so viel leichter die richtigen Zusammenhänge zwischen diesen Bildern.

4.

Affekt = Gemütsregung

13.2 Visualisierung der Information

247

Darstellung des Ergebnisses aller Sparten (1. Quartal 2008, Region Nord, in Mio. EUR ) 100 80 60 40 20 0 – 20 – 40 Kfz

Abb. 13–8

Unfall

Gebäude Haushalt

Leben

Haftpflicht

Risiko

Bild mit geringer Informationsdichte Ergebnis nach Sparten und Regionen in Mio. EUR (Q1/2008) Nord

Risiko

3,9

Haftpflicht Leben

Mitte

5,6

Abb. 13–9

5,9

5,7

4,4 3,5 25

Gebäude

Kfz

6,3

8,5

– 5,7

Haushalt – 20,4

Unfall

Süd

65

90 27,4 20,4

23,5

13,9 24,7

54 13,9 12,4

Bild mit höherer Informationsdichte

Wie sich die Informationsdichte ebenfalls erhöhen lässt, zeigt Abbildung 13–10: Für die drei Kennzahlen Umsatz, Anzahl Neukunden und Umsatzrendite sind die jeweiligen Zielbereiche mit zugehörigen Schwellwerten farbig gekennzeichnet, der aktuelle Wert ist über einen horizontalen, schwarzen Balken und der Zielwert über einen vertikalen schwarzen Strich dargestellt. Wieder ist die Informationsdichte sehr hoch: Alle Informationen sind auf relativ geringer Fläche dargestellt und auf einen Blick erfassbar.

248

13 Verbesserung der Datenqualität in der Bereitstellung und Visualisierung

Umsatz Mio. EUR 0

5

10

15

20

25

30

0

100

200

300

400

500

600

0

5%

10 %

15 %

20 %

25 %

30 %

Neukunden Anzahl

Umsatzrendite %

Abb. 13–10

Kombinierte Darstellung von Grenz-, Ziel- und aktuellen Werten (Beispiel)

Eine weitere Möglichkeit, sehr viele Informationen auf wenig Raum abzubilden, bieten die sogenannten Sparklines5. Es handelt sich hierbei um sogenannte Wortgrafiken, die benutzt werden, um Zahlen in einem Text auf Platz sparende Weise grafisch zu erklären. Der Nutzen dieser Art der Visualisierung liegt auf der Hand:6 »In der Form eines stark miniaturisierten (Zeitreihen­)Diagramms zeigen Sparklines die historische Entwicklung eines numerischen Werts und geben ihm so den Kontext, der für seine Interpretation wichtig ist.« 1999.1.1 65 months 2004.4.28 low

high

2003.4.28 12 months 2004.4.28 low

high

Euro foreign exchange $ 1.1608

1.1907

.8252 1.2858 $ 1.1025

1.1907

1.0783 1.2858

Euro foreign exchange ¥ 121.32

130.17

89.30 140.31 ¥ 132.54

130.17

124.80 140.31

Euro foreign exchange £ 0.7111

0.6665

.5711 0.7235 £ 0.6914

0.6665

0.6556 0.7235

Abb. 13–11

Preis des Euros über 65 bzw. 12 Monate in Bezug zu drei Währungen (vgl. [Tufte 2006, S. 8])

Achsenskalierung bei null beginnen In vielen Grafiken mit Wertereihen beginnt die Skalierung der Werteachse bei einem höheren Wert als null. Die Begründung: Der Benutzer bemerke die Veränderung sonst nicht. Dieses Vorgehen widerspricht der Grundregel: Stelle nur dar, was auch da ist. Gibt es keine Veränderung oder ist diese sehr klein, dann ist das ebenso. Durch eine abweichende Skalierung wird dem Benutzer meist nur eine eigentlich unwesentliche Veränderung der Kennzahl vorgegaukelt. In Abbildung 13–12 sind die Auswirkungen einer überhöhten Skalierung dargestellt. Auf den ersten Blick suggeriert das linke Diagramm, dass der Umsatz im vierten Quartal mehr als dreimal so hoch sei wie im ersten. Erst wenn der Benutzer die bei 20 beginnende Skalierung der Größenachse entdeckt, relativiert sich diese Steigerung. Im rechten Diagramm wurden die gleichen Werte mit einer Skalierung bei null richtig dargestellt – man erkennt sofort, dass die Umsatzsteigerung in der Realität nur marginal ist. 5. 6.

Entwickelt wurde diese Präsentationsform von Edward Tufte (vgl. [Tufte 2006, S. 7ff.]). vgl. http://de.wikipedia.org/wiki/Sparkline

13.2 Visualisierung der Information

249

Umsatz 2008 21,6 21,4 Umsatz 2008

21,2 25

21 20,8

20,5

21

21,5

1. Qrtl.

2. Qrtl.

3. Qrtl.

4. Qrtl.

15

20,6

10

20,4

5

20,2 20

20,4

20

0 1. Qrtl.

Abb. 13–12

2. Qrtl.

3. Qrtl.

4. Qrtl.

Auswirkungen einer erhöhten Skalierung (Beispiel)

Farben richtig wählen Einerseits werden Farben wahllos verwendet, andererseits werden sie häufig falsch ausgewählt. Beispiel: Entweder ist in den Berichten alles in grellen Farben dargestellt oder die unterschiedlichen Farben lassen sich schlecht voneinander unterscheiden. ■ Grelle, leuchtende Farben sind nur sparsam einzusetzen, da ansonsten beim Benutzer eine »Farbübersättigung« eintritt. Deshalb sollten sie nur wichtige Informationen hervorheben. ■ Dezente, matte Farben kennzeichnen Informationen, die nicht besonders hervorgehoben werden sollen. In beiden Fällen ist darauf zu achten, dass die verwendeten Farben leicht voneinander zu unterscheiden sind. Das trifft nur auf bestimmte Kombinationen von Farben zu, sodass man die verwendete Farbpalette vorab wohlüberlegt festlegen muss. Es ist kritisch zu prüfen, ob man Grün und Rot zur Darstellung von Ampeln verwendet. Zehn Prozent der Männer und ein Prozent der Frauen besitzen eine Rot­Grün­Blindheit und können somit diese beiden Farben nicht voneinander unterscheiden. Diesen Personen helfen verschiedene Farbintensitäten oder eindeutige Symbole weiter. Um den Benutzer gezielt auf die wichtigsten Informationen hinzuweisen, ist insbesondere bei Ampeln zu empfehlen, nur die anzuzeigen, die vom Benutzer eine Aktion verlangen. Ampeln mit der Aussage, dass alles in Ordnung ist, sind unnötig: Sie lenken nur von eigentlichen Problemen ab. Werden wenige Ampeln oder Symbole gezielt gesetzt, fallen diese dem Benutzer sehr viel deutlicher und schneller auf.

250

13 Verbesserung der Datenqualität in der Bereitstellung und Visualisierung

Tabellen und Diagramme richtig einsetzen Viele entscheiden aus dem Bauch heraus, ob sie Zahlen als Tabelle oder Diagramm darstellen. Häufig sieht man auch die Unsitte, beides gleichzeitig anzuzeigen. Weder das Bauchgefühl noch der Drang nach Abwechslung sind entscheidend. Nach Few (vgl. [Few 2004, S. 41ff.]) gelten feste Kriterien: ■ Tabellen sind vorzugsweise zu verwenden, wenn • spezielle Werte nachgeschlagen werden sollen (z.B. der Umsatz im Februar 2008), • diese speziellen Werte miteinander zu vergleichen sind (z.B. der Umsatz mit der Anzahl der Anrufe im Callcenter im Februar 2008), • eine Anforderung an die Genauigkeit der Werte besteht oder • die quantitativen Werte in mehr als einer Einheit vorliegen. ■ Diagramme eignen sich, wenn • der Verlauf der Werte oder • die Beziehung zwischen mehreren Werten dargestellt werden soll. Regeln zur Organisation und Sicherheit

Damit die Präsentation der Daten ihre Aufgabe erfüllt, müssen neben den Regeln für eine bessere Visualisierung auch einige organisatorische und sicherheitstechnische Regeln eingehalten werden. Zugriff nur über semantische Schicht erlauben Die semantische Zugriffsschicht der Business­Intelligence­Plattform ist die alleinige Quelle für die Präsentation von Daten (siehe Abschnitt 13.1): Wer Darstellungsformen erstellt, darf nur freigegebene Datencontainer und definierte, zulässige Beziehungen verwenden. Freigabeprozess für Darstellungsformen etablieren In einer BI­Anwendung können in der Regel neben den privaten Darstellungsformen, die nur für den jeweiligen Ersteller sicht­ und nutzbar sind, auch öffentliche Darstellungsformen für andere Benutzer publiziert werden. Für diese öffentlichen Darstellungsformen hat sich in der Praxis ein zweiteiliger Freigabeprozess bewährt, damit die Erfüllung der Qualitätsanforderungen vor der endgültigen Veröffentlichung überprüft wird. Der erste Teil des Freigabeprozesses betrifft den Ersteller der jeweiligen Darstellungsform. Mithilfe einer Checkliste überprüft dieser die Voraussetzungen für eine Veröffentlichung. Typische Kriterien sind: Wurden die Kennzahlen abgestimmt? Wurden die neuen Kennzahlen in das Glossar aufgenommen? Wurde die Notation eingehalten? Wurden die zugehörigen Metadaten ins Repository eingetragen? Die Checkliste kann auch um Kriterien außerhalb des Datenqualitätsma-

13.3 Empfehlungen

251

nagements ergänzt werden: Wurden Testfälle erstellt? Wurden die Testfälle erfolgreich durchgeführt? Sind alle Kriterien erfüllt, gibt der Ersteller seine Darstellungsform für den zweiten Teil des Prozesses frei. Beispiel: Der Ersteller muss in einer elektronischen Checkliste die Erfüllung der einzelnen Kriterien durch Aktivierung der zugehörigen Checkboxen bestätigen und anschließend explizit auf einen Freigabe­Button drücken. Der Vorteil: Für den Ersteller steigt die Verbindlichkeit, diese Kriterien zu überprüfen. Im zweiten Teil des Freigabeprozesses überprüft der Freigebende, ob der Ersteller alle Kriterien eingehalten hat. Im negativen Fall muss der Ersteller die Darstellungsform nachbearbeiten. Im positiven Fall bewertet der Freigebende die Darstellungsform nach übergreifenden Kriterien. Beispiele für diese Kriterien sind: Existiert im Unternehmen bereits eine ähnliche Darstellungsform? Bietet die Darstellungsform einen Mehrwert für die Benutzer? Veröffentlichungsrechte für Darstellungsformen festlegen Damit die Darstellungsformen den gestellten Qualitätsanforderungen genügen, sollte diese Veröffentlichung auf einen begrenzten Benutzerkreis eingeschränkt werden. Dieser Benutzerkreis wird vorher entsprechend geschult: Notation, Design-Konzept, Regeln für eine bessere Visualisierung, Metadatenerstellung/ ­nutzung und Freigabeprozess sind einige der Inhalte. Zur Verbesserung der Qualität kann wie bei der Zwischenschicht ein Vier­Augen­Prinzip für die Erstellung eingeführt werden. Dieses ergänzt den vorab beschriebenen Freigabeprozess.

13.3 Empfehlungen Dieses Kapitel hat deutlich gezeigt, wie wichtig die visuelle und inhaltliche Gestaltung von Berichten, Analysen und Dashboards für die Steigerung der Informationsqualität ist. Bereits wenige Gestaltungsregeln, wie z.B. die Formulierung klarer Botschaften, die konsequente Standardisierung und Strukturierung sowie die Reduzierung auf das Wesentliche führen zu ersten Erfolgen. Dem interessierten Leser sind zum einem die Veröffentlichungen von Rolf Hichert (www.hichert.com), einem der Pioniere auf diesem Gebiet, sowie die Bücher von Stephen Few (vgl. [Few 2008]) und Edward Tufte (www.edwardtufte.com) zu empfehlen. In der TDWI Edition ist ebenfalls ein umfangreiches Werk zum Thema »Visual Business Analytics« erschienen (vgl. [Kohlhammer/ Proff/Wiener 2013]). Interessante Diskussionen zum Thema Visualisierung von Geschäftsdaten finden sich auch in den beiden Blogs »http://blog.bissantz.de« und »http://www.bella­beraet.de«.

252

13 Verbesserung der Datenqualität in der Bereitstellung und Visualisierung

253

14 Wertschöpfung durch Metadaten

Der Nutzen einer BI­Anwendung hängt sehr stark davon ab, ob der Anwender die zur Bewältigung seiner Aufgaben notwendigen Informationen in der geforderten Datenqualität bekommt. Für die systematische Analyse sind neben den Nutzdaten (unabhängig vom Detaillierungsgrad) auch Informationen über den Aufbau, die Relevanz oder die Aktualität nötig. Die Daten in den operativen Systemen enthalten in der Regel wenig von dieser zusätzlichen Semantik. Erst im Rahmen der Übertragung in ein Data Warehouse werden diese Informationen (sogenannte Metadaten) hinzugefügt: Somit beinhalten erst die Metadaten die eigentlich wertschöpfende Funktion für die weitere Analyse der Daten und stellen damit eine der wichtigsten Quellen für das Management der Datenqualität dar. Die gewachsene Bedeutung von Metadaten spiegelt sich auch in der Architektur des DW 2.0 (vgl. [Inmon/Strauss/Neushloss 2008, S. 95ff.]) wider, in die Inmon das Metadaten­Repository explizit als Komponente aufgenommen hat. Der folgende Abschnitt 14.1 definiert zunächst einige Begriffe und stellt mögliche Strukturierungen von Metadaten vor. In Abschnitt 14.2 werden anschließend verschiedene Repository­Architekturen vorgestellt. Den Schwerpunkt dieses Kapitels bilden die Abschnitte 14.3 und 14.6, die sich mit dem Metadatenmanagement sowie der Erstellung und Nutzung von Metadaten beschäftigen.

14.1 Metadaten: Begriff und Strukturierung In der Literatur werden Metadaten oft als »Daten über Daten« beschrieben. Die Vorsilbe Meta (griechisch meta = nach, über) bedeutet, dass es sich um einen Begriff handelt, der eine Beschreibung von etwas, dem sogenannten Betrachtungsobjekt, enthält. Metadaten sind also als Daten anzusehen, die jeweils eine Abstraktionsstufe über den zu beschreibenden Daten liegen.1 Auch wenn diese Beschreibung oft als wenig aussagekräftig kritisiert wird (vgl. [Devlin 1997, S. 52]), ist sie dennoch als gemeinsame Basis aller Definitionen anzusehen. Prägnanter ist dage1.

Anzahl der Stufen ist dabei theoretisch beliebig, d.h., das Präfix ist relativ und nicht absolut zu sehen.

254

14 Wertschöpfung durch Metadaten

gen die Definition von Jossen u.a. (vgl. [Jossen et al. 2009, S. 345ff.]), die Metadaten als »jede Art von Information, die für den Entwurf, die Konstruktion und die Benutzung eines Informationssystems benötigt wird« beschreiben, wie auch die Definition von Rowohl u.a.: »Metadaten im Rahmen des Data Warehousing sind all diejenigen Daten, die geeignet sind, Fragen über die im Data Warehouse enthaltenen Daten, deren Transformationen und der sie umgebenden Systeme zu beantworten« (vgl. [Rowohl/Schwarz/Strauch 2000, S. 5]). Bezüglich der Nutzung von Metadaten wird grundsätzlich zwischen passiver, aktiver und semiaktiver Nutzung unterschieden (vgl. [Staudt/Vaduva/Vetterli 1999, S. 5f.]). Bei passiver Nutzung liegt der Schwerpunkt auf der Dokumentation über Aufbau und Nutzung der BI­Anwendung. Die Metadaten haben somit keinen Einfluss auf das Verhalten zur Laufzeit. Bei aktiver Nutzung steuern Metadaten z.B. die Ausführung von Transformationsprozessen. Wenn Metadaten zur Laufzeit zwar gelesen, aber nicht direkt zur Steuerung genutzt werden, spricht man von semiaktiven Metadaten. Grundsätzlich lassen sich zwei Sichtweisen bei der Betrachtung der Nutzenpotenziale von Metadaten im Kontext Business Intelligence herausarbeiten: die Anwender­ und die Entwicklersicht (siehe Abb. 14–1). Für den Anwender steht die Steigerung von Effektivität und Effizienz bei der Nutzung der Inhalte des Data Warehouse im Mittelpunkt (z.B. durch die Begriffsvereinheitlichung oder die Anfrageoptimierung). Aus Sicht der Entwickler gilt es, den Aufwand für die Administration oder die Weiterentwicklung zu minimieren.

Metadatenmanagement Anwender

Entwickler

Begriffsvereinheitlichung Orientierung über Datenangebot

Terminologie

Abfrageoptimierung

Analyse

Erleichterte Dateninterpretation

Organisationsbezug

Verbesserte Benutzerakzeptanz

Unterstützung bei Administration

Metadaten Metadatenhistorie

Objektdaten

Qualität

Unterstützung bei Zugriffskontrolle

Transformation

Vereinfachte Datenintegration

Systembezug

Auswirkungsanalysen

Struktur/ Bedeutung

Vereinfachte Fehlersuche Verbesserte Wiederverwendbarkeit

Verkürzte Einarbeitungszeit

Expertenidentifikation

Qualitätskontrolle

Nutzenrealisierung

Abb. 14–1

Nutzenpotenziale Metadaten (vgl. [Auth 2004, S. 181])

Durchgängige Dokumentation

14.2 Metadatenarchitekturen

255

In der Literatur findet man eine Vielzahl von Strukturierungsmöglichkeiten (vgl. [Lehmann 2001, S. 83ff.] oder [Staudt/Vaduva/Vetterli 1999, S. 18ff.]). Als Beispiel sei an dieser Stelle kurz auf die oft gewählte Unterscheidung in fachliche und technische Metadaten eingegangen (vgl. [Inmon/O’Neil/Fryman 2008, S. 12ff.] oder [Do/Rahm 2000, S. 3ff.]). Fachliche Metadaten beschreiben die betriebswirtschaftlichen Zusammenhänge der Daten sowie das verwendungsnotwendige Wissen (fachliche Definition von Kennzahlen oder eine Übersicht der im Unternehmen vorhandenen Berichte). Da dieses oftmals nur als implizites Wissen bei den Anwendern vorhanden ist, muss es erst strukturiert und manuell erfasst werden, um als explizites Wissen in Form von Metadaten zur Verfügung zu stehen (vgl. [Auth 2004, S. 40]). Die existierenden Metadatenstandards (siehe Abschnitt 14.2) sind mehr auf den Metadatenaustausch zwischen Werkzeugen ausgerichtet und enthalten nur im geringen Umfang Metadaten, die das Verständnis der Daten auch für Benutzer verbessern. Die technischen Metadaten beschreiben eher den Aufbau und die Struktur eines Data Warehouse (z.B. Schemaspezifikationen, APIs, SQL­Befehle) und sorgen damit für eine korrekte Verarbeitung der Daten. Die Beschreibungen der Datenstrukturen liegen z.B. im Data Dictionary der Datenbank. Informationen über die Transformationen liegen im Repository des ETL­Werkzeugs vor. Dazu kommen Statistiken über Verteilungen von Datenzugriffen oder Systemverfügbarkeiten. Für die Akzeptanz und den nachhaltigen Erfolg einer BI­Anwendung müssen die Anwender im Datenbestand problemlos navigieren können, indem sie beispielsweise einen »Business Information Guide« (vgl. [Devlin 1997, S. 276f.]) nutzen. Dies wird aber nur funktionieren, wenn eine Verknüpfung von technischen (z.B. Datenmodell, Transformationen) und fachlichen Metadaten (z.B. Fachbegriffe oder Verantwortlichkeiten) existiert (vgl. [Melchert 2004, S. 10]).

14.2 Metadatenarchitekturen Der Erfolgsfaktor zur Hebung der beschriebenen Nutzenpotenziale ist die übergreifende Verwaltung aller Metadaten – über System­, Werkzeug­ und Schichtengrenzen hinweg. Aufgabe dieses Metadatenmanagements ist es, die Metadaten zu erfassen, zu generieren, zu speichern, zu verwalten und den Benutzern zur Verfügung zu stellen. Dies geschieht in der Regel in einem Metadaten­Repository, dem zentralen Bestandteil der Architektur eines Metadatenmanagementsystems. Für die Implementierung eines Metadaten­Repositorys gibt es drei Architekturvarianten (siehe Abb. 14–2), die verschiedene Vor­ und Nachteile besitzen. Das Projektteam wählt die passende Variante je nach den spezifischen Anforderungen im Projekt.

256

14 Wertschöpfung durch Metadaten

Zentrales Repository DWHKomponente A

DWHKomponente B

Zentrales Repository

Metadatenflüsse

DWHKomponente A

DWHKomponente B

Lokales Repository

DWHKomponente C

Metadaten flüsse

• Konsistenz + • Global verfügbar • Hohe Abdeckung • Niedrige Schnitt• stellenkomplexität • Redundanzfreiheit

• Niedrige – • Ausfallsicherheit • Langsamer Zugriff • Toolsituation • Mittlere bis • hohe Kosten

Lokale Repositorys DWHKomponente C Lokales Repository

Lokales Repository

• Maximale • Autonomie • Schneller Zugriff • Geringe Kosten

+

• Hohe Schnitt– • stellenkomplexität • Niedrige Abdeckung • Integrität und • Konsistenz

Lokale Repositorys mit zentralem Repository DWHKomponente A

DWHKomponente B

DWHKomponente C

Lokales Repository

Lokales Repository

Lokales Repository

Zentrales Repository

Abb. 14–2

• Integrierte Sicht auf Metadaten • Autonomie bleibt gewährleistet • Geringe Schnittstellenkomplexität • Kontrollierte Replikation

+

Metadaten flüsse

Metadatenarchitekturen

Zentrales Metadaten-Repository

Bei einem zentralen Metadaten­Repository werden alle Metadaten in einem einzigen Repository gespeichert. Alle Data-Warehouse-Komponenten greifen ausschließlich auf dieses Repository zu, es werden keine Metadaten lokal gehalten. Hauptvorteile dieser Architektur sind die Konsistenz, der hohe Abdeckungsgrad und die globale Verfügbarkeit aller Metadaten, außerdem ist die Schnittstellenkomplexität niedrig. Für den Metadatenaustausch benötigt jede Komponente lediglich eine Schnittstelle zum zentralen Repository. Doch ein zentrales Repository birgt auch einige gravierende Nachteile. Durch die räumliche Trennung ist die Kommunikation in der Regel langsam, das zentrale Repository wird somit leicht zum Flaschenhals für die Metadatenflüsse. Die Ausfallsicherheit ist grundsätzlich gering, sofern keine Gegenmaßnahmen (z.B. durch hochverfügbare Lösungen) getroffen werden. Bei Nichtverfügbarkeit des zentralen Repositorys oder Verbindungsstörungen ist keinerlei Metadatenaustausch mehr möglich. Die Kosten sind bei Einsatz eines Produkts höher als bei den anderen Varianten, bei einem individual entwickelten Repository sind sie jedoch noch viel höher. Trotz der Vorteile eines zentralen Repositorys findet man diese Architektur in der Praxis selten. Die Ursache liegt hauptsächlich im Fehlen von etablierten und vollständigen Metadatenstandards. Die Metadatenmodelle und ­strukturen der meisten Werkzeughersteller sind in der Regel proprietär und in vielen Fällen auch

14.2 Metadatenarchitekturen

257

undokumentiert, sodass die Integration in einem zentralen Repository unmöglich wird. Zudem fehlen diesen Werkzeugen offene Schnittstellen, um die Metadaten in einem externen Repository zu speichern. Über die bestehenden Schnittstellen kann meistens nur ein kleiner, nicht ausreichender Teil des Metadatenbestands ausgetauscht werden. Lokale Metadaten-Repositorys

In dieser Architekturvariante verwaltet jede Data-Warehouse-Komponente ihre Metadaten selbst in einem lokalen Repository. Die anderen Komponenten greifen bei Bedarf über Schnittstellen auf diese Metadaten zu, es werden keine Metadaten zentral gehalten. Diese Architektur hat gegenüber einem zentralen Repository mehrere Vorteile: Erstens ist die Autonomie hoch, zweitens sind die Kosten niedrig, drittens erlaubt sie einen schnellen Zugriff und viertens können so mehr Werkzeuge eingesetzt werden, auch solche, die nur ein lokales Repository unterstützen. Im Gegensatz dazu verschärft sich allerdings die Schnittstellenproblematik: Die Schnittstellenkomplexität ist hoch. Für den Metadatenaustausch muss jede DataWarehouse-Komponente mit allen anderen Komponenten kommunizieren. Der Abdeckungsgrad und der Integrationsgrad sind jedoch gering, die redundante Metadatenhaltung ist hoch. Außerdem erlauben die meisten Werkzeuge nur einen Metadatenaustausch unidirektional über einen Dateiexport, was den automatisierten Austausch erschwert. Zusätzlich können abhängig von der Architektur bei Nichtverfügbarkeit dezentraler Metadaten unerwünschte Verzögerungen im ETL-Prozess auftreten. Trotz dieser Nachteile ist diese Architektur in der Praxis weit verbreitet, da sie am einfachsten und kostengünstigsten zu realisieren ist. Das darf aber nicht darüber hinwegtäuschen, dass die Nutzbarkeit der Metadaten bei dieser Variante am geringsten ist. Lokale Repositorys mit zentralem Repository

Hierbei handelt es sich um eine Kombination der beiden bereits vorgestellten Architekturvarianten. Wie bei den lokalen Repositorys verwenden die DataWarehouse-Komponenten ihre eigenen Repositorys, zusätzlich werden die Metadaten aber in ein zentrales Repository repliziert.2 Der Metadatenaustausch zwischen den Komponenten erfolgt über das zentrale Repository. Auch wenn dieser Ansatz die Vorteile der beiden zugrunde liegenden Alternativen erfolgreich verbindet und die Nutzbarkeit der Metadaten erhöht, ist diese Architektur in der Praxis leider nur selten zu finden.

2.

Diese Variante ist in der Literatur auch unter der Bezeichnung »Föderiertes Repository« bekannt.

258

14 Wertschöpfung durch Metadaten

Standards zum Metadatenaustausch

Seit Jahren wird versucht, den Austausch von Metadaten durch die Einführung von Metadatenstandards zu erleichtern (vgl. [Melchert 2003, S. 89 ff.]). Ein prominentes Beispiel ist das Common Warehouse Metamodel (CWM).3 In der Praxis bewährt und durchgesetzt haben sich diese Standards aber aus folgenden Gründen nicht: Erstens sagen zwar alle Hersteller, dass ihre Produkte CWM unterstützen. In der Praxis sind die verschiedenen Versionen aber nicht kompatibel, da die Hersteller kein großes Interesse daran haben, ihre Metadaten mit den Produkten anderer Hersteller austauschbar zu machen. Zweitens beinhalten die Standards nur einen Teil der benötigten Metadatenobjekte, sodass ein erheblicher Teil nicht über den Standard austauschbar ist. So bleibt derzeit in der Regel nur eine einzige Möglichkeit, nämlich die Metadaten über individuell erstellte Metadatenstrukturen und ­schnittstellen auszutauschen.

14.3 Metadatenmanagement Für die erfolgreiche Steuerung der Datenqualität sind Metadaten unerlässlich, um eine ausreichende Daten- und Prozessqualität zu erreichen. Vor der Erstellung der Metadaten muss das Projektteam in einem dreistufigen Prozess ein geeignetes Metadatenmanagement einführen. Dazu muss es ■ zunächst die Anforderungen aufnehmen, ■ daraufhin die Metadatenstrategie erstellen und ■ anschließend das Metadatenmanagement implementieren. Im ersten Schritt nimmt das Projektteam die Anforderungen an das Metadatenmanagement auf. Die Anforderungen geben Antwort u.a. auf folgende Fragen: Wozu brauchen wir im Projekt die Metadaten? Welche Metadaten brauchen wir konkret? Wie viel Metadatenintegration ist erforderlich? Welche Arten des Zugriffs auf die Metadaten braucht der Benutzer? Die klare Festlegung dieser Anforderungen schafft im Unternehmen ein gemeinsames Verständnis und bildet die unabdingbare Basis für die weiteren Schritte. In der Praxis hat es sich bewährt, die Frage nach dem Zweck der Metadaten durch eine Priorisierung der Nutzenpotenziale (siehe Abb. 14–1) zu beantworten. Anhand der Ergebnisse lässt sich der Bedarf leichter einordnen, außerdem können die Maßnahmen auf Basis der Priorisierung besser gesteuert werden. Dabei muss das Projektteam darauf achten, wirklich alle Nutzerklassen der Metadaten in die Abfrage mit einzubeziehen. Der Grund: Ein Entwickler braucht in der Regel die Metadaten aus anderen Gründen als ein Empfänger eines Berichts.

3.

siehe omg.org/technology/cvm

14.3 Metadatenmanagement

259

Die Anforderungen an den Umfang der Metadaten bestimmen die benötigten und bereitzustellenden Metaobjekte. Dazu zählen insbesondere die Metadaten zu den Quellsystemen, die Beschreibungen von Datenobjekten, -strukturen und -flüssen, die Metadaten zur Datenqualität und die Beschreibungen von Schnittstellen. Beispiele finden sich in Abschnitt 14.4. Das zugrunde liegende Metamodell sollte möglichst flexibel und um unternehmensspezifische oder zusätzliche Metaobjekte erweiterbar sein. Anhand dieser Anforderungen erstellt das Team anschließend eine spezifische Metadatenstrategie für das Projekt. Es wählt die geeignete Metadatenarchitektur aus, die sich aus der Theorie (siehe Abschnitt 14.2) und den tatsächlichen Rahmenbedingungen und Anforderungen im Projekt ergibt. Die Architektur muss alle Komponenten abdecken, dazu zählen insbesondere die Architektur der Schnittstellen, der Metadaten-Repositorys, der Middleware­ und der FrontendWerkzeuge. Weiterhin konzipiert das Projektteam das Metadatenmanagement mit folgenden vier Zielen: Das Metadatenmanagement soll erstens einen eindeutigen Zweck mit einem passenden Aktionsplan besitzen und der Erfolg muss messbar sein. Zweitens sollen die erfassten Metadaten korrekt, aktuell, vollständig, konsistent und zugänglich sein. Die verwendete Technologie muss drittens skalierbar, robust und zuverlässig sein. Und viertens soll der Zugang zu den Metadaten für alle Benutzer leicht möglich sein. Da ein effektives Metadatenmanagement häufig sehr viel Geld kostet, muss für diese Strategie immer eine Kosten-Nutzen-Analyse durchgeführt und der Return On Investment (ROI) vom Projektteam zweifelsfrei nachgewiesen werden. Gleichzeitig werden so die Anforderungen identifiziert, die mit den geringsten Kosten den höchsten Mehrwert erzielen. Dazu werden die Nutzenpotenziale für die vorliegende Metadatenstrategie qualitativ, aber vor allem quantitativ beurteilt. Mit diesen Erkenntnissen kann das Projektteam bei Bedarf die Priorisierung der Nutzenpotenziale um eine Stufenplanung erweitern, um die Investitionen besser auf die Zeitachse zu verteilen und hohe Investitionen zu Beginn zu vermeiden. In der Praxis hat es sich bewährt, die Erfassung und Integration der Metadaten wie folgt zu gliedern: ■ Stufe 1: zu den Datenmodellen des BI­Systems und den Datenquellen ■ Stufe 2: zu den ETL­Prozessen und den Ladeläufen ■ Stufe 3: zu den Reports, Analysen und Dashboards/Scorecards ■ Stufe 4: zu den Geschäftsprozessen ■ Stufe 5: zum Rest

260

14 Wertschöpfung durch Metadaten

Ein Beispiel für den quantitativen Nutzen ist die metadatenbasierte Auswirkungsanalyse (Lineage). Damit ist das Projektteam in der Lage, bei notwendigen Programmänderungen alle davon betroffenen Teile eindeutig und vollzählig zu identifizieren. Eine aufwendige und fehlerträchtige Suche innerhalb der Programme wird somit vermieden, woraus sich eine deutliche Ersparnis an Zeit und Geld ergibt. Im letzten Schritt erfolgt die Implementierung mit der fachlichen, organisatorischen und technischen Umsetzung des Metadatenmanagements. Nicht vergessen werden darf in diesem letzten Schritt, die Nutzer in dem Metadatenmanagement zu schulen. Schließlich sollen die Metadaten nicht nur am Anfang des Projekts korrekt und vollständig sein, sondern es im gesamten Lebenszyklus des BI-Systems auch bleiben. Seit kurzem hält auch das Web 2.0 Einzug in das Metadatenmanagement. Mithilfe dieser Technologien kann der Nutzer die Metadaten nicht nur abrufen – er kann sie sogar kommentieren oder ändern. Einerseits ist das ein Segen, da Metadaten somit einfach und schnell geändert werden können und die Qualität verbessert werden kann. Andererseits ist es aber auch ein Fluch, da Metadaten dadurch verfälscht werden können. Werden Web­2.0­Technologien (z.B. ein Wiki) für die Bearbeitung der Metadaten eingesetzt, sind geeignete Maßnahmen zur Verhinderung solcher Verfälschungen zu treffen. Beispielsweise könnten Änderungen in einem Freigabeprozess qualitätsgesichert und erst danach veröffentlicht werden. Erfolgreicher ist, wer Web­2.0­Technologien gezielt und überlegt als Ergänzung etablierter Technologien einsetzt – für sich allein betrachtet sind sie keine gute Lösung.

14.4 Metadatenkategorien Im Umfeld von BI­Lösungen kommt den Metadaten ein besonderer Stellenwert zu. Tabelle 14–1 zeigt anhand der Referenzarchitektur aus Kapitel 5 Beispiele dazu. Layer der BI-Referenzarchitektur

Beispiele für Metadaten

Anwender und Rollen

Benutzerprofile, Rollen etc.

Informationsverarbeitung

Kennzahlen, Reports, Nutzungsfrequenz der Reports etc.

Datenhaltung

Tabellen, Aufbau der Datenwürfel, Granularitäten, Dimensionshierarchien etc.

Datenintegration

Datenflüsse, Mapping-Regeln, Harmonisierungen etc.

Datenquellen

Hardware, Netze, Datenstrukturen, Extraktionslogik etc.

Tab. 14–1

Metadaten entlang der BI-Referenzarchitektur

In den folgenden Abschnitten wird detaillierter auf die einzelnen Kategorien eingegangen.

14.4 Metadatenkategorien

261

Datenquellen

Zu den am Data Warehouse angebundenen Datenquellen müssen Informationen zur verwendeten Hardware sowie die Strukturdefinitionen wie z.B. über das Datenbankschema vorliegen (technische Metadaten). Weiterhin sind fachliche Metadaten z.B. zur Codierung des Attributs GESCHLECHT (m = männlich, w = weiblich) wichtig. Angaben zu der erwarteten Anzahl von durchschnittlich zu extrahierenden Datensätzen erleichtern die Planung der ETL-Prozesse. Datenintegration

Die technischen Metadaten innerhalb der Datenintegrationsschicht beschreiben den Datenfluss von den Quellsystemen bis zu den Zielstrukturen. Dazu gehören die Regeln zur Extraktion, Selektion und Transformation der operativen Daten. Wichtig sind hierbei insbesondere die Angaben zur Datenverwendung, d.h. die Informationen, aus welchen Quellen die Daten stammen und wohin sie gespeichert werden. Daraus lassen sich später gezielt Abhängigkeiten zwischen den verschiedenen Objekten und Strukturelementen ermitteln.

Abb. 14–3

Metadaten zu Datenflüssen

Zur Laufzeit der Datenflussprozesse werden in der Regel folgende Metadaten berechnet und gespeichert: Beginn und Ende des Prozesses, Dauer, Anzahl der verarbeiteten Datensätze, Anzahl der aufgetretenen Fehler und der Endestatus (siehe Abb. 14–4).

262

14 Wertschöpfung durch Metadaten

Abb. 14–4

Anzeige der Laufzeitinformationen zu einem Prozess

Die Metadaten zu Schnittstellen gleichen denen zu Datenobjekten und -strukturen. Zusätzlich werden auch Metadaten zur geforderten Qualität in Form eines Service Level Agreement erstellt. Datenhaltung

Im Rahmen der Datenhaltung wird zu den Datenobjekten jeweils eine Beschreibung erfasst (siehe Abb. 14–5). Erfolgreich ist, wer für den jeweiligen Leserkreis eine fachliche und eine technische Beschreibung erstellt. Die Datenstrukturen besitzen typischerweise folgende Metadaten (siehe Abb. 14–6): ■ ■ ■ ■ ■

Beschreibung (fachlich und technisch), Datentyp, Domänen, Formate (z.B. für das Geburtsdatum) und Muster (z.B. für deutsche Rentenversicherungsnummern).

Abb. 14–5

Metadaten zu einer Tabelle

14.4 Metadatenkategorien

Abb. 14–6

263

Metadaten zu den Spalten einer Tabelle

Informationsbereitstellung

Die fachlichen Metadaten zur Beschreibung der betriebswirtschaftlichen Zusammenhänge werden vom Projektteam in Befragungen mit fachlichen Experten erstellt, da dieses Wissen zumeist nur in deren Köpfen vorhanden ist (siehe Abschnitt 14.1). Für die effiziente Erfassung erstellt das Projektteam vordefinierte Formulare (siehe Tab. 14–2). Nr.

Metadatenelement

Inhalt

1.

ID1*

Eindeutige ID für den KPIa

2.

Name*

Name des KPI

3.

Bereich*

Bereich des KPI

4.

Extern/intern*

Intern: Empfänger innerhalb des Unternehmens

5.

Relevant für

Adressaten des KPI

6.

Fachliche Beschreibung*

Ausführliche Beschreibung des KPI

7.

Nutzen*

Beschreibung des Nutzens dieses KPI und was damit gesteuert wird

8.

Schwellwerte

Definition der Schwellwerte, die nach Überschreitung zu korrektiven Maßnahmen führen

9.

Korrektive Maßnahmen

Mögliche Maßnahmen bei Überschreitung der Schwellwerte

10.

Frequenz/Update*

Beschreibung der Frequenz, mit der der KPI berechnet werden muss, und ggf. der genaue Fertigstellungstag

11.

Beispiel

Ein kurzes Beispiel mit Werten für diesen KPI

12.

Verantwortlicher fachlich*

Die Person, die fachlich für diesen KPI verantwortlich ist

13.

Verantwortlicher technisch*

Die Person, die technisch für diesen KPI verantwortlich ist

14.

Beeinflusst durch

Liste von KPIs (ID plus Name), die diesen KPI beeinflussen

15.

Beeinflusst

Liste von KPIs (ID plus Name), die von diesem KPI beeinflusst werden Genauigkeit des KPI für das Reporting

16.

Datentyp, Datenformat

17.

Einheit

Einheit des KPI (z.B. EUR)

18.

Berechnungsalgorithmus*

Beschreibung der Berechnung des KPI

(Länge, Nachkommastellen)

➝

264

Nr.

14 Wertschöpfung durch Metadaten

Metadatenelement

Inhalt

19.

Automatisierung

N: Automatisierung der Berechnung nicht notwendig

20.

Quellsysteme/-daten*

Name und Daten der verwendeten Quellsysteme

21.

Status*

offen = Analyse/Technik, Spezifikation noch nicht begonnen

22.

Gültig ab*:

Beginndatum der Gültigkeit des KPI

23.

Gültig bis:

Endedatum der Gültigkeit des KPI

a.

KPI = Key Performance Indicator

Tab. 14–2

Formular zur Erfassung der Metadaten zu einem KPI (* = Mandatory)

Typische Beispiele für fachliche Metadaten sind fachliche Beschreibungen von Kennzahlen, fachliche Erklärungen von Fachbegriffen, fachliche Zusammenhänge zwischen verschiedenen Kennzahlen oder fachliche Berechnungsvorschriften von Kennzahlen. Anwender und Rollen

Aufgrund der Aufgaben und Verantwortlichkeiten innerhalb einer BI­Anwendung – technische Administration/Berichtserstellung – werden den Benutzern definierte Rollen zugewiesen, in denen die jeweils benötigten Zugriffsrechte zusammengefasst werden. Metadaten zur Datenqualität

Die Metadaten zur Datenqualität als übergreifendes Querschnittsthema lassen sich nur schwer einer Schicht in der Referenzarchitektur zuordnen. Sie enthalten in erster Linie die Geschäftsregeln zur Prüfung der Datenqualität (siehe Kap. 9), aber auch die Benachrichtigungsregeln, die festlegen, wer bei einer Unterschreitung der Datenqualitätskennzahlen informiert werden soll. Weiterhin werden auch die Benutzer und Datenlieferanten als Metadaten zu den jeweiligen Berichten gespeichert, um bei abgebrochenen oder verzögerten Ladeprozessen die Betroffenen vorab zu informieren. Die Akzeptanz und das Vertrauen in die Berichte steigen ungemein, wenn die Benutzer nicht selbst feststellen müssen, dass ihre Berichte noch nicht mit den aktuellen Daten befüllt worden sind, sondern z.B. per Mail proaktiv darüber informiert werden – möglichst nebst einer Zeitangabe, ab wann die Daten verfügbar sind. Zu den Datenqualitätsmetadaten gehören auch die Datenqualitätskennzahlen, die eine qualitätsmäßige Bewertung der Kennzahlen darstellen. Beispiel: Zur Kennzahl »Callcenter­Auslastung« mit dem Wert 92,3 Prozent wird die Qualitätskennzahl 85 Prozent berechnet, die sich aus der Aktualität, der Vollständigkeit und der Korrektheit ergibt.

14.5 Probleme bei der Erstellung: Motivation und Aktualität

265

14.5 Probleme bei der Erstellung: Motivation und Aktualität Die Hauptprobleme bei der Erstellung der Metadaten liegen in der Motivation der Teammitglieder und der Aktualität. Deshalb ist es besonders wichtig, einige Regeln für das Metadatenmanagement zu beherzigen. Nur die notwendigen Metadaten erstellen

Überzogene Forderungen an den Umfang der Metadaten sind kontraproduktiv, da das Team erstens die Notwendigkeit nicht verstehen kann, es zweitens durch die Vielzahl der Metadaten überfordert wird und dadurch drittens die Qualität sinkt. Zu Projektbeginn sind die Motivation und die Qualität in der Regel noch hoch, nach einiger Zeit nimmt beides aber rapide ab, wie die Erfahrung gezeigt hat. Erfolg hat das Projektteam, das nur die wirklich notwendigen Metadaten in der erforderlichen gleichbleibenden Qualität erfasst. Metadaten automatisiert erfassen

Ein hoher Automatisierungsgrad bei der Erfassung der Metadaten entlastet das Projektteam und garantiert eine gleichmäßige Qualität. Eine »Nachdokumentation« funktioniert in der Praxis nicht: Metadaten und Realität werden sehr schnell inkonsistent. Ein Schlüssel zum Erfolg sind z.B. moderne ETL­Werkzeuge, die eine modellbasierte Entwicklung und eine Codegenerierung ermöglichen. Basis für die Generierung sind allein die Metadaten, die dadurch zwangsläufig immer vollständig und aktuell sind.

14.6 Nutzung von Metadaten Wie in Abschnitt 14.1 beschrieben, gibt es eine Vielzahl verschiedener Arten zur Nutzung von Metadaten. Eine umfassende Beschreibung würde den Rahmen dieses Buches sprengen, weshalb in diesem Kapitel auf die Vollständigkeit der Darstellung verzichtet wird; stattdessen werden in den nachfolgenden Abschnitten nur einige typische Arten dargestellt. Abstammungs- und Auswirkungsanalysen

Metadaten ermöglichen Abstammungs­ und Auswirkungsanalysen, mit denen der Weg der Daten von den Quellsystemen zu den Zielen im Data Warehouse und umgekehrt nachvollziehbar ist (siehe Abb. 14–7). Damit ist es z.B. möglich, bei Änderungen in der Schnittstelle zu einem Quellsystem die Objekte in der BI­Anwendung zu identifizieren, die von dieser Änderung ebenfalls betroffen und somit auch zu ändern sind. Auf der anderen Seite kann der Benutzer eines Berichts durch die Abstammungsanalyse auf einen Blick erkennen, aus welchen Quellen die zur Berechnung einer bestimmten Kennzahl verwendeten Daten

266

14 Wertschöpfung durch Metadaten

stammen, wie die Daten verarbeitet wurden und wie die Kennzahl genau berechnet wurde. Zielgruppe dieser Metadaten sind somit sowohl die Entwickler der BI­Anwendung als auch die Benutzer.

Abb. 14–7

Abstammungsanalyse für einen Datenwürfel (Beispiel)

Steuerung der Prozesse im Data Warehouse

Immer mehr Unternehmen nutzen Metadaten zur Steuerung der Prozesse im Data Warehouse. Dadurch können einerseits diese Prozesse variabel gesteuert und andererseits Änderungen in den Prozessen einfach durch Änderungen der steuernden Metadaten durchgeführt werden. Zudem ist dadurch sichergestellt, dass die Metadaten vollständig und richtig erfasst und über die gesamte Lebensdauer des Data Warehouse aktuell gehalten werden. Ein Nachteil dieser Nutzungsart ist die Fehleranfälligkeit, da die Prozesse nicht wie üblich modelliert, sondern über Metadaten konfiguriert werden. Somit kann man leicht die Übersicht über den Ablauf verlieren. Darüber hinaus ist es schwieriger, die Prozessabläufe aktuell und korrekt zu dokumentieren (z.B. für ein Betriebshandbuch). Erfüllung regulatorischer Anforderungen

Metadaten werden auch häufig zur Erfüllung regulatorischer Anforderungen (z.B. SOX, Basel II) nach Dokumentation der Geschäftsprozesse und den Grundlagen zur Berechnung von Unternehmenskennzahlen genutzt. Weiterhin nimmt die Zahl der Revisionsabteilungen von Unternehmen zu, die Metadaten als revisionssichere Dokumentation zulassen. Dadurch steigen der Mehrwert und die Akzeptanz für ein Metadatenmanagement im Unternehmen.

14.6 Nutzung von Metadaten

267

Qualitätssicherung der Data-Warehouse-Entwicklung

Für die Qualitätssicherung der Data­Warehouse­Entwicklung können die Metadaten ebenfalls genutzt werden. Einige Werkzeuge bieten z.B. einen Metadatenbrowser zur hierarchischen Darstellung der Metadatenobjekte. Zur Qualitätssicherung kann das Team mit diesem Browser über die Beziehungen und Abhängigkeiten der Objekte im Data Warehouse navigieren, deren Status und Dokumentation überprüfen, die Einhaltung von Qualitätsstandards überwachen und Inkonsistenzen feststellen. Dazu braucht das Team keinen Zugriff auf den Programmcode oder die verwendeten Werkzeuge, da alle benötigten Informationen über die Metadaten verfügbar sind. Zur Qualitätssicherung werden somit keine tiefer gehenden Werkzeugkenntnisse benötigt, weiterhin entfällt die Notwendigkeit, die Beziehungen über den Programmcode händisch zu identifizieren. Ergebnis: Der Aufwand für die Qualitätssicherung sinkt, die Qualität steigt. Erhöhung der Verständlichkeit von Kennzahlen

Die Darstellungsformen (Berichte, Scorecards und Dashboards) des BI­Systems mit ihren Informationen bilden die Grundlage für die Entscheidungsfindung der jeweiligen Benutzer. Der Benutzer braucht vollständige und verständliche Informationen zu den Kennzahlen, um deren Werte korrekt zu interpretieren und daraus die richtige Entscheidung abzuleiten. Ein Teil dieser Informationen besteht aus der Abstammungsanalyse, für den anderen Teil verwenden viele Unternehmen ein Kennzahlenglossar. Dieses Glossar enthält fachliche Informationen zu allen Kennzahlen; Grundlage sind die jeweiligen fachlichen Metadaten. Sowohl das Kennzahlenglossar als auch die Darstellung der Abstammungsanalyse werden in die Darstellungsformen (z.B. einen Bericht) integriert, sodass diese Metadaten zu jeder Kennzahl schnell und einfach abrufbar sind. Metadaten für das Data Profiling

Die Data­Profiling­Analyse ist ebenfalls ein wichtiger Nutzer von Metadaten (siehe Kap. 9). Das Data Profiling nimmt dabei eine Sonderstellung ein: Es werden sowohl Metadaten aus den vorhandenen Daten erstellt als auch die vorhandenen Metadaten anhand der Daten überprüft. Metadaten sind für das Data Profiling unverzichtbar – sie sind der Schlüssel zum Verständnis der Daten und zur Ermittlung der geltenden Geschäftsregeln eines Unternehmens.

268

14 Wertschöpfung durch Metadaten

14.7 Empfehlungen Sowohl für das Entwicklungsteam als auch für die Benutzer lohnt sich ein Metadatenmanagement, sodass kein Projekt darauf verzichten sollte. Erfolgsfaktoren hierfür sind einerseits die Motivation aller Beteiligten zur Erstellung und Nutzung der Metadaten, andererseits die Einhaltung der richtigen Balance zwischen dem Ausmaß der notwendigen Metadaten und unnötigem Ballast. Ist der Umfang der Metadaten zu gering, sinkt deren Nutzbarkeit. Ist der Umfang zu groß, sinkt die Motivation der Ersteller, und der Füllgrad und die Qualität nehmen ab. Zudem muss das Metadatenmanagementkonzept frühzeitig zu Projektbeginn ausgearbeitet werden, damit die Erstellung zeitnah während der Aktivitäten durchgeführt werden kann. Versuche zur nachträglichen Erstellung von Metadaten sind von vornherein zum Scheitern verurteilt, da später in der Regel sowohl die dafür notwendige Zeit und die Motivation der Teammitglieder fehlen als auch das Wissen zum Projektende nicht mehr präsent ist. Wichtig für den Erfolg ist auch die Erkenntnis, dass die Metadaten über die gesamte Lebensdauer der BI­Anwendung aktuell gehalten werden müssen. Ansonsten hätte man sich den Aufwand für die initiale Erstellung ebenfalls besser sparen sollen. Denn veraltete Metadaten bergen wie veraltete Dokumentationen die große Gefahr, dass daraus falsche Schlüsse gezogen werden.

269

15 Data Quality Monitoring

Vertrauen ist gut, Kontrolle ist besser. Im Mittelpunkt von Data Quality Monitoring (DQ­Monitoring) steht die laufende Überwachung der Datenqualität im Data Warehouse. Dies kann einerseits mittels definierter Kennzahlen und Berichte durchgeführt werden, andererseits lässt sich die Wirksamkeit von Maßnahmen zur Verbesserung der Datenqualität auch durch regelmäßiges Data Profiling verifizieren. Ziel eines DQ­Monitorings ist es daher, ein Instrumentarium zur Verfügung zu stellen, mit dessen Hilfe Aussagen über die Dynamik (Verbesserung/Verschlechterung) der Datenqualität getätigt werden können. Zwar kann zu Projektbeginn die Datenqualität evaluiert werden (DQ-Assessment), ob sich die Datenqualität aber wirklich permanent verbessert, entscheidet sich erst im laufenden Betrieb. Das frühzeitige Erkennen von Trends bei der Qualität der Daten und die zeitnahe Einleitung von Steuerungsmaßnahmen beim Überschreiten definierter Grenzwerte stellen erst nachhaltig die Datenqualität sicher. Wenn nicht zeitgerecht gegengesteuert wird, werden die Auswirkungen umso gravierender sein, je höher der Reifegrad eines DWH ist. So müssen beispielsweise bei Operational BI bedeutend strengere DQ­Kriterien angelegt werden als in einem DWH, das nur monatliche Listen produziert. Die Darstellung quantifizierbarer Verbesserungen in den Daten und eine Visualisierung der positiven Auswirkungen auf die Geschäftstreiber erleichtern die Argumentation der Kosten­ und Nutzen­Betrachtungen für ein laufendes Datenqualitätsberichtswesen. Ein periodisch durchgeführtes Data Quality Monitoring erhöht zudem generell das Vertrauen in die vorhandenen Daten im Unternehmen. Das ist für eine hohe Qualität von Entscheidungen sowie die Erfüllung regulatorischer Anforderungen eine unabdingbare Voraussetzung. Dieses Kapitel beginnt mit der DQ-Planung, in der geeignete Bereiche des Unternehmens ausgewählt werden, die es bzgl. Datenqualität zu untersuchen gilt (Abschnitt 15.1). In diesen Bereichen werden anschließend DQ-Assessments durchgeführt, mit deren Hilfe sich das DQ-Niveau (gemessen mittels DQ-Metriken) zu einem definierten Zeitpunkt bestimmen lässt (Abschnitt 15.2). Die weiteren Maßnahmen müssen in ein Phasenschema eingebettet sein, um die DQ nach-

270

15 Data Quality Monitoring

haltig auf einem hohen Niveau zu halten (Abschnitt 15.3). Darauf aufbauend müssen im Rahmen einer DQ-Planung geeignete Maßnahmen zur Verbesserung der DQ definiert werden.

15.1 DQ-Planung Die Planung beginnt dabei einerseits mit der Identifikation von Datenbereichen, für die aufgrund bestehender Datenqualitätsprobleme eine verstärkte Überwachung aufgesetzt werden soll. Um die Überwachung durchführen zu können, sind andererseits die für diesen Datenbereich relevanten Datenqualitätskriterien zu identifizieren und geeignete Kennzahlen zu definieren. Identifikation der Bereiche

Unter diesem Punkt wird in erster Linie die Identifikation von Datenbereichen oder von Daten in Systemen verstanden, in denen Datenqualitätsprobleme auftreten. Unter diese Problembereiche fallen z.B.: ■ ■ ■ ■ ■ ■

operative Systeme Schnittstellen BI­Anwendungen Domänen Entitäten Attribute

Der nächste Schritt im Rahmen der Planung ist die Identifikation der relevanten Datenqualitätskriterien, die für die zuvor bestimmten Datenbereiche und Systeme Anwendung finden sollen. Die Verantwortung für die Identifikation der Datenbereiche liegt bei den fachlich für die Daten zuständigen Personen. Definition der Kennzahlen

Auf Basis der zuvor geplanten Verbesserungsmaßnahmen können nun die Definitionen der konkreten Kennzahlen festgelegt werden. Dazu gehören die Beschreibung von Gültigkeitsbereichen der Daten sowie die Identifikation messbarer Verbesserungspotenziale. Der erste Schritt ist die Definition von Prüfregeln und Kennzahlen: ■ Identifikation und Definition der entsprechenden Kennzahlen ■ Festlegung, ob automatische oder manuelle Überprüfungen durchgeführt werden ■ Festlegung der Periodizität der Überprüfung

15.2 DQ-Assessment

271

Der nächste Schritt ist die Definition von zulässigen Wertebereichen und Verbesserungszielen der Datenqualität: ■ Definition von Gültigkeitsbereichen der Wertefelder ■ Definition von messbaren Verbesserungspotenzialen Im Zuge eines laufenden Berichtswesens sind die definierten Kennzahlen mittels Plan­Ist­Abweichungsanalysen zu validieren.

15.2 DQ-Assessment Das DQ­Assessment (vgl. [English 1999, S. 137ff.]) beschäftigt sich einerseits mit einer initialen Einschätzung der Datenqualität und andererseits mit einer Impact­Analyse bereits aufgetretener Datenqualitätsprobleme bzw. wahrgenommener Datenqualitätsthemen durch die Anwender und die Bestimmung ihrer Ursachen. Dieser Abschnitt beinhaltet analytische Methoden zum Erkennen und Analysieren von Datenqualitätsproblemen, die im Umfeld von BI­Projekten auftreten. Wie bereits mehrfach erwähnt, muss grundsätzlich die Zielsetzung bestehen, Datenqualitätsprobleme so früh wie möglich zu erkennen, zu analysieren und entsprechend zu bereinigen. Es ist daher bei Maßnahmen im Zuge eines DQ­Assessments, wie z.B. bei der Umsetzung von Prüfroutinen, immer zu validieren, wo diese Routinen aufsetzen sollen bzw. aufsetzen können: ■ ■ ■ ■ ■ ■

Datenerfassungsmasken operative Produktionssysteme Datenübernahme/Staging Area Data Warehouse Data Marts BI­Anwendungen

In jedem Fall ist zu beachten, dass die Auswirkungen solcher Regeln die Performance in den operativen Systemen beeinflussen können. Daraus ergibt sich, dass nicht alle Prüfregeln in den operativen Produktionssystemen aufgesetzt werden können. Zudem ist die Verfügbarkeit von Budgets und Ressourcen je Bereich oder je Architekturebene als Kriterium zu evaluieren. Analyseansätze

Es sind zwei verschiedene Analyseansätze (vgl. [Olsen 2003, S. 67ff.]) zu unterscheiden, um zu einer Beurteilung der Datenqualität zu kommen. Die beiden Ansätze unterscheiden sich grundlegend durch ihre Vorgehensweise: ■ Analyse der Daten, um vorab Datenqualitätsprobleme aufzudecken, bevor sie in den Anwendungen wirksam werden. Eine Möglichkeit, dies zu tun, ist ein umfangreiches Data Profiling (siehe Kap. 9) der Basisdaten.

272

15 Data Quality Monitoring

■ Erhebung bereits aufgetretener Datenqualitätsprobleme in den diversen Anwendungen und anschließende Analyse der Daten, um die Ursachen der Probleme nachvollziehen und bestimmen zu können Beide Ansätze haben sowohl Vor- als auch Nachteile. Nachfolgend eine kurze Gegenüberstellung. Der erste Ansatz beginnt mit einem umfangreichen Data Profiling der Daten. Voraussetzung dafür sind u.a. entsprechend zur Verfügung stehende Metadaten. Die Metadaten beschreiben praktisch den Sollzustand, gegen den die Daten zu prüfen sind. Das Ergebnis dieser Analyse ist eine Reihe inkorrekter Daten, die anschließend mit den Analysten aus den Fachbereichen im Detail zu untersuchen sind. Ein Vorteil dieser Methode ist, dass grundsätzlich initial wenige Ressourcen benötigt werden, um eine erste Einschätzung der Datenqualität vornehmen zu können. Der Nachteil dabei ist, dass gültige, aber inkorrekte Daten (inhaltlich falsche Daten) nur bedingt entdeckt werden können, nämlich insofern sie klar definierte Regeln verletzen. Dies ist allerdings in vielen Fällen nicht möglich. Der zweite Ansatz beginnt mit einer Analyse von Datenqualitätsproblemen, die in den Anwendungen bereits aufgetreten sind. Die Analyse erfolgt im Wesentlichen durch eine intensive Kommunikation mit den Anwendern in den verschiedenen Geschäftsbereichen. Der Vorteil dieses Ansatzes ist, dass inhaltliche Fehler durch diese Analysen erkannt werden können. Der Nachteil ist, dass nur Probleme aufgedeckt werden, die bisher schon zumindest einmal in den Anwendungen aufgetreten sind. Für eine umfassende Analyse des Gesamtzustands der Datenqualität in einem Unternehmen sind beide Ansätze anzuwenden, da sie sich gegenseitig ergänzen und unterschiedliche Problembereiche beleuchten. Ein weiterer möglicher Ausgangspunkt für die generelle quantitative Einschätzung der Datenqualität sind automatisiert ermittelte Kennzahlen, die regelmäßig bei der Datenbeladung mitzuschreiben oder durch das Ausführen von Prozeduren bei Bedarf zu berechnen sind. Abhängig von der Definition geeigneter Kennzahlen beschreiben die dadurch getroffenen Aussagen mehr oder weniger vollständig den Zustand der Datenqualität. Die Definition von Kennzahlen zur Messung von Datenqualität kann je Datenqualitätskriterium erfolgen. Die Verwendung von Kennzahlen (siehe dazu auch Abschnitt 7.3) hat, wie bereits erwähnt, zur Einschätzung der Datenqualität Grenzen. Ein Assessment der Datenqualität kann auch über Datenqualitätsberichte durchgeführt werden, z.B. durch die Darstellung von Aggregationen einzelner oder zusammengesetzter Kennzahlen. Auf das Thema Datenqualitätsberichte und die Visualisierung von Datenqualität wird in Abschnitt 15.3 noch detaillierter eingegangen.

15.2 DQ-Assessment

273

Inhaltliche Prüfungen

Wie beschrieben, können Kennzahlen nur eine Indikation des Zustands der Datenqualität wiedergeben. Um eine korrekte inhaltliche Einschätzung zu erhalten, sind Analysen unter Einbeziehung der fachlichen Anwender notwendig. Eine weitere Möglichkeit ist auch die Durchführung von sogenannten Nachfassaktionen (z.B. Prüfungen gegen die Kreditverträge), um ggf. die Qualität der erfassten Daten zu validieren bzw. die Aktualität ihrer Inhalte zu evaluieren. Rückmeldungen der Anwender

Eine qualitative Aussage über den Zustand der Datenqualität lässt sich auch über die Rückmeldungen der Anwender der Daten (User Feedback) erhalten. Hier ist zwischen aktiv einzufordernden und passiven Rückmeldungen zu unterscheiden: ■ Aktiv: • direkte Rückfragen bei den Anwendern • Fragebögen für konkrete Problemstellungen oder über generelle Eindrücke ■ Passiv: • Sammeln und Auswerten der Rückmeldungen der Anwender • Analyse von Störungen (Incidents) Die Analyse der Rückmeldungen der Anwender ermöglicht eine qualitative Einschätzung des Zustands der Datenqualität im Unternehmen. Werkzeuge

Um Datenqualitätsanalysen durchführen zu können, steht eine Reihe von Werkzeugen zur Verfügung. Tabelle 15–1 beinhaltet eine beispielhafte Auflistung der wesentlichen Werkzeuge für Datenqualitätsanalysen: Werkzeuge

Tab. 15–1

■ ■ ■ ■ ■ ■

SQL-Abfragen BI-Frontend-Werkzeuge Monitoring mittels Kennzahlen Data-Profiling-Werkzeuge Data Monitoring mittels DQ-Werkzeugen Data-Cleansing-Werkzeuge

Beispiele für DQ­Werkzeuge

Die Ergebnisse einer umfangreichen Analyse der Datenqualität sind als Input für die Definition von Kennzahlen zu verwenden. Die im Rahmen eines DQ­Assessments aufgezeigten Problembereiche bzw. deren Ursachen können mittels Kennzahlen überwacht und die Fortschritte bei der Umsetzung von Maßnahmen können gemessen werden.

274

15 Data Quality Monitoring

15.3 DQ-Phasenkonzepte Um dauerhaft eine ausreichende Datenqualität zu gewährleisten, haben sich in der Praxis zyklische Phasenkonzepte durchgesetzt. Konkret sind dies vor allem der »Plan-Do-Check-Act«-Ansatz1 sowie der aus dem Six-Sigma-Umfeld bekannte DMAIC-Ansatz. Im Hinblick auf Datenqualität setzt sich der Kreislauf »Plan-Do-Check-Act« folgendermaßen zusammen: ■ Plan: Definition der zu überwachenden Datenbereiche sowie der Methoden zur Überwachung je Datenqualitätskriterium bzw. Definition des Sollzustands der zu erreichenden Datenqualität ■ Do: Auswahl bzw. Implementierung der Werkzeuge zur regelmäßigen Überwachung der Datenqualität ■ Check: Periodische Durchführung der Überwachung der Datenqualität im laufenden Betrieb ■ Act: Definition und Initiierung von Verbesserungsmaßnahmen DMAIC ist der Kernprozess des Qualitätsmanagement-Ansatzes Six Sigma und wird eingesetzt, um Prozesse so zu gestalten, dass diese stabil ein vorgegebenes Qualitätsniveau aufrechterhalten: ■ Define: Spezifikation des Umfangs, der Ziele und der Ressourcen der DQ-Initiative. Das Ergebnis legt die Qualitätsmerkmale fest, mit denen in der nächsten Phase die konkreten Qualitätsniveaus gemessen werden. ■ Measure: Messung der Datenqualität auf Basis der festgelegten Merkmale anhand von Stichproben ■ Analyse: Analyse der Messergebnisse aus der Phase »Measure« mit dem Ziel, Verbesserungsmöglichkeiten daraus abzuleiten ■ Improve: Priorisierung und Pilotierung der gefundenen Verbesserungsmaßnahmen ■ Control: Kontrolle der definierten Maßnahmen mit dem Ziel, das durch die Verbesserungen erreichte DQ-Niveau zu stabilisieren 1.

zum Plan-Do-Check-Act«-Kreislauf siehe auch Abschnitt 1.4

15.3 DQ-Phasenkonzepte

275

Inzwischen gibt es eine Reihe von weiteren Ansätzen, die sich an diesen Grundideen orientieren. Beispielsweise schlagen Servas/Wandt einen Data Quality Life Cycle mit den Phasen »Inspect – Transform – Name – Address – Identify – Merge – Enrich – Report« vor. Aus diversen Praxisprojekten ist auch der DMAIC-Zyklus für DQM entstanden (vgl. [Schmidt 2011, S. 29ff.], [Schmidt 2012, S. 26ff.]). Allgemein betrachtet geht es bei allen Ansätzen darum, den erreichten Qualitätsstandard durch regelmäßiges Messen zu überwachen und bei Erreichen vorher definierter Schwellwerte entsprechende Maßnahmen einzuleiten. Durch diese permanente Überwachung (DQ-Monitoring) ist das Unternehmen in der Lage, jederzeit Auskunft über seinen DQ-Status zu geben. Eine regelmäßige Überwachung der Datenqualität ermöglicht zudem eine laufende Adaption der definierten Datenqualitätsmaßnahmen. Dies ist wichtig, um festzustellen, ob die durchgeführten Maßnahmen den gewünschten Erfolg erzielt haben. Denn oftmals kommt es in der Praxis vor, dass trotz durchgeführter Maßnahmen die Fehleranzahl nicht sinkt, ein Indiz dafür, dass die eigentliche Ursache noch nicht gefunden wurde. Nur mit einer kontinuierlichen Überprüfung der Datenqualität wird sichergestellt, dass qualitativ hochwertige Daten konsistent, korrekt und zuverlässig bleiben. Die Data­Quality­Monitoring­Ergebnisse können in Datenqualitätsberichten bzw. in sogenannten Data Quality Scorecards dargestellt werden. Die wesentlichen Zielsetzungen von Data Quality Monitoring lassen sich folgendermaßen zusammenfassen: ■ periodische, allgemeine Überwachung der Datenqualität im Rahmen des laufenden Berichtswesens ■ Nachvollziehbarkeit der Wirksamkeit von Datenqualitätsmaßnahmen ■ Trendanalyse und frühzeitige Identifikation neuer Datenqualitätsprobleme ■ Ableitung von Steuerungsmaßnahmen beim Überschreiten definierter Grenzwerte Der Kreislauf der Überwachung der Datenqualität lässt sich auch noch in anderer Form darstellen. Ausgangspunkt dabei ist das Erkennen von Datenqualitätsproblemen im Rahmen des laufenden Data Quality Monitoring. Der nächste Schritt ist die Kommunikation an alle relevanten Stakeholder, die diese Information zur Erfüllung ihrer Aufgaben benötigen. Gerade die Kommunikation ist ein wesentlicher Bestandteil eines Datenqualitätsprogramms, um die unternehmensweiten Auswirkungen von Datenqualitätsproblemen frühzeitig adressieren zu können. Der letzte Schritt ist das Lösen des erkannten Datenqualitätsproblems. Danach schließt sich wiederum die laufende Überwachung an, um die Fortschritte in der Umsetzung bzw. die Wirksamkeit der Maßnahmen darstellen zu können. Abbildung 15–1 gibt diesen Kreislauf des Data Quality Monitoring wieder.

276

15 Data Quality Monitoring

Lösen

Erkennen

Kommunizieren

Abb. 15–1

Kreislauf Data Quality Monitoring

Messpunkte definieren die Bereiche in der Business­Intelligence­Architektur, auf denen die Überwachung der Datenqualität generell aufsetzt. Da Kennzahlen ein wesentlicher Bestandteil eines Data­Quality­Monitoring­Programms sind, haben auch die entsprechenden unter Kapitel 7 definierten Messpunkte für Kennzahlen hier allgemeine Gültigkeit. Zur Wiederholung nachfolgend die Auflistung der fünf Messpunkte, die im Rahmen der Business­Intelligence­Architektur definiert wurden: ■ ■ ■ ■ ■

Datenquellen Datenintegration Data Warehouse Data Marts Business Intelligence Frontends

Je nach Anforderungen an die Überwachung (z.B. Übernahme der Daten aus den Quellsystemen in die Data­Warehouse­Umgebung, Überwachung von Geschäftsregeln) ist der jeweilige Messpunkt in Betracht zu ziehen und auszuwählen. Dabei gelten im Wesentlichen die gleichen Kriterien und Überlegungen, die schon im Kapitel über die Kennzahlen Anwendung gefunden haben (siehe Kap. 7). Bei fachlich komplexen Datentransformationsprozessen empfiehlt es sich, nach jedem fachlichen Prozessschritt einen Messpunkt zu setzen (Beispiel: Berechnung von Risikokennzahlen für Basel II).

15.4 Methoden

277

15.4 Methoden Um die Überwachung der Datenqualität operativ durchführen zu können, stehen diverse Methoden zur Visualisierung oder zur Benachrichtigung der Anwender zur Verfügung, auf die im Folgenden näher eingegangen wird. Data Profiling

Die Methode des Data Profiling im Umfeld von BI­Projekten selbst wird ausführlich in Kapitel 9 beschrieben. Hier folgt ein Überblick über die Verwendung von Data Profiling im Rahmen von Data Quality Monitoring. Generell ist in diesem Zusammenhang die Unterscheidung zwischen initialem und laufendem Data Profiling zu treffen. Initiales Data Profiling

Data Profiling wird initial vor allem im Zuge oder bereits vor der Durchführung von Datenmigrationsprojekten oder BI­Projekten angewendet. Dies ermöglicht das frühzeitige Erkennen von Datenqualitätsproblemen und in weiterer Folge somit eine Reduktion der Kosten bzw. der Durchlaufzeiten dieser Projekte. Zudem erleichtern die Erkenntnisse eines initialen Data Profiling die Definition und Implementierung von Data­Quality­Monitoring­Maßnahmen, um die so erkannten Datenqualitätsprobleme regelmäßig überwachen zu können. Laufendes Data Profiling

Data Profiling wird regelmäßig durchgeführt, um so eine laufende Kontrolle über die Qualität der Daten zu bekommen. Dabei werden die Daten auf neue bzw. bisher nicht bekannte Datenqualitätsprobleme hin untersucht. Regelmäßig kann dabei z.B. Folgendes bedeuten: ■ ■ ■ ■

anlassgetrieben (beim Auftreten bestimmter Konstellationen) monatlich quartalsweise jährlich

Dieses asynchrone Data Profiling setzt dabei auf den diversen Data Repositorys im Unternehmen auf (z.B. Staging Area, Data Warehouse oder auch Data Marts). Beispiel: Morgens um 10.00 Uhr wird ein Batch­Skript gestartet, das das Data Profiling auslöst, und um 12.00 Uhr werden entsprechende Berichte und Benachrichtigungs­E­Mails produziert.

278

15 Data Quality Monitoring

Berichtswesen

Berichte, bzw. das Berichtswesen generell, eignen sich ebenfalls, um ein laufendes Data Quality Monitoring durchzuführen. Berichte können dabei entweder mittels Business­Intelligence­Frontend­Werkzeugen direkt auf den Basisdaten aufsetzend generiert oder aus diversen Aggregationen aus den Daten zusammengestellt werden. Um einen Drill­down zu ermöglichen, sind die Datenqualitätsberichte direkt mit den Detaildaten zu verknüpfen, um so bei Bedarf eine Ausgabe der Einzeldatensätze z.B. in Listenform zu ermöglichen. Eine andere Variante ist die Verlinkung eines eigenen zusätzlich definierten Detailberichts mit den Datenqualitätsberichten, der bei einem Aufruf die entsprechenden Detaildaten beinhaltet. Die Berichte mit den Detaildaten basieren dabei auf der gleichen Logik wie die dazugehörigen Einschränkungen der Datenqualitätsberichte. Eine wesentliche Anforderung aus den Fachbereichen der Unternehmen ist die Nachvollziehbarkeit der Datenqualitätsberichte in den Detaildaten. Dazu gehört die erwähnte Definition einer entsprechenden Drill­down­Struktur des Berichtswesens sowie aufeinander abgestimmte Detailberichte und High-LevelBerichte als Aggregationen von Einzelberichten oder einzelnen Kennzahlen. Die Durchführung des Datenqualitätsberichtswesens erfolgt generell mit den entsprechenden Business­Intelligence­Frontend­Werkzeugen. Die Berichte selbst sind durch die fachlich verantwortlichen Personen zu definieren und anschließend in die Umsetzung einzubringen. Die in den Gremien vorzulegenden Datenqualitätsberichte sind dabei mit allen beteiligten Personen abzustimmen und an die entsprechenden Stakeholder zu kommunizieren. Das Generieren der Berichte kann als asynchroner Prozess – ähnlich dem laufenden Data Profiling – zu bestimmten Tageszeiten erfolgen oder als integrierter Bestandteil des ETL­Prozesses aufgesetzt werden. Beispielsweise kann ein nächtlicher Ladejob am Ende einen Standardaufruf beinhalten, der Satzzahlen vergleicht und definierte Prüfungen durchläuft. Werden dabei gewisse Toleranzen überschritten, wird ein Ausnahmenbericht generiert und die verantwortlichen Personen werden informiert. Insgesamt muss jedoch darauf geachtet werden, dass sich die Verarbeitung der ETL­Prozesse dadurch nicht zu sehr verlängert, da für diese Prozesse nur ein begrenztes Zeitfenster zur Verfügung steht. Innerhalb der Berichte können verschiedene Darstellungsformen gewählt werden, um den allgemeinen Zustand der Datenqualität zu zeigen. Die vorgestellten Formen sind als On­Top­Indikation zu verstehen und stellen eine hochaggregierte Zusammenfassung der einzelnen Datenqualitätskriterien dar.

15.4 Methoden

279

Spinnengrafik

Eine Spinnengrafik ermöglicht eine übersichtliche grafische Darstellung des Zustands der unterschiedlichen Datenqualitätskriterien. Abbildung 15–2 gibt einen Überblick der Zielerreichung des Istzustands der Datenqualitätskriterien auf aggregierter Ebene im Vergleich zum definierten Sollzustand in Prozentwerten. Zeitnähe 100 80 60 Vollständigkeit

Relevanz

40 20

Soll

0 Ist

Konsistenz

Korrektheit

Zuverlässigkeit

Abb. 15–2

Spinnengrafik

Wie schon in Kapitel 7 ausführlich dargestellt, kann die Berechnung mancher Datenqualitätskriterien, wie z.B. der Zuverlässigkeit, oftmals nicht automatisiert erfolgen, sondern muss manuell durch die verantwortlichen Personen durchgeführt werden. Historienreihe

Eine weitere Möglichkeit für einen Datenqualitätsbericht ist die Darstellung der Entwicklung der Datenqualität mittels Kennzahlen über die Zeit. Wiederum gilt hier die Einschränkung, dass sich nicht alle Datenqualitätskriterien automatisiert berechnen lassen.

280

15 Data Quality Monitoring

Kriterium Zeitnähe 100 90 80

Prozent

70 60

Soll

50 Ist

40 30 20 10

Abb. 15–3

er No ve m be De r ze m be r

be

Ok

to b

r

t em

us pt Se

li Zeit

Au g

Ju

ni Ju

ai M

r il Ap

z

ar

är M

ru Fe b

Ja

nu

ar

0

Historischer Vergleich der Entwicklung von Datenqualitätskriterien

Abbildung 15–3 zeigt eine einfache Darstellung für einen Zeitreihenvergleich. Dabei ist die Entwicklung des Istzustands des Datenqualitätskriteriums Zeitnähe über die Monate im Vergleich zum Sollzustand dargestellt. Das Kriterium Zeitnähe kann in diesem Zusammenhang beispielsweise die Anlieferungszeitpunkte der Daten aus den verschiedenen Schnittstellen in der BI­Architektur wiedergeben. Bei diesen Berichten bzw. Darstellungsformen ist generell zu beachten, dass sich die dargestellten aggregierten Berichte je nach Definition aus einer Reihe von komplexen Einzelkennzahlen zusammensetzen können, die nachvollziehbar bleiben müssen. Die Überschreitung von Eskalationsschwellen sowie die damit verbundene automatisierte Einleitung von Maßnahmen (z.B. löst die Unterschreitung von 70 Prozent eine Benachrichtigung aller Stakeholder mittels E­Mail aus) können einerseits auf Einzelkennzahlen und andererseits auf einem aggregierten Level zur Anwendung kommen. Es ist darüber hinaus zu beachten, dass unterschiedliche Fachbereiche verschiedene Eskalationsschwellen haben können. Um den Gesamtüberblick über alle Informationen zu den einzelnen Kennzahlen und Berichten zu behalten, ist dies zentral in den Metadaten abzulegen und standardisiert zu dokumentieren. Qualitative Aussagen (z.B. zum Kriterium Zuverlässigkeit) der fachlich verantwortlichen Personen bezüglich der Datenqualitätsprobleme in den jeweiligen Datenbereichen sind auch bei Verwendung dieser Darstellungsform zu sammeln, manuell zu bewerten und über Kennzahlen und Berichte zugänglich zu machen.

15.4 Methoden

281

Ampelgrafik

Die Darstellung als sogenannte Ampelgrafik ist eine weitere Möglichkeit zur Veranschaulichung von Datenqualität im Rahmen einer laufenden Überwachung. Eine Ampelgrafik gibt einen guten Überblick über den Zustand der Datenqualität durch die Verwendung von Farben. Dabei werden verschiedene Datenqualitätskriterien mit den zugehörigen Istwerten und den definierten Sollwerten berichtet und die Ergebnisse im Ampelformat angezeigt. Diese Kriterien können in den Berichten aggregiert oder auch als Einzelkennzahlen dargestellt werden. Wesentlich dabei ist, dass zur Steuerung der Ampel sogenannte Wertebereiche hinterlegt sind, z.B. für das Datenqualitätskriterium Vollständigkeit die folgenden Kennzahlen: ■ ROT ■ HELLGRÜN ■ GRÜN

 85% 85–89%  90%

Abbildung 15–4 gibt in vereinfachter Form die prinzipielle Darstellung einer Ampelgrafik wieder.

Abb. 15–4

SOLL

IST

Korrektheit

95 %

96 %

Vollständigkeit

90 %

88 %

Zuverlässigkeit

95 %

75 %

Ampel

Prinzip der Ampeldarstellung

Die Ampelgrafik findet oft als Teil einer Darstellung der Datenqualität innerhalb von sogenannten DQ­Dashboards Verwendung. Datenqualitätsradar

Das Datenqualitätsradar (vgl. [Würthele 2003, S. 29ff.]) eignet sich ebenfalls zur Visualisierung der Datenqualitätsüberwachung. Eine einfache Möglichkeit der Visualisierung besteht darin, die Sektoren entsprechend einzufärben.

282

15 Data Quality Monitoring

Prozess

Technikqualität Korrektheit

b- r J o l tu ku

Modellangemessenheit

ä

M i Sk il t a r ls be it

Abb. 15–5

stä

it ke

is Kons

te n z

Ver füg b

arkeit

Ab - Verhän traugigenswürkeit digkeit

- RedundanzEin freiheit d e u eit k tig e s d Konts Nützlichk te x eit

er

st Ver

n dl

Fa weic kto he re n

e it ichk

ll Vo harte Faktoren

O sa rgan ti o i n

Ow sh n e r ip -

ig nd

Datenqualitätsradar

Für eine aufzusetzende Datenqualitätsüberwachung sind die dafür relevanten Kriterien farblich zu markieren. Dies kann ebenso in den Ampelfarben geschehen, um den Status der Datenqualität anschaulich darzustellen. Dashboard

Ein Dashboard2 visualisiert große Mengen von meist verteilten Informationen in verdichteter Form, um die wesentlichen Kennzahlen, nach denen ein Prozess gesteuert wird, übersichtlich darzustellen. Dashboards können sich dabei aus unterschiedlichen Grafiken und Tabellen zusammensetzen und werden damit zum zentralen Kontrollpunkt in Sachen Datenqualität. Viele Hersteller von standardisierten Datenqualitätswerkzeugen, wie z.B. Data-Profiling­ oder Data­Cleansing­Komponenten, bieten auch mehr oder weniger umfangreiche Komponenten zur Darstellung und Überwachung von Datenqualität an. Benachrichtigungen

Ein wesentlicher Punkt im Rahmen eines automatisiert durchgeführten Data Quality Monitoring ist die Benachrichtigung (Notifikation) der verantwortlichen Personen im Fall von Über­ oder Unterschreitungen von Grenzwerten. Dies kann im einfachsten Fall durch die Versendung von E­Mails oder SMS geschehen. Denkbar sind aber auch entsprechende Informationen in einem DQ­Info­Portal.

2.

zum Thema Dashboard siehe auch Abschnitt 13.2

15.5 Verantwortlichkeiten

283

Zu beachten ist dabei, dass eine sogenannte Betroffenheitsmatrix erstellt wird, die alle Stakeholder umfasst, die beim Auftreten von Datenqualitätsproblemen zu benachrichtigen sind. Handelt es sich um besonders kritische Daten, werden die Verantwortlichen (z.B. die fachlichen Data Stewards) nach jedem Ladelauf informiert. Eine Prüfung der Daten erfolgt beispielsweise über eine Intranetanwendung. Freigegeben werden die jeweiligen Datenbestände nur in Abhängigkeit vom Ergebnis der Prüfungen.

15.5 Verantwortlichkeiten Abschließend wird für das laufende Monitoring der Datenqualität, basierend auf den in Kapitel 4 definierten Rollen, noch eine Zuordnung der Verantwortlichkeiten definiert. Diese Zuordnung ist als Empfehlung zu sehen, da sich die konkreten Verantwortlichkeiten, entsprechend der tatsächlich implementierten Organisation, zwischen den Rollen verschieben können: ■ Die Verantwortung für die Definition und Überwachung formal­technischer Metriken und Berichte liegt bei den technischen Data Stewards und den technischen Systemverantwortlichen. ■ Die Verantwortung für die Definition und Überwachung inhaltlicher und qualitativer Metriken und Berichte liegt bei den fachlichen Data Stewards sowie ggf. bei weiteren Anwendern aus den Fachbereichen. ■ Die Verantwortung des Datenqualitätsmanagers liegt in der unternehmensweiten Koordination der Aktivitäten und der Sicherstellung der Konsistenz der definierten Maßnahmen.

15.6 Empfehlungen Data Quality Monitoring ist ein wesentlicher Bestandteil jedes Datenqualitätsmanagementprogramms. Ohne die laufende Überwachung der Qualität der Daten lassen sich keine Aussagen über den Zustand und die Entwicklung der Datenqualität sowie die Wirksamkeit von Maßnahmen zur Verbesserung der Datenqualität machen. Um dies zu erreichen, sind die Ziele und die Regeln klar zu definieren und verantwortlichen Personen zuzuordnen. Die Überwachung lässt sich mit verschiedenen Werkzeugen erreichen; wesentlich dabei ist, dass die Konsistenz und die Nachvollziehbarkeit gewahrt bleiben. Abschließend ist nochmals festzuhalten, dass nur jene Bereiche eine Verbesserung erfahren werden, die sich auch messen und überwachen lassen.

284

15 Data Quality Monitoring

285

16 Produktauswahl und -integration

Dieses Kapitel soll bei der Auswahl von Werkzeugen bzw. Lösungen für Datenqualitätsmanagement Unterstützung leisten. Nach einer kurzen Marktbetrachtung werden die wesentlichen Auswahlkriterien aufgelistet und jeweils wichtige Aspekte sowie häufige Fallstricke angesprochen. Bei der Produktauswahl steht naturgemäß vor allem der Umfang an bereitgestellter Funktionalität im Blickpunkt. Eine umfassende Auflistung und Beschreibung der Funktionalitäten, Verfahren und Algorithmen für das Datenqualitätsmanagement findet sich in den vorangegangenen Kapiteln dieses zweiten Buchteils. Das folgende Kapitel bringt praxisrelevante Aspekte rund um die reine Funktionalität ein.

16.1 Anbieter und Produkte Die Anbieter für Produkte und Lösungen zum Thema Datenqualitätsmanagement lassen sich in drei Kategorien einteilen: ■ reine DQM­Anbieter ■ große Anbieter von Anwendungssoftware (ERP, CRM) oder/und Infrastruktursoftware ■ Anbieter für Datenintegration der Techniken ETL (vor allem im Bereich Business Intelligence eingesetzt) und Enterprise Application Integration/Enterprise Service Bus Datenqualitätsmanagement steht häufig im Kontext von Datenintegration. Daher ist es für Anwender wichtig, den Integrationsgrad zwischen den DQM­ und Datenintegrations­Tools zu betrachten. Zu diesem Zweck sind die Anbieter für Datenqualitätsmanagement und Datenintegration lange Zeit Partnerschaften eingegangen. Manche Anbieter haben ihre DQM­Tools organisch entwickelt und können daher mit einem höheren Integrationsgrad im Vergleich zu Tools aus den Bereichen Datenintegration bzw. Master Data Management aufwarten. In den letzten Jahren hat sich der Markt dahingehend weiterentwickelt, dass viele DQM­Anbieter von Anbietern für Datenintegration, Anwendungen und

286

16 Produktauswahl und -integration

Infrastruktur übernommen wurden. Der Integrationsgrad der übernommenen DQM­Produkte zu den eigenen Produkten in den Bereichen Datenintegration, Anwendungen, Infrastruktur ist inzwischen recht gut. Zudem werden meistens heterogene IT­Anwendungslandschaften gut unterstützt. Die vorhandenen DQM­Werkzeuge lassen sich hinsichtlich des Integrationsgrads wie folgt charakterisieren: ■ DQM­Suites decken im Wesentlichen alle funktionalen Bereiche von Data Profiling über Match & Merge bis zum Monitoring der Datenqualität ab. Hier ist der höchste Grad an Integration zu erwarten, was die einzelnen Bausteine der Architektur für DQM betrifft. Das fällt vor allem dann ins Gewicht, wenn ein lückenloser DQM­Prozess aufgebaut werden soll. Ungünstig ist, wenn einzelne Bausteine wie Match & Merge­Tools – womöglich von einem anderen Anbieter – bereits eingesetzt werden. DQM­Suites decken viele funktionale Bereiche des DQM ab. Dennoch gibt es auch weiße Flecken: Nur einige Anbieter warten mit DQ­Kennzahlensystemen auf. Häufig fehlt die Funktionalität des Monitoring der Datenqualität. ■ Best­of­Breed­Tools kleiner Anbieter können zwar nicht den ganzen DQMZyklus abdecken, sind aber die erste Wahl, wenn man den Fokus nur auf einen funktionalen Bereich (z.B. Haushaltsbildung) legt und in diesem eine möglichst mächtige Funktionalität sucht. Vor der Auswahl eines Best-ofBreed-Tools ist jedoch immer zu prüfen, ob mittel­ oder langfristig die Einbindung des ausgewählten Werkzeugs in den Kontext eines größeren Prozesses bzw. einer Anwendung erforderlich wird. Ist der Integrationsgrad des favorisierten Tools gering, können überproportional hohe Kosten für Integration, Wartung und Betrieb alle kurzfristigen Kostenkalkulationen ad absurdum führen. Man sollte also nicht nur die Lizenzkosten betrachten, sondern die Gesamtkosten (Total Cost of Ownership). ■ Einige Tools für Datenintegration verfügen über komplett integrierte DQMKomponenten. Das macht die Entwicklung von Programmen für die Datenintegration unter Berücksichtigung des Datenqualitätsmanagements sehr effizient, denn die Integration der Komponenten ist meist nahtlos. Natürlich ist der Preis die Abhängigkeit vom Datenintegrationswerkzeug und dem betreffenden Hersteller. Eine unvollständige, wertfreie Liste bekannter Anbieter1 für Datenqualitätsmanagement sei hier genannt: Oracle, IBM (Übernahmen von Ascential, Initiate u.a.), Informatica (Übernahmen von Similarity, AddressDoctor, Identity Systems u.a.), SAP (Übernahmen von FirstLogic, Fuzzy! Informatik u.a.), SAS/DataFlux, Microsoft, Talend, Human Inference, Trillium, Uniserv, Innovative Systems, Group 1 Software. 1.

Alle Marken- und Produktnamen sind Handelszeichen oder registrierte Handelszeichen der betreffenden Unternehmen.

16.2 Auswahlkriterien im Überblick

287

16.2 Auswahlkriterien im Überblick Eines der wichtigsten Auswahlkriterien ist in der Regel die Funktionalität, die sich immer auf die konkreten Anforderungen des jeweiligen Anwenders bezieht. Die spezifische Unterstützung der relevanten Sprachräume, Zeichensätze, Länder usw. ist eine häufig anzutreffende Anforderung, die sich nicht auf Funktionalitäten bezieht. Wichtig sind in der Regel auch die Möglichkeiten bzw. der Grad der Integration der DQM­Tools untereinander. Die Möglichkeiten zur Anbindung von Referenzdaten sowie der involvierten Datenintegrationswerkzeuge, Datenbanken und Anwendungen spielen ebenso eine wichtige Rolle. Generelle, also nicht DQM­spezifische, Kriterien zur Produktauswahl werden hier nicht weiter betrachtet.

16.3 Funktionale Kriterien Die aufzustellenden funktionalen Kriterien orientieren sich an den spezifischen Anforderungen, die in erster Linie durch die jeweiligen Fachbereiche formuliert werden. Es ist wichtig, diese Kriterien zu kategorisieren und die entsprechenden Kategorien von DQM­Produkten zu identifizieren. Es gibt nicht das eine ultimative Werkzeug für Datenqualitätsmanagement, sondern verschiedenartige Werkzeuge, die in diverse Produktkategorien zu unterteilen sind. Tabelle 16–1 listet einige Beispiele typischer Anwendungsfälle und die damit verbundenen Anforderungen auf. Domäne

Anwendungsfall

Anforderungen

Kategorie

Geschäftspartner (z.B. Kunde)

Kampagnenmanagement

Korrektur von Namen und Adressen, ggf. Anreicherung

Name & Adresse, Anreicherung

Blacklist Matching

Finden von Duplikatkandidaten

Duplikate

Produkte

Product Information Management

Finden von Duplikatkandidaten

Duplikate

Steuererklärung

Automatisierte Überprüfung

Validierung gegen definierte Regeln

Validierung

Tab. 16–1

Exemplarische Anwendungsfälle für Datenqualitätsmanagement

Der Bezug der gesammelten Anforderungen zu geschäftlichen Zielen muss beschrieben und die Datenqualitätsprobleme samt deren Ursachen müssen bekannt sein. Meistens reicht es nicht, Symptome von Datenqualitätsproblemen durch Datenbereinigung im Nachhinein zu beheben, sondern es ist notwendig, die Ursachen aufzuspüren und zu beheben, wie z.B. Brüche in der Prozesskette. Nicht selten lassen sich diese Ursachen mit denselben Geschäftsregeln und sogar denselben Werkzeugen angehen. Aber dieser Aspekt muss unbedingt bedacht und vom Produktanbieter eingefordert werden.

288

16 Produktauswahl und -integration

Um die Kosten in ihrer Gesamtheit ermitteln zu können, muss man sich für jedes zu betrachtende Werkzeug einen Überblick über den für die Umsetzung erwarteten Aufwand verschaffen. Es reicht also nicht abzuklären, ob sich ein bestimmtes Problem mit dem Werkzeug lösen lässt, sondern man muss auch grundlegend verstehen, wie es gelöst wird. Data Profiling

Die Ergebnisse des Data­Profiling­Prozesses müssen in der Regel mit den Fachbereichen diskutiert werden. Wichtige Kriterien für die Darstellung der Profiling­Ergebnisse sind daher Anschaulichkeit, Bezug zu den originären Daten sowie On­/Offline­Darstellung. Profiling­Ergebnisse lassen sich anschaulich darstellen durch Visualisierung, Grafiken oder Prozentsätze. In diesem Zusammenhang steht häufig eine weitere Anforderung, die sich nicht an das DQM­Tool, sondern an die Client­Hardware richtet: Erfahrungsgemäß hat man bei der Interpretation der Profiling­Ergebnisse sehr viele Fenster offen, um die Auffälligkeit aus verschiedenen Blickwinkeln betrachten zu können. Ein großer Bildschirm oder noch besser zwei sind daher sehr hilfreich. Wenn Auffälligkeiten in den Data­Profiling­Ergebnissen erkannt werden, baut sich bei Anwendern oft unweigerlich Skepsis auf. Das Einzige, das in dieser Situation hilft, ist die sofortige Verknüpfung zu den zugrunde liegenden Detaildaten, quasi der Drill­down. Die Data­Profiling­Ergebnisse sollten auch losgelöst vom DQM­Tool in Form von druckbaren Berichten bereitgestellt werden können. Diese Ergebnisse sollten den in Abschnitt 1.3 beschriebenen DQ­Kriterien wie z.B. Vollständigkeit und Korrektheit zugeordnet sein, um neben den Detailproblemen auch eine übersichtliche Zusammenfassung der Datenqualität darzustellen. Bei vielen Werkzeugen fehlt dieser Bezug gänzlich. Ursache dafür ist, dass es keinen etablierten Standard für die Definition von Datenqualitätsdimensionen gibt. Trotzdem wäre eine produktseitige Unterstützung hier denkbar. DQM­Produkte müssten eine Liste von DQ­Kennzahlen bereitstellen, deren Werte durch den Anwender zu definieren sind. Die so definierten DQ­Kennzahlen ließen sich dann – wiederum durch den Anwender – den jeweiligen Geschäftsregeln zuordnen. Ohne produktseitige Unterstützung muss dieser Vorgang fortlaufend durch das DQM­Team vorgenommen werden, was einen erheblichen Aufwand verursacht.

16.3 Funktionale Kriterien

289

Eine weitere Anforderung, die heute die wenigsten Data­Profiling­Werkzeuge unterstützen, ist die Umwandlung rein technischer Bewertungen der Datenqualität in fachlich verständliche und relevante Erkenntnisse. Zur Veranschaulichung soll das folgende Beispiel herangezogen werden: ■ Profiling­Ergebnis: 3 Prozent der Datensätze der Tabelle Kundenstamm haben NULL­Werte in der Spalte PLZ. ■ Abgeleitete fachlich relevante Erkenntnis: 10 Prozent der Kunden des Kundensegments Gold haben eine unvollständige Adresse. Datenbereinigung

Einerseits verkürzt es die Entwicklungszeit, wenn der Produktanbieter bereits vordefinierte Regeln für die relevanten Domänen (z.B. Namen und Adressen, Produktstammdaten) bereitstellt. Andererseits ist es aber sehr häufig erforderlich, diese Regeln entsprechend der Spezifika des Anwenders zu modifizieren oder auch ganz neu zu definieren. Diese Flexibilität sollte ein Werkzeug mitbringen. Duplikate

Duplikate zuverlässig zu finden ist eine Wissenschaft für sich. Problematisch ist dabei vor allem, dass die Algorithmen für Match als auch Merge sehr stark sprach­ und regionsspezifisch sind. Global agierende Unternehmen stehen dann vor der Herausforderung, dass sie in ihrem Duplikaterkennungsprozess alle diese Spezifika abdecken müssen. Aber selbst Unternehmen, die ihr Geschäft nur in einem Land betreiben, müssen mehr oder weniger stark auch Kunden berücksichtigen, deren Namen aus anderen Sprachräumen stammen. Letztendlich ist meistens eine große Vielfalt an passenden Algorithmen erforderlich. In erster Näherung lässt sich sagen, dass ein Anbieter genau die Sprachräume und Regionen gut unterstützt, in denen er selbst zu Hause ist und sein Geschäft aufgebaut hat. Durch die Konsolidierung und Globalisierung des Anbietermarkts wird es hier in den nächsten Jahren eine für die Anwender günstige Entwicklung geben. Die notwendige Vielfalt an Algorithmen lässt sich aber auch noch auf einem anderen Wege bewerkstelligen: Manche Werkzeuge unterstützen die Bereitstellung ihrer Algorithmen für Drittanbieter, die wiederum die Einbindung der extern bereitgestellten Algorithmen unterstützen müssen (siehe Abb. 16–1).

290

16 Produktauswahl und -integration

Tool A

Tool B

Dublettenerkennung Programm

Abb. 16–1

Match & Merge-Algorithmen

Match & Merge-Algorithmen

WHIRL

Soundex Deutsch

N-Gramme

Rekursiver Feldabgleich

Soundex Englisch

Editierabstand

…

…

Beispiel für die Einbindung von Algorithmen eines Drittanbieters

Da sich nicht in allen Fällen Duplikate sicher feststellen lassen, sollen ■ Match­Funktionen eine Wahrscheinlichkeit für das Duplikat ermitteln, ■ Anwender Schwellwerte definieren können, ab denen Datensätze automatisiert verknüpft (Merge) bzw. als Duplikatkandidat (zur manuellen Auflösung durch einen Data Steward) gekennzeichnet werden, und ■ Merge­Funktionen entsprechend der durch den Anwender eingestellten Schwellwerte Duplikate automatisch bereinigen, d.h. die Datensätze entsprechend reduzieren. Anreicherung

Zur Anreicherung von Daten werden häufig Referenzdatenbanken befragt oder direkt erworben. Zuvor sollte allerdings die Vollständigkeit der Referenzdaten hinterfragt werden. Häufig sind die Referenzdaten zwar für eine bestimmte Region sehr vollständig und korrekt, für andere, entferntere Regionen hingegen sehr schlecht gepflegt. Sicherheitshalber sollte der Anbieter die Qualität der bereitgestellten Referenzdaten vertraglich zusichern. Beispiel: Wenn der Anbieter zugesichert hat, dass die Adressdaten zu 98 Prozent korrekt sind, aber bei einer Aussendung 5 Prozent Rückläufer auftreten, sollte der Anbieter eine Vertragsstrafe zahlen.

16.4 Integration

291

Monitoring

Das DQ­Monitoring soll Ergebnisse auch in Form von Berichten bereitstellen. Neben der Darstellung von Detailproblemen ist ebenfalls eine übergreifende Darstellung der Datenqualität bezogen auf die einzelnen DQ­Kriterien wie Vollständigkeit und Korrektheit wichtig. Eine Aggregation der Ergebnisse vom Attribut über die Entität bis zur Domäne ist erforderlich. Darüber hinaus sind auch Trendanalysen auf Zeitreihen über mehrere Monitoring­Läufe gewünscht, z.B. um den Erfolg eingeleiteter DQ­Maßnahmen zu überprüfen.

16.4 Integration Die Integration der verschiedenen Komponenten und Services des Datenqualitätsmanagements sowie deren Einbindung in operative Geschäfts­ und Datenintegrationsprozesse ist in der Regel eine zentrale Anforderung. So liegt es meist in der Verantwortung des DQ­Monitoring, Datenintegrationsprozesse abzubrechen, wenn definierte Prüfkriterien nicht erfüllt sind. Abbildung 16–2 zeigt eine Referenzarchitektur für die Integration der Produkte des Datenqualitätsmanagements. Anwender Data Steward Fachbereich

Entwickler

DQ-Manager

Clients StandarBereinigung Regeldisierung, Profiling, von Namen definition, Bereinigung Exploration & Adressen Validierung Server allgemein

Match & Merge

AnreicheMonitoring rung

DQ-Plattform Zentrales Repository Regeln

Profiles

Stats

Kennzahlen, Dimensionen

Laufzeitumgebung (Online/Offline)

API

Abb. 16–2

Lokalisierung

Services

Metadatenmanagement

SDK

Referenzdatenbanken

Referenzarchitektur für die Integration der Komponenten und Services des Datenqualitätsmanagements

Ergebnisse, die innerhalb eines funktionalen Bereichs des Datenqualitätsmanagements, quasi einer Produktkategorie, erstellt wurden, sollen auch in den anderen Bereichen zur weiteren Verwendung zur Verfügung stehen. Ein wichtiges Beispiel hierfür wird im Folgenden beschrieben:

292

16 Produktauswahl und -integration

■ Im Data Profiling wird der Inhalt eines Datenfelds bezüglich der Werteliste ermittelt. ■ Der Data Steward wird aus dieser Liste der real vorkommenden Werte eine Liste zulässiger Werte ableiten, d.h. eine Geschäftsregel für dieses Datenfeld aufstellen. ■ Die definierte Geschäftsregel soll nun validiert werden, wenn Daten in das Data Warehouse geladen werden. Dazu muss die Geschäftsregel von mehreren Ladeprogrammen ausgeführt werden. Dabei sollte jedoch die Geschäftsregel nicht in den Ladeprogrammen ausformuliert sein, sondern von dort aus aufgerufen werden. ■ Beim Monitoring der Datenqualität werden Verletzungen der definierten Geschäftsregel angezeigt. Zu empfehlen sind daher DQ­Suites, die auf einer gemeinsamen Plattform aufsetzen und auf ein zentrales Repository zugreifen. Das Repository des DQM­Produkts soll über ein dokumentiertes API verfügen, sodass auf die Ergebnisse von DQM­Prozessen bei Bedarf auch zugegriffen werden kann und diese extern weiterverwendet werden können. So könnte z.B. der Zugriff auf definierte Geschäftsregeln und Monitoring­Ergebnisse über eine selbst erstellte spezifische Komponente »Monitoring­Scorecard bezogen auf die eigenen DQ­Dimensionen« sichergestellt werden. Weiterhin muss es eine API zur Einbindung von DQ­Funktionen in operative Anwendungen bzw. Prozesse geben. Dies ist insbesondere bezüglich der Datenvalidierung und ­bereinigung, aber auch in Hinsicht auf das Monitoring unerlässlich. Zu diesem Zweck unterstützen viele DQM­Werkzeuge gängige Standards für die Konnektivität wie Java Messaging Service, Web Services u.a. Beispiel: Duplikate in der Kundendimension des Data Warehouse wurden als Problem erkannt. Im ersten Schritt werden die Duplikatkandidaten identifiziert und in der Folge automatisch bzw. manuell aufgelöst. Damit ist die Kundendimension in dieser Hinsicht sauber – jedoch nur für kurze Zeit, denn jeden Tag kommen neue Kundendaten aus dem operativen Quellsystem hinzu, die neue Duplikate mit sich bringen. Zur Lösung des Duplikatproblems muss auch das operative Quellsystem einbezogen werden, idealerweise die entsprechende Datenerfassungsmaske. Wie Duplikate erkannt und ein Duplikatcluster gebildet werden, wurde bereits im ersten Schritt definiert und implementiert. Genau diese Logik muss nun in das operative Quellsystem eingebunden werden. Viele Datenbereinigungswerkzeuge können die definierte Logik als Webservice bereitstellen, der vom operativen Quellsystem eingebunden werden kann. Die Integration mit den operativen Systemen ist wichtig, insbesondere auch mit dem Produktionsbetrieb (Automation) sowie zu zentralen Repositorys (Data Description) und zur zentralen Security.

16.5 Einbeziehung der Fachbereiche

293

Es gibt verschiedene Arten des Deployments von DQ­Programmlogik. Meistens wird hierbei in Batch (Offline) und Service (Online) unterschieden. Zur Erläuterung soll folgendes Beispiel herangezogen werden: Adressangaben sollen bereinigt werden. Das Online­Deployment stellt die Funktionalität in Form eines Webservice bereit, der in die Neukundenerfassungsmaske integriert wird. Zusätzlich werden monatlich die Adressangaben des Gesamtbestands überprüft und bereinigt. Dies erfolgt im Batch­Mode anhand derselben Regeln wie im Webservice.

16.5 Einbeziehung der Fachbereiche In der Regel werden DQ­Tools von Entwicklern eingesetzt. Letztlich sind DQProbleme aber auf fachlicher Ebene zu diskutieren und abzuklären. Ansprechpartner der Fachbereiche sind also immer involviert. Damit liegt die Idee auf der Hand, DQ­Tools auch den Anwendern der Fachbereiche nahezubringen. Manche Werkzeuge versuchen eine sehr intuitive kollaborative und auf die fachliche Ebene abstrahierte Sichtweise zu bieten, sodass auch IT­affine Anwender der Fachbereiche und Data Stewards teilweise DQ­Tools einsetzen können. Das vereinfacht die Kommunikation zwischen IT und Fachbereich bzw. macht sie in kleineren Teilbereichen (z.B. Definition geschäftlicher Datenregeln) überflüssig. Ein weiterer Ansatz sind Konzepte zur Einbeziehung des Fachbereichs in das DQ­Monitoring. Hierbei wird die Freigabe von Datenbereitstellungen über ein intuitives Interface direkt durch den Fachbereich durchgeführt. Erst nach dieser Freigabe können die Daten für Auswertungszwecke verwendet werden.

16.6 Sprachen und Länder Vor allem international agierende Unternehmen sehen sich vor die Problematik der verschiedenen Zeichensätze gestellt. Deswegen sollten heutzutage DQ­Tools Unicode unterstützen: DQ­Tools müssen die Zeichensätze der Quelldaten kennen und in Unicode konvertieren können. Die gesamte Programmlogik des DQ­Tools muss auf Unicode ausgerichtet sein. Die Referenzdaten wie auch die Regeln der Datenbereinigung (z.B. für das Matching) müssen Sprachspezifika wie Umlaute berücksichtigen. So müssen z.B. Match Rules die Tücken von Umlauten verstehen. Das soll an einem einfachen Beispiel verdeutlicht werden: Die Einträge »Müller« und »Mueller« könnten sich auf dieselbe Person beziehen, müssen es aber nicht. Ein weiteres Beispiel für Sprachspezifika ist der Gebrauch von Middlenames im englischen Sprachraum, der von Matching­Verfahren berücksichtigt wird. Im deutschen Sprachraum ist die Verwendung von Middlenames ungebräuchlich, was das Matching­Verfahren einbeziehen muss.

294

16 Produktauswahl und -integration

Jedes Land bringt darüber hinaus eigene Postleitzahlen und Schreibweisen für Adressdaten mit sich, aber auch spezifische Abkürzungen, Präfixe und Suffixe, wie z.B. »Bad Nauheim a.d. Elbe«.

16.7 Einbindung in DQM-Prozesse Neben der reinen Funktionalität der Werkzeuge oder Lösungen ist ebenfalls zu hinterfragen, wie sich die jeweiligen Werkzeuge in die vom Unternehmen aufgestellten DQM­Prozesse einbinden lassen. Passen die ausgewählten Werkzeuge auch zur Organisation und zur Governance des Unternehmens? Lassen sich die Regeln und Ergebnisse der DQM­Prozesse den beteiligten Abteilungen mit dem ausgewählten Werkzeug transparent machen?

16.8 Empfehlungen Häufig werden Entscheidungen für Produkte des Datenqualitätsmanagements nur unter dem Blickwinkel einer speziellen Anwendung getroffen, also isoliert von der umgebenden IT­Anwendungslandschaft. Dabei werden meistens funktionale Aspekte übergewichtet. Um das Ziel eines ganzheitlichen, nachhaltigen Datenqualitätsmanagements zu erreichen, wird jedoch empfohlen, eher eine umfassende DQM­Suite mit einer werkzeugübergreifenden, gemeinsamen Plattform, zentralem Repository und der Möglichkeit zur Bereitstellung von Services im gesamten Unternehmen zu etablieren. Die Abstimmung mit der Anwendungsentwicklung der IT und dem Betrieb ist wichtig, um die DQM-Plattform erfolgreich zu etablieren.

Teil III 17

Datenqualitätsmanagement in einer Studie

301

18

Datenqualitätsmanagement in der Spezifikation

319

19

Datenqualitätsmaßnahmen in der Konstruktionsphase

335

20

Steuerung der Datenqualität in der Realisierung

345

21

Steuerung der Datenqualität im Betrieb

351

296

Einleitung

In vielen Projekten werden Wochen und Monate für die Anforderungsanalyse aufgewendet, um dann am Ende feststellen zu müssen, dass die Spezifikation nicht mit den realen Daten aus den Quellsystemen übereinstimmt. Diese Projekte folgen dem leider vielfach beobachteten Ablauf: ■ ■ ■ ■ ■

Spezifikation erstellen, BI­Anwendung realisieren, Systemtest mit realen Daten durchführen, von der schlechten Datenqualität überrascht sein und wieder von vorne beginnen.

Das Problem dieses Vorgehens ist, dass die Entwicklung ausschließlich auf Grundlage der Spezifikation geplant und durchgeführt wird – ohne sich vorher ein Bild von der Qualität der Echtdaten in den Quellsystemen verschafft zu haben. Um diesen Teufelskreis zu durchbrechen, werden nachfolgend die Inhalte der ersten beiden Teile dieses Buches auf das Vorgehen in einem BI­Projekt abgebildet. Damit wird einerseits der zusätzliche Aufwand für das Rework vermieden und andererseits die Datenqualität der Ergebnisse verbessert. Das verwendete Projektmodell gliedert sich in fünf Phasen (siehe Abb. III–1). Jede dieser Phasen wird im Folgenden in einem eigenen Kapitel behandelt: ■ ■ ■ ■ ■

Studie Spezifikation Konstruktion Realisierung Betrieb

298

Einleitung

Systemerstellung (oft in Stufen) Spezifikation

Studie

Betrieb

Konstruktion

Wichtige Ergebnisse

Ziel

Realisierung

Machbarkeit sicherstellen: › Funktionsumfang › Technik › Termin › Kosten › › › ›

Systemvision Grobkonzept Projektvorschlag ggf. Prototyp

Abb. III–1

› Kundenanforderungen detaillieren › Anforderungen in ein produktives System umsetzen

› Reibungsloser Betrieb › Frühzeitiges Erkennen von Problemen

› › › ›

› Logdateien › Statistiken

Spezifikation Konstruktion ggf. Prototyp Produktive Software

Verwendetes Projektmodell

Die Studie beschreibt grob den Funktionsumfang, die Technik, die Termine und die Kosten. Sie soll die Machbarkeit (auch in Bezug auf die Datenqualität) der nachfolgenden Systemerstellung gewährleisten. Typische Ergebnisse sind Systemvision, Grobkonzept, Projektvorschlag und nötigenfalls ein Prototyp. Eine Spezifikation1 ist eine Beschreibung der künftigen BI­Lösung aus fachlicher Sicht. Es ist die verbindliche (vollständige, widerspruchsfreie und nachvollziehbare) Darstellung dessen, was die Lösung beinhaltet und was nicht. Sie bildet die Schnittstelle zwischen der Fachabteilung, die das geplante System beurteilt, und dem Konstruktions­ und Realisierungsteam, das das System umsetzt. Beschreibt die Spezifikation das »Was«, nämlich die fachliche Funktionalität eines Softwaresystems, so legt die Konstruktion das »Wie«, die softwaretechnische Konzeption der BI­Anwendung, fest. Diese Phase wird in aller Regel »verzahnt« mit der Spezifikation durchlaufen, um technische Risiken frühzeitig zu erkennen. Wichtige Ergebnisse einer Konstruktion sind z.B. (physischer) Datenbankentwurf, Fehlerbehandlung, Systemarchitektur. Oft wird die Gesamtheit aller Konstruktionsergebnisse auch DV­Konzept genannt. Die Realisierung umfasst die Programmierung und das Testen der Lösung. Nach Abschluss der Integration folgt mit der Inbetriebnahme die Phase des Betriebs. Zu beachten ist, dass eine sehr frühzeitige Einbeziehung des Betriebs, d.h. lange vor der Inbetriebnahme, ein wesentlicher Erfolgsfaktor für BI-Projekte ist.

1.

auch Systemspezifikation, Fachkonzept oder Analyse genannt

Einleitung

299

Um die Abbildung der einzelnen Phasen auf andere Vorgehensmodelle zu erleichtern, ist in Abbildung III–2 eine Zuordnung zu den »Engineering Disciplines« des Rational­Unified­Prozesses (RUP) (vgl. [Jacobson/Booch/Rumbaugh 1999]) dargestellt. Die Phase »Studie« kann nicht zugeordnet werden, da sie nicht zur Systemerstellung zählt. RUP Engineering Disciplines

Projektphasen

Business Modeling Requirements Analysis & Design Implementation

Spezifikation Konstruktion Realisierung

Test Deployment

Abb. III–2

Betrieb

Abbildung der Projektphasen auf den RUP

Fallstudie: Fusion der Motorsport Engines AG und der Bike GmbH In einer durchgängigen Fallstudie (die Idee zu dieser Fallstudie stammt aus [Apel/ Behme 2010]) werden über den gesamten Teil III die einzelnen Maßnahmen zur Verbesserung der Datenqualität in den verschiedenen Phasen praxisorientiert dargestellt, um dem Leser die Umsetzung in einem eigenen Projekt zu erleichtern. Das international tätige Unternehmen Motorsport Engines AG hat vor kurzem die Bike GmbH gekauft. Um am Markt als gemeinsames Unternehmen erfolgreich zu sein, müssen die verschiedenen Anwendungslandschaften und Systeme schnellstmöglich konsolidiert werden. Denn nur konsistente, akkurate und unternehmensweite Stammdaten, die das Herzstück aller Geschäftsprozesse bilden, ermöglichen einen einheitlichen Blick auf den Datenbestand. In den Stammdaten stecken die Kerninformationen über Materialien, Produkte, Lieferanten, Verträge und Kunden, aus denen sich später die Datenhaltungs- und Datenverteilungsarchitektur für die Konzernstammdaten ableitet. Die Motorsport Engines AG verwendet aktuell im Einkauf ein zentrales Stammdatensystem, in der ehemaligen Bike GmbH existierten dagegen aus historischen Gründen zwei verschiedene Systeme. Die Abwicklung der operativen Geschäftsprozesse erfolgt jeweils in einem eigenen ERP-System. Somit ist es derzeit nicht möglich, ein einheitliches Bild über die Vorgänge im Einkauf zu erhalten. In einem BI-Projekt bestehend aus den Teilprojekten Integration und Reporting soll das Management in die Lage versetzt werden, mithilfe eines einheitlichen Berichtswesens (Spend Management Reporting) das neu entstandene Unternehmen einkaufsseitig zu steuern. Um das Beispiel nicht zu umfangreich werden zu lassen, fokussiert sich der BI-Teil ausschließlich auf den Konzernbereich Einkauf, wohlwissend, dass zur Unternehmenssteuerung mehr Sichten gehören.

➝

300

Einleitung

Gerade in der Einkaufsabteilung offenbaren sich die großen Einsparungspotenziale einer Unternehmensfusion. Nach einer alten Kaufmannsregel entspricht ein Prozent Einsparung im Einkauf einer Absatzsteigerung von 18 Prozent! Solche Einsparungen lassen sich erzielen, indem man z.B. gleiche Materialien oder Dubletten bei den Lieferantenstammdaten konzernweit identifiziert und zusammenführt. Die dadurch möglichen Bündelungseffekte führen dazu, dass von einzelnen Materialien höhere Volumen bestellt werden können, was dem Einkauf höhere Rabatte bei den Lieferanten einbringt. Diesen Effekt hat sicherlich jeder schon im Supermarkt erlebt: Eine Großpackung Margarine ist kaum teurer als eine kleine mit deutlich weniger Inhalt. Um diesen Effekt nutzen zu können, müssen in dem Teilprojekt Integration die drei genannten Stammdatensysteme in ein gemeinsames Zielsystem überführt und die vorhandenen Daten migriert und zusammengeführt werden. Um diese Ziele möglichst zeitnah erreichen zu können, wurde seitens der Motorsport Engines AG entschieden, die operativen Systeme der beiden Unternehmen vorerst unverändert zu belassen und die Integration der Daten über ein in der Motorsport Engines AG bereits vorhandenes DWH durchzuführen. Parallel dazu wird ein Auswahlprojekt gestartet, das die Suche nach einem operativen Zielsystem für das gemeinsame Unternehmen zur Zielsetzung hat. In einem ersten Schritt werden zunächst konzernweit gleiche Materialien oder Teile (sogenannte Gleichteile) aufgespürt. In der Regel gibt es aber in den verschiedenen Systemen keine dafür notwendige eindeutige Materialnummer. Auch die Hersteller-Teilenummern sind in der Praxis häufig nicht gepflegt, sodass ein aufwendiger Abgleich über andere Stammdatenattribute erfolgen muss. Selbst in den jeweiligen Systemen der Motor Engines AG und der Bike GmbH existieren vermutlich viele Gleichteile unter verschiedenen Bezeichnungen. In einem zweiten Schritt wird das Einkaufsvolumen des Konzerns zusätzlich auf bestimmte Materialgruppen abgebildet, damit die Einkäufer bei Rahmenverträgen mit ihren Lieferanten eine bessere Verhandlungsgrundlage haben. Am einfachsten und besten gelingt das mit einer eindeutigen, hierarchischen Klassifizierung aller Materialien. Die Motorsport Engines AG hat in der Vergangenheit keine der im Markt vorhandenen Klassifikationen genutzt, sondern ein eigenes Klassifikationsverfahren entwickelt. Die Bike GmbH setzt hingegen die vom Bundesverband für Materialwirtschaft, Einkauf und Logistik zusammen mit einigen Großkonzernen entwickelte Klassifikation eClass (siehe Abschnitt 12.5) ein. Im Rahmen einer Lieferantenstammdatenkonsolidierung werden im dritten Schritt mehrfach in den Systemen vorkommende Lieferanten zu einem Stammdatensatz zusammengefasst. Nur damit gelingt es, eine zuverlässige Aussage über das gesamte Beschaffungsvolumen eines Lieferanten zu bekommen. Zusätzlich müssen dabei Konzernverflechtungen in der Lieferantenorganisation identifiziert werden, um alle Umsätze richtig zuordnen zu können. Ausgehend von diesen Rahmenbedingungen wird in den folgenden Kapiteln dargestellt, wie die einzelnen Maßnahmen zur Verbesserung der Datenqualität für dieses Praxisbeispiel konkret gestaltet werden (jeweils gekennzeichnet durch einen grauen Kasten).

301

17 Datenqualitätsmanagement in einer Studie

Eine Studie zu erstellen ist eine komplexe, zielgerichtete und strukturierte Aufgabe, die aus vier Teilschritten besteht: 1. 2. 3. 4.

Istzustand analysieren, Sollkonzept entwerfen, Bewertung und Empfehlung abgeben und Umsetzung planen.

Die Ergebnisse einer Studie dienen in der Regel zur Entscheidungsfindung; sie sind die Ausgangsbasis für die nachfolgende (Weiter­)Entwicklung der BI­Anwendung. Wer eine Studie erstellt, muss an die nachfolgenden Phasen denken und Anforderungen, Ausgrenzungen und Prämissen für die Spezifikation berücksichtigen. Wie sich Studie und nachfolgende Spezifikation unterscheiden, ist in Kapitel 18 erläutert. Studien (vgl. [Agens 2007]) belegen, dass es in über 80 Prozent der Projekte zu substanziellen Termin­ und/oder Budgetüberschreitungen kommt oder diese scheitern, weil bei der Planung vor allem das Ausmaß der Datenqualitätsprobleme nicht bekannt war. Schon zu Beginn der Studie muss das Projektteam die Datenqualität unter die Lupe nehmen, da es ansonsten die Umsetzung nicht realistisch planen kann (Zeit, Budget, Funktionsumfang). Insbesondere muss das Team die Qualität der benötigten Daten aus den Quellsystemen kennen, um die BI­Anwendung (weiter­)entwickeln zu können. Verzichtet man darauf, eine Studie zu erstellen, sind die im Folgenden beschriebenen Aktivitäten zu Beginn der Spezifikationsphase nachzuholen oder zu ergänzen. Ein Rat für Dienstleister: Festpreisangebote sind erst möglich und einhaltbar, wenn die verschobenen Aktivitäten aus der Studie in der Spezifikation nachgeholt worden sind. Wer vollständig auf diese Aktivitäten verzichtet, riskiert den Erfolg des gesamten Projekts. Im Folgenden sind ausschließlich jene Aspekte beschrieben, die die Datenqualität betreffen.

302

17 Datenqualitätsmanagement in einer Studie

17.1 Analyse des Istzustands Identifikation der Quellsysteme

Als Erstes werden die Quellsysteme mit ihren Datenbeständen identifiziert, die bei der nachfolgenden (Weiter­)Entwicklung der BI­Anwendung Verwendung finden sollen. Dies geschieht in der Regel in Interviews und/oder Workshops, wobei vorab zu klären ist, welche Projektbeteiligten (Fachbereiche, IT­Abteilung, Auftraggeber etc.) die Informationen liefern. Wichtig ist, dass die Befragten vorbereitet in diese Gespräche gehen, denn aus dem Stand können sie die detaillierten Fragen zur Herkunft der Daten nicht beantworten. Sinnvoll ist es, die Teilnehmer vorab Fragebögen ausfüllen zu lassen, sodass sie in den Gesprächen nur noch bestehende Unklarheiten beseitigen und offene Fragen beantworten müssen. Häufig werden auch einzelne Dateien (wie z.B. Excel­Mappen) als Datenquellen für die BI­Anwendung benutzt. Gerade diese Dateien vergessen die Befragten gerne, weshalb es sich lohnt, explizit nachzufragen. Denn diese Dateien besitzen oftmals eine unzureichende Datenqualität und sind nicht hinreichend dokumentiert. Vielfach machen Projektteams den Fehler, sich blind ausschließlich auf die vorgeschlagenen Datenbestände zu beschränken. Den Befragten ist jedoch nicht immer bekannt, dass es im Unternehmen unterschiedliche Quellen für die benötigten Daten gibt. Natürlich schlagen sie nur die ihnen bekannten Quellsysteme vor, die aber nicht unbedingt die beste Datenqualität besitzen. Um die alternativen Datenquellen zu finden, muss man den Kreis der Befragten eventuell erweitern. Hilfreich sind auch vorhandene Metadaten, dazu zählen u.a. Daten­ und Prozessmodelle sowie Datenarchitekturen. Die verschiedenen Datenquellen werden in den nachfolgenden Schritten genauer analysiert und hinsichtlich ihrer Datenqualität bewertet, um daraus einen Vorschlag mit der am besten geeigneten Alternative zu erarbeiten. In einem Workshop identifiziert das Team des Teilprojekts Integration als Erstes die Systeme der beiden Unternehmen, die die zu integrierenden Stammdaten zu Materialien und Lieferanten enthalten. Die Motorsport Engines AG hält die Stammdaten zu Materialien und Lieferanten im Stammdatensystem Alpha. Bei der Bike GmbH liegen alle Stammdaten zu Materialien und Lieferanten im Stammdatensystem Bravo. In anschließenden Befragungen und Recherchen wurde erfolgreich validiert, dass die beiden Systeme die einzigen mit diesen Stammdaten sind und keine weiteren Daten aus anderen Systemen integriert werden müssen.

➝

17.1 Analyse des Istzustands

Datenquellen

303

Operative Systeme Motorsport Engines AG

Bike GmbH

Stammdaten Einkauf B (Bravo)

Stammdaten Einkauf A (Alpha) Material

Abb. 17–1

Lieferant

Kunde

Material

Lieferant

Stammdaten Kunde

Quellsysteme für die Stammdaten

In Tabelle 17–1 ist am Beispiel der Materialstammdaten zu erkennen, dass sich die Strukturen der Daten in den Stammdatensystemen der beiden Unternehmen unterscheiden. Dies gibt dem Team einen ersten Fingerzeig auf die im Teilprojekt Integration notwendigen Datenintegrationsprozesse.

Tab. 17–1

Stammdatensystem Alpha

Stammdatensystem Bravo

Artikel_ID

Artikelnummer

Artikel_Kurztext

–

Artikel_Langtext

Artikeltext

Nettogewicht

Gewicht

Nettogewicht_Masseinheit

–

Artikelgruppen_ID

–

–

Artikelgruppe

Artikelklassen_ID

–

Lieferanten_ID

Lieferantennummer

Lieferantenbestellnummer

Bestellnummer

Beschreibung

–

Breite

Breite_in_cm

Breite_Masseinheit

–

Hoehe

Hoehe_in_cm

Hoehe_Masseinheit

–

Laenge

Laenge_in_cm

Laenge_Masseinheit

–

Mindestbestellmenge

Mindestmenge

eClass_Nr

Eigene_Klassifikations_Nr

Vergleich der Materialdatenstrukturen der Stammdatensysteme Alpha und Bravo

304

17 Datenqualitätsmanagement in einer Studie

Suche nach den Datenverantwortlichen

In einem Unternehmen mit einer zentralen Data­Governance­Organisation (siehe Kap. 4) lassen sich die Ansprechpartner für die Datenqualität leicht identifizieren. Existiert diese Organisation nicht, sind die jeweiligen Datenverantwortlichen zu suchen. Es ist von Vorteil, dies möglichst iterativ zu tun, nachdem die jeweiligen Quellsysteme mit ihren Datenbeständen identifiziert wurden. Aus den Gesprächen mit den Datenverantwortlichen erhält man oft bisher unbekannte Informationen und Hinweise auf alternative Quellen, die diesen Prozess beschleunigen und zu besseren Ergebnissen führen. Wichtig ist es, bei diesem Schritt sowohl den fachlichen als auch den technischen Datenverantwortlichen zu identifizieren. Die fachlichen Datenverantwortlichen informieren über die fachliche Bedeutung der Daten, die zugehörigen Geschäftsprozesse und die an der Datenerfassung beteiligten Systeme. Ergänzend erklären die technischen Datenverantwortlichen Struktur und Qualität der Daten sowie den geplanten Bereitstellungsprozess (z.B. Aktualisierungsrhythmus, Bereitstellungszeitpunkt, Datenvolumen). Die Ergebnisse werden dokumentiert (siehe Tab. 17–2): Sie bilden die Grundlage für weitere Informationen, die in den nachfolgenden Schritten und Projektphasen hinzukommen. ID System

Datenobjekt

1

IKARUS

Tabelle, Server: Lieferunmucdb1, T_LIEFEgen SID: ad10 RUNGEN

2

–

Absatzplanung

Server: bnfs1, d:\ablage\ II.1\

…

…

… …

Tab. 17–2

Standort

Verantwortlich (fachl.)

Verantwortlich (techn.)

Peter Müller, Abt. II.1

Branco Sippel, Abt. V.4

ExcelMappe, Absatz_p_ mmyy.xls

Dirk Schuster, Abt. II.4

Frank Förster, Abt. II.4

pro Monat eine Datei

…

…

…

…

Art, Name

Bemerkung

Tabelle mit Übersicht der Datenverantwortlichen (Beispiel)

Wenn man die Zielsetzung dieses Praxisbeispiels im Auge behält, sind die hier zu betrachtenden Daten in erster Linie die Material- und die Lieferantenstammdaten. Die relevanten Datenquellen sind daher die Systeme A (Alpha) und B (Bravo). Das Quellsystem C beinhaltet Kundendaten, die für dieses von der Einkaufsabteilung geplante Projekt keine unmittelbare Berücksichtigung finden. Dies zeigt auch gleich eine erste Problematik auf, die in Projekten, die aus einer einzelnen Abteilungssicht heraus gestartet werden, regelmäßig auftritt: Es werden hier in erster Linie Daten der Einkaufsabteilung analysiert und qualitätsgesichert, während die Kundendaten keine Beachtung finden. Es ist aber festzuhalten, dass eine Kundenkonsolidierung aus Konzernsicht allerhöchste Priorität haben muss, da die nachfolgenden Schritte und Aktivitäten analog für Kundendaten durchzuführen sind.

➝

17.1 Analyse des Istzustands

305

Nachdem die Quellsysteme der beiden Unternehmen identifiziert sind, müssen schnell die fachlichen und technischen Verantwortlichen dieser Datenquellen gefunden werden. Der Ausgangspunkt für die Suche nach den Datenverantwortlichen in beiden Unternehmen ist die Frage nach einer bestehenden Data-Governance-Organisation. Ergebnis dieser Untersuchung ist, dass die Bike GmbH bereits vor längerer Zeit eine Data Governance für die Quellsysteme implementiert hat. Es wurde einerseits ein unternehmensweit verantwortlicher Data Quality Manager installiert sowie andererseits Datenverantwortliche für die einzelnen Quellsysteme benannt. Diese Datenverantwortlichen sitzen in den verschiedenen Fachabteilungen. In der Einkaufsabteilung der Bike GmbH gibt es somit Datenverantwortliche für die Materialund Lieferantenstammdaten des Quellsystems B. Die Aufgabe der Datenverantwortlichen in der Bike GmbH ist die monatliche standardisierte Prüfung der Datenqualität in den Quellsystemen und eine Berichterstattung an den Data Quality Manager. Er konsolidiert die Berichte aller Quellsysteme und berichtet diese an den DQ-Lenkungsausschuss, der aus den Abteilungsleitern der Bike GmbH besteht. Im Lenkungsausschuss werden im Bedarfsfall Maßnahmen beschlossen, die vom Data Quality Manager vorgeschlagen wurden. Neben den Abläufen zur laufenden Qualitätssicherung hat die Bike GmbH auch ein formales Anforderungs- und Problemmanagement definiert. In der Motorsport Engines AG existiert dagegen keine formale Data Governance. Die Verantwortung zur Datenqualitätssicherung ist den Abteilungsleitern der Fachabteilungen bzw. der IT überlassen. Diese reagieren meist erst beim Auftauchen von Datenqualitätsproblemen, indem sie ihre Mitarbeiter ad hoc für die Lösung der Probleme verantwortlich machen. Dieses Vorgehen führt auch dazu, dass es keine abteilungsübergreifende Kommunikation von Datenqualitätsproblemen in der Motorsport Engines AG gibt. Die technischen Systemverantwortlichen sind im Gegensatz zu den fachlichen Datenverantwortlichen in beiden Unternehmen klar definiert. In den IT-Abteilungen der Motorsport Engines AG und der Bike GmbH gibt es technische Systemverantwortliche für die hier relevanten Quellsysteme A und B, die allerdings keine formale Verantwortung für die Datenqualitätssicherung besitzen. Die potenzielle Datenorganisation innerhalb der bestehenden BI-Systeme (DWH/Berichtssysteme) wird in Abschnitt 18.2 genauer betrachtet. Es ist hier allerdings festzuhalten, dass die fachlichen Datenverantwortlichen der Quellsysteme im Regelfall in die Datenqualitätssicherung der BI-Systeme involviert sein müssen bzw. die Verantwortung für die Qualitätssicherung in den BI-Systemen innehaben sollten. Nicht zu vergessen ist in diesem Zusammenhang auch die Suche nach einem Sponsor, der hinter dem Projekt steht bzw. der ein unmittelbares Interesse an dem Projekterfolg hat. Im Idealfall ist das bereits vor dem Start der Studie erfolgt, allerdings ist dies im Zuge der Studie noch einmal für das gesamte folgende Projekt zu bestätigen. Der Sponsor sollte in jedem Fall eine C-Level-Position innehaben. In diesem Beispiel konnte jener Vorstand als Sponsor gewonnen werden, dem die Einkaufsabteilung der Motorsport Engines AG unterstellt ist.

306

17 Datenqualitätsmanagement in einer Studie

Qualitative Analyse der Quellsysteme

Analyse der Metadaten Wie notwendig und nützlich Metadaten für das Verständnis der Daten sind, wurde in Kapitel 14 dargelegt. Aus diesen Gründen sind auch die Metadaten in der Istanalyse zu suchen, zu analysieren und zu dokumentieren. Ein zentrales Metadaten­Repository erleichtert diese Suche. Da es dieses in den meisten Unternehmen nicht gibt, muss man die Datenverantwortlichen fragen und die Quellen für diese Metadaten identifizieren. In den Befragungen werden meistens weitere Know­how­Träger genannt, die ebenfalls Hinweise geben können. Typische Quellen für Metadaten sind fachliche, logische und physikalische Datenmodelle, Spezifikationen und sonstige Dokumentationen (z.B. Anwendungshandbücher). Am einfachsten pflegt man diese Informationen in einem Repository oder tabellarisch (siehe Tab. 17–3). Die Tabelle enthält das Feld »Bemerkung« für wichtige Zusatzinformationen: z.B. für den Fall, dass die in den Metadaten beschriebenen Teile nicht realisiert wurden oder durch Weiterentwicklungen (ohne Pflege der Metadaten!) veraltet sind. Zudem enthält die Tabelle eine Referenz1 auf die Quellsysteme und Datenbestände in Tabelle 17–2, mit der z.B. die Vollständigkeit überprüft werden kann.

ID

System/ Datenobjekt

Bezeichnung

Version/ Datum

Ablageort

Art

Kontaktperson

Bemerkung

1

IKARUS, Lieferungen

2.6/ Physikalisches 15.04.2006 Datenmodell

x:\Ablage\ Doku, DM_IKARUS_ 26.erx

Datenmodell

Fred Kamper, Abt. V.4

CR2958 nicht eingearbeitet

…

…

…

…

…

…

…

Tab. 17–3

…

Tabelle mit Übersicht über die Metadatenquellen (Beispiel)

Die vorhandenen Metadaten sind nicht nur zu dokumentieren, sondern anschließend auch zu analysieren. Allerdings reicht es in dieser Phase, einen qualitativen Eindruck der Metadaten zu erhalten: Sind sie vollständig? Konsistent? Wie hoch ist der Detaillierungsgrad? Nur mit diesen Eindrücken kann das Projektteam die nächsten Projektphasen realistisch planen. In den nachfolgenden Projektschritten wird dieser Eindruck vervollständigt: Weitere Metadaten kommen hinzu, die Analysen werden feiner. Mithilfe der Metadaten wird zusätzlich analysiert, inwieweit die Definitionen der Daten sowie die Geschäftsregeln in den Quellsystemen mit denen der geplanten BI­Anwendung übereinstimmen. Aus dem Grad der Überdeckung lässt sich der Aufwand für die notwendigen Datenqualitätsmaßnahmen ableiten. 1.

im Feld System/Datenobjekt

17.1 Analyse des Istzustands

307

Metadaten zu den im Einkauf verwendeten Stammdatensystemen sind vorhanden. Bereits auf den ersten Blick (siehe Tab. 17–1) lassen sich einige Erkenntnisse beschreiben: ■ Die Bezeichner in den Stammdatensystemen beider Unternehmen weichen stark voneinander ab. Es gibt zahlreiche Synonyme. ■ Auch inhaltlich weichen viele Datenfelder voneinander ab, insbesondere bei Dateninhalten, die in einer Maßeinheit angegeben werden. ■ Einige Angaben, z.B. die Materialgruppen, lassen sich nicht ohne Weiteres aufeinander abbilden.

Dokumentation bekannter Datenqualitätsprobleme In den ersten Gesprächen mit den Datenverantwortlichen und den Kontaktpersonen erhalten die Projektmitarbeiter in der Regel bereits Hinweise auf bekannte Datenqualitätsprobleme. Diese helfen, die im späteren Verlauf des Projekts durchzuführenden Aktivitäten einzuschätzen und das Projekt realistischer zu planen. Um die vorhandenen Hinweise zu konkretisieren und neue Hinweise zu erhalten, sind weitere Befragungen nötig. Es empfiehlt sich, für jeden relevanten Personenkreis einen Workshop zu einem fest umgrenzten Datenbestand durchzuführen. Fragebögen sind kein Ersatz für den Workshop, weil die Befragten aufgrund der starren Struktur und der geschlossenen Fragen die Probleme nicht vollzählig und nicht vollständig darstellen können. Sie helfen aber den Teilnehmern, sich auf den Workshop vorzubereiten. Denn auch hier gilt: Ohne Vorbereitung ist kaum ein Teilnehmer in der Lage, einen hinreichenden Beitrag zum Ergebnis zu liefern. An diesen Workshops sollten möglichst alle Mitarbeiter teilnehmen, die Informationen zur Datenqualität haben könnten. Auch ist Wert auf den richtigen Mix zwischen fachlich und technisch orientierten Mitarbeitern zu legen. Mitarbeiter aus der Fachabteilung können z.B. von ihren Problemen bei der Datenerfassung sprechen, Datenbankadministratoren hingegen über falsche Datentypen für einzelne Attribute oder vorhandene Duplikate. Anschließend sind die Sichten zu synchronisieren und zu konsolidieren, um ein möglichst vollständiges und vollzähliges Gesamtbild zu erhalten. Die Dokumentation der bekannten Datenqualitätsmängel ist die Basis für die Analysen in den nachfolgenden Phasen und liefert zudem Anhaltspunkte für weitere, quantitative Analysen (z.B. durch Data Profiling). Quantitative Analyse der Quellsysteme

Hat man sich in den qualitativen Analysen einen ersten Eindruck, ein »Bauchgefühl«, hinsichtlich der Datenqualität verschafft, gilt es nun, diesen Eindruck quantitativ mit Zahlen zu untermauern. Das probate Mittel für diesen Zweck ist Data Profiling (siehe Kap. 9). Leider glauben viele Leute, dass Data Profiling erst in späteren Projektphasen einzusetzen sei. Das ist eine Fehleinschätzung, denn kein Unternehmen sollte ein BI­Pro-

308

17 Datenqualitätsmanagement in einer Studie

jekt beginnen, ohne einen validen Zustand von der Qualität der Quelldaten zu haben. Ansonsten wird schon die Projektplanung zur Farce. Allerdings beschränkt sich das Data Profiling in dieser Phase auf relativ einfache Prüfungen, für die kein großer Aufwand zur Integration der Daten notwendig ist. So erfolgen keine Prüfungen anhand von Geschäftsregeln. Diese werden ohnehin erst während der Spezifikation erhoben und dokumentiert. Es ist empfehlenswert, das Data Profiling in zwei Schritten durchzuführen: a) ein Data Profiling hinsichtlich der bekannten Datenqualitätsprobleme und b) ein allgemeines Data Profiling. Beim Data Profiling hinsichtlich der bekannten Datenqualitätsprobleme werden die bei der qualitativen Analyse der Quellsysteme dokumentierten Datenqualitätsprobleme validiert. Dazu wird für einen realen Datenbestand überprüft, ob die vermuteten Qualitätsprobleme tatsächlich existieren und in welchem Ausmaß. Entgegen der vorigen Aussage werden in diesem Schritt häufig Geschäftsregeln verwendet, da nur mit ihnen viele der konkreten Probleme anhand der Daten geprüft werden können. In Einzelfällen kann es vorkommen, dass sich die vermuteten Probleme nicht in den Daten nachweisen lassen. Die erwartete Datenqualität stimmt nicht mit der tatsächlichen Qualität der Daten überein: Das ist ein Problem, da die Glaubwürdigkeit der Daten gering ist. Die Daten müssen in den nachfolgenden Phasen des Projekts zwar nicht korrigiert werden, aber es sind Maßnahmen zur Erhöhung der Glaubwürdigkeit dieser Daten einzuplanen und durchzuführen. Andernfalls überträgt sich die geringe Glaubwürdigkeit der Daten aus dem Quellsystem negativ auf die Daten in der BI­Anwendung. Normalerweise bestätigen sich die vermuteten Datenqualitätsprobleme anhand der Daten. Das Data Profiling liefert aber zumeist auch wichtige statistische Daten über das Ausmaß der Probleme (z.B. Prozentsatz von Artikeln ohne Artikelgruppe vom Gesamtbestand). In Diskussionen mit den Datenverantwortlichen werden die Gründe für diese Probleme erforscht. Meist erhält man auch erste Hinweise, welche dieser Datenqualitätsprobleme sich außerhalb des nachfolgenden Projekts (z.B. in den Quellsystemen selbst) beheben lassen und welche im Projekt behoben und eingeplant werden müssen. Das ist wichtig, weil die Bereinigung dieser Daten einen großen Aufwand für das BI­Projekt bedeutet – eine Bereinigung im Quellsystem hingegen nicht. Außerdem kann ohne diese Einteilung kein realistisches Sollkonzept entworfen werden. Das allgemeine Data Profiling hat die Aufgabe, bisher nicht bekannte Datenqualitätsprobleme frühzeitig zu identifizieren. Es empfiehlt sich, ein Timeboxing­Verfahren2 einzusetzen, da aus Ressourcengründen in dieser Phase keine vollständige Analyse des Datenbestands möglich ist. Der Erfolg der Analyse 2.

Dauer und Ressourceneinsatz sind festgeschrieben.

17.1 Analyse des Istzustands

309

hängt sowohl von der Erfahrung und dem Gespür des Data­Profiling­Teams als auch von der Komplexität der Daten ab. Das Team sollte die Data­Profiling­Verfahren und die Daten verwenden, mit denen es mit möglichst wenig Aufwand möglichst viele kostenträchtige Probleme identifiziert. Aus den Ergebnissen lässt sich abschätzen, wie hoch der Aufwand für die Behebung der Qualitätsprobleme sein wird. Eingangsparameter für diese Schätzung ist insbesondere der Grad der Abdeckung beim Data Profiling: Wie viele Daten wurden verwendet und wie vollständig wurden diese Daten analysiert? Das Teilprojektteam Integration führte das Data Profiling für die Material- und Lieferantendaten aus den Stammdatensystemen wie vorgeschlagen im Timeboxing-Verfahren durch (Dauer: 1 Tag). % der Nullen

% der eindeutigen Werte

Artikelnummer

0,5%

Artikelgruppe

3,7%

Bestellnummer Breite_in_cm Mindestmenge

1,5%

Spalten

Tab. 17–4

Minimum

Maximum

99,2%

13825

82703512

31,1%

1

Z9959

6,3%

99,5%

1-45243434-8

999-45322-2345

50,5%

27,4%

-56

9253664748585

53,9%

0

200.001

Teilergebnis (Auszug) des Data Profiling der Materialdaten im Stammdatensystem Bravo (Aggregation)

Aus den Ergebnissen der Data-Profiling-Analyse (Aggregation) der Materialdaten im Stammdatensystem Bravo lassen sich folgende Auffälligkeiten erkennen: ■ Artikelnummer: Nicht alle Datensätze (0,5 Prozent) besitzen eine Artikelnummer, und einige Artikelnummern (0,8 Prozent) sind mehrfach vorhanden. Damit ist die Artikelnummer in der aktuellen Qualität nicht zur eindeutigen Identifizierung eines Artikels geeignet. ■ Artikelgruppe: Es fehlt in einigen Datensätzen (3,7 Prozent) die Angabe zur zugehörigen Artikelgruppe. Somit ist eine Aggregation von Artikeln zur nächsthöheren Hierarchiestufe »Artikelgruppe« vermutlich fehlerhaft, da Artikel ohne Artikelgruppe nicht berücksichtigt werden. ■ Bestellnummer: Auch hier fehlt die Bestellnummer bei einigen Datensätzen (6,3 Prozent). Das erschwert Bestellungen, da für diese Materialien die Bestellnummer beim Lieferanten manuell ermittelt werden muss. ■ Breite_in_cm: Bei 50,5 Prozent der Datensätze fehlt die Breitenangabe, und der minimale Wert ist negativ. Durch die fehlende Breitenangabe wird der Supply-Chain-Prozess behindert, da das Volumen des Materials nicht ermittelt werden kann. Der negative Wert lässt auf Fehleingaben bei der Datenerfassung schließen.

➝

310

17 Datenqualitätsmanagement in einer Studie

■ Mindestmenge: Wie auch bei den anderen Spalten ist diese bei einigen Datensätzen nicht gefüllt (1,5 Prozent), zusätzlich lässt der »krumme« Maximalwert (200.001) wie bei der Breite auf eine fehlerhafte Datenerfassung schließen. Die Teilergebnisse der anschließend durchgeführten Genauigkeitsanalyse für die Spalte MINDESTMENGE sind in Tabelle 17–5 dokumentiert. Darin ist zu erkennen, dass die Werte 11, 2007 und 200001 vermutlich durch Fehleingaben bei der Erfassung eingetragen wurden. Wert

Anzahl Zeichen

0

Tab. 17–5

643

1

9324

10

5286

11

5

100

81463

1000

43663

2000

6354

2007

2

10000

99262

100000

230

200000

318

200001

1

Ergebnis des Data Profiling der Spalte MINDESTMENGE der Materialdaten im Stammdatensystem Bravo (Genauigkeitsanalyse)

Abgleich der Daten Die Praxis lehrt, dass das Projektteam in der Studie die in den Quellsystemen vorhandenen Daten mit den in der BI­Anwendung erforderlichen Daten abgleichen sollte. Manchmal kommt es tatsächlich vor, dass nicht alle benötigten Daten in den Quellsystemen existieren, manchmal noch nicht einmal im gesamten Unternehmen. Bemerkt das Team diese Diskrepanzen frühzeitig innerhalb der Studie, können die erforderlichen Änderungen in den Quellen oder in den Anforderungen noch rechtzeitig durchgeführt werden. Andernfalls kommt es zu einem Terminverzug und erhöhtem Aufwand in den nachfolgenden Phasen. Zusätzlich sollte geprüft werden, ob mit den verfügbaren Quellsystemdaten alle geplanten Integrationen in der BI­Anwendung möglich sind. Beispiel: Ein Quellsystem liefert die Daten zu den Kunden, ein anderes zu den Bestellungen. Die Fragen lauten hier: Gibt es eine Möglichkeit, die Bestellung direkt und eindeutig einem Kunden zuzuordnen? Oder braucht man dazu noch andere, bisher unbekannte Datenquellen, z.B. die Aufträge, mit denen die Kunden erst mit den zugehörigen Bestellungen verknüpft werden können?

17.2 Entwurf des Sollkonzepts

311

Eine weitere zu klärende Frage ist die zeitliche Verfügbarkeit zusammenhängender Quelldaten: Werden bei Bestellungen von Neukunden die Daten zu den neuen Kunden zeitgleich mit den zugehörigen Bestellungen geliefert? Oder gibt es hier einen Zeitverzug, der die Validierung der Geschäftsregeln (z.B. »Ein Kunde muss mindestens eine Bestellung getätigt haben«) beeinflusst? Analyse der Anwendungslandschaft Bevor man das Sollkonzept erstellt, ist die bestehende Anwendungslandschaft nach Systemen zu durchsuchen, in denen bereits Maßnahmen durchgeführt wurden, um die Datenqualität zu verbessern. Ziel ist es, die gemachten Erfahrungen aufzunehmen und für die Erstellung des Sollkonzepts zu überprüfen, ob sich die eingesetzten Werkzeuge eignen. Natürlich sind auch Synergieeffekte möglich, z.B. durch die gemeinsame Nutzung bereits vorhandener Datenqualitätsmaßnahmen. Um nicht die gesamte Anwendungslandschaft durchsuchen zu müssen, sollte sich das Team zunächst auf die Bereiche mit der höchsten Wahrscheinlichkeit für den Einsatz eines Datenqualitätsmanagements konzentrieren: andere BI­Anwendungen, Controlling­Systeme und die Systeme, in denen die für das Unternehmen »wertvollsten« Daten verarbeitet werden. Wieder lohnt es sich zu fragen! Oft erhält man in den Gesprächen mit den zugehörigen Projektmitarbeitern weitere, bislang unbekannte Informationen, z.B. Hinweise auf bestehende Unternehmensstandards oder Konzepte zum Datenqualitätsmanagement. Analyse der technischen Architektur In diesem Schritt wird die bestehende technische Architektur analysiert, um daraus Vorgaben für den Entwurf des Sollkonzepts zu gewinnen. Bei der Weiterentwicklung einer bestehenden BI­Anwendung werden die vorhandene Architektur und bestehende Architekturkonzepte auf die Problemstellen hinsichtlich der Datenqualität (siehe Abschnitt 5.2) analysiert. Bei der Neuentwicklung beschränkt sich die Analyse allein auf die Konzeptdokumente. Weiterhin wird analysiert, ob und wie über welche Verbindungen auf die benötigten Daten aus den Quellsystemen technisch zugegriffen werden kann, wobei ebenfalls die Performance und die Verfügbarkeit der Quellen und der Verbindungen untersucht wird.

17.2 Entwurf des Sollkonzepts Qualitative Analyse des Zielsystems

Zunächst wird das zukünftige Zielsystem qualitativ analysiert. Bei einer Neuentwicklung ist der Aufwand für diese Maßnahme größer als bei einer Weiterentwicklung, da sich dort die Analyse überwiegend auf die geänderten oder neuen Anteile beschränkt.

312

17 Datenqualitätsmanagement in einer Studie

Erwartungen an die Datenqualität

Die Anforderungen an die Datenqualität legen die Benutzer fest (siehe Abschnitt 1.3), deshalb müssen diese vor der Erstellung des Sollkonzepts nach ihren Erwartungen befragt werden. Das geschieht in drei Schritten: Als Erstes legt das Projektteam den zu befragenden Benutzerkreis fest, dann fragt es zweitens Erwartungen ab und dokumentiert diese, und drittens priorisiert es die aufgenommenen Anforderungen. Der zu befragende Benutzerkreis variiert von Projekt zu Projekt; generell gilt aber: Bei der Neuentwicklung des Systems sollte man in dieser Phase die potenziellen Endnutzer nicht direkt befragen, da der Aufwand sehr hoch wäre und diese in der Regel wenig dazu beitragen können. Besser ist es, diese Aktivität in die Spezifikationsphase zu verlagern. Mehr Erfolg hat, wer einige exemplarische Vertreter für jeden Benutzerkreis befragt. Dabei dürfen neben den direkten Datennutzern (z.B. den Sachbearbeitern aus dem Controlling) auf gar keinen Fall die anderen Dateninteressenten (z.B. das obere Management) vergessen werden, da unterschiedliche Benutzer unterschiedliche Anforderungen stellen. Alle Erwartungen sind wichtig für die Erarbeitung des Sollkonzepts und beeinflussen die Projektplanung. Immer ist der Projektauftraggeber zu befragen, da auch er häufig eigene Erwartungen an die Datenqualität hat – ohne selbst späterer Benutzer der Daten sein zu müssen. Von ihm erfährt man beispielsweise Anforderungen seitens des Unternehmensmanagements oder ob er schon Versprechungen hinsichtlich der zukünftigen Datenqualität des Systems oder dessen Weiterentwicklung abgegeben hat. Anschließend wird der festgelegte Benutzerkreis nach seinen Erwartungen an die Datenqualität befragt. Diese Erwartungen sollten möglichst konkret und verständlich formuliert werden (siehe Abb. 17–2). Qualitätsanforderungen an die Artikelstammdaten 99,8 Prozent der Artikelstammdaten müssen vollständig sein und dafür folgende Anforderungen erfüllen: ■ ■ ■ ■

Die Artikelidentifikationsnummer muss mit einem Wert (nicht Null) gefüllt sein. Der Artikel muss einer vorhandenen Artikelgruppe zugeordnet sein. Alle produzierten Artikel des Unternehmens müssen in den Stammdaten enthalten sein, neben den aktuellen auch alle jemals produzierten Artikel.

Abb. 17–2

Dokumentation der Erwartungen an die Datenqualität (Beispiel)

Bei den Befragungen orientiert man sich am besten an den Datenqualitätskriterien (siehe Kap. 1): Die Benutzer werden pro Datenobjekt befragt, welche Anforderungen sie bezüglich des jeweiligen Datenqualitätskriteriums (z.B. Korrektheit) haben. Dieses Vorgehen erleichtert die Strukturierung und steigert die Vollständigkeit, da bei einer unstrukturierten Befragung die Befragten leicht einige Erwartungen vergessen.

17.2 Entwurf des Sollkonzepts

313

In der Regel sind bei einer Studie nur begrenzte Ressourcen für diese Befragungen verfügbar, sodass fehlende Erwartungen im späteren Projektverlauf zu ergänzen sind. Die in dieser Phase aufgenommenen Erwartungen müssen aber trotzdem ausreichen, um damit ein Sollkonzept zu erstellen und das spätere Projekt zu planen. Das Projektteam konzentriert sich deshalb auf die Erwartungen, die die größten Auswirkungen auf diese beiden Bereiche haben. Indizien hierfür sind erstens die Schärfe (d.h. die Höhe der Prozentzahl) der Anforderung und zweitens das zugehörige Datenqualitätsmerkmal. Ein Datenqualitätsexperte kann aufgrund seiner Erfahrung hieraus eine Priorisierung ableiten. Die Dokumentation legt man am besten in einem Meta-daten­Repository ab. Existiert dieses nicht, kann das Projektteam die Erwartungen z.B. auch in einer Tabelle oder einem Dokument speichern. Zu jeder Erwartung wird dokumentiert, welcher Benutzer diese artikuliert hat. So kann das Team im späteren Projektverlauf mit diesem Benutzer noch weitere Fragen klären. Hat das Projektteam die Erwartungen an die Datenqualität möglichst vollständig dokumentiert, priorisieren die Benutzer diese. Durch diese Priorisierung hat das Projekt die Möglichkeit, verschiedene Alternativen für ein geeignetes Sollkonzept anzubieten. In der Praxis hat sich gezeigt, dass man auf diese Priorisierung nicht verzichten sollte. Jede Datenqualitätsmaßnahme bedeutet Aufwand – und der kann insgesamt für den Auftraggeber überraschend hoch sein. Besser ist deshalb der Ansatz, in mehreren Szenarien (je nach Priorität) den Aufwand für die Handlungsalternativen getrennt auszuweisen. Dadurch fällt dem Auftraggeber die Entscheidung leichter, die wirklich wichtigen Erwartungen mit hoher Priorität zu beauftragen, auch wenn sie viel Aufwand erfordern. Nötigenfalls kann er den Aufwand für die nicht so wichtigen Erwartungen reduzieren. Für das Teilprojekt Migration wurden die Erwartungen an die Datenqualität ermittelt und dokumentiert (siehe Abb. 17–3). Materialstammdaten (Vollständigkeit): Im DWH sollen die Materialstammdaten zu 99,5 Prozent vollständig sein. Vollständigkeit ist definiert über folgende Anforderungen: ■ Die Materialidentifikationsnummer muss mit einem Wert ungleich Null gefüllt sein. ■ Jedem Artikel muss ein Lieferant zugeordnet sein. ■ Alle Maße und Gewichte müssen mit einem Wert größer Null gefüllt sein. ■ Jedes Material muss einer Materialgruppe zugeordnet sein. ■ Alle Materialien müssen in den Stammdaten enthalten sein; das betrifft neben den aktuellen auch alle Materialien, die es jemals gab. Abb. 17–3

Erwartungen an die Datenqualität am Beispiel der Vollständigkeit der Materialstammdaten

314

17 Datenqualitätsmanagement in einer Studie

Entwurf der Architektur

Die Architektur der BI­Anwendung muss auch die Anforderungen an das Datenqualitätsmanagement abdecken. Daraus kann sich beispielsweise eine Forderung nach einer Staging Area ergeben, die sich nicht aus den sonstigen fachlichen Anforderungen ableiten ließe. Ist ein zentrales Metadatenmanagement gefordert, muss dieses in die BI­Architektur integriert werden. Aus dem Entwurf der Architektur muss erkennbar sein, wo welche Datenqualitätsmaßnahmen wie geplant sind. Aus Sicht des Fachbereichs Einkauf sollen die Stammdaten zu Material, Lieferant und Kunde möglichst schnell vereinheitlicht werden, um im Einkaufsprozess die mit der Unternehmensfusion beabsichtigten Synergien zu heben. In einer Studie wurde betrachtet, wie sich dieses Ziel in der IT unter Gesamtkostenaspekten am besten umsetzen lässt. Die Studie fand heraus, dass die Konsolidierung der bestehenden operativen Einkaufssysteme beider Unternehmen einen Zeitraum von mehreren Jahren umfassen wird. Um dennoch rasch Kosten im Einkauf sparen zu können, wurde daher beschlossen, parallel zur Konsolidierung der operativen IT-Anwendungslandschaften umgehend ein übergreifendes Spend Management Reporting aufzubauen. Der grobe Entwurf der Zielarchitektur beschreibt, dass die Stammdaten zu Material, Lieferant und Kunde aus den beiden Unternehmen in einem regelmäßig durchgeführten Datenintegrationsprozess konsolidiert und in ein neues gemeinsames Data Warehouse Einkauf geladen werden sollen. Dieses Data Warehouse ist die Datenbasis für das angestrebte Spend Management Reporting. Der Prozess der Stammdatenkonsolidierung ist in den folgenden Phasen fachlich und technisch im Detail zu beschreiben. Jedoch ist bereits jetzt absehbar, dass hier die Funktionalitäten des Datenqualitätsmanagements eine maßgebliche Rolle spielen werden. Anwender und Rollen

Fachbereich Einkauf

Datenzugriff

Speed Management Reporting

Datenziele

Data Warenhouse Einkauf Material

Datenintegration Datenquellen

Kunde

Konsolidierung der Stammdaten Operative Systeme Bike GmbH

Motorsport Engines AG

Stammdaten Einkauf A (Alpha) Material

Abb. 17–4

Lieferant

Zielarchitektur

Lieferant

Kunde

Stammdaten Einkauf B (Bravo) Material

Stammdaten Einkauf C Kunde

17.2 Entwurf des Sollkonzepts

315

Auswahl geeigneter Werkzeuge

Die Werkzeuge (siehe Kap. 16) sind mit besonderer Sorgfalt auszuwählen, da ein Wechsel in einem laufenden Projekt sich sehr negativ auf Termine und Budget auswirkt. Der Erfolg der Entwicklung einer BI­Anwendung hängt sehr viel stärker von der Wahl des richtigen Werkzeugs ab als z.B. in einem Java­Projekt. Fehlende Funktionalitäten lassen sich nur sehr schwer und mit großem Aufwand nachträglich einbauen. Für diese Entscheidung sind drei Anforderungsarten zu berücksichtigen: die in der Studie identifizierten Anforderungen, die für die Spezifikationsphase erwarteten Anforderungen und die innerhalb der Lebensdauer der BI­Anwendung absehbaren, aber aktuell noch nicht gestellten Anforderungen. Neben den Erfahrungen aus ähnlichen Systemen sind für diese Abschätzung auch Fachkenntnisse über die unterstützten Geschäftsprozesse (auch aus anderen Unternehmen) hilfreich. Weiterhin sind tiefe Kenntnisse über die Werkzeuge notwendig, um deren Möglichkeiten mit den Anforderungen zu vergleichen und daraus eine Entscheidung abzuleiten. Bei BI­Projekten mit mittleren/längeren Laufzeiten lohnt es sich oft, mit dem Werkzeughersteller über die Funktionserweiterung anstehender neuer Versionen zu sprechen. Auch wenn das Werkzeug heute den Anforderungen noch genügt, kann das morgen schon ganz anders aussehen. Zur Absicherung der Entscheidung lohnt sich die Erstellung eines Prototyps mit den ausgewählten Werkzeugen, was dem Projektteam mehr Sicherheit gibt. Im Kern geht es bei dem Vorhaben um die Konsolidierung von Stammdaten. Eine wesentliche Abwägung, die zu Beginn des Vorhabens erfolgen muss, ist daher: Soll eine Master-Data-Management-Lösung aufgebaut werden oder werden die Stammdaten mittels DQ-Werkzeugen während der Datenintegration zum Data Warehouse konsolidiert? Das Projektteam hat sich aus folgenden Gründen gegen den Einsatz einer MDM-Lösung entschieden: ■ Mittelfristig, d.h. nach Konsolidierung der operativen IT-Anwendungen der Motorsport Engines AG und der Bike GmbH, wird es einen einzigen Master für die Stammdaten geben. Damit würde eine MDM-Lösung obsolet. ■ Das Unternehmen verfolgt keine explizite Strategie des anorganischen Wachstums. Es ist nicht geplant, fortlaufend weitere Unternehmen zu übernehmen, deren Stammdaten dann jedes Mal zu integrieren wären. ■ Das Unternehmen möchte keine von Herstellern angebotenen umfassenden Stammdatenmodelle einsetzen, sondern ein eigenes Modell erstellen, das lediglich die überschaubar wenigen eigenen Anforderungen abdeckt. ■ Es wird keinerlei Bedarf gesehen, das Resultat der Stammdatenkonsolidierung für weitere Anwendungen zur Verfügung zu stellen bzw. an die Quellsysteme zurückzuspielen. Die multidirektionale Integration der Stammdaten mehrerer ITAnwendungen ist nicht von Bedeutung. Stattdessen liegt der Fokus ganz darauf, die Dateninhalte zu bereinigen, vor allem die der Datendomänen Material und Lieferant.

➝

316

17 Datenqualitätsmanagement in einer Studie

Folgende wesentliche DQ-Funktionalitäten stehen im Vordergrund: ■ Bereinigung von Adressdaten (für Lieferant) ■ Ermittlung und Auflösung von Dubletten (jeweils für Material und Lieferant) ■ Datenanreicherung, um eine Klassifizierung (von Materialdaten) sowie eine Hierarchienbildung (von Lieferantenorganisationen) durchführen zu können Daraus resultieren Bedarfe nach den entsprechenden Kategorien von DQ-Werkzeugen und externen Referenzdaten bzw. Kategorisierungsstandards (eClass, Dun & Bradstreet).

Kosten-Nutzen-Betrachtung

Um eine endgültige Empfehlung abgeben zu können, muss man Kosten und Nutzen für die jeweiligen Datenqualitätsmaßnahmen abschätzen (siehe Kap. 3). Zudem sind anhand der priorisierten Benutzeranforderungen verschiedene Lösungsmöglichkeiten zu erstellen. Beispiel: Alternative 1 enthält alle Maßnahmen aus hoch priorisierten Benutzeranforderungen, Alternative 2 umfasst zusätzlich die aus mittel priorisierten Anforderungen mit gutem Kosten­Nutzen­Verhältnis und Alternative 3 zusätzlich die aus den restlichen Anforderungen. Je nach den vorliegenden Randbedingungen sind aber auch andere Gruppierungen möglich und sinnvoll.

17.3 Bewertung Nun ist das Sollkonzept (einschließlich der ggf. vorhandenen Alternativen) zu bewerten. Dabei sind die Vor­ und Nachteile der einzelnen Ziele gegeneinander abzuwägen. Anschließend wird eine Empfehlung gegeben; diese enthält auch eine Option hinsichtlich der in den nachfolgenden Projektphasen einzusetzenden Werkzeuge. Die Erfahrung lehrt, dass die Empfehlung des Werkzeugs besonders schwierig ist: Schließlich kennt das Projektteam nicht alle Anforderungen. Es ist davon abzuraten, diese Entscheidung erst nach der Spezifikationsphase zu treffen. Schließlich soll nur das spezifiziert werden, was mit dem jeweiligen Werkzeug auch umgesetzt werden kann. Beispiel: Best­of­Breed­Lösungen bieten zwar grundsätzlich die mächtigsten Funktionalitäten, haben aber in der Regel Schwächen bei der Integration (siehe Kap. 16).

17.4 Umsetzungsplanung

317

17.4 Umsetzungsplanung Die geplanten Datenqualitätsmaßnahmen in der BI­Anwendung beeinflussen die Umsetzungsplanung für das nachfolgende Projekt, da der entsprechende Aufwand berücksichtigt werden muss. Sind in den nachfolgenden Phasen weitere Analysen notwendig (z.B. Data Profiling der Quellsysteme), sind diese ebenfalls in der entsprechenden Phase einzuplanen.

17.5 Empfehlungen Die größte Schwierigkeit in dieser Phase ist die Balance. Sie gilt es zu wahren und Extreme zu vermeiden: Keine Aktivitäten und kein Aufwand sind genauso wenig gangbar wie zu viele Aktivitäten und hoher Aufwand. Letztlich sollte das Projektteam einige Randbedingungen (z.B. Qualitätsziele, Datenqualität in den Quellsystemen) ermitteln und sich auf das eigene Bauchgefühl und die eigenen Erfahrungen verlassen. Am Ende sollte es sicher sein, dass die in der Studie durchgeführten Aktivitäten zum Datenqualitätsmanagement die Projektplanung auf feste Füße gestellt haben und diese nach derzeitigem Stand mit angemessener Wahrscheinlichkeit einhaltbar ist. Wer zudem jede Projektphase Revue passieren lässt, kann zukünftige Projekte besser einschätzen.

318

17 Datenqualitätsmanagement in einer Studie

319

18 Datenqualitätsmanagement in der Spezifikation

Die Spezifikation beschreibt, was eine Anwendung leistet. Fachliche Abläufe und Funktionen werden genauso veranschaulicht wie nicht funktionale Anforderungen (z.B. Performance). Das Wie der technischen Umsetzung ist nicht Bestandteil der Spezifikation. Pragmatisches Vorgehen führt allerdings dazu, dass vorhersehbare technische Restriktionen bereits in die Spezifikation einfließen und die Gestaltung der fachlichen Lösung beeinflussen. Die Grenze zwischen Studie und Spezifikation wird wie folgt gezogen: ■ Die Studie definiert die fachlichen Probleme vollständig und skizziert die fachliche Lösungsidee. ■ Die Spezifikation verfeinert und vervollständigt die fachliche Lösungsidee und enthält weiter die vollständige Ausarbeitung der fachlichen Gestaltung. In der Praxis werden in der Spezifikationsphase die fachlichen Anforderungen hinsichtlich der Datenqualität nur selten beschrieben. Auch die Beschreibungen der fachlichen Objekte, Abläufe etc. genügen häufig nicht den Anforderungen der Datenqualität. Welche Datenqualitätsmaßnahmen Unternehmen bereits in der Spezifikationsphase ergreifen sollten, ist in den folgenden Abschnitten beschrieben. Im Folgenden sind ausschließlich jene Aspekte beschrieben, die die Datenqualität betreffen.

18.1 Spezifikation der Schnittstellen In der Spezifikationsphase werden die Ergebnisse aus der Analyse der Quellsysteme (siehe Abschnitt 17.1) vervollständigt. Die Schnittstellenspezifikation wird um Aspekte zur Datenqualität ergänzt. Hierzu zählen erstens die Anforderungen an die Qualität der Daten, z.B. an die Eindeutigkeit von Werten, und zweitens die Anforderungen hinsichtlich der Aktualität der Daten und des Zeitpunkts ihrer Verfügbarkeit. In der Praxis hat es sich bewährt, eine Schnittstellenvereinbarung abzuschließen: Mit den Vertretern der Quellsysteme wird ein Service Level Agreement (SLA) getroffen, das die Qualität der Leistung genau bestimmt. Um zu verhin-

320

18 Datenqualitätsmanagement in der Spezifikation

dern, dass die Vertreter der Quellsysteme die Schnittstellen unbemerkt ändern, ist in der Vereinbarung zudem zu regeln, wer wann unter welchen Bedingungen Änderungen an der Schnittstelle vornehmen darf und wer darüber zu informieren ist. In der Praxis vergessen die Quellsystem­Verantwortlichen jedoch oft, den BI­Anwendungsbetreuern Änderungen mitzuteilen. Sicherer ist es deshalb, im Rahmen einer Workflow­Steuerung die BI­Anwendung als zustimmungspflichtige Stelle für Änderungen im Quellsystem zu definieren. Alternativ oder zusätzlich wird automatisiert bei der Extraktion überprüft (z.B. durch Abzug der Metadaten aus einem Source­Versionierungssystem), welche Version das operative Programm hat, das die Schnittstellendatei schreibt, oder die Extraktionsprozesse überprüfen die Versionsangabe im Header­Satz bei einer sequenziellen Datei.

18.2 Definition der Rollen in der Datenorganisation In der Studie wurden bereits die Datenverantwortlichen für die Quellsysteme festgelegt. In der Spezifikation kommen die Datenverantwortlichen für die BI­Anwendung (siehe Kap. 4) hinzu. Wieder sind sowohl fachliche als auch technische Ansprechpartner zu bestimmen. Ihre Verantwortung für die Daten beginnt mit der Spezifikationsphase und nicht erst mit dem Betrieb des Systems. Sie sind für das Projektteam die ersten Ansprechpartner, um Fragen und Unklarheiten zu klären. Je früher sie in das Projekt einbezogen werden, desto höher ist in der Regel auch die Akzeptanz des späteren Systems. Diese Benutzer übernehmen früh die Verantwortung für die Qualität ihrer Daten. Mit ihrem Fachwissen können sie außerdem weiteren Benutzern besser erklären, warum die Qualität der Daten wie festgelegt wurde. Ein Beispiel: Als bei der Einführung eines neuen zentralen Systems die Fachbereiche mit Kritik nicht sparten, konnten die fachlichen Datenverantwortlichen die Daten mit unwiderlegbaren fachlichen Argumenten gegenüber den eigenen Kollegen verteidigen. Da sie früh in das Projekt mit einbezogen wurden, stimmten Bedarf und Daten überein. Die Kritik legte sich sofort, die Benutzer akzeptierten das neue System, die späteren Nutzungsstatistiken untermauerten den Erfolg dieser Maßnahme ebenfalls. Sollte es in dem Unternehmen noch keine Data­Governance­Organisation geben, so sind in dieser Phase zusätzlich die Rollen mit ihren Aufgaben zu definieren.

18.2 Definition der Rollen in der Datenorganisation

321

Da die Bike GmbH bereits erste Ansätze einer Data-Governance-Organisation in Betrieb hat, wurde entschieden, die Data Governance für das gemeinsame Unternehmen darauf aufbauend zu definieren. Dazu wurden im Wesentlichen fünf Schritte identifiziert und implementiert: 1. Installation des Data Quality Managers der Bike GmbH als Data Quality Manager des gemeinsamen Gesamtunternehmens. 2. Bestimmung von fachlichen Data Stewards mit der Verantwortung zur Datenqualitätssicherung der konsolidierten Material- und Lieferantenstammdaten in den DWH-/Berichtssystemen. Da die Bike GmbH standardisierte Materialschemata verwendet, wurde ein Mitarbeiter der Einkaufsabteilung der Bike GmbH als zuständiger Data Steward für die Materialstammdaten bestimmt. Für die Lieferantenstammdaten wurde als Data Steward hingegen ein Mitarbeiter der Einkaufsabteilung der Motorsport Engines AG nominiert. 3. Bestimmung von Datenverantwortlichen für die Material- und Lieferantenstammdaten aus dem Quellsystem A der Motorsport Engines AG analog der Bike GmbH. Diese Datenverantwortlichen (Mitarbeiter der Einkaufsabteilung) sind die ersten Ansprechpartner der Data Stewards bei Datenqualitätsthemen. 4. Adaption der Datenqualitätsprozesse (laufende Qualitätssicherung, Anforderungsmanagement und Problembehandlung) der Bike GmbH auf das Gesamtunternehmen. 5. Bestimmung eines technischen Data Steward für die künftige DWH-Landschaft des gemeinsamen Unternehmens mit Fokus auf das Spend Management Reporting. Aus politischen Gründen wurde hier ein Mitarbeiter der IT-Abteilung der Motorsport Engines AG (akquirierendes Unternehmen) ausgewählt. Als Sponsor für das Projekt (und ebenso für den anschließenden Betrieb) wurde schon während der Studie der für die Einkaufsabteilung zuständige Vorstand der Motorsport Engines AG gewonnen. Zudem wurde der DQ-Lenkungsausschuss der Bike GmbH um die Abteilungsleiter der Motorsport Engines AG erweitert. Den Vorsitz übernimmt dabei der zuvor erwähnte Sponsor. Die Data Governance erfordert nun die Erfüllung einer Reihe von Aufgaben durch die zuvor identifizierten Rollen. Die fachlichen Data Stewards haben die Verantwortung zur initialen und laufenden Qualitätssicherung der konsolidierten Daten beider Unternehmen im DWH. Sie haben dabei die Material- und Lieferantenstammdaten zu analysieren und diese zu Master-Datensätzen im DWH zusammenzuführen. Dazu müssen sie in enger Abstimmung mit den fachlichen Datenverantwortlichen der Quellsysteme beider Unternehmen zusammenarbeiten. Dies ist einerseits initial im Zuge des Projekts aufzusetzen und andererseits später im Betrieb laufend durchzuführen. Des Weiteren sind die fachlichen Data Stewards für die Definition von DQKennzahlen und die Erstellung von Datenqualitätsberichten verantwortlich. Der technische Data Steward ist für die technischen Aspekte (technische Methoden und Werkzeuge, Definition von technischen Kennzahlen, Implementierung der Kennzahlen innerhalb der BI-Architektur) der Qualitätssicherung innerhalb der BI-Systemlandschaft zuständig. Zudem sind die fachlichen Data Stewards bei auftretenden Fragen die ersten Ansprechpartner für die Benutzer der Lieferanten- und Materialstammdaten.

➝

322

18 Datenqualitätsmanagement in der Spezifikation

Der Data Quality Manager konsolidiert die Berichte der einzelnen fachlichen und technischen Data Stewards und berichtet die Datenqualität gesamthaft an den DQLenkungsausschuss. Im Falle von Dissens vermittelt der Data Quality Manager zwischen den Parteien und bindet im Bedarfsfall den DQ-Lenkungsausschuss zur Entscheidungsfindung mit ein. Zudem nimmt der Data Quality Manager die Anforderung der verschiedenen Data Stewards auf, analysiert und bewertet sie und legt sie dem DQ-Lenkungsausschuss zur Entscheidung vor. Neben den Rollen wurden zudem die DQ-Prozesse der Bike GmbH erweitert, um das Zusammenspiel dieser Rollen im Gesamtunternehmen zu ermöglichen. Die wichtigsten Prozesse sind wie erwähnt die Abläufe der regulären monatlichen Qualitätssicherung, das Anforderungsmanagement und die Problembehandlung. Die Prozessverantwortung liegt dabei beim Data Quality Manager. Die Abnahme der Prozesse erfolgt im DQ-Lenkungsausschuss.

18.3 Festlegung der Datenqualitätsziele Aus den Ergebnissen der Studie legt das Projektteam Qualitätsziele für die Daten und Prozesse fest; detaillierte Informationen zu diesem Thema enthält Kapitel 6. Außerdem spezifiziert das Projektteam zu den Zielen die passenden Kennzahlen. Am einfachsten lassen sich die Qualitätsziele in Umfragen ermitteln. Für jedes Datenobjekt wird den zugehörigen Mitarbeitern ein Fragebogen vorgelegt und die Ergebnisse werden ausgewertet. Erfolgreich ist, wer alle relevanten, repräsentativen Gruppen einbezieht: Lieferanten, Benutzer und Interessenten für das jeweilige Objekt – sowohl aus der Fach- als auch aus der IT-Abteilung. Zu jeder Datenqualitätskennzahl werden die Ziel und Grenzwerte definiert, mit denen im späteren Betrieb der aktuelle Stand der Datenqualität und der Erfolg der Maßnahmen bewertet werden. Deshalb müssen die in der nachfolgenden Konzeptionsphase entworfenen Datenqualitätsmaßnahmen diese Zielwerte einhalten. Den Objekten und Attributen im fachlichen Datenmodell werden als Metadaten jeweils die zugehörigen Datenqualitätsmerkmale mit ihren Zielwerten zugeordnet. In dem Beispiel in Abbildung 18–1 wird dem Objekt KUNDE das Datenqualitätskriterium »Eindeutigkeit« zugeordnet; der Zielwert ist auf 100 Prozent festgelegt, d.h., es dürfen keine Duplikate vorhanden sein. Dem Attribut ZUSTELLADRESSE werden die Kriterien »Vollständigkeit« und »Aktualität« zugeordnet; der Zielwert für »Vollständigkeit« liegt bei 100 Prozent und für »Aktualität« bei 95 Prozent: Für alle Kunden muss deshalb die Zustelladresse mit einem Wert gefüllt sein; maximal fünf Prozent der Zustelladressen dürfen veraltet sein.

18.3 Festlegung der Datenqualitätsziele

323

Eindeutigkeit1: 100 %

Kunde

… Vollständigkeit2: 100 %

Zustelladresse

Aktualität3: 95 %

… Kriterien: 1. Es existiert maximal ein Kunde mit identischen Attributwerten. 2. Zustelladresse mit einem Wert ungleich NULL gefüllt 3. Zustelladresse gleich der aktuellen Zustelladresse

Abb. 18–1

Datenqualitätsanforderungen zu fachlichen Objekten

Auch den Beziehungen zwischen den fachlichen Objekten im Datenmodell werden entsprechende Metadaten zugeordnet (siehe Abb. 18–2). In den meisten Fällen werden die Anforderungen an die Beziehung durch Kardinalitäten spezifiziert. Kunde Widerspruchsfreiheit1: 100 %

Widerspruchsfreiheit2,3: 100 %

Bestellung Kriterien: 1. Jede Bestellung muss zu genau einem Kunden gehören. 2. Ein Kunde kann mehrere Bestellungen tätigen. 3. Es darf maximal 70 Prozent der Kunden ohne Bestellung geben.

Abb. 18–2

Datenqualitätsanforderungen zu Beziehungen zwischen fachlichen Objekten

Um später regelmäßig überprüfen zu können, ob diese Zielwerte auch eingehalten werden, sind in dieser Phase neben den Fach- auch die Qualitätsberichte (siehe Abb. 18–3) zu spezifizieren. Diese Berichte sollten Benutzern aus dem Management regelmäßig vorgelegt werden, da nur dann genug Aufmerksamkeit erzeugt und regulierende Maßnahmen (z.B. durch Aktualisierung der Geschäftsregeln) durchgeführt werden können. Die zugehörige Prozessbeschreibung ist ebenfalls Teil der Spezifikation.

324

18 Datenqualitätsmanagement in der Spezifikation

Datenqualitätskennzahlen 2008 100 % 90 % Soll

80 % 70 %

Vollständigkeit Verfügbarkeit Aktualität

60 % 50 % 40 % 30 % 20 % 10 % 0%

Abb. 18–3

Januar

Februar

März

April

Bericht mit Datenqualitätskennzahlen

Ausgehend von den in der Studie erhobenen Erwartungen an die Datenqualität müssen nun die Ziele detailliert und auf Datenqualitätskennzahlen heruntergebrochen werden. Diese Datenqualitätskennzahlen sind die Basis für Datenqualitätsberichte und das spätere laufende Monitoring der Datenqualität im Betrieb. Für die Erwartungen an die Vollständigkeit der Materialstammdaten müssen fünf Einzelkennzahlen definiert werden. Diese fünf Einzelkennzahlen sind danach analog zu Abschnitt 6.5 zu einem Kennzahlenbaum zusammenzuführen. Zielsetzung ist es, dass diese aggregierten Kennzahlen eine Vollständigkeit von 99,5% erreichen. Die Priorisierung dieser Einzelkennzahlen ist dabei gleich verteilt und beträgt jeweils 20%. Die Anforderungen an diese fünf Einzelkennzahlen sind: 1. MatID: Die Material-ID muss  0 sein. 2. Mat_Lief: Jedem Artikel muss ein Lieferant zugeordnet sein (Sicherstellung der referenziellen Integrität zwischen Artikel und Lieferant). 3. Maße_Gewicht: Maße und Gewicht müssen  0 sein (kann auch auf zwei Kennzahlen aufgeteilt werden). 4. Materialgruppe: Jedes Material muss einer Materialgruppe zugeordnet sein (Sicherstellung der referenziellen Integrität zwischen Material und Materialgruppe). 5. Mat_Stammdaten: Materialien müssen in Materialstammdaten vorhanden sein (Prüfung der referenziellen Integrität zwischen Materialstammdaten und Bewegungsdaten (z.B. Rechnungs- oder Produktionsdaten).

➝

18.4 Bezeichnung und Definition der Objekte

325

Verantwortlich für die Definition der Kennzahlen sind die fachlichen Data Stewards in Abstimmung mit dem Data Quality Manager und den fachlichen Datenverantwortlichen der Quellsysteme. Die Definition der Datenqualitätsziele muss natürlich unter Berücksichtigung von Kosten-Nutzen-Überlegungen stattfinden. Die Beschreibung der Einzelkennzahlen erfolgt analog dem Kennzahlenformular aus Abschnitt 7.6. Die Formulare werden anschließend in den Metadaten abgelegt und allgemein zugänglich gemacht. Der technische Data Steward ist verantwortlich für die architektonische Entscheidung innerhalb der technischen Umsetzung. Da es hier um Datenqualitätskennzahlen geht, die das gemeinsame Unternehmen abbilden sollen, werden die Kennzahlen im DWH auf den konsolidierten Datenbeständen für Lieferanten- und Materialstammdaten aufgesetzt. Weiterhin wird eine DQ-Kennzahl für das Datenqualitätskriterium Zeitnähe dazu verwendet, um ausgehend von der gegenwärtigen Situation jene Ziele zu definieren, die innerhalb des nächsten Jahres zu erreichen sind. Derzeit gibt es aufgrund manueller Eingriffe erst zum 10. Arbeitstag jedes Monats einen qualitätsgesicherten konsolidierten Lieferantenbestand. Zielsetzung ist es daher, diese Frist für die Datenbereitstellung innerhalb der nächsten 12 Monate auf den 3. Arbeitstag zu reduzieren. Die Kennzahl misst dann jenen Zeitpunkt, zu dem die Freigabe der Daten monatlich erfolgt, und vergleicht das Ist mit dem Soll. Zugleich definiert der verantwortliche Data Steward jene Maßnahmen, die zu ergreifen sind, um diese Zielsetzung auch erreichen zu können. Analog werden Kennzahlen für Korrektheit (z.B. Befüllung der Lieferantenadressen) und Konsistenz (z.B. Inkonsistenzen zwischen den Quellsystemen A und B) definiert (siehe auch Kap. 6).

18.4 Bezeichnung und Definition der Objekte Die Daten der BI-Anwendung werden von unterschiedlichen Benutzern aus unterschiedlichen Organisationseinheiten oder Unternehmen verwendet. Um Missverständnisse und Fehlinterpretationen zu vermeiden, muss das Team mit dem Fachbereich diese Objekte klar, einheitlich, korrekt, vollständig und verständlich bezeichnen und definieren (Geschäftsbegriffe, Entitäten, Attribute und Domänen). Meist existieren in einem Unternehmen zahlreiche Synonyme und Homonyme. Die Bezeichnung eines Objekts muss für den fachlichen Benutzer intuitiv verständlich sein: Er muss sofort wissen, was sich hinter dieser Bezeichnung verbirgt. Die Bezeichnung enthält deshalb nur fachliche, keine technischen Begriffe. Am einfachsten ist das bei weitgehend standardisierten Objekten wie UMSATZ oder ABSATZMENGE. Weitaus schwieriger sind Bezeichnungen für unternehmensoder abteilungsspezifische Objekte zu finden. In der Abteilung für das Kundenmanagement kann beispielsweise die Bezeichnung KUNDE sowohl für Kunde, Interessent, Partner und Lieferant stehen, in der Finanzabteilung hingegen nur für Kunde. In einer BI-Anwendung müssen diese Bezeichnungen zwingend standardisiert und zentral festgelegt werden. Eine Lösung für dieses Beispiel ist, die

326

18 Datenqualitätsmanagement in der Spezifikation

Bezeichnungen Kunde, Interessent, Partner und Lieferant einzeln festzulegen und eine neue Oberklasse GESCHÄFTS PARTNER für diese Gruppe zu definieren. Auch die Bezeichnungen für Attribute müssen eindeutig sein und eine Beziehung zur zugehörigen Entität enthalten. Wird z.B. das gleichnamige Attribut ADRESSE in der Entität Kunde (im CRM-System) und in der Entität Rechnungsempfänger (Rechnungswesensystem) verwendet, muss das Team diese Bezeichnung eindeutig und verständlich machen. Eine Möglichkeit ist, zwischen Kundenadresse und Rechnungsadresse zu unterscheiden. Die Bezeichnungen sollten in allen Schichten des Systems konsistent sein. Oft existieren aber Formatbeschränkungen. Beispielsweise darf der Name eines Attributs in einer Datenbank eine festgelegte Länge nicht überschreiten und keine Leerzeichen enthalten. Oder der zur Verfügung stehende Platz in einem Bericht reicht für die vollständige Bezeichnung eines Geschäftsbegriffs nicht aus, z.B. für Ertrag vor Zinsen, Steuern, Abschreibungen auf Sachanlagen und Abschreibungen auf immaterielle Vermögensgegenstände. Hier empfiehlt es sich, für jede Verwendung (Geschäftsbegriff, in der Datenbank, im Bericht etc.) die Bezeichnung getrennt festzulegen. Wichtig ist, dass sich die Bezeichnungen entweder ähneln oder der Benutzer die Verbindung sofort erkennen kann. Bestehen die Bezeichnungen aus mehr als sechs Buchstaben, sind Kurzbezeichnungen oder Abkürzungen einzusetzen. Die Kurzbezeichnungen sollten so kurz wie möglich sein, ohne dass der Sinn für den Benutzer verloren geht. Die Verständlichkeit wird erhöht, wenn die Kurzbezeichnung mit dem ersten Buchstaben der Bezeichnung beginnt und die Bildung der Kurzbezeichnung konsistent über alle Bezeichnungen ist (z.B. aus den Konsonanten: Knd für Kunde). Wer standardisierte Abkürzungen benutzt, muss darauf achten, dass diese allen Benutzern bekannt sind. Die Definition eines Objekts muss folgende Anforderungen erfüllen: ■ Sie muss das Objekt korrekt beschreiben, ■ es präzise gegenüber anderen Objekten abgrenzen und ■ dem fachlichen Benutzer verständlich sein. In der Praxis hat sich hierfür das von English [English 1999] vorgeschlagene formale Format bewährt: Begriff = Generelle Klasse + Differenzierung Das Template für die Definition lautet: »_____ [Begriff, Entität, Attribut, Domäne] ist ein(e) _____ [zugehörige, generelle Klasse], der/die/das_____ [Differenzierung gegenüber anderen Begriffen, Entitäten, Attributen, Domänen].« Beispiel: »Erlös ist eine betriebswirtschaftliche Kennzahl, die zeigt, wie viel Geld und Forderungen ein Unternehmen durch den Verkauf von Waren (Erzeugnissen) oder Dienstleistungen sowie aus Vermietung oder Verpachtung erhalten hat.«

18.5 Festlegung der Geschäftsregeln

327

Um sicherzustellen, dass alle Benutzer ein gleiches Verständnis der Begriffe haben, definieren Fachbereich und Projektteam die Objekte in einem projektweiten Glossar (siehe Kap. 14), sofern kein unternehmensweites Glossar vorhanden ist. Jedem Objekt wird ein Verantwortlicher aus dem Fachbereich als Steward (siehe Kap. 4) zugeordnet, der für die Aktualität, Korrektheit und Verständlichkeit des Eintrags verantwortlich ist und Änderungsanforderungen entgegennimmt. Domänen legen u.a. die zulässigen Werte (siehe S. 144, Domänenanalyse) der Attribute fest und werden ebenfalls zentral definiert. In einer Domäne darf jeweils nur eine Eigenschaft beschrieben sein, in Spezifikationen findet man aber häufig Domänen mit Werten unter schiedlicher Bedeutung. Ein Beispiel aus der Praxis ist folgende diskrete Werteliste für das Attribut KUNDENSTATUS: P für Privatkunde, F für Firmenkunde, GK für guter Kunde und SK für schlechter Kunde. Hier enthält die Domäne Werte zur Unterscheidung der Art des Kunden (Privat oder Firmenkunde) und Werte zum Auftragsvolumen dieses Kunden. Wer korrekt spezifiziert, vermeidet Mehrfachnutzungen: In dem Beispiel sind deshalb zwei getrennte Domänen zu definieren. Die integrierten Stammdaten sollen im Data Warehouse von unterschiedlichen Benutzern aus unterschiedlichen Organisationseinheiten der beiden Unternehmen verwendet werden. Um Missverständnisse und Fehlinterpretationen zu vermeiden, hat das Team mit den Fachbereichen diese Objekte klar, einheitlich, korrekt, vollständig und für jeden verständlich bezeichnet und definiert (Geschäftsbegriffe, Entitäten, Attribute und Domänen). Das Attribut Mindestbestellmenge der Entität Material wurde zum Beispiel folgendermaßen definiert: »Die Mindestbestellmenge ist eine Maßzahl, die die unterste Grenze derjenigen Menge angibt, die bei einer Bestellung abzunehmen ist.« Für das Attribut »Breite_Masseinheit« wurde eine Domäne definiert mit den zulässigen Werten Millimeter, Zentimeter und Meter. Während der Migration werden später andere vorhandene Maßeinheiten durch Umrechnung in einen der drei zulässigen Werte konvertiert.

18.5 Festlegung der Geschäftsregeln Geschäftsregeln beschreiben fachlich die geltenden und in der Zukunft absehbaren Regeln für die Geschäftsprozesse. Sie werden innerhalb der Spezifikation definiert. Sie leiten sich ab aus regulatorischen, externen oder unternehmensinternen Anforderungen und ändern sich typischerweise im Laufe der Zeit. Die Art der technischen Umsetzung ist nicht Teil der Definition, da für jede Regel mehrere Umsetzungen (je nach Kontext) möglich sind. Oft besitzen die Regeln einen Zeitbezug. Somit ist festgelegt, wann die Regel gilt. In einer Regel dürfen immer nur die Objekte benutzt werden, die gemäß Abschnitt 18.4 definiert wurden. Alle möglichen Ausnahmen zu einer Regel sind ebenfalls Bestandteil der Definition.

328

18 Datenqualitätsmanagement in der Spezifikation

Verwendet werden diese Regeln z.B. zum Data Profiling (siehe Kap. 9) und zur Validierung (siehe Kap. 10) der Daten. Ein Beispiel für eine solche Regel ist: »Der Lagerbestand eines Produkts muss immer über dessen Mindestbestand liegen. Ausnahme: Bei Neuaufnahme eines Produkts in den Lagerbestand kann der Lagerbestand niedriger oder gleich dem Mindestbestand sein.« Neben der Regel »Der Lagerstand muss […] über dem Mindestbestand liegen« enthält sie zusätzlich den Zeitbezug »immer« und die Ausnahme »Bei Neuaufnahme eines Produkts in den Lagerbestand kann der Lagerbestand niedriger oder gleich dem Mindestbestand sein«. Ohne diese Ausnahme dürfte der Mindestbestand erst bei der Aufnahme des neuen Produkts in den Lagerbestand gesetzt werden, da ansonsten z.B. die Validierung der Werte (z.B. Lagerbestand = 0, Mindestbestand = 100) zu einem falschen Ergebnis führen würde. Die Geschäftsregeln werden wie die Bezeichnungen und Definitionen in einem projektinternen oder noch besser in einem zentralen Repository abgelegt. Ein für die Geschäftsregel verantwortlicher Steward kümmert sich um deren Aktualität. Geschäftsregeln eignen sich nun auch besonders für die Definition von DQ-Kennzahlen. Die Verantwortung für die Definition von Geschäftsregeln liegt bei den fachlichen Data Stewards, wobei sich diese eng mit den fachlichen Datenverantwortlichen aus der Einkaufsabteilung abzustimmen haben (falls es nicht ohnehin dieselbe Person ist). Geschäftsregeln zeichnen sich durch komplexere Zusammenhänge zwischen verschiedenen Dateninhalten aus. Im hier betrachteten Fall müssen für bestimmte Lieferanten die Materialien in andere Materialgruppen konsolidiert werden, als es die Standardzuordnung verlangen würde. Entsprechend definierte Kennzahlen geben dann die Anzahl der Materialien je Materialgruppe dieses Lieferanten an und setzen diese zudem in Relation zu der erwarteten Anzahl je Materialgruppe. Für die Materialstammdaten werden zusätzlich folgende Geschäftsregeln implementiert: ■ Das Nettovolumen ist gleich dem Produkt der Maßzahlen (unter Berücksichtigung der Einheiten). ■ Die Länge ist immer größer als die Höhe und die Breite. Des Weiteren werden qualitative Kennzahlen definiert, die die Beurteilung nach eben qualitativen Kriterien durch die fachlichen Datenverantwortlichen erfordern. Dies ist etwa eine Plausibilisierung der Kosten und Umsätze je Lieferant und Materialgruppe, die saisonalen Schwankungen unterliegen können.

18.6 Messung der Qualität von Definitionen und Geschäftsregeln

329

18.6 Messung der Qualität von Definitionen und Geschäftsregeln Die Qualität der Definitionen kann man messen, indem man eine repräsentative Gruppe von Benutzern befragt, für die die ausgewählten Entitäten von Interesse sind. Aus der Menge der Entitäten wird eine überschaubare Anzahl ausgewählt, einschließlich der zugehörigen Geschäftsbegriffe, Attribute, Kurzbezeichnungen, Abkürzungen, Domänen und Geschäftsregeln. Daraus wird ein Fragebogen erstellt, der die Zufriedenheit der Benutzer zu den einzelnen Objektarten abfragt. Die Kriterien sind die Korrektheit, die Verständlichkeit, die Vollständigkeit und der Wert für den jeweiligen Benutzer und das Unternehmen. Der Wertebereich für die Antwort liegt zwischen 1 (= Unzufrieden) und 5 (= Sehr zufrieden). Die Auswertung der Bögen zeigt dem Team das aktuelle Qualitätsniveau dieser Definitionen und liefert Anhaltspunkte für notwendige Verbesserungen.

18.7 Data Profiling in der Spezifikation Um die Data­Profiling­Analyse (siehe Kap. 9) der Studie zu verfeinern, überprüft das Team in der Spezifikation, ob und inwieweit die Geschäftsregeln und Definitionen aus den Abschnitten 18.4 und 18.5 eingehalten wurden. Dazu werden Daten aus dem Produktivsystem der Quellen verwendet. Samples1 sind nicht empfehlenswert, da erfahrungsgemäß das Data Profiling nur mit dem Gesamtbestand die gewünschten Ergebnisse erzielt. Entsprechen die Definitionen und Geschäftsregeln nicht den Ergebnissen des Data Profiling, so sind diese entweder anzupassen oder es sind Regeln zur Bereinigung zu spezifizieren. Im anderen Fall werden die Definitionen und Geschäftsregeln unverändert als Basis für die weitere Spezifikation und die nachfolgende Realisierung verwendet. Das Team überprüft die vorhandenen Geschäftsregeln und Definitionen anhand der zu integrierenden Stammdaten. Für die Domäne des Attributs »Breite_Masseinheit« wird geprüft, ob alle vorhandenen Werte zur Domäne mm, cm oder m gehören. Ergebnis der Data-Profiling-Analyse: 99,5 Prozent der Datensätze entsprechen dieser Domäne, 0,5 Prozent enthalten den Wert dm (Dezimeter) und müssen auf den zulässigen Wert cm umgerechnet werden.

➝

1.

Sample: zufällige Teilmenge der Daten

330

18 Datenqualitätsmanagement in der Spezifikation

Anschließend werden die beiden Geschäftsregeln überprüft. Erste Regel: Das Nettovolumen ist gleich dem Produkt der Maßzahlen (unter Berücksichtigung der Einheiten). Die Data-Profiling-Analyse ergibt, dass alle Datensätze mit vorhandenen Werten diese Regel einhalten. Dadurch ergibt sich im Umkehrschluss die Möglichkeit, z.B. eine fehlende Längenangabe mithilfe der Höhe, der Breite und des Volumens nachzuberechnen. Zweite Regel: Die Länge ist immer größer als die Höhe und die Breite. Durch das Data Profiling erkennt das Team, dass nur 75,4 Prozent der Datensätze diese Geschäftsregel einhalten. In einer weiteren Analyse stellt sich heraus, dass diese Regel nicht für alle Materialien gilt: Bei allen Artikeln der Artikelklasse »Aufstellartikel« gilt die Regel nicht. Aus diesem Grund wird die Geschäftsregel präzisiert: »Bei allen Materialien, die nicht zur Artikelklasse ›Aufstellartikel‹ gehören, ist die Länge immer größer als die Höhe und die Breite.«

18.8 Entwurf des Systems Im Entwurf der BI­Anwendung werden neben den fachlichen Prozessen auch die Prozesse zum Datenqualitätsmanagement spezifiziert. Dazu zählen die Prozesse zur Validierung, Bereinigung und Anreicherung der Daten in den ETL­Prozessen, die Prozesse zur Bereitstellung der Daten und die Prozesse zur Überwachung (Auditing) der Daten im laufenden Betrieb. Für die Validierung verwendet man die Definitionen und Geschäftsregeln aus den Abschnitten 18.4 und 18.5. Für die Bereinigung der Daten muss das Team ein eigenes Konzept erstellen, das die gestellten Anforderungen erfüllt. Weitere Informationen und Tipps zur Validierung und Bereinigung enthalten die Kapitel 10 und 11. Gelten für die BI­Anwendung Auflagen zur Revisionssicherheit oder Compliance, so müssen diese im Konzept berücksichtigt werden. Diesen Auflagen gemäß dürfen Daten meist nicht einfach korrigiert werden: Die Änderungen müssen nachvollziehbar sein, die ursprünglichen Daten müssen erhalten bleiben und Metadateninformationen (z.B. Datum der Änderung, Name des Ändernden) sind zusätzlich abzuspeichern. Die bestehenden operativen Einkaufssysteme stellen ihre Stammdaten zu Material bzw. Teilen, Lieferant und Kunde bereit. Im Prozess der Konsolidierung dieser Stammdaten sind aus fachlicher Sicht folgende Datenqualitätsfunktionen erforderlich: (1) Material- bzw. Teilestammdaten ■ Unter den angelieferten Teilestammdaten sind die Gleichteile zu ermitteln. ■ Die Materialstammdaten sind zu kategorisieren in Materialgruppen. (2) Lieferantenstammdaten ■ Die Namen und Adressen der Lieferantenstammdaten sind zu bereinigen. ■ Lieferantendubletten müssen gefunden und aufgelöst werden. ■ Die Lieferanten sind jeweils in eine Lieferantenorganisation bzw. -hierarchie einzuordnen.

18.8 Entwurf des Systems

331

Das fachliche Datenmodell wird mit den Definitionen (siehe Abschnitt 18.6) geprüft, es dürfen z.B. nur die dort definierten Objekte verwendet werden, Synonyme und Homonyme werden aufgelöst. Die Prozesse zur Bereitstellung der Daten werden gemäß Kapitel 13 spezifiziert (z.B. Freigabeprozesse), ebenso die notwendigen Rollen. In dieser Phase legt das Team auch eine einheitliche Notation (siehe Kap. 13) für alle Darstellungsformen (Berichte, Dashboards, Scorecards) fest. Diese Notation ist Teil eines Designkonzepts für das Projekt. In dem Konzept wird auch bestimmt, welche Diagramme, Farben etc. zu verwenden sind. Außerdem definiert das Team darin die zugehörige Rolle eines Informations­(Chef­)Designers und bestimmt diesen auch in Absprache mit dem Fachbereich. Deshalb kann die Festlegung nicht in die Konstruktionsphase verlagert werden. Die Qualität des Konzepts wird besser, wenn das Team zur Absicherung des Designkonzepts Designprototypen erstellt. Die Prototypen sollen dem Benutzer das Designkonzept vor Augen führen, damit er besser und sicherer auswählen kann. Diese Prototypen stellen ausschließlich das Design vor; sie enthalten keine Funktionalitäten des zukünftigen Systems. In der Regel werden die Prototypen mithilfe von Grafikprogrammen oder BI­Werkzeugen erzeugt. Im produktiven Betrieb müssen die Datenqualitätskennzahlen für die Prozesse und Daten innerhalb der BI­Anwendung laufend gemessen werden (siehe Kap. 15), einerseits für die Datenqualitätsberichte und andererseits für die Steuerung der Prozesse. Beispiel: Stammdaten zu Kunden dürfen nicht in das DWH geladen werden, wenn die Adressdaten nicht vollständig sind. Der Umfang, die Form und das Ziel der Auditierung sind innerhalb der Spezifikation festzulegen. Das Teilprojektteam legt vor dem Entwurf der Migrationsprozesse die Struktur fest, in die sich die Stammdaten danach einpassen sollen. Zusätzlich dokumentiert es die zugehörigen Attribute aus den Quellsystemen. In dem Beispiel aus Tabelle 17–1 ist zu erkennen, dass nicht alle Attribute der Zielstruktur in den Quellsystemen vorhanden sind. Für diese Fälle werden anschließend Funktionen spezifiziert, die die notwendigen Werte automatisiert oder manuell ermitteln. Ein Beispiel: Die Breite, Höhe und Länge der Materialien aus dem Stammdatensystem Bravo ist immer in Zentimeter angegeben, es existiert kein eigenes Attribut für die Maßeinheit. Deshalb ist der Wert bei dem neuen Attribut für die Maßeinheit bei der Migration auf den Wert cm zu setzen. Neben den eigentlichen Integrationsprozessen, die die Daten in dem einheitlichen Zielsystem zusammenführen, konzipiert das Projektteam auch Prozesse für die Verbesserung der Datenqualität. Das Hauptaugenmerk liegt hier auf der Identifikation und Bereinigung von Gleichteilen (Duplikaten), denn das ist in jeder Integration ein kritischer Faktor. Ebenso wichtig ist die Einführung einer unternehmensweiten Klassifikationsmethode für Artikel und Lieferanten, um diese eindeutig identifizierbar und duplikatsfrei zu machen.

➝

332

18 Datenqualitätsmanagement in der Spezifikation

Vor der Integration sind in einem ersten Schritt die Duplikate in den jeweiligen Quellsystemen zu identifizieren. Dabei ist zunächst jedes Quellsystem getrennt zu analysieren, da Duplikate so einfacher zu erkennen sind. Erst im zweiten Schritt werden Duplikate in beiden Systemen identifiziert und bereinigt. Dafür sind die Daten zuerst zu strukturieren und anschließend zu normieren. Bei der Strukturierung werden die Daten in ein einheitliches Format gebracht. So wird beispielsweise das Gewicht aus dem Quellsystem B aufgetrennt in den Wert für das Gewicht (Nettogewicht) und die Maßeinheit (Gewicht: 25 kg wird zu Nettogewicht: 25, Maßeinheit: Kilogramm). Die Normierung bildet die vorhandenen Attribute auf eine vorgegebene normierte Werteliste ab. In unserem Beispiel soll die Maßeinheit nur die drei zulässigen Werte Gramm, Kilogramm und Tonne annehmen können. Attribut

Entsprechendes Attribut aus System Alpha

Entsprechendes Attribut aus System Bravo

Artikel_ID

Artikel_ID

Artikelnummer

Artikel_Kurztext

Artikel_Kurztext

Erster Teil aus dem Artikeltext, muss manuell überarbeitet werden

Artikel_Langtext

Artikel_Langtext

Artikeltext

Nettogewicht

Nettogewicht

Gewicht, ohne Maßeinheit

Nettogewicht_Masseinheit

Nettogewicht_Masseinheit

Aus Gewicht extrahieren

Artikelgruppen_ID

Artikelgruppen_ID

Über Artikelgruppe bestimmen

Artikelklassen_ID

Artikelklassen_ID

Über Artikelgruppe die Artikelklasse bestimmen

Lieferanten_ID

Lieferanten_ID

Lieferantennummer

Lieferanten_Bestellnummer Lieferanten_Bestellnummer Bestellnummer Beschreibung

Beschreibung

Muss festgelegt werden

Breite

Breite

Breite_in_cm

Breite_Masseinheit

Breite_Masseinheit

Breite immer in cm

Hoehe

Hoehe

Tiefe_in_cm

Hoehe_Masseinheit

Hoehe_Masseinheit

Tiefe immer in cm

Laenge

Laenge

Laenge_in_cm

Laenge_Masseinheit

Laenge_Masseinheit

Länge immer in cm

Mindestbestellmenge

Mindestbestellmenge

Mindestmenge

eClass_Nummer

eClass_Nr

Muss bestimmt werden

Tab. 18–1

Zielstruktur und Abbildungsverzeichnis für die Materialstammdaten

➝

18.9 Empfehlungen

333

Während der Integration der Lieferantenstammdaten wird zu jedem Lieferanten seine zugehörige DUNS-Nummer bestimmt und gespeichert. Dadurch erhält man zusätzlich eine weitere Möglichkeit, Dubletten zu finden. Datensätze von Lieferanten, die dieselbe DUNS-Nummer bekommen, sind mit hoher Wahrscheinlichkeit Duplikate. Um Güter und Dienstleistungen unternehmensübergreifend zu standardisieren, sind entsprechende Codes nötig, anhand derer sich die Daten Klassen zuordnen lassen. Die Bike GmbH hat dazu das standardisierte Klassifikationssystem eClass benutzt. Die Motorsport Engines AG hat hingegen eine eigene Klassifikationsmethode für das Material verwendet, die nicht kompatibel mit der eClass-Methode ist. Der Standard eClass empfiehlt sich allerdings für das Zielsystem, weil er zunehmend in global agierenden Firmen zum Einsatz kommt. Da eine automatische Konvertierung unmöglich ist, legen Experten einmalig eine Brückentabelle an. Mit ihrer Hilfe wird für jeden Artikel der Motorsport Engines AG die interne Klassifikationsnummer durch die eClass-Nummer ersetzt.

18.9 Empfehlungen Auch wenn es schwierig und aufwendig ist, Datenqualitätsanforderungen in eine Spezifikation aufzunehmen, ist dieser Schritt unbedingt notwendig, wird doch damit der Grundstein für den Erfolg der nachfolgenden Konstruktions­ und Realisierungsphase gelegt. Datenqualität ist ein fachliches Thema, das der Fachbereich mit Unterstützung des Projektteams und im Rahmen der Leitlinien der DQ-Organisation innerhalb der Spezifikation explizit definieren muss. Versuche, diese Anforderungen später implizit durch das Entwicklerteam festzulegen, erzeugen ähnlichen Aufwand, bringen aber erheblich weniger Nutzen oder verschlechtern sogar die Qualität der Daten.

334

18 Datenqualitätsmanagement in der Spezifikation

335

19 Datenqualitätsmaßnahmen in der Konstruktionsphase

Beschreibt die Spezifikation das Was, nämlich die fachliche Funktionalität, so legt die Konstruktion das Wie fest, die softwaretechnische Konzeption der BI­Anwendung. Oft wird die Gesamtheit aller Konstruktionsergebnisse auch DV­Konzept genannt. Viele Projektteams beschreiben in der Konzeptionsphase nicht die Prozesse zum Datenqualitätsmanagement. Unberücksichtigt bleibt auch, welche Anforderungen das Datenqualitätsmanagement an die Architektur und das physikalische Modell etc. stellt. Das Team fokussiert allein auf die fachlichen Abläufe und Funktionen, schon in der Spezifikationsphase war die Datenqualität kein Thema. Probleme mit der Datenqualität werden deshalb erst in der nachfolgenden Realisierungsphase bemerkt. Meist versucht man dann, diese ohne vorherige Konzeption ad hoc zu lösen: Die Ergebnisse sind dementsprechend schlecht und der Aufwand hoch.

19.1 Übertragung der Datenqualitätsziele In der Spezifikation wurden den Objekten und Attributen des fachlichen Datenmodells die zugehörigen Datenqualitätsmerkmale mit ihren Zielwerten zugeordnet. Das Projektteam überträgt diese Merkmale und Zielwerte des fachlichen Modells auf das in dieser Phase daraus abgeleitete physikalische Modell. Dabei ist darauf zu achten, dass alle Metadaten zusammengefasst werden. Beispiel: Im fachlichen Modell existieren die Objekte KUNDE und INTERESSENT. Diese beiden Objekte werden im physikalischen Modell zu einem neuen Objekt GESCHÄFTSPARTNER zusammengefasst, weshalb das neue Objekt die Merkmale und Zielwerte aus den beiden fachlichen Geschäftsobjekten erfüllen muss. Die technische Umsetzung der Anforderungen zu den Beziehungen zwischen fachlichen Geschäftsobjekten muss ebenso konzipiert werden. In der Regel geschieht das über Kardinalitäten im physikalischen Modell; in diesem Fall sind die Datenqualitätsmerkmale und zugehörigen Zielwerte auf diese Kardinalitäten zu übertragen.

336

19 Datenqualitätsmaßnahmen in der Konstruktionsphase

19.2 Konventionen und Richtlinien Die Prinzipien und Konventionen zur Bezeichnung der Objekte aus Abschnitt 18.4 gelten auch für die Vergabe von Bezeichnungen für technische Objekte (z.B. Packages, Klassen, Datenbanktabellen, Dateinamen). Hat man in der Spezifikation die Bezeichnungen noch nicht für alle Schichten (z.B. für das physikalische Modell in der Datenbank) festgelegt, so ist dies in der Konstruktionsphase zu tun. Schließlich dienen die Bezeichnungen als Vorgabe für die nachfolgende Entwicklung. Kryptische Objekt­ und Attributbezeichnungen erschweren die Verständlichkeit. Ein Projektteam hat beispielsweise die Bezeichnungen der Tabellenattribute zu dem Stammdatenobjekt ARTIKEL fortlaufend nummeriert: ATTR_1, ATTR_2 … ATTR_n. Gleichzeitig war es zulässig, dass die Benutzer dieses Stammdatenobjekt für eigene Abfragen und Berichte verwenden. Die kryptische Bezeichnung verführte die Benutzer: Sie leiteten aus den Werten der Attribute eigene Bedeutungen ab, die nicht immer mit der tatsächlichen Bedeutung übereinstimmten. Letztlich führte die kryptische Bezeichnung zu fehlerhaften Berichten und Abfragen. Die Programmierrichtlinien enthalten nicht nur Regeln für die Codeform, sondern auch Vorgaben für die Lösung wiederkehrender Aufgaben. Aus Sicht des Datenqualitätsmanagements gehören hierzu z.B. einheitliche Vorgaben für die Fehlerbehandlung und die Abspeicherung fehlerhafter Daten oder die Auflage, dass die Programmierer beim Verbinden von Datensätzen aus unterschiedlichen Tabellen auf innere Joins verzichten, damit keine Datensätze unbeabsichtigt und unbemerkt verloren gehen. Zur Einhaltung dieser Vorgaben können später z.B. Standardklassen entworfen werden. Die Programmierrichtlinien geben auch vor, wie Metadaten zu erstellen sind und welche Metadaten für welche Objekte wo abzulegen sind. Wer zudem Anforderungen an Inhalt, Struktur und Qualität der Metadaten stellt, erhöht den Projekterfolg. In der Praxis finden sich allerdings viele Beispiele, in denen die Metadaten zwar gefüllt wurden, aber keine verwendbaren Informationen enthielten. So bringt der Text »Füllt die Tabelle Geschäftspartner« zu einem ETL­Prozess nur wenig Mehrwert. Besser schreibt man: »Aus den Tabellen T_Kunde und T_Interessent werden die Datensätze zusammengefasst und in die Tabelle DIM_ Geschäftspartner geschrieben. Doppelte Datensätze werden dabei entfernt, unkorrekte Daten in der Fehlertabelle T_Fehler mit einem Fehlercode abgelegt. Der Prozess wird über den Workflow WF_Laden aufgerufen. Er kann beliebig wiederholt werden, auch nach einem Abbruch im Prozess.«

19.3 Entwurf des Systems

337

19.3 Entwurf des Systems Steht der fachliche Entwurf der BI­Anwendung, kann das Projektteam in der Konstruktionsphase das technische System entwerfen: Zentrales Thema ist die Architektur der BI­Anwendung. Die Gesamtarchitektur ist das zentrale Dokument der Konstruktionsphase. Es enthält die Architektur der technischen Infrastruktur und einen Überblick über die technische und fachliche Architektur des Systems. Es dokumentiert die zentralen Randbedingungen und Entwurfsentscheidungen und gibt den Rahmen für Design und Entwicklung vor. Die Gesamtarchitektur stellt den Einstiegspunkt in die technische System­ und Projektdokumentation dar und bildet die Grundlage für die Detaillierung. Da auch die Anforderungen des Datenqualitätsmanagements Auswirkungen auf die Gesamtarchitektur haben, müssen sie beim Entwurf berücksichtigt werden. Die Gesamtarchitektur des Vorhabens zum Spend Management Reporting beschreibt alle wesentlichen Schichten, Komponenten und Prozesse (siehe Abb. 19–1): Als Datenquellen werden die bestehenden Systeme für Stammdaten zu Material, Lieferant und Kunde der beiden Unternehmen Motorsport Engines AG und Bike GmbH verwendet. Zur späteren Anreicherung werden externe Referenzdaten von Dun & Bradstreet (Lieferantenorganisationen) sowie eClass (Klassifizierung von Teilen) herangezogen. In einem regelmäßig ausgeführten Datenintegrationsprozess (ETL-Technologie im Batch-Mode) werden die Daten der Quellsysteme zusammengeführt, transformiert, bezüglich der Datenqualität behandelt und in das neue Einkaufs-Data-Warehouse geladen. Der Data Steward greift über DQ-Werkzeuge auf das Data Warehouse zu, um die Qualität der Daten zu bewerten und ggf. manuell zu bereinigen. Über Reports, Dashboards etc. ist das Spend Management Reporting umgesetzt. Lediglich der Fachbereich Einkauf tritt als Endanwender auf. In einem zentralen Repository sind die Metadaten der drei Quellsysteme beschrieben sowie die des Data Warehouse (inkl. Synonymen etc.). Hier sind ebenfalls die DQ-Ziele der einzelnen Datenobjekte und -attribute festgelegt. Die Regeln für die Qualität der Daten sind im Repository zentral abgelegt. Sie werden sowohl aus dem Data Profiling in den frühen Phasen gewonnen als auch vom Data Steward erfasst. Alle Regeln werden von verschiedenen Datenintegrationsprogrammen bei der Datenvalidierung verwendet.

➝

338

19 Datenqualitätsmaßnahmen in der Konstruktionsphase

Fachbereich Einkauf

Anwender und Rollen Datenzugriff

Spend Management Reporting

Datenziele

Data Warehouse

Data Steward

Administrator

DQ-FrontendWerkzeuge

Einkauf DQRepository

Transformation Extraktion

Datenquellen

Abb. 19–1

Operative Systeme

MSE AG Einkauf A

Bike GmbH Einkauf B

Bike GmbH Einkauf C

Externe Daten

eClass

D&B

Systemmanagement

Datenqualität

Prozessmanagement

Laden Staging Area

Metadatenmanagement

Data Profiling

Datenintegration

MetadatenRepository

Gesamtarchitektur für Spend Management Reporting

Die Erfahrung lehrt, dass die Prozesse und Objekte zur fachlichen Verarbeitung möglichst getrennt von den Prozessen zur Steuerung der Datenqualität konzipiert und realisiert werden sollten. Eine zu starke Kopplung erschwert die Wartbarkeit und Verständlichkeit der fachlichen und der qualitätssteuernden Logik. Umfangreiche Prozesse zur Validierung, Filterung und Bereinigung der Daten erhöhen beispielsweise oft die Komplexität des ETL­Prozesses zum Laden der Daten. In dem Beispiel aus Abbildung 19–2 werden die Daten von Kunden und Interessenten mit ihrer Rolle (Kunde, Interessent) in eine gemeinsame Stammdatentabelle geladen. Die fachliche Logik ist einfach, doch die integrierte Logik für die länderspezifische Standardisierung und Bereinigung von Duplikaten macht den ETL­Prozess sehr komplex. Wer die Logik für die Datenqualitätsverbesserung getrennt vom reinen Ladeprozess modelliert, reduziert diese Komplexität.

19.3 Entwurf des Systems

339

MATCHMERGE_KD_US NAME_ADRESS_ BEREINIGUNG_KD_US

SPLITT_ COUNTRIES_KD

T_KUNDEN

T_INTERESSENTEN

MATCHMERGE_ KD_GE NAME_ADRESS_ BEREINIGUNG_KD_GE

NAME_ADRESS_ BEREINIGUNG_KD_OTH

NAME_ADRESS_ BEREINIGUNG_INT_US

SPLIT_ COUNTRIES_INT

NAME_ADRESS_ BEREINIGUNG_INT_GE

NAME_ADRESS_ BEREINIGUNG_INT_OTH

Abb. 19–2

JOINER_KD SET_UNION_KD

CONSTANT MATCHMERGE_KD_OTH

MATCHMERGE_INT_US

MATCHMERGE_ INT_GE

SET_UNION

MATCHMERGE_ALL T_STAMM_GP

JOINER_INT

SET_UNION_INT

MATCHMERGE_INT_OTH

Fehlende Trennung zwischen fachlicher und qualitätssteuernder Logik im ETL-Prozess

In der Architektur der technischen Infrastruktur müssen die Hardware, die beteiligten Datenbanken und die Systeme für das Datenqualitätsmanagement beschrieben werden. Dazu zählen z.B. die internen Systeme für das zentrale Metadaten­Repository, das Data Profiling und die externen Systeme mit Referenzdaten für die Validierung oder Anreicherung der Daten. Insbesondere beim Metadaten­Repository ist darauf zu achten, dass alle Benutzer des Repositorys aus allen Systemen in allen Phasen der Entwicklung und im Betrieb darauf zugreifen können, z.B. die Entwickler während der Realisierung und der Berichtserstellung, die Benutzer bei der Analyse der Berichte, Scorecards und Dashboards. Die technische Architektur des Systems beschreibt auch, welche Technologien für das Datenqualitätsmanagement verwendet werden sollen und wie diese einzusetzen sind. Ein Beispiel sind die Technologien für die technische Fehlerbehandlung. Dazu gehört auch ein technisches Berechtigungskonzept, das die fachlichen Qualitätsanforderungen hinsichtlich des Datenqualitätsmerkmals »Zugänglichkeit« umsetzt. So muss das Team darin festlegen, welche Anwenderrollen welchen Zugriff auf die einzelnen Schichten der späteren BI­Anwendung (Staging Area, Core Data Warehouse, Data Marts, Berichte, …) haben werden. Auch ist für die Realisierungsphase einheitlich zu regeln, wie Fehler zu behandeln sind. Das physikalische Datenmodell wird dementsprechend um die Tabellen zur Validierung und Fehlerbehandlung erweitert. Die zugehörigen Prinzipien und die Vorgehensweise enthalten die Kapitel 11 und 12.

340

19 Datenqualitätsmaßnahmen in der Konstruktionsphase

Weiter ist technisch vorzugeben, wie die in der Spezifikation definierten Domänen umzusetzen sind. In Abbildung 19–3 wurde beispielsweise die Domäne GESCHLECHT als Dimension modelliert. Die Dimensionsausprägungen enthalten die fachlich zulässigen Werte MANN, FRAU, KEIN und UNBEKANNT. Geschlecht

MANN FRAU KEIN UNBEKANNT

Abb. 19–3

Umsetzung von Domänen als Dimension (ADAPT ™-Notation1)

Anhand des Designkonzepts aus der Spezifikation (siehe Abschnitt 18.8) legt man in der technischen Architektur auch das Design der Benutzeroberfläche (Berichte, Dashboards, Scorecards) fest. Hinzu kommt der Entwurf der Funktionen zur Überprüfung der Geschäftsregeln (siehe Abschnitt 18.5). Es ist z.B. möglich, diesen als Datenbank­Constraint umzusetzen. Daneben konzipiert das Team die zugehörigen Prozesse, den Zeitpunkt und den Ort der Überprüfung sowie den nachfolgenden Prozess für die Fehlerfälle. Sofern möglich, sind die Geschäftsregeln von der restlichen Logik zu entkoppeln. Die Erfahrung lehrt, dass sich diese Regeln stark ändern: Immer wieder werden sie aktualisiert, neue Regeln kommen hinzu, alte werden ungültig. Je enger sie an Prozesse und Objekte gekoppelt sind, desto aufwendiger ist das Ändern. Wer die Regeln zentral und redundanzfrei definiert und nur lose koppelt, senkt den Aufwand, sind doch die Änderungen an den Regeln nur noch an einer Stelle durchzuführen. Trotzdem sind die Änderungen sofort in den Prozessen und Objekten wirksam. Noch mehr Aufwand lässt sich sparen, wenn die Regeln mehrfach in verschiedenen Prozessen und Objekten verwendet werden. Bei einer engen Kopplung wären auch diese mehrfach zu aktualisieren, bei loser Kopplung hingegen nur einmal. Oft klagen Projektteams, dass sie wegen der hohen Anforderungen an die Performance oder nach einer Real­Time­Verarbeitung auf Maßnahmen zur Verbesserung der Datenqualität verzichten müssen. Vergessen wird, dass Datenqualitätsmaßnahmen kein Selbstzweck sind, sondern die negativen Auswirkungen schlechter Datenqualität vermeiden (siehe Kap. 3). Zwei Ansätze bieten sich an,

1.

ADAPT = Application Design for Analytical Processing Technologies (vgl. [Bulos/Forsman 2006])

19.3 Entwurf des Systems

341

um dieses Problem zu lösen: Im ersten wird die BI­Anwendung in zwei Bereiche aufgeteilt, einen für die Real­Time­Verarbeitung und einen für die »normale« Verarbeitung (z.B. im Batch­Betrieb). Für beide Bereiche werden angepasste, auf die jeweiligen Performance­Anforderungen abgestimmte Datenqualitätsmaßnahmen konzipiert. Im zweiten Ansatz werden die Daten nur mit den nötigsten Datenqualitätsmaßnahmen geladen, komplexere Maßnahmen erfolgen im Nachgang mit nachträglicher Korrektur der vorab geladenen Daten. Die Praxis zeigt, dass der erste Ansatz zielführender ist. Notfalls lässt sich in diesen sogar der zweite Ansatz integrieren. In einer Vollständigkeitsanalyse vergleicht man das Objektmodell mit den vorhandenen Daten aus den Quellsystem­Schnittstellen. Die Frage lautet: Können alle Daten aus dem Objektmodell aus den vorhandenen Daten in der geforderten Granularität erstellt werden? Bei auftretenden Diskrepanzen ist entweder das Objektmodell zu ändern oder es müssen zusätzliche Daten aus den alten oder neuen Quellsystemen extrahiert werden. Die fachliche Architektur beschreibt, wie die fachlichen Komponenten die Fachlichkeit des Systems umsetzen. Aus Sicht der Datenqualität gehören dazu z.B. die Komponenten, mit denen die Datenqualitäts­Stewards fehlerhafte Daten manuell korrigieren. Der Data Steward spielt im Vorhaben zum Spend Management Reporting eine wichtige Rolle. Er braucht DQ-Frontends, die seine spezifische Sichtweise und seine fachliche Perspektive darstellen. Dazu zählen die Exploration von Daten sowie das Data Profiling, die Erstellung und Anpassung von Datenregeln, die Definition von DQKriterien und schließlich auch die manuelle Datenbereinigung (z.B. Auflösung von Dubletten) im Anschluss an erfolgte Datenintegrationsprozesse. Anwender und Rollen Datenzugriff

Datenziele

Fachbereich Einkauf

Spend Management Reporting

Data Steward

DQ-FrontendWerkzeuge Exploration

Profiling

DQ Measures Definition

Manual Cleansing

Rule Definition Repository Metadaten, Datenqualität

Data Warehouse Einkauf

Abb. 19–4

DQ-Frontends für den Data Steward

➝

342

19 Datenqualitätsmaßnahmen in der Konstruktionsphase

Ein Schritt des Datenintegrationsprozesses ist das Management der Datenqualität. Wesentliche Teilschritte sind dabei die Validierung der Stammdaten entsprechend der vom Data Steward aufgestellten Regeln, die standardisierte Darstellung der Stammdaten, der sich die Bereinigung des Lieferantenstamms bezüglich Name und Adresse anschließt, gefolgt von der Dublettenbehandlung von Teile- und Lieferantenstamm und letztlich die Kategorisierung der Stammdaten. Datenintegration

Laden

Staging Area

Datenqualität

Anreicherung und Clustering: Teile nach eClass, Lieferanten nach D & B Duplikate: Gleichteile, Lieferantendubletten Bereinigung: Name und Adresse von Lieferant Standardisierung Validierung

Transformation Extraktion

Abb. 19–5

DQ-Management innerhalb der Datenintegration

Weiterhin werden das fachliche Fehlerbehandlungsverfahren und das fachliche Berechtigungskonzept festgelegt. In diesem wird beispielsweise die Rolle beschrieben, mit der Änderungen in der Zugriffsschicht auf die Data Marts für die Berichtserstellung möglich sind (siehe Kap. 13). Hinzu kommt eine konkrete Anleitung. Sie zeigt, wie sich die in der Spezifikation festgelegten Berichte in der technischen Architektur umsetzen lassen. Hier wird auf das während der Spezifikation erstellte Designkonzept verwiesen. Sollte dies noch nicht fertig sein, ist es spätestens jetzt zu vervollständigen. In der Konstruktionsphase wird nun definiert, wo die Datenqualitätskennzahlen und die Datenqualitätsberichte innerhalb der BI-Architektur umgesetzt werden (siehe auch Abschnitt 6.2). Die Verantwortung dafür liegt in erster Linie bei den technischen Data Stewards. Grundsätzlich gilt, je früher Datenqualitätsprobleme in der Kette der Datenverarbeitung erkannt und adressiert werden, desto besser. Es besteht auch die Möglichkeit, die Datenqualitätskennzahlen direkt in den Quellsystemen zu implementieren. Dies hätte den Vorteil, dass die Datenqualität unmittelbar in den Quellen geprüft wird. Allerdings werden die Material- und Lieferantenstammdaten der verschiedenen Quellsysteme der beiden Unternehmen erst im DWH zusammengeführt. Somit kann auch erst dort eine übergreifende Validierung der Datenqualität mittels Kennzahlen erfolgen.

➝

19.4 Erstellung eines Prototypen

343

Des Weiteren sind Datenqualitätsberichte zu definieren, bzw. es ist festzulegen, wo diese Berichte implementiert werden sollen. Um das gemeinsame Unternehmen darstellen zu können, werden die Datenqualitätsberichte in den BI-Frontends umgesetzt, die auf den konsolidierten Daten des DWH aufsetzen. Die Datenqualitätskennzahlen und die Datenqualitätsberichte, die auf den Kennzahlen aufbauen, sind aus fachlicher Sicht ein wesentlicher Teil der Überwachung der Datenqualität im laufenden Betrieb. Zusätzlich ist im Rahmen dieser Phase zu entscheiden, ob sogenannte Workflow-Systeme eingesetzt werden, um die fachlichen Datenqualitätsprozesse abzubilden und zu unterstützen. Die Entscheidungsvorbereitung obliegt dabei dem technischen Data Steward. Die Entscheidung selbst trifft der DQ-Lenkungsausschuss.

19.4 Erstellung eines Prototypen Haben die Datenqualitätsanforderungen zu einer komplexen Architektur und komplexen Prozessen geführt? Dann sollte man einen Prototyp erstellen, um die Designentscheidungen abzusichern. Ein Prototyp empfiehlt sich auch bei hohen Performance­Anforderungen, da die Prozesse zum Datenqualitätsmanagement die Verarbeitung der Daten in der BI­Anwendung verlangsamen können. Somit lassen sich Designentscheidungen rechtzeitig vor der endgültigen Realisierung verändern und Datenqualitätsmaßnahmen anpassen. Eine nachträgliche Änderung während der Realisierung führt hingegen zu einem (vermeidbaren) hohen Aufwand. Wer Werkzeuge verwendet, um BI­Anwendungen zu realisieren, senkt in der Regel den Aufwand für die Erstellung eines Prototyps. Erfahrungsgemäß rechtfertigt der entstandene Mehrwert den Aufwand. Die Motorsport Engines AG hat in ihrem Data Warehouse seit vielen Jahren ein funktional mächtiges und ansonsten ausgereiftes ETL-Tool des Herstellers XYZ eingesetzt. Auf den guten Erfahrungen und dem angesammelten Know-how will man im Vorhaben »Spend Management Reporting« aufsetzen. Daher wurde nach einer Prüfung der Funktionalität der DQ-Tools desselben Herstellers XYZ sowie der Integration mit dem ETL-Tool entschieden, sowohl ETL- als auch DQ-Tools des Herstellers einzusetzen. Um diese Idee zu validieren, wird ein Proof of Concept initiiert.

19.5 Empfehlungen In der Konstruktionsphase werden die Weichen für die erfolgreiche Realisierung gelegt – auch in Bezug auf ein erfolgreiches Datenqualitätsmanagement. Jede Minute, die man sinnvoll in das Design steckt, erhöht den Mehrwert der Datenqualitätsmaßnahmen und reduziert den dadurch verursachten Aufwand um ein Vielfaches. Datenqualität kann in der nachfolgenden Umsetzungsphase weder

344

19 Datenqualitätsmaßnahmen in der Konstruktionsphase

»hineinrealisiert« noch später »hineingetestet« werden. Deshalb müssen im Datenqualitätsmanagement erfahrene Mitarbeiter mit besonderer Sorgfalt die Konzeption erstellen und unterstützen. Für die Datenqualität gelten dabei die gleichen Designrichtlinien wie für den Rest der BI­Anwendung, wie z.B. nach einer Entkopplung oder einer Schichtentrennung.

345

20 Steuerung der Datenqualität in der Realisierung

In der Realisierungsphase wird die BI­Anwendung programmiert und getestet – Basis sind die Vorgaben aus der Konstruktion (siehe Kap. 19).

20.1 Einhaltung der Konventionen, Richtlinien und Konzepte Egal ob Konvention, Programmierrichtlinie oder Konzept: Das Projektteam hat sich in der Realisierungsphase an die Vorgaben zu halten. So hat es die Konventionen (siehe Abschnitt 19.2) zur Bezeichnung der technischen Objekte (z.B. Packages, Klassen) einzuhalten. Geeignete Qualitätssicherungsmaßnahmen wie eine Code­Inspektion1 zeigen, ob alle Konventionen auch umgesetzt worden sind. Die Programmierrichtlinien werden bei Bedarf um fehlende Teile ergänzt. Nicht benötigte Teile sind zu entfernen. Wieder prüft das Qualitätsmanagementteam mittels Qualitätssicherungsmaßnahmen, ob die Richtlinien eingehalten werden. Die Erfahrung zeigt, dass es Realisierern besonders schwerfällt, die gewünschte Qualität der Metadaten zu liefern. Deshalb ist schwerpunktmäßig zu prüfen, ob die Anweisungen zur Erstellung, Struktur und Qualität der Metadaten erfüllt sind. Wird die Erstellung von Metadaten in der geforderten Struktur technisch erzwungen, z.B. durch das ETL­ und Modellierungswerkzeug, ist in der Regel lediglich die Qualität zu überprüfen. Wer die Metadaten nachträglich erstellt, hat einen höheren Aufwand, der sich zudem leicht hätte vermeiden lassen. Deshalb sollte man die Metadaten so früh wie möglich innerhalb dieser Phase prüfen. Das Designkonzept gibt vor, wie Berichte, Scorecards und Dashboards auszusehen haben. Die Programmierer realisieren diese dementsprechend. Ob sie alle Vorgaben eingehalten haben, ist mit Qualitätssicherungsmaßnahmen wie dem Vier­Augen­Prinzip zu prüfen.

1.

Eine Inspektion ist eine Form der Qualitätssicherung durch (intensive) Begutachtung.

346

20 Steuerung der Datenqualität in der Realisierung

20.2 Data Profiling in der Realisierung In Data­Profiling­Analysen (siehe Kap. 9) werden die Daten aus den Quellsystemen und das Datenbankmodell überprüft. Profiling der Daten aus den Quellsystemen

Das Data Profiling der Quellsystemdaten aus der Spezifikationsphase (siehe Abschnitt 18.7) wird mit aktuellen Daten aus den Produktivsystemen wiederholt. So überprüft man einerseits, ob die Schnittstellenspezifikation eingehalten ist, andererseits erkennt man frühzeitig, ob die Struktur und Qualität zwischenzeitlich geändert wurde, und kann rechtzeitig gegensteuern. Wer bereits den DataProfiling­Prozess in der Spezifikation automatisiert hat, spart in dieser Phase beim Wiederholungslauf nennenswerten Aufwand. Weiterer Aufwand wird vermieden, wenn das Data Profiling erst nach Fertigstellung der Extraktionsprozesse aus den Quellsystemen erfolgt. Das Data Profiling kann dann direkt auf den Tabellen der Staging Area oder – falls nicht vorhanden – des Data Warehouse erfolgen. Das Projektteam wiederholt die Data-Profiling-Analyse aus der Spezifikationsphase mit den Geschäftsregeln und Definitionen zu den Stammdaten. 99,1 Prozent der Materialien enthalten im Attribut »Breite_Masseinheit« die zulässigen Werte dieser Domäne (mm, cm oder m), 0,6 Prozent enthalten den Wert dm (Dezimeter) und 0,3 Prozent haben angloamerikanische Maßeinheiten. Diese angloamerikanischen Maßeinheiten sind in das Stammdatensystem aufgenommen worden, als ein neuer Lieferant aus England ausgewählt wurde. Das Team entschließt sich deshalb, die bisherige Konvertierung (dm in cm) um die Umrechnung der angloamerikanischen in die metrischen Maßeinheiten zu ergänzen. Anschließend werden die beiden Geschäftsregeln überprüft. Erste Regel: Das Nettovolumen ist gleich dem Produkt der Maßzahlen (unter Berücksichtigung der Einheiten). Die Data-Profiling-Analyse ergibt, dass alle Datensätze mit vorhandenen Werten diese Regel einhalten und keine weiteren Maßnahmen notwendig sind. Zweite Regel: Bei allen Materialien, die nicht zur Artikelklasse »Aufstellartikel« gehören, ist die Länge immer größer als die Höhe und die Breite. Auch hier entsprechen 100 Prozent der Datensätze dieser Geschäftsregel, es sind keine weiteren Maßnahmen durchzuführen.

Profiling des Datenbankmodells

Sobald die Prozesse zum Laden der Daten in die Ziele der BI­Anwendung fertiggestellt sind und die Daten geladen wurden, sollte das Team ein Data Profiling des physikalischen Datenbankmodells durchführen. Beispielsweise können damit Beziehungen zwischen Attributen oder Tabellen aufgedeckt werden, die nicht explizit modelliert wurden und auf einen Fehler in der Modellierung hindeuten, oder es wird geprüft, ob die festgelegten Domänen für die einzelnen Attribute

20.3 Einbindung der Datenverantwortlichen und Benutzer

347

und die festgelegten Geschäftsregeln eingehalten wurden. Um realistische Ergebnisse zu erhalten, sind Daten aus dem Produktivbestand der Quellsysteme zu verwenden. Die Ergebnisse der Data­Profiling­Analyse liefern einen Eindruck der Qualität des Modells, der Daten und der zugehörigen Prozesse. Erkannte Auffälligkeiten werden anschließend tiefer analysiert, und im Fehlerfall werden die Prozesse und das Datenbankmodell entsprechend geändert. Zuerst überprüft das Projektteam die korrekte Einhaltung der Domäne »Breite_ Masseinheit« für die Materialstammdaten, nachdem diese in das Data Warehouse integriert wurden. Es dürfen nur noch die Einheiten mm, cm und m darin enthalten sein, die Werte dm und die angloamerikanischen Werte sollten bei der Integration umgerechnet worden sein. Die Data-Profiling-Analyse ergibt folgendes Ergebnis: 100 Prozent der Datensätze entsprechen der Domäne – die Umrechnung war damit erfolgreich. Auch die Musteranalyse des Attributs »Nettogewicht« ergibt das erwünschte Ergebnis: Die Datensätze haben alle rein numerische Werte – die vorher enthaltenen Maßeinheiten aus dem Stammdatensystem Bravo (z.B. kg) wurden erfolgreich abgetrennt, es gibt auch keine übrig gebliebenen Leerzeichen.

20.3 Einbindung der Datenverantwortlichen und Benutzer Auch in der Realisierungsphase hält das Projektteam den Kontakt zu den Datenverantwortlichen und ausgewählten Benutzern. Offene Fragen lassen sich so schnell klären und Anforderungen sind leichter zu präzisieren. Außerdem stärkt der Kontakt das »Wir­Gefühl«, die Mitarbeiter identifizieren sich stärker mit der BI­Anwendung, die Akzeptanz des Systems ist höher. Auch hat es sich bewährt, den jeweiligen Datenverantwortlichen und ausgewählten Benutzern einen fachlichen Teil der BI­Anwendung (z.B. eines Data Mart einschließlich der zugehörigen Ladeprozesse und Darstellungsformen) vorzuführen, sobald dieser fertiggestellt ist. Für die Validierung der Darstellungsformen hat sich ein zweistufiges Verfahren bewährt: 1. Validierung von Design, Struktur etc. ohne Darstellung realer Kennzahlwerte 2. Validierung der Kennzahlwerte anhand realer, für die Empfänger bekannter Daten In der ersten Stufe liegt der Fokus allein auf dem Design, der Struktur und dem Inhalt der Darstellungsform. Es werden nur Spieldaten angezeigt, die möglichst stark von den real zu erwartenden Werten abweichen sollten (z.B. Umsatz statt der erwarteten 10 Millionen € bei 3€). Natürlich ist dies den Betrachtern auch mitzuteilen, damit diese sich nicht unnötig in Zahlendiskussionen echauffieren. Sind die Ergebnisse dieser Validierung nicht befriedigend, sind nötigenfalls die Darstellungsformen zu ändern.

348

20 Steuerung der Datenqualität in der Realisierung

In der zweiten Stufe werden die nun verbesserten Darstellungsformen mit realen Daten beladen. Es hat sich bewährt, hierzu für die Beteiligten bekannte Daten zu verwenden. Kommt also der ausgewählte Benutzer aus der Abteilung A, so sind in den Darstellungsformen die Daten der Abteilung A darzustellen. Durch diese Maßnahme und den daraus resultierenden Wiedererkennungseffekt fällt es den Beteiligten oft leichter, die angezeigten Daten zu validieren.

20.4 Realisierung der Datenqualitätsmaßnahmen Auch die Maßnahmen zur Verbesserung der Datenqualität sind in dieser Phase umzusetzen. Dazu zählen insbesondere die Prozesse zur Standardisierung, Validierung, Fehlerbehandlung und Anreicherung der Daten, das Monitoring der Datenqualität und die Datenqualitätsberichte (siehe Kap. 9 bis 13). Nicht vergessen werden sollten die Prozesse, die Workflow-Steuerung und die Oberflächen zur manuellen Korrektur der Daten, die die Datenverantwortlichen nicht automatisch korrigieren können. Empfehlenswert ist auch die Realisierung von Fehlerberichten, in denen die Datensätze aus den Fehlertabellen (z.B. Fehler aus den Quellsystemen) angezeigt werden. Diese Berichte sind wesentlich benutzerfreundlicher als der direkte Zugriff, z.B. über SQL, insbesondere wenn eine Möglichkeit zum Ausdruck dieser Fehlerlisten vorhanden ist. Der Zugriff auf diese Berichte wird auf die vorgesehene Benutzergruppe eingeschränkt. Enthalten die Metadaten die dafür notwendigen Informationen, lassen sich bei Verzögerungen der Ladeprozesse die betroffenen Benutzer vorab informieren. So wissen sie, dass die Berichte noch nicht wie vorgesehen die aktuellen Daten anzeigen. Schließlich ist es lästig, dies erst beim Öffnen der Berichte zu bemerken. Die zugehörigen Prozesse werden ebenfalls während der Realisierungsphase erstellt.

20.5 Durchführung von Tests

349

20.5 Durchführung von Tests Bevor die BI­Anwendung den Betrieb aufnimmt, sind die Datenqualitätsmaßnahmen zu testen. Fünf Aspekte sind zu prüfen: ■ Erstens prüft man mit einer Data­Profiling­Analyse, ob die Geschäftsregeln eingehalten sind. Dazu wird die Analyse des Datenbankmodells aus Abschnitt 11.2 wiederholt, wobei die Daten aus den Produktivquellsystemen neu mit den Prozessen aus dem Testbetrieb geladen werden. ■ Zweitens sind die Fehlertabellen auf Unregelmäßigkeiten zu untersuchen: Sind alle dort eingetragenen Datensätze tatsächlich fehlerhaft? Im Zweifelsfall zieht das Team den entsprechenden Datenverantwortlichen zur Unterstützung und Klärung hinzu. ■ Drittens ist zu prüfen, ob die Darstellungsformen dem Designkonzept entsprechen. ■ Viertens ist mithilfe der Datenqualitätskennzahlen zu prüfen, ob alle Datenqualitätsziele erreicht wurden. ■ Und fünftens ist die Korrektheit der Daten zu testen. Hierzu empfiehlt es sich, spezielle Testdaten zu laden und das tatsächliche mit dem erwarteten Ergebnis zu vergleichen. Dabei ist darauf zu achten, dass die Testfälle alle möglichen Datenkonstellationen berücksichtigen. Wie auch bei den anderen Testfällen ist die Grundlage die Spezifikation.

20.6 Empfehlungen Wer in allen Phasen die Hinweise zur Steuerung der Datenqualität beachtet, sollte in der Realisierungsphase keine Überraschungen oder Verzögerungen aufgrund unbekannter Datenqualitätsprobleme erleben. Trotzdem sollten die Realisierer Kenntnisse und Erfahrungen des Datenqualitätsmanagements haben. Ist das nicht der Fall, hilft nur ein projektexternes Datenqualitätsteam weiter. Wer die Hinweise nicht beachtet und versucht, möglichst alle Aktivitäten in der Realisierungsphase nachzuholen, wird das Projekt mit hoher Wahrscheinlichkeit stark in die Länge ziehen. Wie bereits erläutert, ist für ein erfolgreiches Datenqualitätsmanagement die Mitarbeit der Fachabteilungen nötig. Im Normalfall haben diese Experten während der Realisierung nicht genügend Zeit. Außerdem kostet es Zeit und Geld, die auftretenden Datenqualitätsprobleme zu klären und anschließend zu ändern. Die Folge: Das Team kann die Termine nicht mehr einhalten und überschreitet meist auch das Budget. Wer hingegen von Projektbeginn an die Datenqualität steuert, kann sein BI­Projekt korrekt planen, kalkulieren und umsetzen.

350

20 Steuerung der Datenqualität in der Realisierung

351

21 Steuerung der Datenqualität im Betrieb

Waren die Tests in der Realisierungsphase erfolgreich, geht die BI­Anwendung in Betrieb. Kontinuierlich ist sie zu warten und mit dem nötigen Support zu versorgen. In puncto Datenqualitätsmanagement heißt das: Die Datenverantwortlichen überwachen kontinuierlich die Datenqualität und passen die Prozesse immer wieder an. In der Praxis reagieren leider viele Projektteams nur auf Fehlermeldungen und Änderungsanforderungen. Doch nur wer proaktiv agiert und die Datenqualität überwacht, erkennt notwendige Änderungen frühzeitig – noch bevor ein Fehler aufgetreten ist. Nur so wird ein Unternehmen in Verbindung mit den anderen Maßnahmen aus diesem Buch das höchste Maturity­Level (siehe Tab. 21–1) erreichen. Grad 5 optimiert

4 geführt

3 definiert

2 wiederholbar

1 initial

Tab. 21–1

Merkmale

Verbesserung durch …

■ Kontinuierliche Prozessverbesserung ■ Kontinuierliche Prozesspflege ■ Rigorose Defektanalyse und -verhütung ■ Automatisierte Datensammlung, um Schwachpunkte zu finden Quantitativ ■ Gemessene Prozesse ■ Minimum an Qualitätsmetriken ■ Prozesserfahrungsbasis

■ Umfassendes Change Management ■ Problemanalyse ■ Proaktive Problemverhütung

Qualitativ ■ Prozesse definiert und institutionalisiert ■ Prozessgruppe etabliert

■ Messen von Prozessergebnissen ■ Analyse von Prozessen ■ Qualitätsplan mit quantitativen Zielen

Intuitiv ■ Schulung ■ Prozesse hängen von Einzelpersonen ab ■ Review- und Testkultur ■ Minimale Prozesskontrolle und -führung ■ Prozessdefinition ■ Hohes Risiko bei neuen Herausforderungen Ad hoc, chaotisch ■ Vorgehen, Planung nicht formuliert ■ Keine wirksamen Führungsmechanismen

■ Projektmanagement ■ Qualitätssicherung ■ Konfigurationsmanagement

Maturity-Modell für das Datenqualitätsmanagement (in Anlehnung an die ISO-Norm 15504)

352

21 Steuerung der Datenqualität im Betrieb

21.1 Monitoring und Berichtswesen Im produktiven Betrieb können die Datenverantwortlichen mithilfe der realisierten Monitoring­Prozesse die Qualität der Daten regelmäßig messen und die Messwerte speichern. Diese Messwerte zeigen, ob die Datenqualitätsmaßnahmen noch erfolgreich sind, und lassen außerdem frühzeitig erkennen, ob sich die Struktur oder die Qualität der Daten verändert hat. Diese Messwerte dienen auch dazu, die Datenprozesse in der BI­Anwendung qualitätsgeregelt zu steuern. Der Datenprozess (M_CUSTOMERS) wird z.B. mit einem Monitoring (CUST_LOAD_AUDIT) überwacht, das misst, ob die Geschäftsregeln eingehalten werden (siehe Abb. 21–1). Über definierte Schwellwerte wird der Datenprozess gesteuert: Ist der obere Schwellwert überschritten, wird der Ladeprozess mit einem Fehler beendet und die nachfolgende Weiterverarbeitung gestoppt; ist hingegen der untere Schwellwert überschritten, wird eine E­Mail an das Betriebsteam versendet, das die Überschreitung nebst zugehörigen Detailinformationen meldet. Unterhalb des unteren Schwellwerts wird die Weiterverarbeitung normal gestartet.

EMAIL CUST_LOAD_AUDIT

END_WARNING

END_SUCCESS START 1

M_CUSTOMERS

Abb. 21–1

END_ERROR

Qualitätsgeregelte Steuerung der Datenprozesse

Aus den Messwerten der Monitoring­Prozesse berechnen sich die definierten Datenqualitätskennzahlen, die in der realisierten Darstellungsform (z.B. als Teil einer Datenqualitäts­Scorecard) präsentiert werden (siehe Abb. 21–2).

21.2 Ausbildung

353

Datenqualitätskennzahlen 2008 100 % 90 % Soll

80 % 70 %

Vollständigkeit Verfügbarkeit Aktualität

60 % 50 % 40 % 30 % 20 % 10 % 0%

Abb. 21–2

Januar

Februar

März

April

Darstellung der Datenqualitätskennzahlen

Lässt die Entwicklung der Messwerte ein Absinken der Datenqualität unter die Sollwerte erwarten, initiieren die Datenverantwortlichen frühzeitig über eine Änderungsanforderung die Anpassung der Datenqualitätsmaßnahmen. Wie in den vorherigen Phasen benötigen die Datenverantwortlichen auch jetzt die Unterstützung des Fachbereichs.

21.2 Ausbildung Vor oder spätestens zu Beginn des Betriebs sind die Benutzer zu schulen. Maßnahmen zur Verbesserung der Datenqualität werden präsentiert und die Mitarbeiter in die Benutzung der BI­Anwendung eingewiesen. Beispiele sind die Online­Hilfe oder das Kennzahlenglossar. Weiter erklären die Trainer den Benutzern die Abläufe bei auftretenden Datenqualitätsproblemen, die Datenqualitätsorganisation (z.B. die Datenverantwortlichen) und das Eskalationsverfahren. Diese Ausbildung ist regelmäßig zu wiederholen, um auch neu hinzukommende Mitarbeiter einzuweisen.

21.3 Empfehlungen Die Erfahrung zeigt, dass sowohl die Wirksamkeit von Datenqualitätsmaßnahmen als auch die Datenqualität selbst durch Veränderungen der Systeme mit der Zeit abnimmt. Dementsprechend ist ein regelmäßiges Monitoring ein notwendiger Bestandteil des Datenqualitätsmanagements (siehe »Messung« in Abb. 21–3). Zudem ist der Monitoring­Prozess zu automatisieren und zu überwachen. Denn die Erfahrung zeigt auch, dass manuelle Überprüfungen zwar häufig geplant, aber äußerst selten tatsächlich durchgeführt werden. Die Datenqualitätsberichte sollten dem Management regelmäßig in Form eines Berichtswesens präsentiert werden. Die Berichte weisen den Erfolg der Datenqualitätsmaßnahmen im Pro-

354

21 Steuerung der Datenqualität im Betrieb

jekt nach. Außerdem lassen sie – und dies ist noch viel wichtiger – notwendige Änderungen rechtzeitig erkennen. • Definition von • Qualitätszielen • (Sollgrößen) • Definition von • Maßnahmen Geschäftliche Zielvorgaben

DQ-Kennzahlen

DQMaßnahmen

M su ng

Kor Maß rek tive nah men

es

• DQ-Ziele • Prioritäten • Zeitplan • Budget

DQ

• Anpassung der • Maßnahmen Analyse

Abb. 21–3

• Bestimmung der • Auswirkungen der • Maßnahmen auf • die Kennzahlen

• Bestimmung der • Effizienz der Maßnahmen • Bewertung der • Maßnahmen

Datenqualitätsmanagement

Datenqualitätsmanagement ist für jeden Datenverantwortlichen eine Daueraufgabe. Eine Daueraufgabe, die immer wieder an eine veränderte Umgebung anzupassen ist. Ein Ende ist erst erreicht, wenn das System außer Betrieb genommen wird. Doch selbst dann gilt: Auch für das Nachfolgesystem ist Datenqualität essenziell.

Anhang Abkürzungen

357

Literatur

359

Index

367

356

357

Abkürzungen

A-T-Nummer

AustinTetra Universal Supplier Identification Number

ADAPT

Application Design for Analytical Processing Technologies

API

Application Programming Interface

BI

Business Intelligence

BICC

Business-Intelligence-Kompetenzzentrum

BSC

Balanced Scorecard

CDQO

Chief Data Quality Officer

CEO

Chief Executive Officer

CFO

Chief Financial Officer

CIO

Chief Information Officer

CRM

Customer Relationship Management

CWM

Common Warehouse Metamodel

DGIQ

Deutsche Gesellschaft für Informations- und Datenqualität

DQ

Datenqualität

DQM

Datenqualitätsmanagement

DUNS

Data Universal Numbering System

DV

Datenverarbeitung

DWH

Data Warehouse

ERP

Enterprise Resource Planning

ETL

Extraktion, Transformation, Laden

HGB

Handelsgesetzbuch

HID

Haushaltsnummer

358

Abkürzungen

HW

Hardware

IFRS

International Financial Reporting Standards

IMDS

International Material Data System

IT

Informationstechnologie

ITIL

Information Technology Infrastructure Library

KPI

Key Performance Indicator

MDM

Master Data Management

NACE

Nomenclature statistique des activités économiques dans la Communauté Européenne

NAICS

North American Industry Classification System

ODS

Operational Data Store

OLAP

Online Analytical Processing

QM

Qualitätsmanagement

RACI

Responsible/Accountable/Consulted/Informed

REACH

Registration, Evaluation, Authorisation and Restriction of Chemicals

RFID

Radio Frequency Identification

RUP

Rational-Unified-Prozess

SCM

Supply Chain Management

SEC

United States Securities and Exchange Commission

SIC

Standard Industrial Classification

SLA

Service Level Agreement

SOA

Serviceorientierte Architektur

SQL

Structured Query Language

SW

Software

TDQM

Total Data Quality Management

TDWI

The Data Warehouse Institute

TQdM

Total-Quality-data-Management-Methodik

UNDP

United Nations Development Program

UNSPSC

United Nations Standard Products and Services Code

WHIRL

Word-based Heterogeneous Information Retrieval Logic

359

Literatur

[Agens 2007] Agens Consulting: Studie Datenqualitätsmanagement in Kreditinstituten, Ellerau 2007. [Apel/Behme 2010] Apel, D.; Behme, W.: Daten kostengünstig und sicher migrieren. In: Linux Technical Reviev 2010 [Internet]. www.linuxtechnicalreview.de/Themen/IT­Management. [Auth 2004] Auth, G.: Prozessorientierte Organisation des Metadatenmanagements für Data­Warehouse­Systeme, Books on Demand, Norderstedt 2004. [Batini/Scannapieco 2006] Batini, C.; Scannapieco, M.: Data Quality: Concepts, Methodologies and Techniques, Heidelberg 2006. [Baeza­Yates/Ribeiro­Neto 1999] Baeza­Yates, R.; Ribeiro­Neto, B.: Modern Information Retrieval, New York 1999. [Behme 2002] Behme, W.: Datenqualität: Der kritische Erfolgsfaktor in Data Warehouse­Projekten. In: Kemper, H.­G.; Mayer, R. (Hrsg.): Business Intelligence in der Praxis. Bonn 2002, S. 47–59. [Behme/Nietzschmann 2005] Behme, W.; Nietzschmann, S. : Strategien zur Verbesserung der Datenqualität im DWH­Umfeld. In: HMD Praxis der Wirtschaftsinformatik, 43. Jg., Heft 247, 2005, S. 43–53. [Bissantz et al. 2010] Bissantz, N.; Mertens, P.; Butterwegge, G.; Christ, V.: Visualisierung betriebswirtschaftlicher Daten. In: Chamoni, P.; Gluchowski, P. (Hrsg.): Analytische Informationssysteme. 4. Auflage, Heidelberg 2010, S. 440–462. [Bulos/Forsman 2006] Bulos, D.; Forsman, S. : Getting started with ADAPT. OLAP Database Design. White Paper, Symmetry Corporation, San Rafael 2006. [Capgemini 2011] Capgemini­Studie »IT­Trends 2011«, München 2011. [Cartlidge et al. 2007] Cartlidge, A. u.a.: An Introductory Overview of ITIL® V3. The IT Service Management Forum 2007. [Cohen 1998] Cohen, W.: Integration of heterogeneous databases without common domains using queries based on textual similarity. In: Proceedings of the 1998 ACM SIGMOD International Conference on Management of Data. Seattle 1998, S. 201–212.

360

Literatur

[Crosby 1979] Crosby, P. B.: Quality Is Free: The Art of Making Quality Certain, New York 1979. [deFries/Seidl/Windheuser 2002] deFries, D.; Seidl, J.; Windheuser, U.: Datenqualität: Ein unterschätzter Erfolgsfaktor. In: ExperPraxis 2001/2002, S. 92–97. [deMarco 1982] deMarco, T.: Controlling Software Projects – Management, Measurement and Estimation. Englewood Cliffs 1982. [Devlin 1997] Devlin, B.: Data Warehouse from Architecture to Implementation. Reading, Massachusetts 1997. [Damerau 1964] Damerau, F. J.: A technique for computer detection and correction of spelling errors, in Communications of the ACM Volume 7 Issue 3, March 1964, S. 171–176. [Davenport/Harris 2007] Davenport Thomas H., Harris Jeanne G.: Competing on Analytics: Harvard Business School Press 2007. [Dember 2006] Dember, M.: 7 Stages for Effectiveness in Data Governance. In: Architecture & Governance Magazine, 2006. [DGIQ 2007] Deutsche Gesellschaft für Informations­ und Datenqualität e.V.: IQ­Definitionen [Internet]. 2007, abgerufen am 9.12.2012, www.dgiq.de. [DIN 55350] DIN 55350­11, Begriffe zu Qualitätsmanagement und Statistik, Teil 11: Begriffe des Qualitätsmanagements. In: DIN Deutsches Institut für Normung (Hrsg.), Berlin 1995. [DIN ISO 8402] DIN ISO 8402, QM­Lexikon [Internet]. Abgerufen am 9.12.2012, www.quality.de/lexikon/din_en_iso_8402.htm. [Do/Rahm 2000] Do, H. H.; Rahm, E.: On metadata interoperability in data warehouses. Technischer Report 1­2000, Institut für Informatik, Universität Leipzig 2000. [Draisbach 2012] Draisbach, U.: Partitionierung zur effizienten Duplikaterkennung in relationalen Daten. Wiesbaden 2012. [Dresdner Bank 1999] Dresdner Bank – Patzer bei der Euro­Umstellung (o.A.). In: Computerwoche 3/1999, S. 47. [Dyché/Levy 2006] Dyché, J.; Levy, E.: Customer Data Integration. New Jersey 2006. [Eckerson 2002] Eckerson, W.: Data Quality and the Bottom Line: Achieving Business Success through Commitment to High Quality Data. TDWI’s Data Quality Report, Chatsworth 2002. [Eckerson 2006] Eckerson, W.: Dashboard or Scorecard: Which Should You Use?, Chatsworth 2005. Eckerson, Wayne: Deploying Dashboards and Scorecards, TDWI Best Practices Report,Chatsworth 2006. [Economist 2010] The Economist, Feb. 27th, 2010, Special report on managing information. [Economist 2012a] The Economist, October 27th, 2012: Special report on technology and geography.

Literatur

361

[Economist 2012b] The Economist: The Deciding Factor: Big Data & Decision Making, The Economist 2012. [English 1999] English, L.: Improving Data Warehouse and Business Information Quality: Methods for Reducing Costs and Increasing Profits. New York 1999. [English 2002] English, L.: Plain English About Information Quality: Information Quality in E­Business – Focus on E­Customer Success. In: DM Review Magazine, Oktober 2002. [Eppler/Helfert 2004] Eppler, M.; Helfert, M.: A Framework for the Classification of Data Quality Costs and Analysis of their Progression. In: Proceedings of 9th International Conference on Information Quality, Cambridge (USA) 2004, S. 311–325. [Feigenbaum 1961] Feigenbaum, A.: Total Quality Control. 2. Auflage, New York 1961. [Feix 2007] Feix, C.: Bedeutung von »Geo Business Intelligence« und Geomarketing zur Entscheidungsunterstützung unternehmerischer Planungsprozesse im Kontext wirtschaftlicher Liberalisierung: Konzeption, Entwicklung und Anwendung komplexer räumlicher Algorithmen für den Aufbau eines GIS­gestützten Geomarketing­Systems. Freie Universität Berlin, Fachbereich Geowissenschaften, Dissertation, 2007. [Fellegi/Sunter 1969] Fellegi, I. P.; Sunter, A. B.: A Theory for Record Linkage. In: Journal of the American Statistical Association, Volume 64, No. 328, 1969, S. 1183–1210. [Few 2004] Few, S. : Show Me The Numbers: Designing Tables and Graphs to Enlighten. Oakland 2004. [Few 2006] Few, S. : Information Dashboard Design: The Effective Visual Communication of Data. Sebastopol 2006. [Few 2008] Few, S. : With Dashboards, Formatting and Layout Definitely Matter [Internet]. 2008, abgerufen am 31. Mai 2010, www.perceptualedge.com. [Friedman 2006] Friedman, T.: Gartner Study on Data Quality Shows That IT Still Bears the Burden. Gartner Group, Stamford 2006. [Friedman 2010] Friedman, T.: Findings from Primary Research Study – Data Quality Issues Create Significant Cost, Yet often go Unmeasured; Gartner Inc. 2010. [Friedman 2012] Friedman, T.: Best Practices for Data Quality Improvement – Ensuring BI Success through High Value Data. Gartner Group, Stamford 2012. [Friedman/Richardson 2008] Friedman T.; Richardson J.: Establish a Virtuous Cycle of Business Intelligence and Data Quality: Gartner Inc. 2008. [Gartner 2011] Gartner: Gartner Special Report Examines How to Leverage Pattern-Based Strategy to Gain Value in Big Data, STAMFORD, 2011. [Garvin 1984] Garvin, D. A.: What does Product Quality Really Mean? In: Sloan Management Review, Fall 1984, Volume 26, No. 1, S. 25–43. [GfK 2010] GfK Geomarketing [Internet]. Abgerufen am 9.12.2012, http://www.gfk-geomarketing.de/geomarketingwissen.html.

362

Literatur

[Grimmer/Hinrichs 2001] Grimmer, U.; Hinrichs, H.: Datenqualitätsmanagement mit Data­Mining­Unterstützung. In: HMD Praxis der Wirtschaftsinformatik, 39. Jg., Heft 222, 2001, S. 70–80. [Hamming 1950] Hamming, R. W.: Error Detecting and Error Correcting Codes. In: The Bell System Technical Journal, Volume 29, No. 2, 1950, S. 147–160. [Hankins 1999] Hankins, L.H.: Cleansing Looms Important in Data Warehouse Efforts. In: SIGNAL AFCEA’s International Journal, Februar 1999. [Hartel 2006] Hartel, C.: Data Cleaning und Record Matching. Seminar Information Integration, Kaiserslautern 2006. [Heinrich et al. 2007] Heinrich, B.; Kaiser, M.; Klier, M.: Metrics for measuring data quality – foundations for an economic oriented management of data quality. In: Proceedings of the 2nd International Conference on Software and Data Technology, Barcelona 2007, S. 87–94. [Heinrich/Klier 2011] Heinrich, B.; Klier, M.: Datenqualitätsmetriken für ein ökonomisch orientiertes Qualitätsmanagement. In: Hildebrand, K. u.a. (Hrsg.): Daten­ und Informationsqualität. 2. Auflage, Wiesbaden 2011, S. 49–67. [Helfert 2000] Helfert, M.: Maßnahmen und Konzepte zur Sicherung der Datenqualität, In: Jung, R.; Winter, R. (Hrsg.): Data Warehousing Strategie. Berlin 2000, S. 61–77. [Helfert 2002] Helfert, M.: Proaktives Datenqualitätsmanagement in Data Warehouse Systemen: Qualitätsplanung und Qualitätslenkung. Berlin 2002. [Helfert/Herrmann/Strauch 2001] Helfert, M.; Herrmann, C.; Strauch, B.: Datenqualitätsmanagement. Arbeitsbericht der Universität St. Gallen, BE HSG/CC DW2/02, 2001. [Helmis/Hollmann 2009] Helmis, S. ; Hollmann, R.: Webbasierte Datenintegration, Wiesbaden 2009. [Hernandéz/Stolfo 1995] Hernandéz, M. A.; Stolfo, S. J.: The merge/purge problem for large databases. In: Proceedings of the 1995 ACM SIGMOD International Conference on Management of Data, San Jose 1995, S. 127–138. [Hernandéz/Stolfo 1998] Hernandéz, M. A.; Stolfo, S. J.: Real­world Data is Dirty: Data Cleansing and the Merge/Purge Problem. In: Data Mining and Knowledge Discovery, 2(1) 1998, S. 9–37. [Herter/Mühlbauer 2008] Herter, M.; Mühlbauer, K.­H.: Handbuch Geomarketing. Heidelberg 2008. [Hichert 2003] Hichert, R.: Betriebswirtschaftliche Analysen richtig visualisieren. In: Controller­Leitfaden 9/14, Zürich 2003, S. 1–21. [Hichert 2004] Hichert, R.: Information Design: Reports professionell gestalten. Workshop­Unterlagen 2004.

Literatur

363

[Hichert 2008] Hichert, R.: Klare Botschaften und verständliche Darstellungen verschaffen dem Controller Gehör. In: Controlling & Management, 01/2008, S. 15–17. [Hichert 2010] Hichert, Rolf: Consulting/Dashboards [Internet]. Abgerufen am 09.12.2012, www.hichert.com/de/consulting/dashboards/52. [Hinrichs 2002] Hinrichs, H.: Datenqualitätsmanagement in Data Warehouse­Systemen. Carl von Ossietzky­Universität Oldenburg, Fachbereich Informatik, Dissertation, 2002. [IDC 2011] IDC Study – Extracting Value from Chaos, USA 2011. [Inmon 1996] Inmon, W.: Building the Data Warehouse. New York 1996. [Inmon/O’Neil/Fryman 2008] Inmon, W.; O’Neil, B.; Fryman, L.: Business Metadata: Capturing Enterprise Knowledge. Burlington 2008. [Inmon/Strauss/Neushloss 2008] Inmon, W.; Strauss, D.; Neushloss, G.: DW 2.0: The Architecture for the Next Generation of Data Warehousing. Burlington 2008. [Jacobson/Booch/Rumbaugh 1999] Jacobson, Ivar; Booch, Grady; Rumbaugh, James: The unified software development process. Boston 1999. [Jossen et al. 2009] Jossen, C.; Quix, C.; Staudt, M.; Vaduva, A.; Vetterli, T.: Metadaten. In: Bauer, A.; Günzel, H. (Hrsg): Data Warehouse Systeme, 3. Auflage, Heidelberg 2009, S. 345–371. [Juran 1988] Juran, J. M.: Juran on Quality by Design: The New Steps for Planning Quality into Goods and Services. New York 1988. [Kaplan/Norton 1992] Kaplan, R. S.; Norton, D. P.: The Balanced Scorecard – Measures that Drive Performance. In: Harvard Business Review, Januar/Februar 1992, S. 71–79. [Kedad/Métais 2002] Kedad, Z.; Métais, E.: Ontology­Based Data Cleaning. In: 6th International Conference on Applications of Natural Language to Information Systems, Stockholm 2002. Lecture Notes in Computer Science, Volume 2553, S. 137–149. [Keizer 2004] Keizer, G.: Gartner: Poor Data Quality Dooms Many IT Projects. In: Information Week, Mai 2004. [Kight/Smith 2007] Kight, B.; Smith, D.: The Strength is in the Governance. In: Teradata Magazine, Juni 2007, S. 77–79. [Kimball 2002] Kimball, R.: The Data Warehouse Toolkit. New York 2002. [Kohlhammer/Proff/Wiener 2013] Kohlhammer, J.; Proff, D.; Wiener, A.: Visual Business Analytics – Effektiver Zugang zu Daten und Informationen, Heidelberg 2013. [Kokemüller/Haupt 2012] Kokemüller, J.; Haupt, F.: Datenqualitätswerkzeuge 2012: Werkzeuge zur Bewertung und Erhöhung von Datenqualität. Stuttgart 2012.

364

Literatur

[Lehmann 2001] Lehmann, P.: Meta-Datenmanagement in Data-Warehouse-Systemen. Rekonstruierte Fachbegriffe als Grundlage einer konstruktiven, konzeptionellen Modellierung. Aachen 2001. [Leser/Naumann 2007] Leser, U.; Naumann, F.: Informationsintegration. Heidelberg 2007. [Levenshtein 1966] Levenshtein, V.: Binary codes capable of correcting deletions, insertions, and reversals. In: Doklady Akademii Nauk SSSR, 163(4), 1965, S. 845–848 (Russisch). Englische Übersetzung in: Soviet Physics Doklady, 10(8), 1966, S. 707–710. [Marco/Smith 2006] Marco, D.; Smith, A. M.: Metadata Management & Enterprise Architecture: Understanding Data Governance and Stewardship. In: DM Review, 2006. [Maydanchik 2008] Maydanchik, A.: Data Quality Assessment – Practical Skills. TDWI World Conference, Vortragsunterlagen, San Diego, 17.–22. August 2008. [Melchert 2003] Melchert, F.: Das Common Warehouse Metamodel als Standard für Metadaten im Data Warehouse. In: Maur, E. von; Winter, R. (Hrsg.): Data Warehouse Management. Berlin 2003, S. 89–111. [Melchert 2004] Melchert, F.: Metadatenmanagement im Data Warehousing. Bericht BE HSG/CC BPM/01, Universität St. Gallen 2004. [Mertens/Meier 2009] Mertens, P.; Meier, M. C.: Integrierte Informationsverarbeitung 2. Planungs­ und Kontrollsysteme in der Industrie, 10. Auflage, Wiesbaden 2009. [Michael 1999] Michael, J.: Doppelgänger gesucht, c’t Magazin für Computer und Technik 25/1999, S. 252-254. [Monge/Elkan 1996] Monge, A. E.; Elkan, C. P.: The field matching problem: Algorithms and applications. In: Proceedings of the 2nd International Conference on Knowledge Discovery and Data Mining, Portland 1996, S. 267–270. [Müller 2000] Müller, J.: Transformation operativer Daten zur Nutzung im Data Warehouse. Wiesbaden 2000. [Naumann/Herschel 2010] Naumann, F.; Herschel, M.: An Introduction to Duplicate Detection. Waterloo 2010. [Newman/Logan 2006] Newman, D.; Logan, D.: Governance Is an Essential Building Block for Enterprise Information Management. Gartner Research, Stamford 2006. [Olson 2003] Olson, J. E.: Data Quality: The Accuracy Dimension, San Francisco 2003. [Omikron 2012] Omikron: Studie: Datenqualität wird zur Herausforderung von Big-Data-Strategien [Internet]. Abgerufen am 5.7.2014, http://www.omikron.net/Datenqualitaet-wird-zur-Herausforderung-vonBig-Data-Strategien.html, 2012. [Otto et al. 2008] Otto, B. u.a.: Unternehmensweites Datenqualitätsmanagement: Ordnungsrahmen und Anwendungsbeispiele. In: Dinter, B.; Winter, R. (Hrsg.): Integrierte Informationslogistik. Berlin 2008, S. 211–230.

Literatur

365

[PAC 2012] Pierre Audoin Consultants (PAC): In-Memory-Datenanalyse in Zeiten von Big Data, PAC 2012. [Postel 1969] Postel, H.: Die Kölner Phonetik. Ein Verfahren zur Identifizierung von Personennamen auf der Grundlage der Gestaltanalyse. In: IBM­Nachrichten, 19. Jahrgang, 1969, S. 925–931. [Raskino/Fenn/Linden 2005] Raskino, M.; Fenn, J.; Linden, A.: Extracting Value From the Massively Connected World of 2015. April 2005. [Redman 1996] Redman, T. C.: Data Quality for the Information Age. Norwood 1996. [Redman 2001] Redman, T. C.: Data Quality – The Field Guide. Boston 2001. [Redman 2008a] Redman T. C.: Data Warehouses and Quality – Not just for IT anymore; Navesink Consulting Group 2008. [Redman 2008b] Redman T. C.: Data Assets, Quality and Top-Line Metrics – Energizing and Focusing the Data Quality Program; Navesink Consulting Group 2008. [Rohwedder et al. 2011] Rohwedder, J. u.a.: Informationsqualität – Definitionen, Dimensionen und Begriffe. In: Hildebrand, K. u.a. (Hrsg.): Daten­ und Informationsqualität. Wiesbaden 2011, S. 25–45. [Rowohl/Schwarz/Strauch 2000] Rowohl, S; Schwarz, B.; Strauch, F.: Entwicklung einer integrierten Metadatenmanagement-Lösung für das Data Warehousing, St. Gallen 2000. [Russel 1918] Russel, R. C.: Soundex Index, 1918 [Internet]. Abgerufen am 9.12.2012, http://west-penwith.org.uk/misc/soundex.htm. [Russom 2006] Russom, P.: Taking Data Quality to the Enterprise through Data Governance. The Data Warehousing Institute, TDWI Report Series, März 2006. [Scheuch/Gansor/Ziller 2012] Scheuch, R.; Gansor, T.; Ziller, C.: Master Data Management: Strategie, Organisation, Architektur. Heidelberg 2012. [Schmidt 2011] Schmidt, T.: DMAIC-Zyklus: Systematisches Datenqualitätsmanagement zahlt sich aus. In: BI-Spektrum 04/2011, S. 26–28. [Schmidt 2012] Schmidt, T.: Systematisches DQ-Management – Den Problemen nicht bloß immer hinterherlaufen. In: BI-Spektrum 05/2015, S. 29–32. [Schumacher 2007] Schumacher, J.: Harmonisierte Stammdaten – Schlüssel zur Optimierung interner und externer Geschäftsprozesse. IIR­Forum Stammdaten­Management, Vortragsunterlagen, Frankfurt a. M., 27. September 2007. [Schüssler 2000] Schüssler, F.: Geomarketing. Anwendungen Geographischer Informationssysteme im Einzelhandel. Marburg 2000. [Smith/Waterman 2001] Smith, T.; Waterman, M.: Identification of common molecular subsequences. In: Molecular Biology, 147 (1), 2001, S. 195–197. [Staudt/Vaduva/Vetterli 1999] Staudt, M.; Vaduva, A.; Vetterli, T.: The Role of Metadata for Data Warehousing. Technical Report 99.06. Institut für Informatik, Universität Zürich 1999.

366

Literatur

[Swanton 2005] Swanton, B.: Master Data Management Organizations: A Balance of Control and Responsibility. AMR Research Alert, Boston 2005. [Tufte 1997] Tufte, Edward: The Visual Display of Quantitative Information. Cheshire 1997. [Tufte 2006] Tufte, E.: Beautiful Evidence. Cheshire 2006. [Wang 1998] Wang, R. Y.: A Product Perspective on Total Data Quality Management. In: Communications of the ACM, 1998, S. 58–65. [Wang/Strong 1996] Wang, R. Y.; Strong, D.: Beyond Accuracy: What Data Quality Means to Data Consumers. In: Journal of Management Information Systems, 1996, S. 5–33. [Wang/Ziad/Lee 2001] Wang, R. Y.; Ziad, M.; Lee, Y. W.: Data Quality. Boston 2001. [Weichert 2008] Weichert, T.: Datenschutz und Nutzung von Geoinformation – ein Oxymoron? Kongress »Wirtschaftsförderung mit Online­GeoInformationen« des DIHK und der GIW­Kommission, Vortragsunterlagen, Berlin, 5. Juni 2008. [Wende 2007a] Wende, K.: A Model for Data Governance – Organising Accountabilities for Data Quality Management. In: Proc. of 18th Australasian Conference on Information Systems, 5.–7. Dezember 2007, Toowoomba, S. 417–425. [Wende 2007b] Wende, K.: Data Governance Defining Accountabilities for Data Quality Management. In: Isari, D.; D’Atri, A.; Winter, R. (Hrsg.): Luiss University Press 2008. – SIWIS 2007, Side Event of ECIS 2007. – St. Gallen. [Wolf 1999] Wolf, P.: Konzept eines TQM­basierten Regelkreismodells für ein Information Quality Management (IQM). Dortmund 1999. [Won/Choi 2003] Won, K.; Choi, B.: Towards Quantifying Data Quality Costs. In: Journal of Objects Technology, Volume 2, No. 4, Juli/August 2003, S. 69–76. [Würthele 2003] Würthele, V. G.: Datenqualitätsmetrik für Informationsprozesse. ETH Zürich, Dissertation, 2003. [Zeh 2009] Zeh, T.: Datenqualität. In: Bauer, A.; Günzel, H. (Hrsg.): Data Warehouse Systeme. Heidelberg 2009, S. 45–47.

367

Index

A abgeleitete Attribute 161 Abgleich der Daten 310 Abhängigkeiten funktionale 158 referenzielle 163 Ablauforganisation 63 Abstammungsanalyse 265 Abstimmungsprobleme 29 Abweisung der fehlerhaften Daten 176 Achsenskalierung 248 Ad­hoc-Querying 73 Aggregatverfahren 215 Ähnlichkeitsmetriken 205 Aktualität 7 Ampelgrafik 281 Analyse von Datensätzen 162 von Tabellen 163, 168 Anforderungen gesetzliche 45 regulatorische 266 Anlieferungszeitpunkt 25 Anreicherung von Daten 290 Anwender 264, 273, 347 Anwendungslandschaft 30, 84, 233 Architektur 30, 69, 75, 81, 256–257, 259, 311, 314, 339 serviceorientierte 83 A­T­Nummer siehe Austin­Tetra Universal Supplier Identification Number Attributbezeichnungen 336 Attribute abgeleitete 161 redundante 166 zeitabhängige 169

Attributnamenanalyse 137 Aufbauorganisation 53 Ausbildung 353 Austin­Tetra Universal Supplier Identification Number (A­T­Nummer) 220 Auswirkungsanalyse 265

B Bedeutung von Daten vii, 4 Benachrichtigungen 282 Benachrichtigungsregeln 264 Benutzerfehler 28 Bereinigung von Daten 179, 187, 189 Bereinigungskosten 43 Bereitstellung der Daten 233 Bericht 178 Berichtswesen 278, 352 Betroffenheitsmatrix 57, 283 Bezeichnungen 234 Beziehungen, zulässige 234 BI-Frontend-Werkzeug 80 Big Data 91 Datenqualität 95 fachlich-datenbezogene Sicht 93 Framework 92 Gartner-Sicht 94 technisch-infrastrukturelle Sicht 95 Branchenklassifizierung 229 Business Case 49 Betrachtungen 51 Business Information Guide 255 Business-Intelligence-Anwendungen 19 Referenzarchitektur 69 Business Intelligence Service 74

368

C Change Data Capture 77 Common Warehouse Metamodel (CWM) 258 Compliance 22, 45 Anforderungen 46 Corporate Design 245 CRM siehe Customer Relationship Management Customer Relationship Management (CRM) 176 CWM siehe Common Warehouse Metamodel

D Darstellungsformen 235, 250 Darstellungsstruktur 242 Darstellungswerkzeuge 233 Dashboard 121, 235, 282 Data Federation 78 Data Governance Ansatz 55 Council 56 Organisation 92, 97 Data Mart 30 Data Mining 80 Data Profiling 51, 81, 131, 272, 277, 288, 307, 329, 346 Metadaten 267 Team 135 Verfahren 137, 158, 163 Vorgehensweise 136 Prozess 132 Werkzeuge 273 Data-Quality-Bericht siehe Datenqualitätsbericht Data Quality Manager siehe Datenqualitätsmanager Data Quality Monitoring (DQ­Monitoring) 121, 269, 276 Data Steward 54, 57, 59, 283, 341 Data Streaming 100 Data Universal Numbering System (DUNSNummer) 220–221

Index

Daten 3 Anreicherung 219, 290 Bedeutung vii, 4 Bereinigung 187 Bereitstellung 233 Erfassung 28 externe 97 Extraktion 180 fehlerhafte 123, 175 Interpretation 80 Korrektur 33, 123 Laden 181 nicht zu bereinigende 218 Partitionierung 199 Überschreiben 193 unstrukturierte 99 Datenabgleich 310 Datenarchitektur 30 Datenbankmodell 346 Datenbereinigung 75, 82, 86, 189, 289 Datenbereitstellung 21 Dateneingabeprozess 126 Datenerfassung 28, 57 Datenextraktion 77 Datenfilterung 175 Datenfluss vii, 121 Metadaten 261 Datenhaltung 73, 79, 262 redundante 75 verteilte 75 Datenintegration 72, 76, 86, 291, 342 Datenintegrationsprozess 121 Datenorganisation 320 Datenqualität (DQ) 3, 7, 19, 75, 312 Assessment 271 Messpunkte 106 Messung 103 Metadaten 264 Phasenkonzepte 274 Planung 270 schlechte 24, 37 Steuerung 345, 351 Verbesserung 123, 233 Datenqualitätsanalyse Werkzeuge 273

Index

Datenqualitätsanforderungs-Management 66 Datenqualitätsbericht 278 Datenqualitätseskalations-Management 66 Datenqualitäts-Jour-Fixe 57, 62 Datenqualitätskosten 38 Datenqualitätskriterien 8 Konsistenz 26 Korrektheit 26 Relevanz 27 Vollständigkeit 27 Zeitnähe 25 Zuverlässigkeit 26 Datenqualitätslenkungsausschuss 56, 62 Datenqualitätsmanagement (DQM) 11, 13, 53, 285 Architektur 81 Komponente 286 Maturity-Modell 351 Ordnungsrahmen 16 Rollen 54 Studie 301 Werkzeuge 285 Datenqualitätsmanager 57–58 Datenqualitätsmaßnahmen 335 Realisierung 348 Tests 349 Datenqualitätsproblem 124 Management 65 Datenqualitätsradar 281 Datenqualitätsreporting 64 Datenqualitätssicherung laufende 64 Datenqualitätsziele 322, 335 Datenquelle 71, 75, 91 Datenredundanz 76 Datensätze, Analyse von 162 Datenstrom 71 Datenstrukturen 79 Datentypanalyse 138 Datenvalidierung 182 Datenverantwortlicher 304, 347 Datenverfall 33 Datenverwendung 33 Datenvolumina 101 Designkonzept 331, 345, 349

369

Designprototyp 239, 331 Domänen 340 Domänenanalyse 144 DQ siehe Datenqualität DQM seihe Datenqualitätsmanagement DQ-Monitoring siehe Data Quality Monitoring DUNS-Nummer siehe Data Universal Numbering System Duplikate 289 D&B Family Trees 220

E eClass 227 Eindeutigkeitsanalyse 147 Entdeckungskosten 42 ETL siehe Extraktion, Transformation, Laden ETL-Prozess 217, 330, 339 ETL­Technologie 72 externe Daten 97 Extraktion, Transformation, Laden (ETL) 72

F Fachbereich 293 fehlerhafte Daten 123, 175 Abweisung 176 Filesystem 79 Filterung 176 funktionale Abhängigkeiten 158

G gemeinsames Vokabular 32 geografische Informationen 222 Geographical Business Intelligence 223 Geo-Marketing 223 Geschäftsregeln 150, 162, 168, 327 Geschäftstreiber 20 Geschwindigkeit 100 gesetzliche Anforderungen 45 Gremien 62

H Hadoop-Framework 101 Haushaltsbildung 225 Historienreihe 279 Historisierung 76

370

Index

I

N

IFRS siehe International Financial Reporting Standard Informationen geografische 222 soziodemografische 224 Informationsbereitstellung 73, 80, 263 Informations­Chef-Designer 239 Informationsdichte 246 International Financial Reporting Standard (IFRS) 46

NACE siehe Nomenclature statistique des activités économiques dans la Communauté Européenne NAICS siehe North American Industry Classification System NAICS­Code 231 nicht zu bereinigende Daten 218 Nomenclature statistique des activités économiques dans la Communauté Européenne (NACE) 230 North American Industry Classification System (NAICS) 231 NULL-Werte-Analyse 149

K Kardinalitäten 166 Kennzahlen 103 Anwendungsmöglichkeiten 104 für Datenqualitätskriterien 112 Kennzahlenbaum 114 Kennzahlenformular 115 Kennzahlensystem 114 Klassifizierung Dienstleistungen 226 Waren 226 Konventionen 336, 345 Konzepte 345 Kosten 22

L laufende Datenqualitätssicherung 64

M Master Data Management (MDM) 85 Architektur 86 MDM siehe Master Data Management Metadaten 253 Analyse 306 Architektur 255 Data Profiling 267 Datenfluss 261 Datenqualität 264 Erstellung 265 Kategorie 260 Management 258 Nutzung 265 Repository 256 Metriken 109 Monitoring 291, 352 Verantwortlichkeiten 283 Musteranalyse 143

O Objekte Bezeichnung 325 Definition 325 Operational Business Intelligence 100 Organisation 53

P Plan-Do-Check-Act-Zyklus 13 Präventionskosten 42 Produktauswahl 285 Produktintegration 285 Prototypen 343

Q QM siehe Qualitätsmanagement Qualität 5 Qualitätsmanagement (QM) 13 Qualitätswesen 12 Quellsysteme 123, 302, 346

R redundante Attribute 166 redundante Datenhaltung 75 Referenzarchitektur 69 referenzielle Abhängigkeiten 163 regulatorische Anforderungen 266 Richtlinien 336, 345 Right Time Data Integration 78 Risiken 22 Rollen 264, 320

S Schlüsselattribute 158 Self Service Business Intelligence 80

Index

Sentimentanalyse 99 Service-Lebenszyklus nach ITIL V3 63 Serviceorientierte Architektur (SOA) 83 Umsetzung 89 SIC siehe Standard Industrial Classification SIC­Code 231 SOA siehe Serviceorientierte Architektur soziodemografische Informationen 224 Spend Management Reporting 337 Spezifikation 319 Schnittstellen 319 Spinnengrafik 279 Sponsor 58 Spread Mart 79 Stammdaten 85 Standard Industrial Classification (SIC) 231 Standardisierung 187 Systementwurf 330, 337 Systemverantwortlicher 57

T Tabellen Analyse von 163, 168 TDQM siehe Total Data Quality Management Total Data Quality Management (TDQM) 13 Total-Quality-data-ManagementMethodik (TQdM) 14 TQdM siehe Total-Quality-dataManagement-Methodik

371

U United Nations Standard Products and Services Code (UNSPSC) 226 UNSPSC siehe United Nations Standard Products and Services Code unstrukturierte Daten 99 Unternehmenssteuerung 23

V Validierung 175, 180 Validierungsregeln 184 verteilte Datenhaltung 75 Visualisierung 233 der Information 235 Vokabular, gemeinsames 32

W Werkzeuge 315 Wertebereichsanalyse 142 Wertschöpfung 253 Wettbewerb 22 Wirtschaftsinformationen 219

Z zeitabhängige Attribute 169 Zielsystem 311 zulässige Beziehungen 234

372

Index