DATENQUALITÄT ERFOLGREICH STEUERN · 2010-10-14 · maßnahmen. Im Gegensatz dazu greifen die praxisorientierten Problemlösungen nicht selten nur lokal und bekämpfen die Folgen,

DATENQUALITÄT ERFOLGREICH STEUERN

PRAXISLÖSUNGEN FÜR BUSINESS-INTELLIGENCE-

PROJEKTE

detlef APEL

wolfgang BEHME

rüdiger EBERLEIN

christian MERIGHI

2., vollständig überarbeitete und erweiterte Auflage

�

Inhalt

Seite

Vorwort.............................................................................................9Einleitung.........................................................................................11

I. Theorie

I.1 Datenqualität...................................................................................16

I.1.1 Daten.................................................................................16I.1.2 Qualität..............................................................................17I.1.3 Datenqualität....................................................................19I.1.4 Datenqualitätsmanagement.............................................24I.1.5 Zusammenfassung............................................................28

I.2 AusprägungenundUrsachenschlechterDatenqualität................29

I.2.1 Geschäftstreiber................................................................29I.2.2 AusprägungenschlechterDatenqualität.........................32I.2.3 UrsachenschlechterDatenqualität..................................34I.2.4 Beispiel:Finanzdienstleister.............................................39I.2.5 Zusammenfassung............................................................41

I.3 AuswirkungenschlechterDatenqualität........................................42

I.3.1 Datenqualitätskosten........................................................42I.3.2 GesetzlicheAnforderungen..............................................47I.3.3 Zusammenfassung............................................................51

I.4 Organisation....................................................................................52

I.4.1 Aufbauorganisation..........................................................52I.4.2 Ablauforganisation...........................................................60I.4.3 Empfehlungen...................................................................63

I.5 ReferenzarchitekturfürBusiness-Intelligence-Anwendungen......65

I.5.1 Referenzarchitektur..........................................................65I.5.2 ProblemstellenundLösungsansätzehinsichtlich

derDatenqualität..............................................................69I.5.3 ArchitekturfürDatenqualitätsmanagement...................73I.5.4 ServiceorientierteArchitektur..........................................75I.5.5 MasterDataManagement................................................76

I.6 KennzahlenzurMessungderDatenqualität..................................81

I.6.1 AnwendungsmöglichkeitenvonKennzahlen..................82I.6.2 MesspunktefürDatenqualität.........................................84I.6.3 DQ-Metriken....................................................................87I.6.4 BeispielefürKennzahlenjeDatenqualitätskriterium.....89I.6.5 Kennzahlenbaum..............................................................91I.6.6 DQ-Assessment.................................................................92

I.6.7 DQ-Planung......................................................................95I.6.8 DQ-Projekte......................................................................96I.6.9 Kennzahlenformular.........................................................96I.6.10 Zusammenfassung............................................................97

II. Technische Umsetzung

Einleitung.......................................................................................100

II.1 VerbesserungderDatenqualitätimQuellsystem.........................103

II.1.1 VorbeugungvorneuenDatenqualitätsproblemen.......103II.1.2 Empfehlungen................................................................108

II.2 DataProfiling.................................................................................110

II.2.1 Data-Profiling-Prozess...................................................111II.2.2 ZusammensetzungdesData-Profiling-Teams..............113II.2.3 Data-Profiling-Verfahren...............................................114II.2.4 Empfehlungen.................................................................147

II.3 ErfolgreicheDatenvalidierungund-filterung..............................149

II.3.1 ValidierungaufvierEbenen...........................................149II.3.2 FilterungfehlerhafterDaten...........................................149II.3.3 ValidierungbeiExtraktionoderLaden.........................153II.3.4 ArtenderDatenvalidierung...........................................155II.3.5 ErstellungderValidierungsregelnundSpeicherung

derErgebnisse.................................................................157II.3.6 Empfehlungen.................................................................158

II.4 StandardisierungundBereinigung...............................................159

II.4.1 Standardisierung.............................................................159II.4.2 Datenbereinigung...........................................................161II.4.3 StandardisierungundBereinigungimETL-Prozess.....183II.4.4 VerfahrenfürnichtzubereinigendeDaten...................184II.4.5 Empfehlungen.................................................................184

II.5 Datenanreicherung........................................................................185

II.5.1 Wirtschaftsinformationen..............................................185II.5.2 GeografischeInformationen..........................................187II.5.3 SoziodemografischeInformationen..............................189II.5.4 Haushaltsbildung............................................................189

II.5.5 StandardszurKlassifizierungvonWarenund

Dienstleistungen.............................................................191II.5.6 Branchen-Klassifizierung...............................................194II.5.7 Empfehlungen.................................................................196

� Inhalt

Inhalt �

II.6 VerbesserungderDatenqualitätinderBereitstellungundVisualisierung.........................................................................197

II.6.1 BereitstellungderDaten.................................................197II.6.2 VisualisierungderInformation.....................................198II.6.3 Empfehlungen.................................................................213

II.7 WertschöpfungdurchMetadaten.................................................214

II.7.1 Metadaten:BegriffundStrukturierung........................214II.7.2 Metadaten-Architekturen...............................................216II.7.3 Metadaten-Management...............................................218II.7.4 Metadaten-Kategorien....................................................220II.7.5 ProblemebeiderErstellung:Motivation undAktualität.................................................................224II.7.6 NutzungvonMetadaten.................................................224II.7.7 Empfehlungen.................................................................226

II.8 DataQualityMonitoring..............................................................227

II.8.1 DQ-Messungund-Analyse............................................227II.8.2 Methoden........................................................................229II.8.3 Visualisierung..................................................................231II.8.4 BenachrichtigungundAktionen....................................235II.8.5 Verantwortlichkeiten......................................................235II.8.6 Zusammenfassung..........................................................235

II.9 Produktauswahlund-integration................................................236

II.9.1 AnbieterundProdukte...................................................236II.9.2 AuswahlkriterienimÜberblick......................................237II.9.3 FunktionaleKriterien.....................................................238II.9.4 Integration......................................................................241II.9.5 EinbeziehungderFachbereiche....................................242II.9.6 SprachenundLänder....................................................243II.9.7 EinbindunginDQM-Prozesse......................................243II.9.8 Empfehlungen................................................................243

III. Projektpraxis

Einleitung.......................................................................................246

III.1 DatenqualitätsmanagementineinerStudie.................................250

III.1.1 AnalysedesIst-Zustands................................................250III.1.2 EntwurfdesSoll-Konzepts.............................................259III.1.3 Bewertung.......................................................................264III.1.4 Umsetzungsplanung.......................................................264III.1.5 Empfehlungen.................................................................264

III.2 DatenqualitätsmanagementinderSpezifikation.........................265

III.2.1 SpezifikationderSchnittstellen......................................265III.2.2 DefinitionderRolleninderDatenorganisation...........266III.2.3 FestlegungderDatenqualitätsziele................................267III.2.4 BezeichnungundDefinitionderObjekte.....................270III.2.5 FestlegungderGeschäftsregeln......................................272III.2.6 MessungderQualitätvonDefinitionenund

Geschäftsregeln...............................................................273III.2.7 DataProfilinginderSpezifikation................................273III.2.8 EntwurfdesSystems.......................................................274III.2.9 Empfehlungen.................................................................277

III.3 DatenqualitätsmaßnahmeninderKonstruktionsphase.............278

III.3.1 ÜbertragungderDatenqualitätsziele.............................278III.3.2 KonventionenundRichtlinien.......................................278III.3.3 EntwurfdesSystems.......................................................279III.3.4 ErstellungeinesPrototypen...........................................285III.3.5 Empfehlungen.................................................................285

III.4 SteuerungderDatenqualitätinderRealisierung.........................286

III.4.1 EinhaltungderKonventionen,Richtlinien undKonzepte..................................................................286III.4.2 DataProfilinginderRealisierung.................................286III.4.3 EinbindungderDatenverantwortlichenund Benutzer..........................................................................287III.4.4 RealisierungderDatenqualitätsmaßnahmen................288III.4.5 DurchführungvonTests.................................................289III.4.6 Empfehlungen.................................................................289

III.5 SteuerungderDatenqualitätimBetrieb......................................290

III.5.1 MonitoringundBerichtswesen......................................290III.5.2 Ausbildung......................................................................292III.5.3 Empfehlungen.................................................................292

AnhangDieAutoren....................................................................................294

Abkürzungen.................................................................................296

Literaturverzeichnis.......................................................................297

Register...........................................................................................302

� Inhalt

Vorwort

Vorwort zur 2. Auflage

Die positive Resonanz auf die 1. Auflage und einige inhaltliche Erweiterungswünsche der Autoren haben zu einer schnellen 2. Auflage des vorliegenden Bandes über Datenqualitätsmanagement geführt. Neben kleinen Korrekturen wurden einige Passagen wie z. B. die Abhandlung über Metadaten oder Standardisierung vollständig überarbeitet. Die umfangreichste Ergänzung liegt sicherlich in der Hinzufügung einer konkreten Fallstudie in Buchteil III, was das Werk für BIProjekte nun noch interessanter macht. Es freut mich, dass der Erfolg der 1. Auflage die Autoren motiviert hat, sofort wieder zur Tastatur zu greifen und ihr profundes Fachwissen zusammenzutragen. Hierfür gebührt mein Dank den Herren Detlef Apel, Dr. Wolfgang Behme, Rüdiger Eberlein und Christian Merighi. Auch die Begleitung des Verlags muss positiv hervorgehoben werden, denn ohne Frau Sabine Baumgartner wäre die schnelle Veröffentlichung der 2. Auflage nicht möglich gewesen.

Den Leserinnen und Lesern lege ich die wesentlich erweiterte Version noch mehr ans Herz und hoffe, dass die Ausführungen zur Steuerung der Datenqualität in den Unternehmen Anklang finden. Univ.-Prof.Dr.PeterChamoni

Vorwort zur 1. Auflage

Das Thema Datenqualität hat eine hohe Relevanz in allen Einsatzgebieten der Informationsverarbeitung. Seit vielen Jahren ist die Problematik verfälschter, unzutreffender oder fehlender Daten und der daraus abgeleiteten Informationen ein großes Hindernis bei der Bearbeitung täglicher Aufgaben, und dies sowohl in Geschäftsprozessen wie auch in technischen Abläufen. Noch gravierender können Fehleinschätzungen oder Fehlinterpretationen bei strategischen Unternehmensentscheidungen ausfallen, wenn die zugrunde liegende Informationsbasis eine schlechte Datenqualität aufweist.

Eine Vielzahl von Beispielen belegt die fatalen Folgen von betrieblichen Fehlentscheidungen oder technischem Systemversagen, die der mangelnden Datenqualität zuzuschreiben sind. Hierbei sind es weniger die Defizite der automatisierten Verarbeitungsprozesse, sondern vielmehr die Unachtsamkeit oder fehlende Voraussicht der agierenden Menschen, die mit der Erfassung, Beschreibung, Verwaltung und Auswertung der Daten betraut sind. Damit kann die Bewältigung der Problematik um die Datenqualität in den Gesamtkontext des Qualitätsmanagements gesetzt werden. Weder theoretische noch praktische Ansätze lösen das Problem bisher befriedigend. Wissenschaftliche Ansätze analysieren das Phänomen der Qualitätsdefizite, weisen auf idealtypische Verhaltensmuster oder Verfahren der Qualitätssicherung hin und sind bestenfalls Referenz für die Einführung von umfassenden Qualitätssicherungsmaßnahmen. Im Gegensatz dazu greifen die praxisorientierten Problemlösungen nicht selten nur lokal und bekämpfen die Folgen, nicht die Ursachen der Datenqualitätsprobleme.

Die vorliegende Publikation setzt hier an, um die theoretischen Erkenntnisse mit den aus der Praxis erwachsenen Problemen der Datenqualität in Einklang zu bringen. Der spezielle Fokus liegt in der Betrachtung der Bereitstellung entscheidungsrelevanter Information für das Management. Dieser komplexe Prozess der Akquisition, Speicherung und Aufbereitung

�

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 beobachte-ten 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 Daten 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 Abbildung III.E.1):› Studie› Spezifikation› Konstruktion› Realisierung› Betrieb

▲ Abb.III.E.1:VerwendetesProjektmodell

246Projektpraxis

Studie Betrieb

Systemerstellung(oftinStufen)

Spezifikation

Konstruktion

Realisierung

Machbarkeitsicherstellen:

FunktionsumfangTechnikTerminKosten

Zie

l

SystemvisionGrobkonzeptProjektvorschlagggf.PrototypW

ich

tig

e Er

geb

nis

se

SpezifikationKonstruktionggf.PrototypProduktiveSoftware

KundenanforderungendetaillierenAnforderungenineinproduktivesSystemumsetzen

Log-DateienStatistiken

ReibungsloserBetriebFrühzeitigesErkennenvonProblemen

›

›

›

›

›

›

›

›

›

›

›

›

›

›

›

›

›

›

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 System-erstellung gewährleisten. Typische Ergebnisse sind Systemvision, Grobkonzept, Projektvor-schlag 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 des-sen, was die Lösung beinhaltet und was nicht. Sie bildet die Schnittstelle zwischen der Fach-abteilung, die das geplante System beurteilt, und dem Konstruktions- und Realisierungsteam, welches das System umsetzt.

Beschreibt die Spezifikation das „Was“, nämlich die fachliche Funktionalität eines Software-Systems, so legt die Konstruktion das „Wie“, die softwaretechnische Konzeption der BI-An-wendung 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.

Nach Abschluss der Integration folgt mit der Inbetriebnahme die Phase des Betriebs.

Um die Abbildung der einzelnen Phasen auf andere Vorgehensmodelle zu erleichtern, ist in Abbildung III.E.2 eine Zuordnung zu den „Engineering Disciplines“ des Rational-Unified-Prozesses (RUP)2 dargestellt. Die Phase „Studie“ kann nicht zugeordnet werden, da sie nicht zur Systemerstellung zählt.

▲ Abb.III.E.2:AbbildungderProjektphasenaufdenRUP

1 AuchSystemspezifikation,FachkonzeptoderAnalysegenannt.2 Vgl.Jacobson/Booch/Rumbaugh1999.

Einleitung247

RUP Engineering Disciplines Projekt-Phasen

BusinessModeling

Requirements

Analysis&Design

Implementation

Test

Deployment

Spezifikation

Konstruktion

Realisierung

Betrieb

Fallstudie: Fusion der Motorsport Engines AG und der Bike GmbH

In einer durchgängigen Fallstudie� werden über den gesamten Teil III die einzelnen Maß-nahmen zurVerbesserung der Datenqualität in den verschiedenen Phasen praxisorientiertdargestellt,umdemLeserdieUmsetzungineinemeigenenProjektzuerleichtern.

DasinternationaltätigeUnternehmenMotorsportEnginesAGhatvorkurzemdieBikeGmbHgekauft. Um am Markt als gemeinsames Unternehmen erfolgreich zu sein, müssen die ver-schiedenen Anwendungslandschaften und Systeme schnellstmöglich konsolidiert werden.Dennnurkonsistente,akkurateundunternehmensweiteStammdaten,diedasHerzstückallerGeschäftsprozessebilden,ermöglicheneineneinheitlichenBlickaufdenDatenbestand.IndenStammdatensteckendieKerninformationenüberMaterialien,Produkte,Lieferanten,VerträgeundKunden,ausdenensichspäterdieDatenhaltungs-undDatenverteilungsarchitekturfürdieKonzern-Stammdatenableitet.

DieMotorsportEnginesAGverwendetaktuellimEinkaufeinzentralesStammdatensystem,inderehemaligenBikeGmbHexistiertendagegenaushistorischenGründenzweiverschiedeneSysteme.DieAbwicklungderoperativenGeschäftsprozesseerfolgt jeweils ineinemeigenenERP-System.Somitistesderzeitnichtmöglich,eineinheitlichesBildüberdieVorgängeimEin-kaufzuerhalten.

In einem BI-Projekt bestehend aus den Teilprojekten Integration und Reporting soll das ManagementindieLageversetztwerden,mitHilfeeineseinheitlichenBerichtswesens(SpendManagement Reporting) das neu entstandene Unternehmen einkaufsseitig zu steuern. UmdasBeispielnichtzuumfangreichwerdenzu lassen, fokussiertsichderBI-TeilausschließlichaufdenKonzernbereichEinkauf,wohlwissend,dasszurUnternehmenssteuerungmehrSichtengehören.

Gerade in der Einkaufsabteilung offenbaren sich die großen Einsparungspotenziale einer Unternehmensfusion. Nach einer alten Kaufmannsregel entspricht ein Prozent EinsparungimEinkaufeinerAbsatzsteigerungvon18Prozent!SolcheEinsparungenlassensichdadurcherzielen,indemmanz.B.gleicheMaterialienoderDublettenbeidenLieferantenstammdatenkonzernweitidentifiziertundzusammenführt.DiedadurchmöglichenBündelungseffektefüh-rendazu,dassvoneinzelnenMaterialienhöhereVolumenbestelltwerdenkönnen,wasdemEinkaufhöhereRabattebeidenLieferanteneinbringt.DiesenEffekthatsicherlichjederschonimSupermarkterlebt:EineGroßpackungMargarineistkaumteureralseinekleinemitdeutlichwenigerInhalt.

UmdiesenEffektnutzenzukönnen,müssenindemTeilprojektIntegrationdiedreigenanntenStammdatensystemeineingemeinsamesZielsystemüberführtunddievorhandenenDatenmigriertundzusammengeführtwerden.UmdieseZielemöglichstzeitnaherreichenzukön-nen,wurdeseitensderMotorsportEnginesAGentschieden,dieoperativenSystemederbei-denUnternehmenvorerstunverändertzubelassenunddieIntegrationderDatenübereininderMotorsportEnginesAGbereitsvorhandenesDWHdurchzuführen.ParalleldazuwirdeinAuswahlprojektgestartet,dasdieSuchenacheinemoperativenZielsystemfürdasgemein-sameUnternehmenzurZielsetzunghat.

In einem ersten Schritt werden zunächst konzernweit gleiche Materialien oderTeile (soge-nannteGleichteile)aufgespürt.InderRegelgibtesaberindenverschiedenenSystemenkeinedafür notwendige eindeutige Materialnummer. Auch die Hersteller-Teilenummern sind inderPraxishäufignichtgepflegt,sodasseinaufwendigerAbgleichüberandereStammdaten-attributeerfolgenmuss.Selbst indenjeweiligenSystemenderMotorsportEnginesAGundderBikeGmbHexistierenvermutlichvieleGleichteileunterverschiedenenBezeichnungen.

� DieIdeezudieserFallstudiestammtausApel/Behme2010.

248Projektpraxis

IneinemzweitenSchrittwirddasEinkaufsvolumendesKonzernszusätzlichaufbestimmteMa-terialgruppenabgebildet,damitdieEinkäuferbeiRahmenverträgenmitihrenLieferanteneinebessereVerhandlungsgrundlagehaben.Ameinfachstenundbestengelingtdasmiteinerein-deutigen,hierarchischenKlassifizierungallerMaterialien.DieMotorsportEnginesAGhatinderVergangenheitkeinederimMarktvorhandenenKlassifikationengenutzt,sonderneineigenesKlassifikationsverfahrenentwickelt.DieBikeGmbHsetzthingegendievomBundesverbandfürMaterialwirtschaft,EinkaufundLogistikzusammenmiteinigenGroßkonzernenentwickelteKlassifikationeClass(sieheSeite192)ein.

ImRahmeneinerLieferantenstammdatenkonsolidierungwerdenimdrittenSchrittmehrfachindenSystemenvorkommendeLieferantenzueinemStammdatensatzzusammengefasst.Nurdamit gelingt es, eine zuverlässige Aussage über das gesamte Beschaffungsvolumen einesLieferantenzubekommen.ZusätzlichmüssendabeiKonzernverflechtungeninderLieferan-tenorganisationidentifiziertwerden,umalleUmsätzerichtigzuordnenzukönnen.

AusgehendvondiesenRahmenbedingungenwirdindenfolgendenKapitelndargestellt,wiedieeinzelnenMaßnahmenzurVerbesserungderDatenqualität fürdiesesPraxisbeispielkon-kretgestaltetwerden(jeweilsgekennzeichnetdurcheinengrauenKasten).

Einleitung249

III.1 DatenqualitätsmanagementineinerStudie

Eine Studie zu erstellen ist eine komplexe, zielgerichtete und strukturierte Aufgabe, die aus vier Teilschritten besteht:1. Ist-Zustand analysieren,2. Soll-Konzept entwerfen,3. Bewertung und Empfehlung abgeben und4. Umsetzung planen.

Die Ergebnisse einer Studie dienen in der Regel zur Entscheidungsfindung; sie sind die Aus-gangsbasis 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 Spezifi-kation unterscheiden, ist in Kapitel III.2 erläutert.

Studien4 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 Ak-tivitä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 die Aspekte beschrieben, die die Datenqualität be-treffen.

III.1.1 AnalysedesIst-Zustands

IdentifikationderQuellsystemeAls Erstes werden die Quellsysteme mit ihren Datenbeständen identifiziert, die bei der nach-folgenden (Weiter-)Entwicklung der BI-Anwendung verwendet werden sollen. Dies ge-schieht 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.

� z.B.AgensConsulting,2007.

250Projektpraxis

DatenqualitätsmanagementineinerStudie251

DatenquellenOperativeSysteme

MotorsportEnginesAG

StammdatenEinkaufA(Alpha)

Material Lieferant Kunde

BikeGmbH

StammdatenEinkaufB(Bravo)

Material Lieferant Kunde

Stammdaten

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 häufig eine unzureichende Daten-qualität und sind nicht hinreichend dokumentiert.

Häufig 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.

IneinemWorkshopidentifiziertdasTeamdesTeilprojekts IntegrationalsErstesdieSystemederbeidenUnternehmen,welchediezuintegrierendenStammdatenzuMaterialienundLie-ferantenenthalten.DieMotorsportEnginesAGhältdieStammdatenzuMaterialienundLiefe-rantenimStammdatensystemAlpha.BeiderBikeGmbHliegenalleStammdatenzuMaterialienundLieferanten imStammdatensystemBravo. InanschließendenBefragungenundRecher-chenwurdeerfolgreichvalidiert,dassdiebeidenSystemedieeinzigenmitdiesenStammdatensindundkeineweiterenDatenausanderenSystemenintegriertwerdenmüssen.

▲Abb.III.1.1:QuellsystemefürdieStammdaten

InderTabelleIII.1.1istamBeispielderMaterialstammdatenzuerkennen,dasssichdieStruktu-renderDatenindenStammdatensystemenderbeidenUnternehmenunterscheiden.DiesgibtdemTeameinenerstenFingerzeigaufdieimTeilprojektIntegrationnotwendigenDateninte-grationsprozesse.

252Projektpraxis

StammdatensystemAlpha StammdatensystemBravo

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

▲Tab. III.1.1: Vergleich der Materialdatenstrukturen der Stammdatensysteme Alpha und Bravo

SuchenachdenDatenverantwortlichenIn einem Unternehmen mit einer zentralen Data-Governance-Organisation (siehe Kapi-tel I.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 Daten-bestä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 Daten-verantwortlichen zu identifizieren. Die fachlichen Datenverantwortlichen informieren über die fachliche Bedeutung der Daten, die zugehörigen Geschäftsprozesse und die an der Daten-erfassung beteiligten Systeme. Ergänzend erklären die technischen Datenverantwortlichen Struktur und Qualität der Daten sowie den geplanten Bereitstellungsprozess (z. B. Aktualisie-rungsrhythmus, Bereitstellungszeitpunkt, Datenvolumen).


ID System Datenob-jekt Standort Art,Name Verantwortlich

(fachl.)Verantwortlich

(techn.) Bemerkung

1 IKARUS LieferungenServer:

mucdb1,SID:ad10

Tabelle,T_LIEFE-RUNGEN

PeterMüller,Abt.II.1

BrancoSippel,Abt.V.�

2 – Absatz-planung

Server:bnfs1,d:\ablage\

II.1\

Excel-Mappe,

Absatz_p_mmyy.xls

DirkSchuster,Abt.II.�

FrankFörster,Abt.II.�

proMonateineDatei

… … … … … … … …

Die Ergebnisse werden dokumentiert (siehe Abbildung III.1.2): Sie bilden die Grundlage für weitere Informationen, die in den nachfolgenden Schritten und Projektphasen hinzu-kommen.

▲ Abb. III.1.2:TabellemitÜbersichtderDatenverantwortlichen(Beispiel)

WennmandieZielsetzungdiesesPraxisbeispiels imAugebehält, sinddiehierzubetracht-enden Daten in erster Linie die Material- und die Lieferantenstammdaten. Die relevantenDatenquellen sind daher die Systeme A (Alpha) und B (Bravo). Das Quellsystem C beinhal-tetKundendaten,die fürdiesesvonderEinkaufsabteilunggeplanteProjektkeineunmittel-bare Berücksichtigung finden. Dies zeigt auch gleich eine erste Problematik auf, die in Pro-jekten,dieauseinereinzelnenAbteilungssichtherausgestartetwerden,regelmäßigauftritt: Eswerdenhier inersterLinieDatenderEinkaufsabteilunganalysiertundqualitätsgesichert,währenddieKundendatenkeineBeachtung finden.Es istaber festzuhalten,dasseineKun-denkonsolidierungausKonzernsichtallerhöchstePrioritäthabenmuss,dadienachfolgendenSchritteundAktivitätenanalogfürKundendatendurchzuführensind.

Nachdem die Quellsysteme der beiden Unternehmen identifiziert sind, müssen schnell diefachlichenundtechnischenVerantwortlichendieserDatenquellengefundenwerden.DerAus-gangspunkt fürdieSuchenachdenDatenverantwortlichen inbeidenUnternehmen istdieFragenacheinerbestehendenData-Governance-Organisation.ErgebnisdieserUntersuchungist,dassdieBikeGmbHbereitsvor längererZeiteineDataGovernancefürdieQuellsystemeimplementierthat.EswurdeeinerseitseinunternehmensweitverantwortlicherDataQualityManager installiertsowieandererseitsDatenverantwortlichefürdieeinzelnenQuellsystemebenannt.DieseDatenverantwortlichensitzen indenverschiedenenFachabteilungen. InderEinkaufsabteilungderBikeGmbHgibtessomitDatenverantwortlichefürdieMaterial-undLie-ferantenstammdatendesQuellsystemsB.DieAufgabederDatenverantwortlicheninderBikeGmbHistdiemonatlichestandardisiertePrüfungderDatenqualitätindenQuellsystemenundeineBerichterstattungandenDataQualityManager.ErkonsolidiertdieBerichteallerQuell-systemeundberichtetdieseandenDQ-Lenkungsausschuss,derausdenAbteilungsleiternderBikeGmbHbesteht. ImLenkungsausschusswerdenimBedarfsfallMaßnahmenbeschlossen,die vom Data Quality Manager vorgeschlagen wurden. Neben den Abläufen zur laufendenQualitätssicherunghatdieBikeGmbHaucheinformalesAnforderungs-undProblemmanage-mentdefiniert.

25�Projektpraxis

InderMotorsportEnginesAGexistiertdagegenkeineformaleDataGovernance.DieVerant-wortungzurDatenqualitätssicherungistdenAbteilungsleiternderFachabteilungenbzw.derITüberlassen.DiesereagierenmeisterstbeimAuftauchenvonDatenqualitätsproblemen, in-demsie ihreMitarbeiteradhocfürdieLösungderProblemeverantwortlichmachen.DiesesVorgehenführtauchdazu,dasseskeineabteilungsübergreifendeKommunikationvonDaten-qualitätsproblemeninderMotorsportEnginesAGgibt.

Die technischen Systemverantwortlichen sind im Gegensatz zu den fachlichen Datenver-antwortlichen in beiden Unternehmen klar definiert. In den IT-Abteilungen der Motorsport EnginesAGundderBikeGmbHgibtes technischeSystemverantwortliche fürdiehier rele-vantenQuellsystemeAundB,dieallerdingskeineformaleVerantwortungfürdieDatenquali-tätssicherungbesitzen.

DiepotenzielleDatenorganisationinnerhalbderbestehendenBI-Systeme(DWH/Berichtssys-teme)wirdinAbschnitt III.2.2genauerbetrachtet.Es isthierallerdingsfestzuhalten,dassdiefachlichenDatenverantwortlichenderQuellsystemeimRegelfall indieDatenqualitätssiche-rungderBI-Systemeinvolviertseinmüssenbzw.dieVerantwortungfürdieQualitätssicherungindenBI-Systemeninnehabensollten.

NichtzuvergessenistindiesemZusammenhangauchdieSuchenacheinemSponsor,derhin-terdemProjektstehtbzw.dereinunmittelbaresInteresseandemProjekterfolghat.ImIdealfallistdasbereitsvordemStartderStudieerfolgt,allerdings istdies imZugederStudienocheinmalfürdasgesamtefolgendeProjektzubestätigen.DerSponsorsollteinjedemFalleineC-Level-Positioninnehaben.IndiesemBeispielkonntejenerVorstandalsSponsorgewonnenwerden,demdieEinkaufsabteilungderMotorsportEnginesAGunterstelltist.

QualitativeAnalysederQuellsysteme› AnalysederMetadatenWie notwendig und nützlich Metadaten für das Verständnis der Daten sind, wurde in Kapi-tel II.7 dargelegt. Aus diesen Gründen sind auch die Metadaten in der Ist-Analyse zu suchen, zu analysieren und zu dokumentieren.

Ein zentrales Metadaten-Repository erleichtert diese Suche. Da es dieses in den meisten Unter-nehmen 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 ge-nannt, 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 (si-ehe Abbildung III.1.3). Die Tabelle enthält das Feld „Bemerkung“ für wichtige Zusatzinfor-mationen: 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 Referenzierung� auf die Quellsysteme und Datenbestände in Abbil-dung III.1.2, mit der z. B. die Vollständigkeit überprüft werden kann.

5 ImFeldSYSTEM/DATENOBJEKT.


▲ Abb.III.1.3:TabellemitÜbersichtüberdieMetadaten-Quellen(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 Meta-daten 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 Meta-daten kommen hinzu, die Analysen werden feiner.

Mit Hilfe 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 notwen-digen Datenqualitätsmaßnahmen ableiten.

MetadatenzudenimEinkaufverwendetenStammdatensystemensindvorhanden.BereitsaufdenerstenBlick(sieheTabelleIII.1.1)lassensicheinigeErkenntnissebeschreiben:

› DieBezeichnerindenStammdatensystemenbeiderUnternehmenweichenstarkvoneinan-derab.EsgibtzahlreicheSynonyme.

› AuchinhaltlichweichenvieleDatenfeldervoneinanderab,insbesonderebeiDateninhalten,dieineinerMaßeinheitangegebenwerden.

› EinigeAngaben,z.B.dieMaterialgruppen,lassensichnichtohneWeiteresaufeinanderabbilden.

› DokumentationbekannterDatenqualitätsproblemeIn 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ät-zen 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 durch-zufü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 voll-ständig darstellen können. Sie helfen aber den Teilnehmern, sich auf den Workshop vorzu-bereiten. Denn auch hier gilt: Ohne Vorbereitung ist kaum ein Teilnehmer in der Lage, einen hinreichenden Beitrag zum Ergebnis zu liefern.

ID System/Datenobjekt Bezeichnung Version/

Datum Ablageort Art Kontakt-person Bemerkung

1 IKARUS,Lieferungen

PhysikalischesDatenmodell

2.6/15.0�.2006

x:\Ablage\Doku,DM_

IKARUS_26.erx

Daten-modell

FredKam-per,Abt.V.�

CR2958nichtein-gearbeitet

… … … … … … … …

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 Analy-sen (z. B. durch Data Profiling).

QuantitativeAnalysederQuellsystemeHat man sich in den qualitativen Analysen einen ersten Eindruck, ein „Bauchgefühl“, hin-sichtlich 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 Kapitel II.2). 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-Projekt beginnen, ohne einen vali-den Zustand von der Qualität der Quelldaten zu haben. Ansonsten wird schon die Projekt-planung 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:1. ein Data Profiling hinsichtlich der bekannten Datenqualitätsprobleme und2. ein allgemeines Data Profiling.

Beim Data Profiling hinsichtlich der bekannten Datenqualitätsprobleme werden die bei der qualitativen Analyse der Quellsysteme dokumentierten Datenqualitätsprobleme vali-diert. Dazu wird für einen realen Datenbestand überprüft, ob die vermuteten Qualitätspro-bleme 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 Quali-tä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. Ansonsten überträgt sich die geringe Glaubwürdigkeit der Daten aus dem Quellsystem negativ auf die Daten in der BI-Anwendung.

256Projektpraxis


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 Dis-kussionen 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 Soll-Konzept ent-worfen werden.

Das allgemeine Data Profiling hat die Aufgabe, bisher nicht bekannte Datenqualitätsprobleme frühzeitig zu identifizieren. Es empfiehlt sich, ein Timeboxing-Verfahren� einzusetzen, da aus Ressourcengründen in dieser Phase keine vollständige Analyse des Datenbestandes möglich ist. Der Erfolg der Analyse hängt sowohl von der Erfahrung und dem Gespür des Data-Pro-filing-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?

DasTeilprojektteamIntegrationführtedasDataProfilingfürdieMaterial-undLieferantendatenausdenStammdatensystemenwievorgeschlagenimTimeboxing-Verfahrendurch(Dauer:1Tag).

Spalten%derNullen

%dereindeutigenWerte

Minimum Maximum

Artikelnummer 0,5% 99,2% 13825 82703512

Artikelgruppe 3,7% 31,1% 1 Z9959

Bestellnummer 6,3% 99,5% 1-�52�3�3�-8 999-�5322-23�5

Breite_in_cm 50,5% 27,�% -56 925366�7�8585

Mindestmenge 1,5% 53,9% 0 200.001

▲Tab. III.1.2: Teilergebnis (Auszug) des Data Profiling der Materialdaten im Stamm-datensystem Bravo (Aggregation)

AusdenErgebnissenderData-Profiling-Analyse(Aggregation)derMaterialdatenimStammda-tensystemBravolassensichfolgendeAuffälligkeitenerkennen:

› Artikelnummer:NichtalleDatensätze(0,5Prozent)besitzeneineArtikelnummerundeinigeArtikelnummern(0,8Prozent)sindmehrfachvorhanden.DamitistdieArtikelnummerinderaktuellenQualitätnichtzureindeutigenIdentifizierungeinesArtikelsgeeignet.

› Artikelgruppe: Es fehlt in einigen Datensätzen (3,7 Prozent) die Angabe zur zugehörigenArtikelgruppe.Somit isteineAggregationvonArtikelnzurnächsthöherenHierarchiestufe„Artikelgruppe“ vermutlich fehlerhaft, da Artikel ohne Artikelgruppe nicht berücksichtigtwerden.

6 DauerundRessourceneinsatzsindfestgeschrieben.

258Projektpraxis

› Bestellnummer:AuchhierfehltdieBestellnummerbeieinigenDatensätzen(6,3Prozent). DaserschwertBestellungen,dafürdieseMaterialiendieBestellnummerbeimLieferantenmanuellermitteltwerdenmuss.

› Breite_in_cm: Bei 50,5 Prozent der Datensätze fehlt die Breitenangabe und der minimaleWertistnegativ.DurchdiefehlendeBreitenangabewirdderSupply-Chain-Prozessbehindert,dadasVolumendesMaterialsnichtermitteltwerdenkann.DernegativeWertlässtaufFehl-eingabenbeiderDatenerfassungschließen.

› Mindestmenge:WieauchbeidenanderenSpaltenistdiesebeieinigenDatensätzennichtgefüllt(1,5Prozent),zusätzlichlässtder„krumme“Maximalwert(200.001)wiebeiderBreiteaufeinefehlerhafteDatenerfassungschließen.

Die Teilergebnisse der anschließend durchgeführten Genauigkeitsanalyse für die Spalte MINDESTMENGEsindinTabelleIII.1.3dokumentiert.Darinistzuerkennen,dassdieWerte11,2007und200001vermutlichdurchFehleingabenbeiderErfassungeingetragenwurden.

Wert AnzahlZeilen

0 6�3

1 932�

10 5286

11 5

100 81�63

1000 �3663

2000 635�

2007 2

10000 99262

100000 230

200000 318

200001 1

▲Tab. III.1.3: Ergebnis des Data Profiling der Spalte MINDESTMENGE der Materialdaten im Stammdatensystem Bravo (Genauigkeitsanalyse)

› AbgleichderDatenDie 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 Diskre-panzen frühzeitig innerhalb der Studie, können die erforderlichen Änderungen in den Quel-len 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ög-lichkeit, 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?

Eine weitere zu klärende Frage ist die zeitliche Verfügbarkeit zusammenhängender Quell-daten: 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?

› AnalysederAnwendungslandschaftBevor man das Soll-Konzept 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 Soll-Konzepts zu überprüfen, ob sich die eingesetzten Werkzeuge eignen. Natürlich sind auch Synergie-Effekte 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 Daten-qualitä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 Pro-jektmitarbeitern weitere, bislang unbekannte Informationen, z. B. Hinweise auf bestehende Unternehmensstandards oder Konzepte zum Datenqualitätsmanagement.

› AnalysedertechnischenArchitekturIn diesem Schritt wird die bestehende technische Architektur analysiert, um daraus Vorgaben für den Entwurf des Soll-Konzepts zu gewinnen. Bei der Weiterentwicklung einer bestehen-den BI-Anwendung werden die vorhandene Architektur und bestehende Architekturkon-zepte auf die Problemstellen hinsichtlich der Datenqualität (siehe Abschnitt I.�.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.

III.1.2EntwurfdesSoll-Konzepts

› QualitativeAnalysedesZielsystemsZunä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.

Documents

DATENQUALITÄT ERFOLGREICH STEUERN · 2010-10-14 · maßnahmen. Im Gegensatz dazu greifen die praxisorientierten Problemlösungen nicht selten nur lokal und bekämpfen die Folgen,