Boris Otto und Hubert Österle

Corporate Data QualityVoraussetzung erfolgreicher Geschäftsmodelle1. Aufl. 2016

Boris Otto

Fraunhofer Institut für Materialfluss und Logistik, Dortmund, Deutschland

Hubert Österle

Business Engineering Institute St. Gallen, St. Gallen, Schweiz

ISBN 978-3-662-46805-0e-ISBN 978-3-662-46806-7

DOI 10.1007/978-3-662-46806-7

Springer Gabler

© Der/die Herausgeber bzw. der/die Autor(en) 2016

Das Buch wurde Open Access veröffentlicht unter SpringerLink.com.

Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.

Open Access Dieses Buch wird unter der Creative Commons Namensnennung-Nicht kommerziell 4.0 International Lizenz (http://creativecommons.org/licenses/by-nc/4.0/deed.de) veröffentlicht, welche für nicht kommerzielle Zwecke die Nutzung, Vervielfältigung, Bearbeitung, Verbreitung und Wiedergabe in jeglichem Medium und Format erlaubt, sofern Sie den/die ursprünglichen Autor(en) und die Quelle ordnungsgemäß nennen, einen Link zur Creative Commons Lizenz beifügen und angegeben, ob Änderungen vorgenommen wurden. This book is distributed under the terms of the Creative Commons Attribution Noncommercial License, which permits any noncommercial use, distribution, and reproduction in any medium, provided the original author(s) and source are credited.

Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Jede kommerzielle Verwertung, die nicht ausdrücklich vom Urheberrechtsgesetz zugelassen ist, bedarf der vorherigen Zustimmung des Verlags. Das gilt insbesondere für Vervielfältigungen, Bearbeitungen, Übersetzungen, Mikroverfilmungen und die Einspeicherung und Verarbeitung in elektronischen Systemen....

Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten wären und daher von jedermann benutzt werden dürften.

Der Verlag, die Autoren und die Herausgeber gehen davon aus, dass die Angaben und Informationen in diesem Werk zum Zeitpunkt der Veröffentlichung vollständig und korrekt sind. Weder der Verlag noch die Autoren oder die Herausgeber übernehmen, ausdrücklich oder implizit, Gewähr für den Inhalt des Werkes, etwaige Fehler oder Äußerungen.

Gedruckt auf säurefreiem und chlorfrei gebleichtem Papier

Springer Berlin Heidelberg ist Teil der Fachverlagsgruppe Springer Science+Business Media (www.springer.com)

Vorwort

Die Digitalisierung bringt einen Umbruch für Wirtschaft und Gesellschaft. Die Daten werden noch mehr als bereits heute eine strategische Ressource für Unternehmen, für staatliche Organisationen und für das Individuum. Nur wenn Daten zu Kunden und Produkten, aber auch Kontextangaben zum Aufenthaltsort, zu Präferenzen und zur Abrechnung in hoher Qualität vorhanden sind, können Unternehmen digitale Dienste anbieten, die das Leben erleichtern, neue Geschäftschancen eröffnen oder Abläufe zwischen Unternehmen einfacher und schneller machen.

Corporate Data Quality als Voraussetzung erfolgreicher Geschäftsmodelle: Das ist und war das Leitbild des Kompetenzzentrums Corporate Data Quality (CC CDQ). Das CC CDQ ist ein Konsortialforschungsprojekt, in dem seit dem Projektstart im Herbst 2006 mehr als hundert Mitarbeiter von über 30 großen Unternehmen in über 40 zweitägigen Konsortialworkshops und mehr als 200 Projektterminen gemeinsam mit Forschern der Universität St. Gallen und von Fraunhofer IML an Lösungen und Methoden für Corporate Data Quality arbeiten. Die Inhalte dieses Buchs sind fast ausnahmslos im Rahmen des CC CDQ entstanden.

Das Buch richtet sich an drei Gruppen von Lesern. Zum einen möchte es Projekt- und Linienverantwortlichen beim Aufbau und bei der Weiterentwicklung des unternehmensweiten Datenqualitätsmanagements Unterstützung bieten. Zum anderen möchte es Studierenden sowie auch Lehrenden an Hochschulen und Universitäten die Grundzüge des Datenqualitätsmanagements als Unternehmensfunktion vermitteln und einen Pool an Fallstudien an die Hand geben. Und drittens bereitet es für die anwendungsinteressierten Forscher die wesentlichen Konzepte aus Forschung und Praxis auf.

Die Inhalte in diesem Buch bilden den Kern der Ergebnisse des CC CDQ. Sie vermitteln anhand von Beispielen aus der Praxis einen Überblick über die wichtigsten Themen zu Corporate Data Quality. Zu allen Fragen gibt es weiterführendes Material, auf das im Buch immer wieder verwiesen wird.

Ohne das Zusammenwirken verschiedener Kompetenzen und Erfahrungen einer Vielzahl von Menschen wäre dieses Buch nicht zustande gekommen. Dank gebührt den Vertretern der Partnerunternehmen des CC CDQ für das aktive Mitwirken am Konsortialforschungsprozess. Sie haben die Probleme ihrer Unternehmen offen diskutiert, gemeinsam mit den Forschern Lösungen entwickelt, diese in der Unternehmenspraxis erprobt und damit dafür gesorgt, dass die Forschungsarbeit immer Spaß gemacht hat. Auch danken wir allen wissenschaftlichen Mitarbeiterinnen und Mitarbeitern, die mit ihrer Leidenschaft und ihrem Einsatz in ihren Dissertationsvorhaben zum Erfolg des CC CDQ beigetragen haben. Unter ihnen gilt besonderer Dank Rieke Bärenfänger, ohne deren Sorgfalt und Zielstrebigkeit dieses Buch nicht zustande gekommen wäre.

Uns macht Corporate Data Quality seit mehr als acht Jahren viel Freude. Viel Freude wünschen wir ebenso allen Leserinnen und Lesern.

Boris Otto

Hubert Österle

Abkürzungsverzeichnis

API

Application Programming Interface

BE

Business Engineering

CAD

Computer-aided Design

CC CDQ

Kompetenzzentrum Corporate Data Quality

CDL

Corporate Data League

CDQM

Corporate Data Quality Management

CIQ

Customer Information Quality

COO

Chief Operating Officer

CRM

Customer Relationship Management

CRUD

Create, Read, Update, Delete (Datenzugriffsoperationen)

d. h.

das heißt

DAMA

Data Management Association

DQM

Datenqualitätsmanagement

DUNS

Data Universal Numbering System

EFQM

European Foundation for Quality Management

ERP

Enterprise Resource Planning

GS1

Globale Standards One

GTIN

Global Trade Item Number

IRR

Internal Rate of Return (Interner Zinsfuß)

IS

Informationssystem

ISO

Internationale Organisation für Normung

IT

Informationstechnologie

LCC

Lifecycle Costing

MDM

Master Data Management (Stammdatenmanagement)

NPV

Net Present Value (Kapitalwert)

o. a.

oben angeführt

OMG

Open Management Group

p. a.

per annum (pro Jahr)

PIM

Product Information Management

PLM

Product Lifecycle Management

ROI

Return on Investment

SBVR

Semantics of Business Vocabulary and Rules

SCM

Supply Chain Management

TCO

Total Cost of Ownership

TQM

Total Quality Management

u. a.

unter anderem

wiss.

Wissenschaftlich/Wissenschaft

xAL

Extensible Address Language

z. B.

zum Beispiel

Inhaltsverzeichnis

1 Datenqualität – eine Managementaufgabe

1.1 Trends der Digitalisierung

1.1.1 Durchdringung aller Lebens- und Wirtschaftsbereiche

1.1.2 Industrie 4.0

1.1.3 Konsumerisierung

1.1.4 Digitale Geschäftsmodelle

1.2 Treiber der Datenqualität

1.2.1 360-Grad-Blick auf den Kunden

1.2.2 Unternehmenszukäufe und -zusammenschlüsse

1.2.3 Compliance

1.2.4 Berichtswesen

1.2.5 Operational Excellence

1.2.6 Datensicherheit und Privatheit

1.3 Herausforderungen und Anforderungen des Datenqualitätsmanagements

1.3.1 Herausforderungen im Umgang mit Daten

1.3.2 Anforderungen an das Datenqualitätsmanagement

1.4 Framework für Stammdatenqualitätsmanagement

1.4.1 Framework-Überblick

1.4.2 Strategieebene

1.4.3 Organisatorische Ebene

1.4.4 Informationssystemebene

1.5 Begriffsdefinitionen und Grundlagen

1.5.1 Daten und Information

1.5.2 Stammdaten

1.5.3 Datenqualität

1.5.4 Datenqualitätsmanagement (DQM)

1.5.5 Geschäftsregeln (Business Rules)

1.5.6 Data Governance

1.6 Kompetenzzentrum Corporate Data Quality

Literatur

2 Fallstudien zur Datenqualität

2.1 Allianz: Data Governance und Datenqualitätsmanagement in der Versicherungswirtschaft

2.1.1 Unternehmensüberblick

2.1.2 Ausgangssituation und Handlungsdruck

2.1.3 Das Solvency-II-Projekt

2.1.4 Datenqualitätsmanagement bei AGCS

2.1.5 Erkenntnisse

2.1.6 Weiterführendes Material

2.2 Bayer CropScience: Datenqualitätscontrolling in der agrochemischen Industrie

2.2.1 Unternehmensüberblick

2.2.2 Ausgangssituation und Handlungsdruck

2.2.3 Aufbau des unternehmensweiten Datenqualitätsmanagements

2.2.4 Erkenntnisse

2.2.5 Weiterführendes Material

2.3 Beiersdorf: Produktdatenqualität in der Konsumgüter-Supply Chain

2.3.1 Unternehmensüberblick

2.3.2 Ausgangssituation des Datenmanagements

2.3.3 Projekt zur Messung der Datenqualität

2.3.4 Erkenntnisse

2.3.5 Weiterführendes Material

2.4 Bosch: Datenarchitekturmanagement in einem diversifizierten Technologiekonzern

2.4.1 Unternehmensüberblick

2.4.2 Ausgangssituation und Handlungsdruck

2.4.3 Datenarchitekturmuster bei Bosch

2.4.4 Erkenntnisse

2.4.5 Weiterführendes Material

2.5 Festo: Unternehmensweites Produktdatenmanagement in der Automatisierungsindustrie

2.5.1 Unternehmensüberblick

2.5.2 Ausgangssituation und Handlungsdruck des Produktdatenmanagements

2.5.3 Projekte im Produktdatenmanagement zwischen 1990 und 2009

2.5.4 Aktuelle Aktivitäten und Ausblick

2.5.5 Erkenntnisse

2.5.6 Weiterführendes Material

2.6 Hilti: Durchgängiges Kundendatenmanagement in der Werkzeug- und Befestigungsindustrie

2.6.1 Unternehmensüberblick

2.6.2 Ausgangssituation des Kundendatenmanagements und Handlungsdruck

2.6.3 Das Projekt Customer Data Quality Tool

2.6.4 Erkenntnisse

2.6.5 Weiterführendes Material

2.7 Johnson & Johnson: Institutionalisierung des Stammdatenmanagements in der Konsumgüterindustrie

2.7.1 Unternehmensüberblick

2.7.2 Ausgangssituation des Datenmanagements im Bereich Consumer Products und Aktivitäten bis 2008

2.7.3 Die Einführung von Data Governance

2.7.4 Aktuelle Situation

2.7.5 Erkenntnisse

2.7.6 Weiterführendes Material

2.8 Lanxess: Business Intelligence und Stammdatenmanagement bei einem Spezialchemiehersteller

2.8.1 Unternehmensüberblick

2.8.2 Ausgangssituation des Datenmanagements und Business Intelligence 2004–2011

2.8.3 Das Stammdatenmanagement bei Lanxess seit 2011

2.8.4 Aufbau des strategischen Reportings seit 2012

2.8.5 Erkenntnisse

2.8.6 Weiterführendes Material

2.9 Shell: Datenqualität im Produktlebenszyklus in der Mineralölindustrie

2.9.1 Unternehmensüberblick

2.9.2 Ausgangssituation und Handlungsdruck

2.9.3 Durchgängiges Datenmanagement im Produktlebenszyklus

2.9.4 Herausforderungen bei der Umsetzung

2.9.5 Nutzen der neuen Lösung

2.9.6 Erkenntnisse

2.9.7 Weiterführendes Material

2.10 Syngenta: Auslagerung von Datenmanagementaufgaben in der Pflanzenschutzindustrie

2.10.1 Unternehmensüberblick

2.10.2 Ausgangssituation und Ziele der Stammdatenmanagementinitiative

2.10.3 Das Transformationsprojekt und MDM-Designprinzipien

2.10.4 Organisationsstruktur des Stammdatenmanagements

2.10.5 Datenpflegeprozess und Entscheidungskriterien für die Auslagerung

2.10.6 Erkenntnisse

2.10.7 Weiterführendes Material

Literatur

3 Methoden und Werkzeuge des Datenqualitätsmanagements

3.1 Methode zur Umsetzung der DQM-Strategie

3.1.1 Aufbau der Methode

3.1.2 Beispieltechniken der Methode

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

3.2.1 Ausgangssituation in Unternehmen

3.2.2 Reifegradmodelle und Benchmarking als Steuerungsinstrumente

3.2.3 EFQM-Exzellenzmodell für das Stammdatenqualitätsmanagement

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

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

3.3.1 Herausforderungen der Geschäftspartnerdatenpflege

3.3.2 Der Lösungsansatz des kooperativen Datenmanagements

3.3.3 Die Corporate Data League

3.4 Weitere Methoden und Werkzeuge des CC CDQ

Literatur

4 Erfolgsfaktoren und Sofortmaßnahmen

4.1 Erfolgsfaktoren des Datenqualitätsmanagements

4.2 Sofortmaßnahmen auf dem Weg zum erfolgreichen Datenqualitätsmanagement

Glossar

Sachverzeichnis

Abbildungsverzeichnis

Abb. 1.1 Megatrends der Digitalisierung. (eigene Darstellung)

Abb. 1.2 Online-Aktivitäten für private Zwecke in den letzten drei Monaten

Abb. 1.3 Datenerfassung an der Schnittstelle zwischen virtueller und physischer Welt

Abb. 1.4 Intelligenter Behälter „InBin“

Abb. 1.5 Zehn Lebensbereiche und Beispiele für ihre digitalen Services

Abb. 1.6 Netzwerkanalyse der Produktinformationsflüsse bei Beiersdorf

Abb. 1.7 Digitale Geschäftsmodelle

Abb. 1.8 Eckdaten zum zentralen System GLOBE bei Nestlé

Abb. 1.9 Datenqualitätsherausforderungen beim Kundenumsatz-Reporting bei ZF Friedrichshafen

Abb. 1.10 Geschäftsprozessprobleme durch schlechte Datenqualität bei Johnson & Johnson

Abb. 1.11 Framework für unternehmensweites Datenqualitätsmanagement

Abb. 1.12 Begriffslandkarte für das Datenqualitätsmanagement

Abb. 1.13 Übersicht der logischen Datenorganisation

Abb. 1.14 Typischer Datenqualitätsverlauf über die Zeit in Unternehmen

Abb. 1.15 Datenqualitätskosten

Abb. 1.16 Datenqualitätsmanagement und Data Governance

Abb. 1.17 Konsortialforschung

Abb. 2.1 Solvenzkapitalstruktur nach Säule 1 von Solvency 2

Abb. 2.2 Zusammenspiel der Rollen im Datenqualitätsmanagement bei AGCS

Abb. 2.3 DMAIC-Zyklus des Datenqualitätsmanagements bei AGCS

Abb. 2.4 Datenqualitätsüberwachung bei AGCS aus Datenkonsumentensicht ( links ) und Datenquellensicht ( rechts )

Abb. 2.5 Datenqualitätsbericht bei AGCS

Abb. 2.6 Future System Landscape-Projekt bei Bayer CropScience

Abb. 2.7 Bedeutung der Qualität von Produkthierarchiedaten für Geschäftsprozesse bei Bayer CropScience

Abb. 2.8 Ursachen von Datenqualitätsproblemen bei Bayer CropScience

Abb. 2.9 Beispiele für Datenqualitätsregeln bei Bayer CropScience

Abb. 2.10 Systemarchitektur des Data Quality Cockpit bei Bayer CropScience

Abb. 2.11 Datenqualitätsmessung bei Bayer CropScience

Abb. 2.12 Datenqualitätsanalyse nach Landesgesellschaft bei Bayer CropScience

Abb. 2.13 Verletzte Datenqualitätsregeln auf Datensatzebene bei Bayer CropScience

Abb. 2.14 Organisationsstruktur von Beiersdorf und Berichtsweg des Datenprozessmanagement

Abb. 2.15 Produktdatenaustausch im Ökosystem von Beiersdorf

Abb. 2.16 Stammdatenflüsse innerhalb der Anwendungslandschaft von Beiersdorf

Abb. 2.17 Geschäftsbereiche der Bosch-Gruppe

Abb. 2.18 Ordnungsrahmen des Stammdatenmanagements bei Bosch

Abb. 2.19 Entwurfsprinzip für die Datenarchitektur bei Bosch

Abb. 2.20 Datenarchitekturmuster bei Bosch

Abb. 2.21 Festo innovation network

Abb. 2.22 Prozessmodell bei Festo

Abb. 2.23 Produktdatenmanagement bei Festo

Abb. 2.24 Systemarchitektur für Produktdaten

Abb. 2.25 Datenverteilungsarchitektur

Abb. 2.26 Zentrale Produktdaten

Abb. 2.27 Teile in Auslaufprojekten nach Anlagedatum

Abb. 2.28 Gemeinkostenwirksame Prozesse

Abb. 2.29 Teilereduktion insgesamt

Abb. 2.30 Teilereduktion am Beispiel „Stahl-Halbzeuge“

Abb. 2.31 Reorganisation der Verwaltungswerkzeuge

Abb. 2.32 Vertriebskanäle der Hilti AG

Abb. 2.33 Vollständige und fehlerfreie Kundendaten als Voraussetzung für CRM-Prozesse

Abb. 2.34 Maßnahmen des proaktiven und reaktiven Kundendatenmanagements

Abb. 2.35 Rollenmodell und Datenqualitätsmanagementprozesse

Abb. 2.36 Data quality tracking tool

Abb. 2.37 Customer data quality workflow

Abb. 2.38 Details aus dem Customer Data Quality Workflow

Abb. 2.39 Systemlandschaft bei Johnson & Johnson

Abb. 2.40 Workflow Status Report bei der Anlage von Materialstammdaten

Abb. 2.41 Entwicklung des Datenqualitätsindex

Abb. 2.42 Aufbau der Data-Owner-Organisation bei Lanxess

Abb. 2.43 Kennzahlen-Framework von Lanxess

Abb. 2.44 BI-Toolauswahl

Abb. 2.45 Umsatz- und Margen-Reporting

Abb. 2.46 Business-Dependency-Network für In-Memory Computing bei Lanxess

Abb. 2.47 Ursache-Wirkungsanalyse der Datenqualitätsprobleme bei Shell

Abb. 2.48 Smart Request Form bei Shell

Abb. 2.49 Verbesserung des Neuanlageprozesses von Produkten bei Shell

Abb. 2.50 Übersicht zum Syngenta-Restrukturierungsprogramm „Sustainable Excellence“

Abb. 2.51 Transformationsprojekt bei Syngenta

Abb. 2.52 Übersicht zur MDM-Organisation bei Syngenta

Abb. 2.53 Syngenta-Betriebsmodell (unter Einbezug externer Partner)

Abb. 2.54 Datenpflegeprozess (Erstellung und Erhalt) bei Syngenta

Abb. 2.55 MDM-Servicereporting bei Syngenta

Abb. 3.1 Nutzen der Methode am Beispiel der TelCo Inc

Abb. 3.2 Methode zur Strategieentwicklung und Wirtschaftlichkeitsanalyse für das DQM

Abb. 3.3 Vorgehensmodell der Methode

Abb. 3.4 Beispiel Ableitung Maßnahmenkatalog (Auszug)

Abb. 3.5 Lebenszykluskosten nach VDI-Richtlinie 2884

Abb. 3.6 Klassifikation von Kennzahlen mit Beispielen für einen DQM-Leistungsvergleich

Abb. 3.7 Das EFQM-Exzellenzmodell für das Stammdatenqualitätsmanagement

Abb. 3.8 Steuerungscockpit für den MDM-Verantwortlichen

Abb. 3.9 Vergleich mit anderen Unternehmen mit der Benchmarking-Datenbank

Abb. 3.10 Lernen von anderen Unternehmen mit der Good Practice-Datenbank

Abb. 3.11 Redundante Pflege von Geschäftspartnerdaten

Abb. 3.12 Gemeinschaftliche Pflege von Geschäftspartnerdaten

Abb. 3.13 Geschäftspartnerdatenpflege durch einen realen Data Owner

Abb. 3.14 Screenshot der Webapplikation der Corporate Data League

Abb. 3.15 Konzeptionelle Darstellung der extensible Address Language (xAL)

Tabellenverzeichnis

Tab. 1.1 Die zehn großen Datenmanagement-Herausforderungen

Tab. 1.2 Anforderungen an das Datenqualitätsmanagement

Tab. 1.3 Ergebnisse der Datenqualitätsstrategie

Tab. 1.4 Ergebnisse des Führungssystems

Tab. 1.5 Ergebnisse der Organisation

Tab. 1.6 Ergebnisse der Prozesse und Methoden

Tab. 1.7 Ergebnisse der Unternehmensdatenarchitektur

Tab. 1.8 Ergebnisse der Anwendungssysteme

Tab. 1.9 Beispiel für eine Geschäftsrichtlinie und Geschäftsregeln

Tab. 1.10 Mitglieder des CC CDQ seit Gründung im Jahr 2006 (in alphabetischer Reihenfolge)

Tab. 2.1 Fallstudienübersicht

Tab. 2.2 Kurzprofil Allianz

Tab. 2.3 Geschäftsregeln bei AGCS

Tab. 2.4 Weiterführendes Material zum Fall von AGCS

Tab. 2.5 Kurzprofil Bayer

Tab. 2.6 Weiterführendes Material zum Fall von Bayer CropScience

Tab. 2.7 Kurzprofil Beiersdorf

Tab. 2.8 Kritische Datenmängel und Einfluss auf Geschäftsprozesse

Tab. 2.9 Weiterführendes Material zum Fall von Beiersdorf

Tab. 2.10 Kurzprofil Bosch

Tab. 2.11 Organisationsentwürfe für die Datenarchitektur bei Bosch

Tab. 2.12 Entscheidungsmatrix für die Datenarchitektur bei Bosch

Tab. 2.13 Weiterführendes Material zum Fall von Bosch

Tab. 2.14 Kurzprofil Festo

Tab. 2.15 Umfang der Teilereduktion

Tab. 2.16 Gemeinkostenanalyse

Tab. 2.17 Kosteneinsparung 2008

Tab. 2.18 Weiterführendes Material zum Fall von Festo

Tab. 2.19 Kurzprofil Hilti

Tab. 2.20 Weiterführendes Material zum Fall von Hilti

Tab. 2.21 Kurzprofil Johnson & Johnson

Tab. 2.22 Entwicklung der Datenmanagementkompetenzen

Tab. 2.23 Weiterführendes Material zum Fall von Hilti

Tab. 2.24 Kurzprofil Lanxess

Tab. 2.25 Weiterführendes Material zum Fall von Lanxess

Tab. 2.26 Kurzprofil Shell

Tab. 2.27 Weiterführendes Material zum Fall von Shell

Tab. 2.28 Syngenta

Tab. 2.29 Designprinzipien für das Stammdatenmanagement bei Syngenta

Tab. 2.30 Kriterien für die Serviceidentifikation bei Syngenta

Tab. 2.31 Weiterführendes Material zum Fall von Syngenta

Tab. 3.1 Typische Fragestellungen von DQM-Verantwortlichen

Tab. 3.2 Weitere Methoden und Werkzeuge des CC CDQ

Tab. 4.1 Erfolgsfaktoren des Datenqualitätsmanagements

Über die Autoren

Prof. em. Dr. Hubert Österle

war von 1980 bis 2014 Professor für Business Engineering und Direktor des Instituts für Wirtschaftsinformatik an der Universität St. Gallen. Im Jahre 1988 gründete er die Information Management Group und war in deren Geschäftsleitung und Verwaltungsrat tätig. Im Jahre 2006 gründete er das Business Engineering Institute St. Gallen, für das er bis heute als Präsident des Verwaltungsrates wirkt. Sein heutiger Forschungsschwerpunkt ist Life Engineering mit dem Ziel, durch digitale Nachbarschaft die Lebensqualität in Quartieren und Dörfern zu steigern.

Prof. Dr. Boris Otto

ist Inhaber des Audi-Stiftungslehrstuhls Supply Net Order Management an der Technischen Universität Dortmund und Leiter des Data Innovation Lab am Fraunhofer-Innovationszentrum für Logistik und IT. Schwerpunkte seiner Forschung und Lehre sind Geschäfts- und Logistiknetzwerke, Unternehmensdatenmanagement sowie Enterprise Systems und Electronic Business. Boris Otto studierte in Hamburg Wirtschaftsingenieurwesen, promovierte bei Prof. Hans-Jörg Bullinger an der Universität Stuttgart zum Dr.-Ing. und habilitierte sich an der Universität St. Gallen bei Prof. Hubert Österle. Zu seinen weiteren Stationen in der Forschung zählen das Fraunhofer-Institut für Arbeitswirtschaft und Organisation in Stuttgart sowie die Tuck School of Business am Dartmouth College in New Hampshire in den USA. Erfahrungen in der Praxis sammelte er bei PricewaterhouseCoopers und bei SAP. Boris Otto ist Mitglied des Vorstands der Graduate School of Logistics, Verwaltungsratspräsident der CDQ AG in St. Gallen sowie Mitglied im Wissenschaftlichen Beirat des eCl@ss e.V., einem der führenden Artikelklassifikationsstandards.

© Der/die Autor(en) 2016

Boris Otto

und Hubert ÖsterleCorporate Data Quality10.1007/978-3-662-46806-7_1

1. Datenqualität – eine Managementaufgabe

Boris Otto1   und Hubert Österle2

(1)

Fraunhofer Institut für Materialfluss und Logistik, Dortmund, Deutschland

(2)

Business Engineering Institute St. Gallen, St. Gallen, Schweiz

Boris Otto (Korrespondenzautor)

Email: boris.otto@iml.fraunhofer.de

Hubert Österle

Email: hubert.oesterle@bei-sg.ch

1.1 Trends der Digitalisierung

1.1.1 Durchdringung aller Lebens- und Wirtschaftsbereiche

1.1.2 Industrie 4.0

1.1.3 Konsumerisierung

1.1.4 Digitale Geschäftsmodelle

1.2 Treiber der Datenqualität

1.2.1 -Grad-Blick auf den Kunden

1.2.2 Unternehmenszukäufe und -zusammenschlüsse

1.2.3 Compliance

1.2.4 Berichtswesen

1.2.5 Operational Excellence

1.2.6 Datensicherheit und Privatheit

1.3 Herausforderungen und Anforderungen des Datenqualitätsmanagements

1.3.1 Herausforderungen im Umgang mit Daten

1.3.2 Anforderungen an das Datenqualitätsmanagement

1.4 Framework für Stammdatenqualitätsmanagement

1.4.1 Framework-Überblick

1.4.2 Strategieebene

1.4.3 Organisatorische Ebene

1.4.4 Informationssystemebene

1.5 Begriffsdefinitionen und Grundlagen

1.5.1 Daten und Information

1.5.2 Stammdaten

1.5.3 Datenqualität

1.5.4 Datenqualitätsmanagement (DQM)

1.5.5 Geschäftsregeln (Business Rules)

1.5.6 Data Governance

1.6 Kompetenzzentrum Corporate Data Quality

Literatur

Zusammenfassung

Kapitel 1 führt in die Rolle der Daten in der Digitalisierung von Wirtschaft und Gesellschaft ein und beschreibt die wichtigsten Geschäftstreiber für Datenqualität. Daten stellen für Unternehmen heutzutage eine strategische Ressource dar, die bewirtschaftet werden muss – nach Zeit-, Kosten- und eben Qualitätsgesichtspunkten. Datenqualitätsmanagement ist die Unternehmensfunktion zur Verbesserung und dauerhaften Sicherung der Datenqualität im Unternehmen. Das Kapitel stellt ein Referenzmodell für das Stammdatenqualitätsmanagement vor und führt die wesentlichen Begriffe und Konzepte ein. Ein Abschnitt zur Konsortialforschung gibt eine Übersicht über die forschungsmethodische Grundlage des Kompetenzzentrums Corporate Data Quality (CC CDQ), das den projektorganisatorischen Rahmen der Inhalte dieses Buchs bildet.

Daten sind das Fundament der digitalisierten Wirtschaft. Die Durchdringung aller Lebens- und Wirtschaftsbereiche mit „digitalen Services“ liefert Daten als Treibstoff für neue Dienstleistungen, neue Kundenzugänge, neue Preismodelle, neue Ökosysteme, also letztlich für einen großen Teil der wettbewerbsentscheidenden Innovationen. Alle Anwendungen der Informationstechnik erzeugen elektronische Daten, sodass eine noch nie dagewesene Datenflut entsteht, die es zu verstehen und zu nutzen gilt.

Ericsson beispielsweise ist ein führender Anbieter von Telekommunikationsprodukten und -dienstleistungen. Das Unternehmen mit Hauptsitz in Stockholm in Schweden bietet u. a. Lösungen für das breitbandige mobile Internet an. Einerseits entstehen also Daten bei der Nutzung von Ericsson-Lösungen. Andererseits wandelt sich das Leistungsangebot von Ericsson selbst immer mehr von der Netzwerktechnologie hin zu digitalen Services. Gemeinsam mit der Container-Reederei Maersk sorgt Ericsson für Informationstransparenz über globale Lieferketten (Ericsson 2012). So kann zum Beispiel der Reifegrad von Bananen auf dem Überseetransport von Südamerika nach Europa permanent überwacht werden und Transportgeschwindigkeiten sowie die Ladungslöschung im Zielhafen bei Bedarf angepasst werden. Das führt zu verbesserten Güterströmen am Hafen, der Optimierung des Treibstoffverbrauchs von Schiffen – und schließlich zu Kundenzufriedenheit am Obstregal im Supermarkt.

Die unternehmerischen Innovationen ebenso wie die „klassischen“ Treiber der Datenqualität, beispielsweise die Harmonisierung der Geschäftsprozesse, verlangen nach zunehmend hoher Datenqualität. Durch die digitale Vernetzung wirken sich Datenfehler und Datenmissbrauch viel gravierender aus als im Zeitalter der isolierten IT-Anwendungen. So klinken sich organisierte „Hackerbanden“ (Dahlkamp und Schmitt 2014) in den E-Mail-Verkehr zwischen Unternehmen ein, geben sich als Kreditor aus und leiten Zahlungen für Lieferungen und Leistungen auf falsche Konten um. Das fällt häufig so lange nicht auf, bis der richtige Kreditor die Zahlung anmahnt. Dann ist eine Rückabwicklung der Überweisung jedoch meist nicht mehr möglich.

Datenqualität ist kein „Hygienefaktor“, sondern braucht Management. In der digitalisierten Wirtschaft müssen Unternehmen Daten bewirtschaften wie jedes andere Wirtschaftsgut auch, nämlich nach Kosten, Zeit – und eben Qualität. Das erste Kapitel nennt aktuelle Treiber für das Datenqualitätsmanagement und stellt das Framework für Stammdatenqualitätsmanagement vor. Es fasst zudem den Stand der Wissenschaft und Praxis zum Datenqualitätsmanagement zusammen und führt in die Kernkonzepte ein.

Aufbau des Buches

Die Fallstudien in Kap. 2 zeigen, wie bedeutende Unternehmen die Datenqualität zu einer Aufgabe aller Managementebenen machen. Die Qualität der Stammdaten[1] kann nicht in einer zentralen IT-Abteilung gewährleistet, sondern muss am Ort der Datenentstehung und -verwendung, also in den Geschäftsbereichen, sichergestellt werden. Die Fallstudien dokumentieren, wie zehn Unternehmen unterschiedlicher Branchen Datenqualitätsmanagement im Unternehmensalltag verankert haben.

Kapitel 3 stellt Methoden und Werkzeuge vor, die Unternehmen beim Aufbau eines erfolgreichen Stammdatenqualitätsmanagements unterstützen. Alle Methoden wurden mehrfach in der Praxis erprobt.

Kapitel 4 fasst die Haupterkenntnisse der beschriebenen Lösungsansätze zusammen und präsentiert eine Liste mit Sofortmaßnahmen für besseres Datenqualitätsmanagement.

1.1 Trends der Digitalisierung

Neue Formen der Informationstechnik verändern alle Bereiche von Wirtschaft und Gesellschaft, wie dies z. B. Kagermann (2014) aus der Sicht der Bundesrepublik Deutschland analysiert. Wir fassen die Entwicklung zu vier Trends zusammen (Abb. 1.1).

Abb. 1.1
Megatrends der Digitalisierung. (eigene Darstellung)

1.1.1 Durchdringung aller Lebens- und Wirtschaftsbereiche

Laut International Telecommunication Union nutzten im Jahre 2013 2,7 Mrd. Menschen das Internet, also knapp 40 % der Weltbevölkerung (ITU 2013). Die technologischen Innovationen der letzten 15 Jahre sind für die Durchdringung des Privat- und des Geschäftsbereichs verantwortlich.

- Mobilität: Drahtlose Netzwerke und die Miniaturisierung von Computern und anderen Komponenten wie Sensoren und Kameras bringen die digitalen Services an den Ort der Benutzung, sei es im Privatbereich, z. B. als Aufzeichnung einer Wanderroute, oder sei es im Unternehmen, z. B. in der Ferndiagnose einer Maschine.

- Usability: Touch Screens und viele Detailverbesserungen wie z. B. die Anmeldung bei digitalen Services über ein Facebook-Konto oder die Sprach-Ein- und Ausgabe haben die Schwelle für die Nutzung drastisch gesenkt. Weitere Erleichterungen wie die Datenbrille (z. B. Google Glass), Gestensteuerung bis hin zur Erkennung von Augenbewegungen zeichnen sich ab.

- Content und Community: Unzählige Menschen produzieren einzeln (z. B. in Blogs, Tweets) oder in Gemeinschaften (z. B. Facebook) eine nur noch maschinell „überschaubare“ Menge von Inhalten in Form von Texten, Bildern, Audio und Video. Youtube zählt über eine Milliarde Videoabrufe pro Tag im Juni 2014[2], Facebook knapp 1,3 Mrd. aktive Benutzer im März 2014[3].

- Kommunikation: Diese Inhalte werden synchron und asynchron, privat und geschäftlich ausgetauscht. In der Schweiz nutzen z. B. bereits 81 % der Bevölkerung täglich oder mehrmals pro Woche das Internet, bei den unter 30-Jährigen sind es sogar 95 %. Kommunikation, z. B. über E-Mail, ist dabei die häufigste Aktivität (BFS 2014). Die Videokommunikation ergänzt immer mehr die herkömmliche Sprachtelefonie und Instant Messaging – Dienste (WhatsApp) werden neben E-Mails zunehmend genutzt.

- Big Data: Bislang unbekannte Datenmengen sind das Ergebnis der Durchdringung von Wirtschaft und Gesellschaft mit digitalen Services und gleichzeitig die Grundlage für die Individualisierung von Services, insbesondere auf Basis von Lokationsinformationen (Abb. 1.2).

Abb. 1.2
Online-Aktivitäten für private Zwecke in den letzten drei Monaten. (Froidevaux 2012, S. 25)

In Deutschland nutzte Ende 2013 fast die Hälfte der Bevölkerung (37 Mio. Menschen) ein Smartphone[4] und ein Fünftel bis ein Viertel der deutschen Bevölkerung nutzt Social Networks über ein Smartphone. Das digitale Networking hat einen enormen Einfluss auf die Meinungsbildung der Menschen in politischen, wirtschaftlichen und privaten Angelegenheiten. Aus Sicht des Datenmanagements sind u. a. folgende Aspekte zu beachten:

- Datensicherheit: Bisher galt das Intranet im Unternehmen als Perimeter, d. h. die Linie, bis zu welcher der Schutz der Daten gesichert wurde. Diese Linie löst sich auf und Unternehmen müssen dazu übergehen, nicht Netze und Anwendungssysteme zu schützen, sondern die Datenobjekte ertüchtigen, selbst zu wissen, von wem sie gelesen werden dürfen und von wem nicht (O’Brien 2014).

- Datenproduktion: Klassischerweise erfassen Unternehmen Daten zentral (z. B. Kundendaten durch einen zentralen Vertriebsinnendienst). Durch die Verbreitung von Social Media und Social Networks werden jedoch Datennutzer auch immer mehr zu „Datenproduzenten“ (Strong et al. 1997). Kundendaten können durch den Kunden selbst oder von Außendienstmitarbeitern per Smartphone oder Tablet vor Ort erfasst werden. Die Mitarbeiter erwarten, dass die Daten überall verfügbar sind.

- „Streams“ statt „Records“: In Social Networks und durch Social Media erzeugen Millionen von Nutzern Datenströme. Das stellt Unternehmen vor neue Herausforderungen, weil die traditionelle Datenverarbeitung transaktionsorientiert ist, d. h. einzelne Datensätze persistent in Datenbanken geschrieben werden. Die Verarbeitung von Datenströmen aus Social Networks – wie auch aus cyberphysischen Systemen bei Industrie 4.0 – kann aber nicht mehr inkrementell sein, sondern muss kontinuierlich erfolgen (BITKOM 2014).

1.1.2 Industrie 4.0

Der Begriff „Industrie 4.0“ steht für die vierte industrielle Revolution, also die Verschmelzung der physischen mit der virtuellen Welt durch sogenannte „cyber-physische Systeme“ (Bauernhansl et al. 2014). Die Daten werden ohne Zeitverzug, ohne menschliches Zutun und viel detaillierter und exakter als zuvor erfasst. Maschinen werden internetfähig, übernehmen selbständig Aufgaben der Produktion und Datenverarbeitung, und die Daten, die bislang nur in der Fabrik verfügbar waren, sind dem gesamten Unternehmen und seinen Geschäftspartnern zugänglich (Abb. 1.3).

Abb. 1.3
Datenerfassung an der Schnittstelle zwischen virtueller und physischer Welt. (Fleisch 2010; Wahlster 2011, S. 5)

Industrie 4.0-Szenarien verändern den grundsätzlichen Umgang mit Daten in und zwischen Unternehmen. Das wird an drei Aspekten deutlich:

- Dezentralisierung des Datenmanagements: Die Dinge selbst werden „smart“, d. h. sie produzieren, nutzen und besitzen mehr und mehr Daten und sind zunehmend weniger auf zentrale Steuerungen angewiesen. Infolgedessen übernehmen die Dinge auch verstärkt Aufgaben der Datenverarbeitung, ohne dass es eines zentralen Rechners bedarf.

- Von der „Klasse zur Instanz“: Im Fokus der elektronischen Datenverarbeitung in der Industrie stehen traditionell „Klassen von Dingen“, also Artikel mit einer bestimmten GTIN, Produkte mit einer bestimmten Materialnummer. Industrie 4.0 bedeutet nun, dass auch jede Instanz (jedes Exemplar) einer Klasse von Produkten identifiziert werden kann, also der einzelne Hydraulikzylinder, die einzelne Flasche Hydraulikflüssigkeit (Österle und Otto 2014).

- Kontinuierliche Kopplung von Informations- und Güterfluss: Traditionell zielt die industrielle Datenverarbeitung darauf ab, Informations- und Güterfluss an bestimmten Kontrollpunkten, sogenannten i-Punkten zusammenzuführen. Ein Beispiel ist die Wareneingangsbuchung im Zentrallager bei Anlieferung von Waren. Industrie 4.0-Szenarien nutzen z. B. RFID-Technologie und ermöglichen zu jeder Zeit den Abruf von Status- und Lokationsinformationen einzelner Produkte (Österle und Otto 2014).

Ein Beispiel für eine Industrie-4.0-Anwendung ist der intelligente Behälter inBin, der von der Firma SICK[5] gemeinsam mit dem Fraunhofer Institut für Materialfluss und Logistik (Fraunhofer IML) entwickelt wurde. Der inBin kennt seine Lokation, erfasst die Temperatur seiner Umgebung und veranlasst selbständig seine Kommissionierung (Abb. 1.4).

Abb. 1.4
Intelligenter Behälter „InBin“. (Fraunhofer IML 2015)

Voraussetzung für den Erfolg von Industrie 4.0 in einzelnen Unternehmen sowie über Supply Chains hinweg ist ein leistungsfähiges Datenmanagement, das folgende Anforderungen erfüllt:

- Beherrschung der Datenvolumina: Das Datenmanagement im Unternehmen muss in der Lage sein, die Massen an Daten zu verarbeiten und sinnvoll auszuwerten (Wrobel et al. 2014).

- Dezentrale Datenverarbeitung: Wenn Maschinen, Behälter, Frachtstücke usw. „intelligent“ werden, bedeutet dies, dass sie Datenverarbeitungsaufgaben selbständig übernehmen. Funktionen der Datenanalyse, der Datenaggregation und Datenbereitstellung finden also nicht mehr zentral in Enterprise Resource Planning (ERP)-Systemen und Data-Warehousing-Systemen statt, sondern lokal vor Ort. Ein Netzwerk von dezentralen intelligenten Geräten ergänzt die zentrale Datenverarbeitung der Unternehmen (Aggarwal et al. 2013).

- Festlegung von Datenstandards: Zeit-, Kosten- und Qualitätsvorteile durch den Einsatz cyber-physischer Systeme und der automatische Datenaustausch lassen sich nur dann realisieren, wenn sich für die Datenbeschreibungen und den Datenaustausch Standards etablieren. Diese Standards müssen mindestens innerbetrieblich, besser jedoch über ganze Supply Chains hinweg gelten (Otto et al. 2014). So entwickelt die MobiVoc-Initiative beispielsweise ein Datenvokabular für neue Mobilitätslösungen[6].

1.1.3 Konsumerisierung

Jeder Einzelne von uns nutzt heute eine Vielzahl unterschiedlicher Konsumentenservices, die uns in verschiedenen Lebenslagen unterstützen (Österle 2014). Abbildung 1.5 zeigt zehn Lebensbereiche, in denen Menschen digitale Services nutzen, von der Navigationsunterstützung bis zum Hören von Musik, vom Preisvergleich bis zur Fernsteuerung der Beleuchtung im eigenen Haus. Der Bereich Kommunikation ist beispielhaft um zwei weitere Ebenen erweitert, um einen Eindruck von der Vielfalt der Services zu vermitteln. Eine ausführlichere, aber nie vollständige MindMap der digitalen Konsumentenservices findet man auf il.iwi.unisg.ch/appmap (Amiona 2014).

Abb. 1.5
Zehn Lebensbereiche und Beispiele für ihre digitalen Services. (Amiona 2014)

Dabei steigen die Erwartungen des Konsumenten, dass digitale Services vermehrt individuell auf ihn zugeschnitten sind. Unternehmen reagieren auf diese Konsumerisierung der Informationstechnik, indem sie ihre Geschäftsprozesse an den Bedürfnissen des Konsumenten, also dem Konsumentenprozess, ausrichten. Dieser besteht aus sämtlichen Aktivitäten, die der Einzelne zur Erfüllung verschiedenster Bedürfnisse (z. B. Einkaufen, Sport treiben, Reisen) in einer Lebenssituation zu verrichten hat.

Die Konsumerisierung führt zu einer neuen Rolle des Konsumenten im Wirtschaftsleben (Konsumentenzentrierung). Er ist nicht mehr Endpunkt bzw. Senke unidirektionaler Waren- und Informationsflüsse, sondern beeinflusst über Plattformen wie Foodwatch.org die öffentliche Meinung von Produkten und Unternehmen und agiert sowohl als Verbraucher als auch als Produzent von Waren und Dienstleistungen. Beispiele sind die Stürme der Entrüstung, die über die Firma Nestlé wegen der Nutzung von Palmöl in KitKat-Schokoladenriegeln hereinbrach, und das Crowdsourcing von Programmierleistungen.

Abbildung 1.6 zeigt exemplarisch, wie sich der Fluss von Produktinformation beim Konsumgüterhersteller Beiersdorf innerhalb eines Zeitraums von fünf Jahren gewandelt hat. Von 2007 auf 2012 ist einerseits die Zahl an Akteuren im Unternehmensnetzwerk gestiegen, weil Unternehmen wie Apple und Google sowie Online-Händler wie Zalando Produktinformationen von z. B. Nivea nutzen und verteilen. Dieses erweiterte Unternehmensnetzwerk wird in Anlehnung an die Ökologie auch als „Ökosystem“ bezeichnet. Andererseits ist der Konsument hinsichtlich der „Macht über die Daten“ im Netzwerk von der Peripherie ins Zentrum gerückt, da nahezu alle Unternehmen des Netzwerks mit dem Konsumenten interagieren (Schierning 2012).

Abb. 1.6
Netzwerkanalyse der Produktinformationsflüsse bei Beiersdorf. (Schierning 2012, S. 9)

Nestlé pflegt nicht nur klassische Unternehmensdaten, sondern auch Konsumentendaten. Nestlé hat 94 Mio. Fans auf Facebook und 16 Mio. Views seines Contrex-Videos auf YouTube. Dazu kommen Daten von Onlineshops, auf denen Nespresso z. B. mehr als 50 % der Kaffee-Kapseln verkauft.

Konsumentenzentrierung bedeutet für Unternehmen eine Abkehr von der traditionellen unternehmenszentrierten Sicht auf den Endkunden. Nicht mehr der Entwurf und die Verbesserung der Interaktion mit dem Konsumenten aus Sicht des Unternehmens steht im Vordergrund des Handelns („Inside-out-Ansatz“), sondern der integrale Konsumentenprozess über die Grenzen einzelner Unternehmen hinweg („Outside-in-Ansatz“).

Die Konsumerisierung führt zu neuen Anforderungen an das Datenmanagement:

- Daten-Ownership: Wem gehören die Daten? Die facettenreiche Diskussion um den Datenschutz und Aussagen wie von Mark Zuckerberg von facebook, dass Datenschutz keine „soziale Norm“ mehr sei (Johnson 2010), zeigen, dass der Trend der Konsumerisierung das traditionelle Verständnis zum Eigentum und Besitz immaterieller Güter überholt hat. Sogenannte Daten-Broker sammeln persönliche Internetdaten in legalen Grauzonen (Anthes 2015). Für Unternehmen bedeutet dies, sich auf eine heterogene Rechtslage zum Datenschutz einzustellen. Gesetzgeber sind gefragt, einheitliche Rahmenbedingungen zu schaffen.

- Datenintegration: Die Menschen nutzen nicht mehr allein einen Kommunikationskanal, um mit einem Unternehmen in Verbindung zu treten, sondern viele verschiedene. Das Schweizer Einzelhandelsunternehmen Migros identifiziert neun verschiedene Kanäle (offline und online), über die es mit dem Konsumenten kommuniziert. Die Vielfalt reicht von Briefpost, Online Shops und E-Mail bis zu SMS. Weil der Konsument erwartet, über alle Kanäle eindeutig identifiziert zu werden und gleiche Preise und Rabatte zu den Migros-Produkten angeboten zu bekommen, muss das Unternehmen konsistente, aktuelle und vollständige Daten zu den Kunden sowie den Produkten über alle Kanäle hinweg verfügbar haben (Schemm 2012).

- Kombination von „strukturierten“ und „unstrukturierten“ Daten: Infolge der Konsumerisierung stellen Unternehmen nicht allein traditionelle alphanumerische Datenformate wie Beschreibungstexte, Gewichts- und Preisangaben zu Produkten bereit, sondern vermehrt Produktvideos, Marketing-Texte, Inhaltsstoffe usw. Die Unterscheidung zwischen Produktdaten, die meist in zentralen ERP- oder Product Lifecycle Management (PLM)-Systemen gespeichert sind, und multimedialen Produktinformationen, die häufig über eine Vielzahl interner Anwendungssysteme sowie externe Dienstleister (z. B. Werbeagenturen) verteilt sind, kann dann nicht mehr aufrecht erhalten werden (Österle und Otto 2014).

1.1.4 Digitale Geschäftsmodelle

Die Durchdringung von Wirtschaft und Gesellschaft und damit von Industrie und Konsumenten mit digitalen Services führt zu neuartigen Geschäftsmodellen abseits klassischer Unternehmen[7]. Beispiele aus dem Konsumentenbereich sind Google, aber auch Airbnb, idealo und viele weitere Unternehmen, die eine große Zahl von Konsumenten und Geschäftskunden mit einer großen Zahl von Anbietern zusammen bringen. Diese Unternehmen nehmen eine Vermittlerrolle zwischen Leistungserstellung und -bezug verschiedener Akteure ein. Aus einer eher technischen Sicht wird vielfach auch vom „Internet der Dienste“ gesprochen. Vier Entwicklungen prägen diese Geschäftsmodelle:

- Datenzentrierung: Neue Geschäftsmodelle der internetbasierten Servicewirtschaft nutzen Daten als strategische Ressource (siehe Abb. 1.7). Die Deutsche Post bietet z. B. über den Dienst GEOVISTA hochauflösende Geoinformationen für den Einzelhandel, die Versicherungswirtschaft, die Immobilienwirtschaft sowie die öffentliche Verwaltung und andere Kunden an („Daten als Produkt“)[8].

Abb. 1.7
Digitale Geschäftsmodelle. (Brenner und Herrmann 2012, S. 20)

- Industriekonvergenz: Traditionelle Branchengrenzen verlieren an Bedeutung. Innovationstreiber beim autonomen Fahren ist Google; klassische Autobauer sind potenzielle Lizenznehmer für die Technologie. Amazon hat sich von einem Buchhändler zu einem Fulfillment-Experten gewandelt, der seine besonderen Fähigkeiten wie die skalierbare IT-Infrastruktur oder Logistikdienstleistungen Unternehmen aus vielfältigen Branchen und sogar Konsumenten anbietet.

- Hybride Services: Vielfach verbinden digitale Geschäftsmodelle digitale Dienstleistungen mit klassischen „Offline-Services“. Ein Beispiel sind Carsharing-Modelle, die das digitale Mieten und Finden von Autos inklusive Bezahlung (meist unterstützt durch SmartPhone-Apps) mit der klassischen Dienstleistung Mobilität kombinieren.

- Konsumentenprozess: Das Internet der Dienste richtet sich an das Individuum, also den einzelnen Konsumenten, den Patienten, den Servicetechniker oder den Shopper. Das Ziel ist die „Ende-zu-Ende“-Unterstützung in Lebenssituationen wie Einkaufen, Arbeiten, Mobilität, Therapie oder Vorsorge (Österle und Senger 2011).

1.2 Treiber der Datenqualität

Digitale Geschäftsmodelle und das Internet der Dienste basieren auf der Ressource Daten. Datenqualität ist damit für Unternehmen kein „Hygienefaktor“ mehr oder gar Selbstzweck von Stabsabteilungen, sondern ist kritisch für die Operational Excellence. Datenqualität ist definiert als ein Maß für die Eignung der Daten für bestimmte Anforderungen in Geschäftsprozessen, in denen sie verwendet werden (Otto et al. 2011). Im Folgenden wird „Datenmanagement“ stets unter besonderer Berücksichtigung des Datenqualitätsmanagements behandelt.

Zu den wichtigsten Treibern für das qualitätsorientierte Datenmanagement gehören:

- 360-Grad-Blick auf den Kunden

- Unternehmenszukäufe und -zusammenschlüsse

- Compliance

- Berichtswesen

- Operational Excellence

1.2.1 -Grad-Blick auf den Kunden

Das Wissen über den Kunden ist der Ausgangspunkt für Marketing und Verkauf, aber auch für die Produkt- und Dienstleistungsentwicklung. Deshalb müssen Unternehmen in der Lage sein, sämtliche Informationen zu den Bedürfnissen des Kunden verfügbar zu haben. Bei Konsumenten sind das z. B. das Internet-Surf-Verhalten, die Einkäufe und die Bezugsgruppen in sozialen Netzen, bei Geschäftskunden seine Adressen, Tochterunternehmen, Kontaktdaten und Namen von Ansprechpartnern, sowie Daten zu gekauften Produkten und bestehenden Verträgen.

Das Unternehmen Bühler, ein global tätiger Hersteller von Produktionsanlagen mit Spezialisierung auf die Nahrungsmittelindustrie, stellt beispielsweise seinen Mitarbeitern im Kundendienst und im Vertrieb einen digitalen Kundensteckbrief zur Verfügung. Dieser beantwortet Fragen wie:

- Wie hoch ist der Umsatz mit dem Kunden (und allen seinen Tochterunternehmen) im aktuellen Geschäftsjahr?

- Welche unserer Anlagen und Dienstleistungen nutzt der Kunden an welchem Standort?

- Wann laufen Wartungsverträge aus?

- Welcher Mitarbeiter hatte in den letzten drei Monaten Kontakt zu welchen Kundenmitarbeitern? Was waren Ergebnisse dieser Kontakte?

- Wie profitabel ist die Kundenbeziehung?

Der 360-Grad-Blick auf den Kunden stellt zahlreiche Anforderungen an das qualitätsorientierte Datenmanagement:

- Datenqualität: Kundendaten müssen konsistent, aktuell und vollständig über alle Funktionsbereiche (Vertrieb, Service etc.) verfügbar sein.

- Datenlebenszyklus: Es muss klar definiert sein, wie Kundendaten ins Unternehmen gelangen, wo sie erfasst und gespeichert werden, wer sie anreichert und ändert und in welche Geschäftsprozesse und Systeme sie einfließen.

- Datenschutz: Vor allem bei Konsumentendaten muss sichergestellt sein, dass die Datenschutzbestimmungen eingehalten werden, also u. a. Kundendaten gelöscht werden, wenn dies gewünscht ist.

- Data Governance: Unternehmen müssen klar festlegen, wer im Unternehmen für welche Kundendaten verantwortlich ist. Ist der Außendienstmitarbeiter für die Kundenadresse verantwortlich oder der Vertriebsinnendienst? Darf der Servicemitarbeiter den Kundenstatus in „aktiv“ ändern? Wer sammelt die E-Mails mit diesem Kunden oder dessen Facebook-Fotos?

1.2.2 Unternehmenszukäufe und -zusammenschlüsse

Unternehmenszukäufe und –zusammenschlüsse sind ein wichtiges Instrument von Unternehmensstrategien. In der chemischen Industrie hat z. B. die BASF seit 2005 u. a. die Eletronikchemikaliensparte von Merck, die Feinchemiefirma Orgamol, den Katalysatorhersteller Engelhard, die Bauchemikaliensparte von Degussa sowie den Spezialchemiekonzern Ciba übernommen. Die Zukäufe wurden in einheitliche Applikationssysteme und Geschäftsprozesse integriert.

Ein weiteres Beispiel für Unternehmensintegrationen liefert Nestlé. Das Unternehmen führt über 2000 unterschiedliche Marken, die in mehr als 440 Fabriken in fast 90 Ländern der Erde produziert und in über 190 Ländern verkauft werden[9]. Von dem Gesamtumsatz in Höhe von mehr als 92 Mrd. Schweizer Franken im Jahre 2013 laufen 93 % auf dem zentralen Enterprise Resource Planning (ERP)-System „GLOBE“. Abbildung 1.8 zeigt einige Eckdaten zu GLOBE.

Abb. 1.8
Eckdaten zum zentralen System GLOBE bei Nestlé. (nach Muthreich 2013, S. 18)

Das GLOBE-Programm verfolgt seit seinem Start 2001 drei Ziele, nämlich die unternehmensweite Nutzung von „Best Practices“ auf Basis gemeinsamer Geschäftsprozesse, die Einführung eines standardisierten Anwendungssystems sowie die Nutzung von Daten als „Asset“. Voraussetzung dafür ist ein leistungsfähiges Datenmanagement, das insbesondere viele Unternehmenszukäufe der letzten Jahre integriert.

- Datenstandards: Für die Erfassung, Pflege und Verwendung der Stammdaten wie Kunden, Lieferanten und Materialien und Produkte müssen verbindliche Vorgaben gelten.

- Datenerfassung an der Quelle: Aufgrund der Größe und Komplexität des Unternehmens können Daten nicht zentral erfasst werden, sondern so nah wie möglich an der Datenquelle.

- Datenqualität: Die Größe des GLOBE-Systems lässt es nicht zu, Daten verunreinigt ins System zu bringen und nachträglich zu reinigen. Die Daten müssen stattdessen bei erstmaligem Erfassen richtig sein („first time right“-Prinzip).

- Datenintegration: Ein integriertes System wie GLOBE lässt keine „Datensilos“ zu, sondern alle Geschäftsbereiche, Funktionen und Märkte arbeiten mit einer integrierten Datenbasis. Die Datenintegration kann ihr Potenzial jedoch nur entfalten, wenn im Unternehmen ein Umdenken einsetzt: Weg von „My Data“ und hin zu „Our Data“.

1.2.3 Compliance

Die zunehmende Regulierungsdichte zwingt die Unternehmen, eine große und weiter steigende Zahl gesetzlicher und behördlicher Vorgaben und Vorschriften zu erfüllen. Zwei prominente Beispiele dazu sind:

- Die EU-Verordnung REACH (Registration, Evaluation, Authorisation and Restriction of Chemicals) regelt die Registrierungspflicht von Chemikalien, welche in der EU in Verkehr gebracht werden, und legt die Datenanforderungen für die Registrierung fest („no data, no market“) (European Commission 2006). Zu den Datenanforderungen gehören u. a. Angaben zur Herstellung und sicheren Verwendung von Chemikalien. Unternehmen müssen diese Anforderungen im Stammdatensatz für Materialien mitführen und für Berichtszwecke aktuell, konsistent, vollständig und in der richtigen Form vorhalten.

- Unter dem Schlagwort Solvency II vereinheitlicht die Europäische Kommission das Versicherungsaufsichtsrecht, insbesondere im Hinblick auf das sogenannte Solvenzkapital. Bestandteile der Richtlinie sind Vorgaben für das Risikomanagement sowie Berichterstattungspflichten für Versicherungsunternehmen. Diese Vorgaben resultieren in Forderungen nach einem unternehmensweit einheitlichen Management von Markt-, Kerngeschäfts- und Finanzdaten (Salchegger und Dewor 2008).

Das Pharmaunternehmen Novartis muss z. B. aufgrund behördlicher und gesetzlicher Auflagen Daten zu klinischen Studien und zu Wirkstoffen in Produkten vollständig, aktuell und korrekt bereitstellen können. Als Voraussetzung dafür schafft das Unternehmen einen durchgängigen, unternehmensweiten „Regulatory Submission“-Prozess. Das Datenmanagement spielt dabei eine besondere Rolle:

- Datenkonsistenz: Nicht nur die Daten selbst, sondern auch die Metadaten (Definitionen, Wertelisten usw.) müssen über Systeme, Geschäftsprozesse und Funktionen hinweg konsistent sein.

- Datenlebenszyklus: Der gesamte Lebenszyklus der Daten von ihrer Entstehung bis zur Archivierung und zum Löschen muss definiert sein.

- Data Governance: Es muss definiert sein, wer im Unternehmen für welche Daten welche Rechte zur Definition und zur Nutzung hat.

1.2.4 Berichtswesen

Unternehmen geben zwischen 1 und 5 % ihres Umsatzes für die Anschaffung und den Betrieb leistungsfähiger Unternehmenssoftware (z. B. SAP Business Suite) aus (Reynolds 2010; Equey et al. 2008), können aber oftmals grundlegende Fragen nicht beantworten. Beispiele für diese Fragen sind:

- Aus wie vielen Produkten besteht unser Sortiment?

- Wie hoch ist das Beschaffungsvolumen mit den größten zehn Lieferanten?

- Welchen Umsatz haben wir im vergangenen Geschäftsjahr mit unserem größten Kunden gemacht?

Der Grund dafür ist nicht etwa das Unvermögen, die Systeme zu nutzen, oder ein niedriger Reifegrad des IT-Betriebs, sondern das Fehlen einer sogenannten „Single Source of the Truth“. Große Unternehmen bestehen aus einer Vielzahl von Sparten, Standorten und Geschäftsprozessen, in denen sich über den Lauf der Zeit jeweils ein eigenes Bild der Realität (Kunden, Materialien, Lieferanten usw.) entwickelt hat. Wenn dann z. B. im Rahmen der Lieferantenentwicklung die Beschaffungsvolumina aller Standorte, Sparten usw. bei einem Lieferanten und all seinen Töchterunternehmen ermittelt werden sollen, passen diese unterschiedlichen Abbildungen der Realität nicht zusammen.

Exemplarisch zeigt Abb. 1.9 einige Datenqualitätsherausforderungen am Beispiel der ZF Friedrichshafen AG, die für ein aussagekräftiges Geschäftspartner-Reporting bewältigt werden müssen.

Abb. 1.9
Datenqualitätsherausforderungen beim Kundenumsatz-Reporting bei ZF Friedrichshafen. (Möller 2012, S.  24)

Bestandteile des Datenmanagements für ein vertrauenswürdiges Berichtswesen sind:

- Datenmodell: Voraussetzung für die Single Source of Truth ist ein straffes Management der Kunden-, Produkt- und Lieferantendaten, sodass alle Objekte eindeutig identifizierbar sind, die unternehmensweit wichtig sind.

- Datenqualität: Die Datennutzung im Reporting gibt die Anforderungen an die Datenqualität vor, also welches Maß an Aktualität, Vollständigkeit und Konsistenz bestimmte Attribute der Kunden-, Produkt- und Lieferantendaten erfüllen müssen.

- Datenarchitektur: Die Datenarchitektur definiert einerseits das Konzerndatenmodell, legt aber andererseits auch fest, welche Systeme Single Source of the Truth für welche Datenobjekte bzw. -attribute sind und in welche anderen Systeme die Daten von dort verteilt werden.

1.2.5 Operational Excellence

Mit der Standardisierung und Automatisierung von Geschäftsprozessen nutzen Unternehmen Skaleneffekte und verringern gleichzeitig ihre Komplexität. Voraussetzung dafür ist ein einheitliches Verständnis über die Daten im Unternehmen, welche in allen Geschäftsbereichen genutzt werden. Denn die Standardisierung der Geschäftsprozesse ist nicht möglich, wenn z. B. Materialstammdaten in Teilprozessen oder Regionen unterschiedlich definiert sind und unterschiedlich erzeugt und verwendet werden.

2007 litt die Konsumgütersparte von Johnson & Johnson in den USA unter vielen Problemen mit der Datenqualität in Geschäftsprozessen (siehe Abb. 1.10 und Kap. 2.7).

Abb. 1.10
Geschäftsprozessprobleme durch schlechte Datenqualität bei Johnson & Johnson. (Otto 2014, S. 20)

Weniger als 30 % der logistischen Daten zu Artikeln, d. h. Angaben zu den Abmessungen und zum Gewicht der Artikel, befanden sich innerhalb der erlaubten Fehlertoleranz von 5 %. Anders ausgedrückt: Mehr als 70 % der logistischen Daten waren falsch. Johnson & Johnson erneuerte sein Stammdatenmanagement und erreichte 2013 einen Six-Sigma-Level hinsichtlich seiner Datenqualität[10]. Voraussetzungen dafür waren:

- Data Governance: Eine zentrale Stelle im Unternehmen legt fest, wie die Daten definiert sind, wie sie angelegt, verwendet und gelöscht werden und welche Qualität sie haben müssen, damit die Geschäftsprozesse reibungslos funktionieren.

- Datenqualitätsmessung: Monatlich wird die Datenqualität der wichtigsten Attribute gemessen. Ein Datensatz, der nicht sämtliche der mehreren hundert Geschäftsregeln erfüllt, gilt als defekt.

- Workflow-gestützte Anlage: Die Erfassung und Änderung der Daten ist klar geregelt und durchgängig durch ein Workflow-Managementsystem gestützt.

1.2.6 Datensicherheit und Privatheit

Privatpersonen geben im Internet vermehrt freiwillig private Daten preis, um Angebote wie soziale Netzwerke zu nutzen. Während in den USA der Datenschutz kaum gesetzlich geregelt ist, wird der Schutz personenbezogener Daten in der Europäischen Union als Grundrecht definiert (EU 2010). Daten dürfen nur mit Einwilligung der betroffenen Personen oder auf Basis einer gesetzlichen Grundlage verarbeitet werden. Für Unternehmen haben diese Vorgaben Auswirkungen auf Werbemaßnahmen oder Analysen des Kundenverhaltens. Allerdings ist die Rechtslage nicht immer eindeutig angesichts der Vernetzung durch das Internet sowie infolge der Auslagerung von IT-Aktivitäten in Länder, in denen andere Datenschutzbestimmungen gelten.

Unternehmen haben im Sinne der Informationssicherheit auch die Aufgabe, die von ihnen verwalteten personenbezogenen Daten gegen den unberechtigten Zugriff Dritter zu schützen. Dabei schaden Datenlecks Internet-Unternehmen besonders intensiv. Deshalb versuchte im Dezember 2013 ein Telekommunikationsunternehmen gerichtlich die Publikation eines Artikels zu verhindern, in dem öffentlich wurde, dass Angaben zu Bankkonten von 7500 Kunden sowie zu 5,6 Mio. E-Mail-Abonnenten entwendet worden sind. Durch ein Gerichtsurteil ist die superprovisorische Verfügung inzwischen aufgehoben und die Veröffentlichung hat stattgefunden (Schmid 2014).

1.3 Herausforderungen und Anforderungen des Datenqualitätsmanagements

Unternehmen stehen vor der Aufgabe, dass sie einerseits die gesellschaftlichen Trends der Digitalisierung (Kap. 1.1) nutzbar machen und gleichzeitig Antworten auf die großen Treiber für Datenqualität (Kap. 1.2) finden müssen. Daraus ergibt sich eine Anzahl von konkreten Herausforderungen und Leistungsanforderungen, die Unternehmen beim qualitätsorientierten Management von Stammdaten (kurz Datenqualitätsmanagement DQM) berücksichtigen müssen.

1.3.1 Herausforderungen im Umgang mit Daten

Das Kompetenzzentrum Corporate Data Quality (CC CDQ) an der Universität St. Gallen und dem Fraunhofer Institut für Materialfluss und Logistik in Dortmund greift die größten Herausforderungen im Datenmanagement auf und entwickelt dafür neue Lösungsansätze. Im Rahmen des CC CDQ wurden im April 2013 Datenmanager aus unterschiedlichen Industrien zu den größten Herausforderungen für das Datenmanagement befragt (Österle und Otto 2014). Tabelle 1.1 zeigt als Ergebnis dieser Fokusgruppe die Rangfolge der Herausforderungen.

Tab. 1.1
Die zehn großen Datenmanagement-Herausforderungena

Rang

Herausforderung

Punktwert

1

Datenqualität

52

2

Transparenz über Datennutzung

36

3

Redundante Datenpflege

33

4

Manuelle Datenpflege

31

5

Limitationen zentraler Datenarchitekturen (Inflexibilität, Bürokratie etc.)

25

6

Semantische Integration

18

Trennung zwischen „strukturierten“ und „unstrukturierten“ Daten

18

8

Datenschutz

14

9

Trennung zwischen OLAP (Online Analytical Processing) und OLTP (Online Transactional Processing)

5

10

Management von „Klassen“ von Dingen, keine Instanzen

1

a Die Teilnehmer der Befragung waren aufgefordert, aus einer Liste von zehn Einträgen die fünf größten Herausforderungen im Datenmanagement zu nennen, wobei der Wert „1“ die größte und „5“ die fünftgrößte Herausforderung darstellte. Bei 17 Teilnehmern ergeben sich ein Maximalwert von 85 und ein Minimalwert von 0 Punkten pro Eintrag.

Die Verbesserung und die Sicherung der Datenqualität gelten den Teilnehmern der Fokusgruppe mit Abstand als die größte Herausforderung. Datenqualität ist ein Maß dafür, in welchem Umfang die Daten geeignet sind, die Anforderungen der Geschäftsprozesse zu erfüllen, in denen sie verwendet werden (Otto et al. 2011). Datenqualität lässt sich in verschiedenen Datenqualitätsdimensionen messen, wie z. B. Konsistenz, Aktualität und Vollständigkeit.

Als zweitgrößte Herausforderung sehen die Teilnehmer der Fokusgruppe die Transparenz über die Datennutzung. Insbesondere in großen Unternehmen mit komplexen Anwendungssystemlandschaften ist oftmals unklar, wo und wie Daten ins Unternehmen gelangen, in welchem System sie federführend gespeichert sind und was nach ihrer Verteilung in lokale Anwendungssysteme mit ihnen geschieht. White und Radcliffe (2010) verwenden in diesem Zusammenhang den Begriff der mangelnden „Downstream Visibility“ von Daten.

Redundante Datenpflege gilt als drittgrößte Herausforderung. Ein Beispiel ist die Erfassung und Pflege von Lieferantenstammdaten in unterschiedlichen Geschäftsbereichen desselben Unternehmens oder bei verschiedenen Unternehmen mit überlappender Lieferantenbasis. Typischerweise erfasst und pflegt jedes Unternehmen die Daten separat, obwohl alle die gleichen Daten benötigen. An wie vielen Orten werden z. B. die Adressdaten von IBM gepflegt? Wie oft muss ein Konsument seine Adresse und andere Informationen eingeben? Wäre es nicht von Vorteil, wenn Portale wie Facebook versuchten, dem Konsumenten redundante Identifikationen abzunehmen und seine Identität allen Interessierten und Berechtigten verfügbar zu machen?

Eine vierte Herausforderung ist die manuelle Datenpflege, die bei Medienbrüchen in der Datenverarbeitung auftritt (Fleisch und Österle 2004). Ein Beispiel für einen Medienbruch ist das Abtippen oder Einscannen von Kundenstammdaten von einer Visitenkarte in ein Customer Relationship Management (CRM)-System. Manuelle Datenpflege ist anfälliger für Fehler und gefährdet damit die Datenqualität.

Als fünfte große Herausforderung gelten die Limitationen zentraler Datenarchitekturen. Denn zukünftig werden immer mehr Daten von externen Quellen beschafft und zur Zeit des Bedarfs im Geschäftsprozess zur Verfügung gestellt. Ein Beispiel sind Angaben zum CO_2-Ausstoß bei der Produktion und Distribution von Konsumgütern. Konsumgüterhersteller, die zu derartigen Angaben z. B. in Frankreich verpflichtet sind (AFNOR 2009), werden diese Daten nicht in zentralen (ERP)-Systemen führend verwalten, sondern auf autorisierte Datenbanken von Drittanbietern zugreifen.

Die semantische Integration von Daten ist die sechstwichtigste Herausforderung im Datenmanagement. In der Datenintegration ist Semantik definiert als die Interpretation von Daten in einem bestimmten Anwendungsfall (Ziegler und Dittrich 2007). Ein Beispiel ist der Begriff „Kunde“, der in der Buchhaltung eines Unternehmens als „aktiver Kunde“ verstanden wird und im Vertrieb als „potentieller Kunde“.

Ebenfalls auf dem sechsten Rang ist die Trennung zwischen „strukturierten“ und „unstrukturierten“ Daten genannt. Als strukturierte Daten werden alphanumerische Daten bezeichnet, die oftmals gemäß einem relationalen Datenbankschema organisiert sind. Als unstrukturiert gelten Texte, Audios, Videos, Bilder, Tweets und Zeichnungen. Die Trennung zwischen diesen beiden Datenarten stellt Unternehmen vor Probleme, wenn z. B. im Berichtswesen neben Umsätzen auch Daten aus Social-Networking-Plattformen oder Verbraucherportalen analysiert werden sollen (Baars und Kemper 2008).

Platz 8 der größten Herausforderungen im Datenmanagement nimmt der Datenschutz ein. Sony wurde z. B. 2011 Opfer eines Hacker-Angriffs auf sein PlayStation-Netzwerk, bei dem auch Daten von Nutzern gestohlen wurden. Wurde das Unternehmen zu Beginn des Jahres 2013 in Großbritannien zu Strafzahlungen in Höhe von 250.000 GBP verurteilt, weil der Vorfall nach Ansicht des Information Commissioner’s Office (ICO) hätte „verhindert werden können“ (BBC 2013), so wog doch der Reputationsverlust viel schwerer.

Die neuntgrößte Herausforderung im Datenmanagement ist die Trennung zwischen „Online Analytical Processing“ (OLAP) und „Online Transactional Processing (OLTP)“. Häufig werden Daten in OLTP-Systemen wie ERP-Systemen erfasst, gepflegt und anschließend extrahiert, um dann nach Transformations- und Bereinigungsschritten in OLAP-Systeme wie Data Warehouses und Business Intelligence-Anwendungen importiert zu werden. Die Herausforderung besteht darin, dass die Daten somit redundant gehalten werden, was zusätzliche Aufwände hervorruft und die Datenqualität gefährdet.

Auf Platz 10 rangiert die Herausforderung, in Zukunft nicht allein Klassen von Entitäten zu bewirtschaften, sondern Instanzen. Durch RFID-Technologien kann ein Spezialmaschinenbauer jedes einzelne Ersatzteil identifizieren. Dieser Ansatz unterscheidet sich von der klassischen Datenverarbeitung, bei der ein Stammdatensatz inkl. einer Teilenummer die Teileklasse beschreibt und Bestandsdaten den jeweiligen Lagerbestand. Das Datenmanagement muss mit dieser Zunahme der Datensätze umgehen können.

1.3.2 Anforderungen an das Datenqualitätsmanagement

Die Beispiele in den Kap. 1.1 und 1.2 haben gezeigt, dass sich diese Anforderungen durch die Digitalisierung noch verschärfen. Tabelle 1.2 fasst die wichtigsten Anforderungen an ein erfolgreiches Datenqualitätsmanagement zusammen, die von den „Top 8“ der Herausforderungen abgeleitet werden können.

Tab. 1.2
Anforderungen an das Datenqualitätsmanagement

Rang

Herausforderung

Anforderung

1

Datenqualität

Definition und Messbarkeit: Das moderne Datenqualitätsmanagement muss festlegen, welche Datenqualität die Geschäftsprozesse für einen reibungslosen Ablauf benötigen. Dabei gilt: Nur was gemessen wird, lässt sich managen. Die Datenqualität muss deshalb kontinuierlich gemessen werden und bei Abweichung vom Sollwert muss das Datenqualitätsmanagement Maßnahmen zur Erhöhung der Datenqualität einleiten.

2

Transparenz über Datennutzung

Transparenz und Verantwortlichkeit: Der Lebenszyklus der Daten, beginnend mit ihrer Entstehung im Unternehmen und erstmaligen Erfassung in einem Informationssystem über ihre Nutzung bis zur Archivierung und Löschung, muss bekannt und gemäß den Anforderungen der Geschäftsprozesse definiert sein. Das Datenqualitätsmanagement muss diesen Lebenszyklus steuern und überwachen. Unternehmen müssen die Definition von Daten sowie ihre Nutzung klar regeln. Dafür müssen Verantwortlichkeiten im Unternehmen geschaffen und zugeordnet sein. Beispielsweise definiert beim unternehmensweiten Umsatzreporting eine zentrale Stelle in der Finanzbuchhaltung oder im Vertrieb die Kundenstammdaten, damit in allen Geschäftsbereichen derselbe Kunde auch eindeutig identifiziert und gleich verwendet wird.

3

Redundante Datenpflege

Prävention: Datenqualitätsmanagement darf nicht erst dann beginnen, wenn die Daten bereits defekt sind, sondern muss vorbeugend wirken – wie bei anderen „Assets“ im Unternehmen auch (z. B. vorbeugende Wartung von Produktionsanlagen, Maßnahmen zur Gesundheitsprävention bei Mitarbeitern).

4

Manuelle Datenpflege

Automatisierung: Die Datenvolumina, ihre Vielfalt und ihre Änderungsrate steigen. Um der daraus resultierenden Komplexität Herr zu werden, müssen Unternehmen Datenverarbeitungsaufgaben (z. B. die Anlage von Daten, ihre Qualitätsmessung, ihre Änderung und Bereitstellung) so weit wie möglich automatisieren, z. B. über Workflows oder Geschäftsregeln.

5

Limitationen zentraler Datenarchitekturen

Flexibilisierung und Verteilung: Datenarchitekturen definieren ein unternehmensweit einheitliches Modell der Konzerndaten (das Konzerndatenmodell) und bestimmen außerdem die Datenverteilungs- und Datenhaltungsarchitektur. Sie haben traditionell den Nachteil, dass sie nur mit hohem bürokratischem Aufwand erstellt werden können und selten aktuell gehalten werden. Moderne Datenarchitekturen müssen hinreichend flexibel an neue Anforderungen angepasst werden können und sowohl klassische unternehmensinterne als auch externe Datenobjekte enthalten. Die Herausforderung besteht darin, diese Flexibilität zu ermöglichen, aber gleichzeitig für die Kerngeschäftsobjekte weiterhin unternehmensweit maßgebend zu sein.

6

Semantische Integration

Einheitlichkeit: Konzerndaten als unternehmensweite Stammdaten müssen eindeutig identifiziert und einheitlich verwendet werden. Das Datenqualitätsmanagement muss dafür die Konzerndaten integrieren. Grundsätzlich stehen zwei Architekturvarianten dafür zur Verfügung: Entweder werden die Daten in einem System zusammengeführt oder die Daten verbleiben in verschiedenen Systemen und die Systeme werden über Schnittstellen und Datenaustausch miteinander verbunden.

Trennung „strukturierte“ und „unstrukturierte“ Daten

Heterogenität der Datentypen: Im Kontext von „Big Data“ wird häufig von „strukturierten“ und „unstrukturierten Daten“ gesprochen, um die wachsende Heterogenität der vorkommenden Datenarten zu beschreiben, mit denen Unternehmen umgehen müssen. Damit ist gemeint, dass neben Daten, die in ERP-Systemen in relationalen Datenbanken abgelegt sind, zunehmend auch Daten wie Videos und Bilder sowie unkonventionelle externe Daten, z. B. über Internetnutzung oder Social Media-Kanäle, verwendet werden. Diese können wertvolle Erkenntnisse über den Markt und Konsumentenvorlieben liefern. Solche „unstrukturierten“ Daten brauchen aber neue Werkzeuge zur Datenanalyse und werden üblicherweise nicht in relationalen Datenbanken gespeichert.

Datenschutz

Gerade multinationale Unternehmen sind mit unterschiedlichen Datenschutzvorgaben konfrontiert. Das Datenqualitätsmanagement muss sicherstellen, dass diese Regeln eingehalten werden. Problemquellen hierfür sind, dass Richtlinien oft nicht transparent sind, sie sich häufig ändern (was ebenfalls unbekannt ist) und niemand genau weiß, inwieweit sie in den Systemen umgesetzt sind. Daher wird Datenschutz von vielen Unternehmen eher als Behinderung angesehen denn als Opportunität.

1.4 Framework für Stammdatenqualitätsmanagement

Die oben genannten Anforderungen müssen in der Praxis an den speziellen Bedürfnissen und Möglichkeiten jedes Unternehmens orientiert werden, damit ein erfolgreiches unternehmensweites Datenqualitätsmanagement entstehen kann. Denn Datenqualität heißt nicht Qualität um jeden Preis, sondern Qualität gemäß den Anforderungen der Unternehmensstrategie, der Geschäftsprozesse und der Strukturorganisation sowie des Informationssystems.

1.4.1 Framework-Überblick

Das Framework für (Konzern-)Stammdatenqualität bietet eine Lösung für diese Gestaltungsaufgabe, indem es den Ansatz des Business Engineering auf das unternehmensweite Datenqualitätsmanagement überträgt (siehe Abb. 1.11). Generell ist Business Engineering die methodenorientierte und modellbasierte Konstruktionslehre für Unternehmen des Informationszeitalters (Österle und Winter 2003). Gestaltet werden Artefakte auf den drei Ebenen „Strategie“, „Organisation“ und „Systeme“ in sechs Gestaltungsbereichen (Otto 2011b; Otto et al. 2011). Jeder Gestaltungsbereich hat eigene Ergebnistypen (Dokumente).

Abb. 1.11
Framework für unternehmensweites Datenqualitätsmanagement. (nach Otto et al. 2011, S. 10)

1.4.2 Strategieebene

Die „Datenqualitätsmanagementstrategie“ richtet das Datenqualitätsmanagement an den Unternehmenszielen aus (siehe Tab. 1.3).

Tab. 1.3
Ergebnisse der Datenqualitätsstrategie

Ergebnistyp

Prüffragen zum Gestaltungsfortschritt

Handlungsauftrag

Ist der Handlungsauftrag organisatorisch zugeordnet? Weiß die betreffende Stelle um die Aufgaben und Verantwortungen?

Zieldefinition

Sind die Ziele des Datenqualitätsmanagements, also z. B. die kritischen Daten, aus den Unternehmenszielen abgeleitet?

Leitlinien

Sind die Leitlinien des Datenqualitätsmanagements entworfen und kommuniziert?

Ein Beispiel für den Zusammenhang zwischen Datenqualitätsmanagement und den Zielen des Unternehmens findet sich bei der DB Netz AG, die für die Eisenbahninfrastruktur in Deutschland zuständig ist. Zur Eisenbahninfrastruktur gehören das Gleisnetz, Tunnels, Brücken, Bahnhöfe etc. Eine Leistungs- und Finanzierungsvereinbarung regelt die Mittelzuwendung des Bundes an die DB Netz AG im Sinne einer Bezuschussung für Instandhaltungsarbeiten an der Eisenbahninfrastruktur. Die Höhe des jährlichen Zuschusses hängt – in gewissen Grenzen – direkt von der Qualität des Infrastrukturkatasters ab, in welchem u. a. Anzahl, Wartungszustand und gewisse Leistungsparameter (zum Beispiel zulässige Geschwindigkeiten) sämtlicher Infrastrukturanlagen erfasst werden. Eine hohe Konsistenz, Aktualität, Vollständigkeit und Verfügbarkeit der Stammdaten zu Infrastrukturanlagen beeinflusst also positiv die Finanzausstattung des gesamten Unternehmens.

1.4.3 Organisatorische Ebene

Die organisatorische Ebene umfasst drei Gestaltungsbereiche, nämlich das Führungssystem für Datenqualitätsmanagement (auch: „Datenqualitäts-Controlling“ oder „Qualitätssicherung“), die DQM-Organisation sowie Prozesse und Methoden für DQM.

Datenqualitätsmanagement kann nur dann zielgerichtet betrieben werden, wenn quantifiziert wird, was „gute“ (Stamm-)daten sind. Dazu muss die Qualität der Daten gemessen werden. Datenqualitätskennzahlen sind ein quantitatives Maß für Datenqualität (Hüner 2011)[11]. Entscheidend beim Aufbau eines Kennzahlensystems für Datenqualität ist herauszufinden, was gemessen werden soll und was gemessen werden kann. Kennzahlensysteme für Datenqualität müssen sich an den fachlichen Erfordernissen orientieren und sind – soweit möglich – mit den Kennzahlen für Geschäftsprozesse zu koppeln. Tabelle 1.4 stellt die Ergebnisse des Gestaltungsbereichs „Führungssystem“ dar.

Tab. 1.4
Ergebnisse des Führungssystems

Ergebnistyp

Prüffragen zum Gestaltungsfortschritt

Kennzahlensystem für Stammdatenqualität

Gibt es Kennzahlen für Datenqualität? Haben die Kennzahlen Geschäftsbezug? Ist das Messverfahren definiert? Gibt es Zielwerte für Datenqualität?

Zielsystemintegration

Sind die Ziele für Datenqualität in das Zielsystem des Unternehmens integriert (z. B. in die Jahreszielvereinbarungen von Mitarbeitern)?

Weil das Management von Stammdaten ein Querschnittsthema ist, müssen die Aufgaben des Datenmanagements über die einzelnen Divisionen und Geschäftsbereiche des Unternehmens hinweg koordiniert werden. Diesem Zweck dient die Organisation des DQM. Sie ist in vielen Unternehmen eine virtuelle Organisation, in welcher die Mitarbeiter disziplinarisch in ihren ursprünglichen Berichtslinien verbleiben und zusätzlich in einer neuen fachlichen Berichtslinie eingebunden sind (Tab. 1.5).

Tab. 1.5
Ergebnisse der Organisation

Ergebnistyp

Prüffragen zum Gestaltungsfortschritt

Rollen

Sind alle Rollen im Datenmanagement identifiziert, beschrieben und zugeordnet? Nehmen Rolleninhaber die Rolle wahr?

Verantwortlichkeiten

Sind Rollen Entscheidungsbereichen zugeordnet? Werden Entscheidungen gemäß der Zuordnung getroffen? Sind die Verantwortlichkeiten im Unternehmen kommuniziert? Ist bei der Zuordnung das Kongruenzprinzip gewahrt (d. h. Umfang der Aufgabe muss zu Kompetenz und Pflichten passen)?

Die Organisation des Datenqualitätsmanagements manifestiert sich in den Rollen des DQM sowie der Zuordnung von Verantwortlichkeiten zu diesen Rollen. In der Praxis haben sich verschiedene Rollen herausgebildet, um die Aufgaben eines unternehmensweiten Datenqualitätsmanagements wahrzunehmen. Neben der Identifikation und Beschreibung der Rollen im Datenqualitätsmanagement müssen die Verantwortlichkeiten definiert sein. Verantwortlichkeiten geben an, welche Aufgabenbereiche und Rechte (z. B. Anweisungs-, Planungs-, Entscheidungs-, Mitspracherechte) einer Rolle im Stammdatenmanagement zugeordnet sind. Ein Aufgabenbereich ist z. B. die Entwicklung eines einheitlichen Datenmodells für die übergreifend verwendeten Geschäftsobjekte. Hauptverantwortlich (im Sinne des englischen „responsible“) dafür ist in vielen Fällen der Konzern-Datensteward, der auch für den Aufbau des Stammdatenmanagements zuständig ist. Neben dem Konzern-Datensteward werden oft weitere Rollen von Datenverantwortlichen definiert, die das notwendige fachliche und technische Wissen haben, um z. B. das Datenmodell freizugeben oder Nachbesserungen zu fordern. Der Data Owner (auch „Dateneigner“) ist im Sinne des englischen „accountable“ für bestimmte Datenobjekte verantwortlich und meist ein Vertreter des Managements (z. B. Leiter Zentraleinkauf, Leiter Supply Chain Management) eines Fachbereichs.

Der vierte Gestaltungsbereich „DQM-Prozesse und -Methoden“ bezieht sich auf das Lebenszyklusmanagement für Stammdaten sowie diejenigen Prozesse, nach denen die Mitarbeiter des Datenqualitätsmanagements arbeiten (Tab. 1.6).

Tab. 1.6
Ergebnisse der Prozesse und Methoden

Ergebnistyp

Prüffragen zum Gestaltungsfortschritt

Lebenszyklus-Management für Stammdaten

Ist für jede Stammdatenklasse klar definiert, in welchen Aktivitäten der Geschäftsprozesse die Daten erzeugt, verändert, erweitert, gelesen, gelöscht und archiviert werden? Ist der Datenpflegeprozess für diesen Lebenszyklus entworfen, modelliert und implementiert?

Funktionsbeschreibungen

Gibt es klare Funktionsbeschreibungen für die Aktivitäten des Datenqualitätsmanagements im Unternehmen? Sind standardisierte Verfahren definiert und kommuniziert? Sind die Aktivitäten in die Geschäftsprozessarchitektur des Unternehmens eingebettet?

Eine der wichtigsten Ursachen für schlechte Datenqualität ist das Fehlen einer gesamthaften Bewirtschaftung einzelner Stammdatenklassen. Unternehmen sind nach Funktionen (z. B. Einkauf, Vertrieb), Ländern bzw. Märkten und Geschäftsprozessen (z. B. „Order-to-cash“, „Make-to-Stock“) organisiert. Deshalb gibt es in nur wenigen Unternehmen eine Stelle, welche den Gesamtüberblick darüber hat, wo ein Stammdatum erfasst, geändert, verwendet und zum Löschen markiert wird.

Die Aufgabe, Ursachen und Auswirkungen niedriger Stammdatenqualität zu analysieren, ist deshalb sehr komplex. Ursachen sind zumeist Aktionen, die innerhalb von Anwendungssystemen mit den Daten ausgeführt werden (z. B. anlegen, ändern, ergänzen, löschen). Diese Aktionen wiederum haben Auswirkungen auf Geschäftsprozesse, deren Qualität sich durch Kennzahlen quantifizieren lässt.

1.4.4 Informationssystemebene

Die Systemebene umfasst zwei Gestaltungsbereiche, nämlich die DQM-Architektur und die Anwendungssysteme für das Datenqualitätsmanagement.

Die Ergebnisse des Gestaltungsbereichs „DQM-Architektur“ fasst Tab. 1.7 zusammen.

Tab. 1.7
Ergebnisse der Unternehmensdatenarchitektur

Ergebnistyp

Prüffragen zum Gestaltungsfortschritt

Kerngeschäftsobjektmodell

Sind die Kerngeschäftsobjekte bekannt? Sind sie eindeutig definiert und beschrieben? Sind Abhängigkeiten untereinander bekannt? Sind unternehmensweite Merkmale bestimmt und definiert?

Stammdatendatenmodell

Gibt es ein Stammdatenmodell, welches aus dem Kerngeschäftsobjektmodell abgeleitet ist?

Datenhaltungs- und Datenverteilungsarchitektur

Ist die Datenhaltungsarchitektur (führendes System, Zentralsystem etc.) für jede Stammdatenklasse definiert? Sind die Datenflüsse zwischen den Systemen analysiert?

Das Kerngeschäftsobjektmodell ist ein zentrales Ergebnis des Datenqualitätsmanagements, weil es die Voraussetzung für ein einheitliches Verständnis der Daten und damit auch für die intendierte Nutzung der Daten ist. Seine Entwicklung und sein Fortschrieb muss durch Einbeziehung der Fachbereiche erfolgen, weil nur dort das Wissen um die Bedeutung der Stammdaten in den Geschäftsprozessen verfügbar ist. Für die informationstechnische Umsetzung wird das Kerngeschäftsobjektmodell in ein Konzerndatenmodell überführt.

Die Datenverteilungs- und Datenhaltungsarchitektur beschreibt, welche Daten in welchen Systemen gespeichert werden und zeigt die Datenflüsse zwischen den Systemen. Schließlich bildet die Anwendungssystemlandschaft für das Datenqualitätsmanagement den sechsten Gestaltungsbereich. Die Ergebnisse dieses Gestaltungsbereichs sind in Tab. 1.8 dargestellt.

Tab. 1.8
Ergebnisse der Anwendungssysteme

Ergebnistyp

Prüffragen zum Gestaltungsfortschritt

Auslegeordnung

Welche Softwarefunktionalität wird für das Stammdatenmanagement heute und in Zukunft benötigt?

Bebauungsplan

Welche Anwendungssysteme stellen welche Funktionalität bereit? Welche Kriterien werden bei der Auswahl und Bewertung der Anwendungssysteme herangezogen?

Dieser Gestaltungsbereich bezieht sich auf die Analyse, den Entwurf, die Implementierung und Verbesserung derjenigen Anwendungssysteme, welche zur Unterstützung des Datenqualitätsmanagements benötigt werden. Dazu gehören zum einen spezielle Stammdatenmanagementsysteme wie SAP Netweaver MDM und zum anderen Softwarewerkzeuge zur Verwaltung des Kerngeschäftsobjektmodells. In der Auswahl dieser Anwendungssysteme für das Stammdatenmanagement müssen Aspekte der Datenmodellierung, des Datenqualitätsmanagements, der Sicherheit, der Benutzungsschnittstellen, der Datenverteilungsarchitekturen und insbesondere die Art der Integration, sowohl bezogen auf Systeme als auch auf die zu integrierenden Informationen, betrachtet werden. Das Fraunhofer-Institut für Arbeitswirtschaft und Organisation liefert einen ausführlichen Vergleich etablierter Systeme (Kokemüller 2009).

1.5 Begriffsdefinitionen und Grundlagen

Das Management von Stammdaten und ihrer Qualität ist kein grundsätzlich neues Thema, die Durchdringung aller Wirtschaftsbereiche mit digitalen Services hat nur seinen Stellenwert drastisch gesteigert. Es wird in Forschung und Praxis diskutiert, seit Unternehmen Informationssysteme zur Unterstützung von Geschäftsprozessen einsetzen. Es ist deshalb sowohl für die Forschung als auch die Praxis von besonderer Bedeutung zu wissen, welche Lösungen bereits existieren, welche sich behauptet haben und welche nicht. Dafür gilt es zunächst die zentralen Konzepte und Begriffe des Datenqualitätsmanagements zu klären. Abbildung 1.12 stellt die wichtigsten Begriffe und ihre Beziehung zueinander dar.

Abb. 1.12
Begriffslandkarte für das Datenqualitätsmanagement. (eigene Darstellung)

1.5.1 Daten und Information

Daten beschreiben die Eigenschaften von Geschäftsobjekten, also materielle und immaterielle Objekte der Realwelt (Boisot und Canals 2004). Zwar gibt es viele Arbeiten zur Unterscheidung von Daten und Information, aber ein eindeutiges und akzeptiertes Verständnis dazu hat sich bisher nicht durchgesetzt (Boisot und Canals 2004; Badenoch et al. 1994). Eine Lehrmeinung fasst Informationen als Wissen auf, das während der menschlichen Kommunikation ausgetauscht wird, während eine zweite eine Informationsverarbeitungsperspektive einnimmt, in der Daten die Bausteine von Information sind (Oppenheim et al. 2003). Demnach werden Daten zu Informationen „verarbeitet“ (Van den Hoven 1999; Holtham 1995; Wang 1998). Nach ISO/IEC 2382-1 sind Daten die formalisierte, d. h. für die weiterführende Verarbeitung, Interpretation und Kommunikation geeignete Repräsentation der Eigenschaften von Geschäftsobjekten (ISO/IEC 1993).

Die logische Datenorganisation unterscheidet verschiedene Aggregationsebenen (Chen 1976; Levitin und Redman 1998; Yoon et al. 2000). Datenelemente bilden die unterste Aggregationsebene. Datenelemente sind die Instanziierungen der Attribute von Datenobjekten (z. B. Nachname eines Kunden). Die zweite Aggregationsebene bilden Datensätze. Ein Datensatz ist die Instanziierung eines Datenobjekts. Zum Beispiel bildet ein Kundenstammdatensatz mit allen Merkmalen das Geschäftsobjekt „Kunde“ so ab, dass alle Geschäftsprozesse rund um den Kunden (Vertrieb, Service, Debitorenbuchhaltung) reibungslos ablaufen. Auf der dritten Aggregationsebene fassen Tabellen mehrere Datensätze zusammen, z. B. in einer Kundenstammdatentabelle. Datenbanken wiederum aggregieren mehrere Tabellen. Eine Kundenmanagement-Datenbank könnte alle Kundenstammdaten sowie die zugehörigen Vertriebsdaten enthalten. Die Gesamtheit aller Datenbanken im Unternehmen bildet schließlich den Unternehmensdatenbestand (engl. Data Resource). Abbildung 1.13 visualisiert diese Beziehungen. Diese Darstellung der Datenorganisation richtet sich nach dem relationalen Datenmodell. Im idealen, semantisch eindeutigen Fall gibt es eine 1:1-Beziehung zwischen der Datenwelt und der realen Welt, d. h. ein Datenobjekt bildet genau ein Geschäftsobjekt ab. In der Realität gibt es jedoch oft mehrere Datenobjekte parallel, die dasselbe Geschäftsobjekt repräsentieren. In diesem Fall ist das Datenqualitätsmanagement gefordert, Richtlinien, Prozesse und Systeme zu etablieren, die erlauben, das für einen bestimmten Kontext „richtige“ Datenobjekt zu identifizieren und für die Nutzung in Geschäftsprozessen bereitzustellen.

Abb. 1.13
Übersicht der logischen Datenorganisation. (eigene Darstellung)

1.5.2 Stammdaten

Der Standard ISO 8000 der International Organization for Standardization (ISO) (ISO 2009) definiert Stammdaten als Informationsobjekte, „welche unabhängig und fundamental für eine Organisation sind. [Stammdaten] müssen referenziert werden, um Transaktionen durchführen zu können.“ Diese Daten müssen innerhalb eines Unternehmens über mehrere Organisationseinheiten hinweg eindeutig identifiziert und einheitlich interpretiert werden. Dabei sind Konzerndaten sogenannte „globale“ Stammdaten, die für das gesamte Unternehmen gelten. Im Gegensatz dazu gelten „lokale“ Stammdaten nur z. B. für einen Geschäftsbereich, einen Standort oder eine Unternehmensfunktion. Im Fokus der hier vorgestellten Methoden und Werkzeuge stehen die Konzerndaten. Da sich im allgemeinen Sprachgebrauch sowie in kommerziellen Softwarelösungen jedoch der Begriff „Stammdaten“ durchgesetzt hat, verwendet das Buch überwiegend diese gängigere Bezeichnung.

Stammdaten verändern sich im Gegensatz zu Bewegungs- oder Bestandsdaten vergleichsweise selten. Diese Daten werden darum manchmal auch als „static data“ (statische Daten) bezeichnet. In der Praxis ist es nicht möglich, eine allgemeingültige Liste aller Stammdatenklassen zu definieren. So gelten z. B. Daten zu Verträgen in der Energie- und Versicherungswirtschaft als Stammdaten, in der Telekommunikationsbranche hingegen aufgrund der im Vergleich kurzen Laufzeiten und häufigen Änderungen faktisch als Bewegungsdaten.

Die Firma Bosch z. B. klassifiziert folgende Daten als Stammdaten (Hatz 2008):

- Kunden

- Kundenhierarchien

- Materialien

- Lieferanten

- Mitarbeiter

- Kontenpläne

- Organisationseinheiten

In der Praxis ist weniger relevant, wie Stammdaten von Bewegungs- und Bestandsdaten abzugrenzen sind, sondern vielmehr, welche einzelnen Attribute einer Stammdatenklasse von einem zentralen Stammdatenmanagement verwaltet werden müssen. Denn eine zentrale Organisationseinheit kann diese Aufgabe aufgrund der Komplexität einzelner Stammdatenklassen nicht in vollem Umfang unternehmensweit übernehmen. Grundsätzlich beantwortet sich die Frage, welche Attribute einer Stammdatenklasse zum Umfang des zentralen Stammdatenmanagements gehören, aus der Analyse der strategischen Anforderungen jedes einzelnen Unternehmens.

Dabei können nach (White 2010; White und Radcliffe 2007) folgende Unterscheidungsmerkmale helfen:

- Organisatorische Reichweite: Unterscheidung zwischen „globalen“, also unternehmensweit genutzten Konzerndaten und lokalen Daten

- Datentyp: Unterscheidung zwischen „strukturierten“ Daten, welche typischerweise in relationalen Datenbanken verwaltet werden, und „unstrukturierten“ Daten wie Produktinformationen (z. B. Bilder, Werbetexte, Applikationsvideos)

- Ort der Metadatendefinition: Unterscheidung zwischen interner Definition von Bedeutung, Formaten sowie Standardwerten einerseits und externer Definition andererseits (zum Beispiel bei Länder- und Währungscodes der ISO sowie Klassifikationsstandards wie eCl@ss und UN/SPSC)

Stammdaten, die extern definiert sind, heißen Referenzdaten. Beispiele sind, wie oben erwähnt, Ländercodes und Währungscodes sowie Geodaten. Metadaten (wörtlich „Daten über Daten“) beschreiben und definieren Eigenschaften von anderen Daten (DAMA 2008, S. 84). Eine Unterart von Metadaten sind z. B. Änderungsdaten. Diese halten fest, wann, wie und von wem ein bestimmtes Datum geändert wurde.

1.5.3 Datenqualität

Datenqualität ist ein mehrdimensionales, kontextabhängiges Konzept (Wang und Strong 1996). Es gibt also nicht ein einziges Merkmal, das Datenqualität vollständig beschreibt. Vielmehr gibt es verschiedene Datenqualitätsdimensionen, die in ihrer Gesamtheit die Qualität von Daten beschreiben. Typische Datenqualitätsdimensionen sind[12]:

- Korrektheit: Stimmen die Daten sachlich richtig mit den Eigenschaften des Objekts in der realen Welt überein, das sie repräsentieren sollen?

- Konsistenz: Stimmen mehrere Datenversionen desselben realen Objekts, die z. B. in unterschiedlichen Informationssystemen gehalten werden, miteinander überein?

- Vollständigkeit: Sind alle Werte/Attribute eines Datensatzes komplett vorhanden?

- Aktualität: Stimmen die Daten zu jedem Zeitpunkt mit dem aktuellen Status des realen Objekts überein und werden die Daten angepasst, wenn es sich ändert?

- Verfügbarkeit: Sind die Daten für Datennutzer zum gewünschten Zeitpunkt problemlos zugänglich?

Kontextabhängigkeit bedeutet, dass Datenqualität für einen Geschäftsvorfall ausreichend sein kann, für einen anderen hingegen ungenügend. Zum Beispiel ist für die Logistikabteilung eines Automobilzulieferers die korrekte Lieferadresse eines Kunden einschließlich der korrekten Frachtrampe essentiell zur Bedienung eines Auftrags. Für die Vertriebsabteilung desselben Unternehmens sind Korrektheit und Konsistenz der Lieferadresse dagegen unerheblich, da ihr z. B. für eine Auswertung über den mit diesem Kunden im vergangenen Jahr eingenommenen Umsatz allein Unternehmensname und Landeszuordnung ausreicht. Deshalb ist Datenqualität insgesamt definiert als ein Maß für die Eignung der Daten für bestimmte Anforderungen in Geschäftsprozessen, in denen sie verwendet werden (Otto et al. 2011).

Datenqualität ändert sich über die Zeit, weil die Daten lediglich ein Abbild der Wirklichkeit darstellen, sich diese Wirklichkeit aber verändert. Zum Beispiel ziehen Kunden um und Lieferanten ändern ihre Rechtsform. Abbildung 1.14 stellt einen typischen Datenqualitätsverlauf dar, wie er in vielen Unternehmen zu finden ist.

Abb. 1.14
Typischer Datenqualitätsverlauf über die Zeit in Unternehmen. (Otto 2014, S. 21)

Viele Unternehmen beginnen erst mit der Lösung der Datenqualitätsprobleme, wenn die Datenqualität bereits unter ein Maß gesunken ist, das reibungslose Geschäftsprozesse ermöglicht. Migrationsprobleme, hoher manueller Aufwand in Geschäftsprozessen, Management Reports mit unterschiedlichen Werten zur gleichen Kennzahl sind Beispiele für die Datenqualitätsprobleme, die plötzlich sichtbar werden, nachdem die Datenqualität zuvor schleichend abgefallen ist.

1.5.4 Datenqualitätsmanagement (DQM)

Die Analyse, Verbesserung und Sicherung der Datenqualität ist Aufgabe des DQM. Wiederum unter Übernahme produktionswirtschaftlicher Ansätze versteht die Data Management Association (DAMA) unter DQM sämtliche Aktivitäten, Verfahren und Systeme, die unter Nutzung von Methoden des Qualitätsmanagements die Eignung der Daten zur Nutzung messen, verbessern und sichern (DAMA 2008).

DQM unterscheidet generell zwischen präventiven und reaktiven Maßnahmen. Präventives DQM zielt darauf ab, Datendefekte mit negativer Auswirkung auf die Datenqualität zu vermeiden. Im Gegensatz dazu zielt das reaktive DQM darauf ab, bestehende Datendefekte zu entdecken und zu beheben.

Der reaktive Ansatz hat mehrere Nachteile:

- Ressourcen für die Verbesserung der Datenqualität (z. B. Software, Expertenwissen, Beratungsleistungen) sind nicht eingeplant und budgetiert und damit im Zweifel nicht verfügbar.

- Rein reaktives Datenqualitätsmanagement geht häufig damit einher, dass Datenqualität nicht gemessen wird. In solchen Fällen fehlen dem Unternehmen häufig Zielwerte, d. h. es ist nicht überprüfbar, ob die (reaktiven) Maßnahmen zur Verbesserung der Datenqualität ausreichen oder gar über das Ziel „hinausschießen“.

- Das Total Quality Management, ein Qualitätsmanagementansatz aus dem Operations Management, zeigt, dass die Summe der Kosten aller reaktiven Maßnahmen im Qualitätsmanagement die Kosten eines präventiven Qualitätsmanagements übersteigt (Reid und Sanders 2005). Das gilt für materielle Güter wie für immaterielle (z. B. Daten).

Ein Beispiel für eine präventive DQM-Maßnahme ist die Nutzung von automatischen Prüfregeln (auch „Geschäftsregeln“, siehe folgender Abschnitt) bei einer manuellen Dateneingabe. Ein wichtiges und von vielen Unternehmen verwendetes Stammdatum ist die DUNS-Nummer (Data Universal Numbering System), ein Zahlencode zur Identifikation von Unternehmen. Für diesen Fall sind Dienste verfügbar, die in Echtzeit die Gültigkeit der in ein systemgestütztes Formular eingegebenen Nummer überprüfen und so eine fehlerhafte Eingabe verhindern. Ein Beispiel für eine reaktive Maßnahme im selben Fall ist die nachträgliche Datenbereinigung von Duplikaten im gleichen oder in verschiedenen Datenbeständen.

Grundsätzliches Ziel von Unternehmen ist es, Datendefekte möglichst zu erkennen, bevor sie eintreten, um Risiken und Kosten infolge mangelnder Datenqualität zu vermeiden. Jedoch verursachen nicht nur defekte Daten Kosten, sondern auch das DQM. DQM-Kosten fallen sowohl für präventive als auch für reaktive Maßnahmen an. In Analogie zum Qualitätsmanagement generell (Campanella 1999) kann ein überproportionaler Zusammenhang zwischen Datenqualität und DQM-Kosten unterstellt werden. Die Grenzkosten des DQM nehmen also zu. Im Gegensatz dazu nehmen die Folgekosten schlechter Daten ab, je höher die Datenqualität ist. Die gesamtkostenoptimale Datenqualität ergibt sich dann als Minimum der Summenfunktion aus DQM-Kosten und Folgekosten defekter Daten (Eppler und Helfert 2004) (Abb. 1.15). Aufgabe des DQM ist es somit, eine kostenoptimale Kombination aus präventiven und reaktiven Maßnahmen zu finden. In der Praxis treten dabei häufig Schwierigkeiten auf, weil das Rechnungswesen typischerweise viele DQM-Kosten nicht ausweist. Das gilt insbesondere für die Folgekosten, die in verschiedenen Unternehmensfunktionen anfallen und in weiten Teilen kaum zu quantifizieren sind.

Abb. 1.15
Datenqualitätskosten. (nach Eppler und Helfert 2004, S. 318)

1.5.5 Geschäftsregeln (Business Rules)

Die automatische Prüfung von Geschäftsregeln (engl. Business Rules) ist ein wichtiges Mittel sowohl für das proaktive als auch für das reaktive Datenqualitätsmanagement. Geschäftsregeln definieren die Ausführung und die Leistung von Geschäftsprozessen (Ross und Lam 2011). Geschäftsregeln formalisieren damit die Richtlinien (engl. business policies) im Unternehmen (OMG 2008). Sie helfen häufig dabei, dass Wissen „in den Köpfen“ der Mitarbeiter zu explizieren, damit es zur Wiederverwendung und Automatisierung in IT-Systemen festgehalten werden kann. Geschäftsregeln sind das Bindeglied zwischen dem Geschäftsprozess- und dem Datenmanagement. Denn neben der Steuerung von Geschäftsprozessen dienen Geschäftsregeln auch dazu, Datenqualität zu messen und zu kontrollieren. In der Praxis werden diese Regeln teilweise auch als „Validierungsregeln“ oder „Prüfregeln“ bezeichnet.

Einfache Geschäftsregeln definieren z. B. Pflichtfelder in Eingabemasken. So könnte eine einfache Regel für die Anlage eines Kundenstamms lauten, dass ein Kundenstammdatensatz nur dann vollständig ist, wenn er eine Rechtsform (GmbH, AG usw.) besitzt. Wird dieses Feld nicht ausgefüllt, kann der Datensatz nicht weiter bearbeitet werden. Im Standard SBVR (Semantics of Business Vocabulary and Business Rules) der Object Management Group werden solche Regeln als strukturelle Regeln (engl. structural rules) bezeichnet (OMG 2008). Ein komplexeres Beispiel wäre beispielsweise eine Regel, die steuert, nach welchen Kriterien über die weitere Behandlung einer Beschwerde im Kundenservice entschieden werden sollte. Eine solche Regel wird in SBVR als operative Regel (engl. operative rule) bezeichnet. Tabelle 1.9 zeigt ein Beispiel für strukturelle und operative Regeln.

Tab. 1.9
Beispiel für eine Geschäftsrichtlinie und Geschäftsregeln. (Ofner 2013, S. 51)

Geschäftsrichtlinie

Neue Lieferanten müssen in Übereinstimmung mit (globalen, national oder regionalen) gesetzlichen Vorgaben und Bestimmungen aufgenommen werden. Der Prozess muss nachvollziehbar sein.

Strukturelle Regel

Es ist notwendig (engl. nach SBVR-Standard: „It is necessary that“), dass jeder Lieferant einen Sicherheitskennzeichen hat.

Operative Regel

Es ist unerlässlich (engl. nach SBVR-Standard: „It is obligatory that“), dass das Sicherheitskennzeichen jedes Lieferanten, der Produkte in die USA liefert, auf „ja“ steht.

Formale Sprachen wie SBVR oder BPMN (Business Process Model and Notation) dokumentieren Geschäftsregeln so, dass sie sich einfach in Programmcode umsetzen lassen bzw. direkt maschinenlesbar sind. Die Gesamtmenge von Geschäftsregeln eines Unternehmens kann in einer Rule Engine verwaltet werden. Es ist Aufgabe des Datenqualitätsmanagements, die für die Sicherstellung hoher Datenqualität relevanten Geschäftsregeln zu identifizieren, zu dokumentieren, umzusetzen und zu pflegen.

Zusammengefasst bieten Geschäftsregeln folgende Vorteile für das DQM:

- Automatisierung: Sie automatisieren Teile von Geschäftsprozessen und können diese damit beschleunigen und manuelle Aufwände reduzieren (z. B. durch automatisches Vor-Ausfüllen IT-gestützter Formulare).

- Fehlervermeidung: Geschäftsregeln helfen dabei, Flüchtigkeits- und vorsätzliche Fehler zu vermeiden (Prüfregeln verhindern, dass obligatorische Felder „vergessen“ werden können). Dies ist eine Maßnahme für proaktives Datenmanagement.

- Messung und Steuerung der Datenqualität: Datensätze können erst kontinuierlich oder periodisch auf Regelkonformität überprüft werden, nachdem Geschäftsregeln definiert und in IT-Systeme implementiert wurden. Nur so können automatisiert Fehler in Datensätzen entdeckt werden, bevor diese Fehler in Geschäftsprozessen verursachen. Dieses Wissen kann erstens dazu verwendet werden, Maßnahmen zur Verbesserung der Datenqualität zu initiieren (Maßnahme des reaktiven Datenqualitätsmanagements). Zweitens kann das Ergebnis der Datenqualitätsmessung über Geschäftsregeln in einem Datenqualitäts-Indikatorwert (auch „Datenqualitätsindex“ oder „Datenqualitäts-Zielwert“ genannt) ausgedrückt werden. Mit diesem Wert lässt sich die Veränderung der Datenqualität in einem System im Laufe der Zeit nachvollziehen und z. B. auch die Datenqualitätsentwicklung zwischen verschiedenen Geschäftseinheiten vergleichen.

- Bewusstsein für DQM: Eine Initiative zur Bestimmung von Geschäftsregeln trägt dazu bei, bei allen beteiligten Mitarbeitern ein Bewusstsein für die Bedeutung von DQM im Allgemeinen zu schaffen. Damit erhöhen sich die Chancen, dass Mitarbeiter auch solche Datenqualitätsprobleme bemerken, die nicht mit Regeln geprüft werden können.

Allerdings ist die Verwendung von Geschäftsregeln auch mit einigen Herausforderungen verbunden:

- Explikation: Da das Wissen über Geschäftsregeln meist nicht in Dokumenten vorliegt (zumindest nicht an einer einzelnen Stelle), sondern „in den Köpfen der Mitarbeiter“ verborgen ist, besteht die größte Herausforderung darin, dieses Wissen zu dokumentieren[13].

- Verringerung der Prozessflexibilität: Sind Geschäftsregeln zu restriktiv definiert, können sie bei seltenen oder unvorhergesehenen Prozessvarianten zu Mehraufwänden oder erst recht zu falschen Eingaben führen, wenn Mitarbeiter Regeln „umgehen“ müssen.

- Überbewertung der Aussagekraft eines Datenqualitätsindex: Ein guter Datenqualitätsindex sagt lediglich aus, dass die Daten gemessen an allen bekannten und implementierten Regeln korrekt sind. Falls diese Regeln aber unvollständig oder veraltet sind, wird das Datenqualitätslevel überschätzt. Daraus folgt, dass Geschäftsregeln aktiv verwaltet werden müssen: Wenn sich die Geschäftswirklichkeit ändert, müssen auch die Regeln geändert werden. Darüber hinaus müssen Datenqualitätsmanager akzeptieren, dass niemals sämtliche Datenqualitätsprobleme mit automatischen Prüfregeln erfassbar sind. Deshalb darf die Schulung und fortwährende Motivation der Mitarbeiter, im Alltag mit „gesundem Menschenverstand“ auf Datenqualität zu achten, auch nach der Implementierung von Geschäftsregeln nicht vernachlässigt werden.

1.5.6 Data Governance

Data Governance unterscheidet sich von DQM. Data Governance verfolgt das Ziel, den Wert der Daten im Unternehmen zu maximieren (Otto 2011a). Die wertmäßige Betrachtung von Daten im Sinne eines Anlageguts geht ebenfalls zurück auf die Übertragung von Konzepten zur Bewirtschaftung materieller Güter auf den Umgang mit Daten (Horne 1995). Heute diskutieren Forschung und Praxis, ob der Wert von Daten für Unternehmen auch finanzbuchhalterisch erfasst werden kann und soll (Atkinson und McGaughey 2006). Grundsätzlich besitzen Daten nur dann einen Wert, wenn sie genutzt werden. Ihre Eignung zur Nutzung wiederum ist definiert als Datenqualität (s. o.). Niedrige Datenqualität schmälert den Wert der Datengüter im Unternehmen, weil ihre Nutzbarkeit gering ist (Even und Shankaranarayanan 2007). Unternehmen sind also bestrebt, mit dem DQM eine von der Geschäftsstrategie geforderte Datenqualität zu erreichen.

Die Beziehung zwischen DQM und Data Governance folgt der von der ISO vorgeschlagenen Unterscheidung zwischen Governance und Management (ISO/IEC 2008). In diesem Sinne bildet Data Governance die Führungsfunktion für das DQM. Denn Data Governance legt fest, welche Entscheidungen im Umgang mit Daten zu treffen sind und wer sie trifft. Aufgabe des DQM ist es, die datenqualitätsrelevanten Entscheidungen zu fällen und umzusetzen.

Abbildung 1.16 stellt diesen Zusammenhang grafisch dar.

Abb. 1.16
Datenqualitätsmanagement und Data Governance. (Otto 2011a, S. 236)

1.6 Kompetenzzentrum Corporate Data Quality

Das Kompetenzzentrum Corporate Data Quality (CC CDQ) ist ein Konsortialprojekt, das Lösungen für die dauerhafte Sicherung von Datenqualität in großen Unternehmen erforscht, entwickelt und überprüft.

Konsortialforschung findet im Verbund von Forschungseinrichtungen und Unternehmen statt, die an einem Thema von gemeinsamem Interesse arbeiten. Konsortialforschung hat mehrere Ziele (Österle und Otto 2010):

- Forscher und Praxispartner definieren gemeinsam die Forschungsziele, bewerten die laufende Arbeit und evaluieren die Projektergebnisse.

- Mehrere Partnerunternehmen bringen ihre Expertise ein und gewähren den Forschern Zugang zu ihrem Wissen.

- Die Forschungsergebnisse sind Artefakte (z. B. Methoden, Modelle oder Prototypen), die zur Lösung praktischer Probleme beitragen.

- Der Gestaltungsprozess ist mehrfach iterativ und umfasst Iterationszyklen über vier Phasen und mehrere Partnerunternehmen.

- Die Partnerunternehmen testen die Artefakte in ihrem betrieblichen Umfeld.

- Die Partnerunternehmen finanzieren das Projekt mindestens in Teilen.

- Forscher und Praktiker nehmen über einen signifikanten Zeitraum hinweg an dem Projekt teil (in der Regel zwei Jahre).

- Die Forschungsergebnisse werden der Öffentlichkeit zugänglich gemacht.

Konsortialforschung läuft, nach ähnlichen Prinzipien wie der Action Design Research (Sein et al. 2011), zyklisch ab, d. h. Ergebnisse werden kontinuierlich an den Anforderungen der Forschung und Praxis gemessen, weiterentwickelt und getestet. Abbildung 1.17 stellt diesen Ablauf dar.

Abb. 1.17
Konsortialforschung. (Österle und Otto 2010, S. 278)

In regelmäßigen Workshops treffen sich die Mitglieder des Konsortiums und tauschen Erfahrungen aus, besprechen offene Punkte und arbeiten gemeinsam an Methoden, Modellen und Lösungen. Sogenannte bilaterale Projekte überprüfen die Ergebnisse anschließend unternehmensindividuell.

Das CC CDQ startete im November 2006 mit dem Ziel, Antworten auf folgende Fragen zum Datenqualitätsmanagement zu finden:

- Welchen Beitrag liefert Stammdatenqualität zu den Unternehmenszielen?

- Wie steht das eigene Unternehmen im Vergleich zu anderen?

- Wie lässt sich die Leistung des Datenqualitätsmanagements messen?

- Was sind Kosten und Nutzen der Datenqualität?

- Wie etablieren Unternehmen Data Governance in der Organisation?

- Was ist das richtige Maß an Standards und Regulierung für die Daten?

- Wie ist ein gemeinsames Verständnis über die Stammdaten im ganzen Unternehmen zu schaffen?

- Was ist die richtige Datenarchitektur?

- Welchen Beitrag leisten innovative Technologien wie das Semantic Web und In-Memory Computing?

Seit 2006 nahmen 30 Unternehmen am CC CDQ teil. Durchschnittlich sind ca. zehn bis vierzehn Unternehmen gleichzeitig aktiv und die Verweildauer im Konsortium reicht von zwei bis über sieben Jahre. Tabelle 1.10 listet sämtliche aktuellen und ehemaligen Unternehmen auf, die seit der Gründung des CC CDQ im Jahr 2006 Partner im Kompetenzzentrum waren.

Tab. 1.10
Mitglieder des CC CDQ seit Gründung im Jahr 2006 (in alphabetischer Reihenfolge)

Unternehmen

Dauer der Mitgliedschaft im CC CDQ

ABB Ltd.

2014 – Gegenwarta

AO Foundation

2011 – 2012

AstraZeneca PLC

2012 – Gegenwart

Bayer AG

2006 – Gegenwart

Beiersdorf AG

2010 – Gegenwart

Corning Cable Systems GmbH

2012

Daimler AG

2007–2008

DB Netz AG

2008–2009; 2014 – Gegenwart

Drägerwerk AG & Co. KGaA

2013 – Gegenwart

eCl@ss e. V.

2014 – Gegenwart

E.ON SE

2007–2008

Ericsson AB

2014 – Gegenwart

ETA SA

2006–2008

Festo AG & Co. KG

2010– Gegenwart

Hewlett-Packard GmbH

2008–2010

IBM Deutschland GmbH

2007–2011

Kion Information Management Service GmbH

2010–2012

Merck KGaA

2014 – Gegenwart

Migros-Genossenschafts-Bund

2009

Nestlé SA

2008 – Gegenwart

Novartis Pharma AG

2008–2010; 2014

Osram GmbH

2013 – Gegenwart

Robert Bosch GmbH

2007 – Gegenwart

SAP AG

2012–2014

Schweizerische Bundesbahnen SBB

2013 – Gegenwart

Schaeffler AG

2014 – Gegenwart

Siemens Enterprise Communications GmbH & Co. KG

2010–2013

Swisscom (Schweiz) AG

2012 – Gegenwart

Syngenta Crop Protection AG

2009–2013

Telekom Deutschland GmbH

2008–2010

ZF Friedrichshafen AG

2007 – Gegenwart

a Entspricht dem Zeitpunkt der Fertigstellung des Manuskripts im Februar 2015

In den meisten Fällen nehmen Vertreter sowohl aus Fachbereichen (z. B. Supply Chain Management, Finanzen) und Informatikabteilung am CC CDQ teil. Dadurch ist gewährleistet, dass immer eine fachliche und eine informationstechnische Perspektive auf das Thema eingenommen werden.

Die Fallstudien in Kap. 2 und die Werkzeuge und Methoden in Kap. 3 sind Ergebnisse des CC CDQ.

Open Access Dieses Kapitel wird unter der Creative Commons Namensnennung-Nicht kommerziell 4.0 International Lizenz (http://creativecommons.org/licenses/by-nc/4.0/deed.de) veröffentlicht, welche für nicht kommerzielle Zwecke die Nutzung, Vervielfältigung, Bearbeitung, Verbreitung und Wiedergabe in jeglichem Medium und Format erlaubt, sofern Sie den/die ursprünglichen Autor(en) und die Quelle ordnungsgemäß nennen, einen Link zur Creative Commons Lizenz beifügen und angegeben, ob Änderungen vorgenommen wurden.

Literatur

AFNOR (Association Française de Normalisation): General principles for an environmental communication on mass market products. La Plaine Saint-Denis, 2009

Aggarwal, Charu C.; Ashish, Naveen; Sheth, Amit P.: The Internet of Things: A Survey from the Data-Centric Perspective. In: Aggarwal, C. C. (Hrsg.): Managing and Mining Sensor Data. New York: Springer, 2013, S. 383–428. – DOI 10.1007/978146146309212

Amiona: AppMapp. – Internetquelle. Aktualisierungsdatum 2014-02-14. Abgerufen 2014-12-05 von: http://www.amiona.com/index.php/downloads/viewdownload/3-appmap/2-amiona-appmap

Anthes, Gary: Data Brokers Are Watching You. In: Communications of the ACM 58 (2015), Nr. 1, S. 28–30. – DOI 10.1145/2686740

Atkinson, Keith; McGaughey, Ronald: Accounting for data: a shortcoming in accounting for intangible assets. In: Academy of Accounting and Financial Studies Journal 10 (2006), Nr. 2, S. 85–95

Baars, Henning; Kemper, Hans-Georg: Management Support with Structured and Unstructured Data: An Integrated Business Intelligence Framework. In: Information Systems Management 25 (2008), Nr. 2, S. 132–148. – DOI 10.1080/10580530801941058

Badenoch, Douglas; Reid, Christine; Burton, Paul; Gibb, Forbes; Oppenheim, Charles: The value of information. In: Feeney, Mary; Grieves, Maureen (Hrsg.): The value and impact of information. London: Bowker-Saur, S. 9–75

Bauernhansl, Thomas; ten Hompel, Michael; Vogel-Heuser, Birgit (Hrsg.): Industrie 4.0 in Produktion, Automatisierung und Logistik. Wiesbaden : Springer Fachmedien, Vieweg+Teubner, 2014. – DOI 10.1007/978-3-658-04682-8

BBC (British Broadcasting Corporation): Sony fined over ‚preventable‘ PlayStation data hack. – Internetquelle. Aktualisierungsdatum 2013-05-10. Abgerufen 2015-02-05 von http://www.bbc.co.uk/news/technology-21160818.

Bitkom: Big-Data-Technologien – Wissen für Entscheider: Leitfaden. Berlin: Bundesverband Informationswirtschaft, Telekommunikation und neue Medien e. V. 2014

Boisot, Max; Canals, Agustí: Data, information and knowledge: have we got it right? In: Journal of Evolutionary Economics 14 (2004), Nr. 1, S. 43–67. – DOI 10.1007/s0019100301819

Brenner, Walter; Herrmann, Andreas: Das Modell des Managements in der digitalen vernetzten Welt. In: Stadler, R.; Brenner, W.; Herrmann, A. (Hrsg.): Erfolg im digitalen Zeitalter: Strategien von 17 Spitzenmanagern, 1. Auflage. Frankfurt: Frankfurter Allgemeine Buch, 2012. – ISBN 978-3899813005

Campanella, Jack: Principles of quality costs : principles, implementation and use. Milwaukee : ASQ Quality Press, 1999

Chen, Peter Pin-Shan: The Entity-Relationship Model: Toward a Unified View of Data. In: ACM Transactions on Database Systems 1 (1976), Nr. 1, S. 9–36. – DOI 10.1145/320434320440

Dahlkamp, Jürgen; Schmitt, Jörg: Die Dotcom-Räuber. In: Der Spiegel 48 (2014-11-24), S. 68–69. – Abgerufen 2015-01-15 von: http://www.spiegel.de/spiegel/print/d-130458636.html

DAMA International: DAMA-DMBOK Functional Framework. Version 3.02. Lutz: Technics Publications, 2008

DAMA International: The DAMA Guide to The Data Management Body of Knowledge (DAMADMBOK Guide). Bradley Beach: Technics Publications, 2009. – ISBN 978-0-9771400-8-4

Eppler, Martin J.; Helfert, Markus: A Framework for the Classification of Data Quality Costs and an Analysis of Their Progression. In: Chengalur-Smith, I., Raschid, L., Long, J., Seko, C. (Hrsg.): Proceedings of the 9th International Conference on Information Quality (ICIQ-04) (2004-11-05). Cambridge, 2004, S. 311–325

Equey, Catherine; Kusters, Rob J.; Varone, Sasha; Montandon, Nicolas: Empirical Study of ERP Systems Implementation Costs in Swiss SME’s. In: Cordeiro, J., Felipe, J (Hrsg.): Proceedings of the 10th International Conference on Enterprise Information Systems (ICEIS) (2008-06-12/16). Barcelona, 2008, S. 143–148

Ericsson: Maersk Line and Ericsson Bring Mobile Connectivity to the Oceans. Press release 2012-11-01. Stockholm: Ericsson Corporate Public & Media Relations, 2012. – Internetquelle. Abgerufen2015-01-15 von: http://hugin.info/1061/R/1576938/491546.pdf

European Commission: Regulation No 1907/2006 of the European Parliament and of the Council. In: Official Journal of the European Union L 396 (2006), 49, S. 1–849

Europäische Union: Charta der Grundrechte der Europäischen Union. In: Amtsblatt der Europäischen Union C 83/389, 2010

Even, Adir; Shankaranarayanan, Ganesan: Utility-driven assessment of data quality. In: ACM SIGMIS Database 38 (2007), Nr. 2, S. 75–93. – DOI 10.1145/1240616.1240623

Fleisch, Elgar: What is the Internet of Things? An Economic Perspective. St. Gallen/Zürich, Universität St. Gallen/ETH Zürich, Institut für Technologiemanagement, Auto-ID Labs, 2010. – White Paper. Auto-ID Labs White Paper WP-BIZAPP-053, 2010-01. Abgerufen 2015-02-08 von: http://www.im.ethz.ch/education/HS10/AUTOIDLABS-WP-BIZAPP-53.pdf

Fleisch, Elgar; Österle, Hubert: Auf dem Weg zum Echtzeit-Unternehmen. In: Alt, R.; Österle, H. (Hrsg.): Real-time Business. Vol 1. Berlin: Springer. S. 3–17. – DOI 10.1007/97836421710861

Fraunhofer IML (Fraunhofer Gesellschaft für Materialfluss und Logistik): InBin – Der intelligente Behälter. – Internetquelle. Abgerufen 2015-01-29 von: http://www.iml.fraunhofer.de/de/themengebiete/automation_eingebettete_systeme/Produkte/IntelligenterBehaelter.html

Froidevaux, Yves: Internet in den Schweizer Haushalten : Ergebnisse der Erhebung Omnibus IKT 2010. Neuchâtel : Office fédéral de la statistique (OFS) (Bundesamt für Statistik (BFS)), 2012

Hatz, Albert: BOSCH Master data Management. (6. Competence Center Corporate Data Quality Workshop (CC CDQ 1), 2008-01-16). St. Gallen, 2008. – Präsentation. Auf Anfrage von den Autoren verfügbar

Holtham, Clive: Resolving the imbalance between information and technology. In: Best, D. (Hrsg.):The Fourth Resource: Information and its Management. Aldershot: Aslib/Gower, 1995, S. 41–58

Horne, Nigel W.: Information as an Asset: The Board Agenda. In: Computer Audit Update 9 (1995), S. 5–11. – DOI 10.1016/0960259395902465

IEEE Software Society: IEEE Standard for a Software Quality Metrics Methodology. IEEE Standard 1061TM-1998 (R2004). New York, 1998. – Reaffirmed Standard on 24 June 2004 by the IEEE-SA Standards Board and on 21 January 2005 by American National Standards Institute, ISBN 1-55937-529–9

ISO/IEC: Information technology: Vocabulary Part 1: Fundamental terms (ISO/IEC 2382-1:1993). Genf: ISO/IEC, 1993

ISO/IEC: ISO/IEC 38500: Corporate governance of information technology. Geneva: ISO/IEC, 2008

ISO: ISO 8000-110:2009: Data quality, Part 110, Master data: Exchange of characteristic data: Syntax, semantic encoding, and conformance to data specification. Genf: ISO, 2009

ITU (International Telecommunication Union): ICT Facts and Figures. The World in 2013. Geneva, February 2014. – Internetquelle. Abgerufen 2014-06-11 von: http://www.itu.int/en/ITU-D/Statistics/Pages/facts/default.aspx

Johnson, Bobbie: Privacy no longer a social norm, says Facebook founder. The Guardian. – Internetquelle. Aktualisierungsdatum 2010-01-11. Abgerufen 2014-02-08 von http://www.theguardian. com/technology/2010/jan/11/facebook-privacy

Kagermann, Henning: Industrie 4.0 und Smart Services. In: Brenner, W.; Hess, T. (Hrsg.): Wirtschaftsinformatik in Wissenschaft und Praxis: Festschrift für Hubert Österle. Berlin Heidelberg: Springer, 2014, S. 243–248

Kokemüller, Jochen: Stammdatenmanagementsysteme 2009: Eine Marktübersicht zu aktuellen Systemen. Stuttgart: Fraunhofer-Verlag, 2009

Levitin, Anany V.; Redman, Thomas C.: Data as a Resource: Properties, Implications, and Prescriptions. In: Sloan Management Review 40 (1998), Nr. 1, S. 89–101

Möller, Henning: Stammdatenqualität als Basis für das globale Kundenumsatz-Reporting der ZF Friedrichshafen AG. St. Gallen, 2012. – Gastreferat in der Vorlesung „Enterprise Systems“ der Universität St. Gallen, 2012-05-07

Muthreich, Karsten: BIG DATA @ Nestlé (37. Competence Center Corporate Data Quality Workshop (CC CDQ 4), 2013-12-11). Hamburg, 2011. – Präsentation. Auf Anfrage von den Autoren verfügbar

Nonaka, Ikujiro: The Knowledge-Creating Company. In: Harvard Business Review 85 (2007), Nr. 7/8, S. 162–171

O’Brien, Ralph: Is Traditional Security Dead? In: ITNOW 56 (2014), Nr. 1, S. 26–27. – DOI 10.1093/itnow/bwu012

Ofner, Martin: Datenqualität aus Prozessperspektive: Methoden und Modelle. St. Gallen, Universität St. Gallen, Institut für Wirtschaftsinformatik, Dissertation, 2013

OMG: Semantics of Business Vocabulary and Business Rules (SBVR): V1.0. Needham, MA: Object Management Group, 2008

Oppenheim, Charles; Stenson, Joan; Wilson, Richard M.S.: Studies on Information as an Asset I: Definitions. In: Journal of Information Science 29 (2003), Nr. 3, S. 159–166. – DOI 10.1177/01655515030293003

Österle, Hubert: Business oder Life Engineering? In: HMD Praxis der Wirtschaftsinformatik 51 (2014), Nr. 6, S. 744–761. – DOI 10.1365/s407020140097x

Österle, Hubert; Otto, Boris: Consortium Research. In: Business & Information Systems Engineering 2 (2010), Nr. 2, S. 283–293. – DOI 10.1007/s115760100238y

Österle, Hubert; Otto, Boris: Das datenzentrierte Unternehmen: Eine Business-Engineering-Perspektive. In: Schuh, G.; Stich, V. (Hrsg.): Enterprise-Integration: Auf dem Weg zum kollaborativen Unternehmen. Wiesbaden: Springer, S. 91–105 (2014)

Österle, Hubert; Senger, Enrico: Prozessgestaltung und IT: Von der Unternehmens- zur Konsumentensicht. In: Controlling & Management 55 (2011), Nr. 2, S. 80–88. – DOI 10.1365/s1217601203363

Österle, Hubert; Winter, Robert: Business Engineering. In: Österle, H.; Winter, R. (Hrsg.) Business Engineering. Vol 2. Berlin: Springer, 2003, S. 3–18

Otto, Boris: Data Governance. In: Business & Information Systems Engineering 3 (2011a), Nr. 4, S.241–244. – DOI 10.1007/s1259901101628

Otto, Boris: Quality Management of Corporate Data Assets. In: Praeg, C.P.; Spath, D. (Hrsg.): Quality Management for IT Services: Perspectives on Business and Process Performance. Hershey, PA: IGI Global, 2011b, S. 193–209. – DOI 10.4018/978-1-61692-889-6

Otto, Boris: Stammdatenqualität: Das Rückgrat moderner logistischer Systeme. In: Fraunhofer Institut für Materialfluss und Logistik IML Dortmund (Hrsg.): Logistik entdecken 15 (2014), S. 20–21

Otto, Boris; Kokemüller, Jochen; Weisbecker, Anette; Gizanis, Dimitros: Stammdatenmanagement: Datenqualität für Geschäftsprozesse. In: HMD – Praxis der Wirtschaftsinformatik 48 (2011), Nr. 279, S. 5–16. – DOI 10.1007/BF03340582

Otto, Boris; Abraham, Rene; Schlosser, Simon: Toward a Taxonomy of the Data Resource in the Networked Industry. In: Proceedings of the 7th International Scientific Symposium on Logistics (ISSL 2014) (2014-06-4/5), Köln, 2014, S. 382–421

Reid, R. Dan; Sanders, Nada R.: Operations Management: An Integrated Approach. Hoboken: John Wiley, 2005

Reynolds, George W.: Information Technology for Managers. Boston, Ma: Course Technology, 2010

Ross, Ronald G.; Lam, Gladys S.W.: Building Business Solutions: Business Analysis with Business Rules. Bissonnet: Business Rule Solutions LLC, 2011

Salchegger, Markus; Dewor, Eva: Höchste Zeit für ein Solvency II Data Management. In: Versicherungswirtschaft 20 (2008), S. 1714–1718

Schemm, Jan W.: Consumer-Centricity at Migros (Focus Group Workshop „Consumer-Centric Information Management (CCIM)“, 2012-06-13). St. Gallen, 2012. – Präsentation. Auf Anfrage von den Autoren verfügbar

Schierning, Andreas: Consumer-Centric Information Management: Exploring Product Information (Business Engineering Forum, 2012-09-20). Bregenz, 2012. – Präsentation. Auf Anfrage von den Autoren verfügbar

Schmid, Andreas: Bankdaten von 7500 Swisscom-Kunden sickern aus Leck. In: Neue Zürcher Zeitung, Ausg. 2014-02-15/16, S. 1 und S. 11

Schweizer Bundesamt für Statistik: Internetnutzung Schweiz. – Internetquelle. Aktualisierungsdatum 2014-03-06. Abgerufen 2014-07-10 von: http://www.bfs.admin.ch/bfs/portal/de/index/themen/16/04/key/approche_globale.indicator.30106.301.html?open=1#1

Sein, Maung K.; Henfridsson, Ola; Purao, Sandeep; Rossi, Matti; Lindgren, Rikard: Action Design Research. In: MIS Quarterly 35 (2011), Nr. 1, S. 37–56

Shah, Rachna; Chandrasekaran, Aravind; Linderman, Kevin: In pursuit of implementation patterns: the context of Lean and Six Sigma. In: International Journal of Production Research 46 (2008), Nr. 23, S. 6679–6699. – DOI 10.1080/00207540802230504

Smart Service Welt Working Group: Smart Service Welt: Recommendations for the Strategic Initiative Web-based Services for Businesses. Berlin: Acatech – National Academy of Science and Engineering, 2014

Strong, Diane M.; Lee, Yang W.; Wang, Richard Y.: Data Quality in Context. In: Communications of the ACM 40 (1997), Nr. 5, S. 103–110. – DOI 10.1145/253769253804

Van den Hoven, John: Information resource management: Stewards of data. In: Information Systems Management 16 (1999), Nr. 1, S. 88–91. – DOI 10.1201/1078/43187.16.1.19990101/31167.13

Wahlster, Wolfgang: Vorarbeiten zu Industrie 4.0: Die Allianzen ADiWa und SemProM (Promotorengruppe KOMMUNIKATION der Forschungsunion (FU), Strategieworkshop „Industrie 4.0“,acatech Hauptstadtbüro, Berlin, 2011-06-27). Berlin, 2011. – Abgerufen 2015-01-29 von: http://www.res-com-project.org/tl_files/music_academy/Dokumente/Vorarbeiten_zur_Industrie_4_0_Die_Allianz_ADiWa_und_SemProM.pdf

Wang, Richard Y.: A product perspective on total data quality management. In: Communications of the ACM 41 (1998), Nr. 2, S. 58–65. – DOI 10.1145/269012.269022

Wang, Richard Y.; Lee, Yang W.; Pipino, Leo L.; Strong, Diane M.: Manage Your Information as a Product. In: Sloan Management Review 39 (1998), Nr. 4, S. 95–105

Wang, Richard Y.; Strong, Diane M.: Beyond Accuracy: What Data Quality Means to Data Consumers. In: Journal of Management Information Systems 12 (1996), Nr. 4, S. 5–33

White, Andrew: The Five Vectors of Complexity That Define Your MDM Strategy. Stamford, CT: Gartner Inc., 2010

White, Andrew; Radcliffe, John: Four Dimensions of MDM: Understanding the Complexity. Stamford, CT: Gartner Inc., 2007

White, Andrew; Radcliffe, John: Hype Cycle for Master Data Management. Stamford, CT: Gartner Inc., 2010

Wrobel, Stefan; Voss, Hans; Köhler, Joachim; Beyer, Uwe; Auer, Sören: Big Data, Big Opportunities. In: Informatik-Spektrum (2014). – DOI 10.1007/s0028701408064

Yoon, Vicotria Y.; Aiken, Peter G.; Guimaraes, Tor: Managing Organizational Data Resources: Quality Dimensions. In: Information Resources Management Journal 13 (2000), Nr. 3, S. 5–13. – DOI 10.4018/irmj.2000070101

Ziegler, Patrick; Dittrich, Klaus R.: Data Integration: Problems, Approaches, and Perspectives. In: Krogstie, J.; Opdal, A.L.; Brinkkemper, S. (Hrsg.): Conceptual Modelling in Information Systems Engineering. Berlin: Springer, 2007, S. 39–58. – DOI 10.1007/978-3-540-72677-7_3

Fußnoten

[1]

Dieses Buch verwendet wegen des verbreiteteren Sprachgebrauchs durchgängig den Begriff „Stammdaten“. Gemeint sind damit die Konzernstammdaten, d. h. jene Untergruppe sämtlicher Stammdaten im Unternehmen, die im Rahmen eines unternehmensweiten qualitätsorientierten Datenmanagements bewirtschaftet werden sollten.

[2]

Quelle: https://www.youtube.com/yt/press/statistics.html.

[3]

Quelle: http://newsroom.fb.com/company-info/.

[4]

Quelle: http://de.statista.com/statistik/daten/studie/198959/umfrage/anzahl-der-smartphonenutzer-in-deutschland-seit-2010/.

[5]

Für einen besseren Lesefluss verzichten wir auf die Nennung der Rechtsformen der erwähnten Unternehmen.

[6]

Siehe hierzu auch http://www.mobivoc.org.

[7]

Die deutsche Smart-Service-Welt-Initiative untersucht Prinzipien solcher Geschäftsmodelle und leitet Handlungsempfehlungen ab (Smart Service Welt Working Group 2014).

[8]

Quelle: https://www.deutschepost.de/de/g/geovista.html.

[9]

Quelle: http://www.nestle.com/media/facts-figures.

[10]

Six Sigma ist ein Qualitätsmanagementansatz, der als Leistungsziel nur 3,4 Fehler pro eine Million Instanzen vorsieht (Shah et al. 2008). Nach Wang et al. (1998) können Qualitätsmanagementansätze für physische Güter auch auf immaterielle Güter wie Daten übertragen werden.

[11]

Die Nomenklatur und Systematik von Datenqualitäts-Messsystemen ist angelehnt an die Vorgaben zu Messsystemen in der Softwareentwicklung der IEEE Software Society (vgl. IEEE 1998). Ein Kennzahlensystem ist eine spezielle Art eines Messsystems. Siehe Kap. 3.2.2 für Details zu einem Datenqualitäts-Kennzahlensystem.

[12]

Literatur und Praxis definieren eine Vielzahl unterschiedlicher Datenqualitätsdimensionen. Quellen finden sich z. B. bei DAMA (2009) oder bei der International Association for Information and Data Quality http://iaidq.org/main/glossary.shtml#D. Hier sind die fünf wichtigsten Dimensionen wiedergegeben.

[13]

Der japanische Wissenschaftler Ikujiro Nonaka beschrieb 1991 in seinem Aufsatz „The Knowledge-Creating Company“ diesen Prozess als „Artikulation von implizitem Wissen“ („articulation of tacit knowledge“) (Nonaka 2007). Wir verwenden hier bewusst den Begriff „Explikation“, da er dem heutigen Sprachgebrauch und den jüngeren auf Nonaka aufbauenden Quellen entspricht.

© Der/die Autor(en) 2016

Boris Otto

und Hubert ÖsterleCorporate Data Quality10.1007/978-3-662-46806-7_2

2. Fallstudien zur Datenqualität

Boris Otto1   und Hubert Österle2

(1)

Fraunhofer Institut für Materialfluss und Logistik, Dortmund, Deutschland

(2)

Business Engineering Institute St. Gallen, St. Gallen, Schweiz

Boris Otto (Korrespondenzautor)

Email: boris.otto@iml.fraunhofer.de

Hubert Österle

Email: hubert.oesterle@bei-sg.ch

2.1 Allianz: Data Governance und Datenqualitätsmanagement in der Versicherungswirtschaft

2.1.1 Unternehmensüberblick

2.1.2 Ausgangssituation und Handlungsdruck

2.1.3 Das Solvency-II-Projekt

2.1.4 Datenqualitätsmanagement bei AGCS

2.1.5 Erkenntnisse

2.1.6 Weiterführendes Material

2.2 Bayer CropScience: Datenqualitätscontrolling in der agrochemischen Industrie

2.2.1 Unternehmensüberblick

2.2.2 Ausgangssituation und Handlungsdruck

2.2.3 Aufbau des unternehmensweiten Datenqualitätsmanagements

2.2.4 Erkenntnisse

2.2.5 Weiterführendes Material

2.3 Beiersdorf: Produktdatenqualität in der Konsumgüter-Supply Chain

2.3.1 Unternehmensüberblick

2.3.2 Ausgangssituation des Datenmanagements

2.3.3 Projekt zur Messung der Datenqualität

2.3.4 Erkenntnisse

2.3.5 Weiterführendes Material

2.4 Bosch: Datenarchitekturmanagement in einem diversifizierten Technologiekonzern

2.4.1 Unternehmensüberblick

2.4.2 Ausgangssituation und Handlungsdruck

2.4.3 Datenarchitekturmuster bei Bosch

2.4.4 Erkenntnisse

2.4.5 Weiterführendes Material

2.5 Festo: Unternehmensweites Produktdatenmanagement in der Automatisierungsindustrie

2.5.1 Unternehmensüberblick

2.5.2 Ausgangssituation und Handlungsdruck des Produktdatenmanagements

2.5.3 Projekte im Produktdatenmanagement zwischen 1990 und 2009

2.5.4 Aktuelle Aktivitäten und Ausblick

2.5.5 Erkenntnisse

2.5.6 Weiterführendes Material

2.6 Hilti: Durchgängiges Kundendatenmanagement in der Werkzeug- und Befestigungsindustrie

2.6.1 Unternehmensüberblick

2.6.2 Ausgangssituation des Kundendatenmanagements und Handlungsdruck

2.6.3 Das Projekt Customer Data Quality Tool

2.6.4 Erkenntnisse

2.6.5 Weiterführendes Material

2.7 Johnson & Johnson: Institutionalisierung des Stammdatenmanagements in der Konsumgüterindustrie

2.7.1 Unternehmensüberblick

2.7.2 Ausgangssituation des Datenmanagements im Bereich Consumer Products und Aktivitäten bis 2008

2.7.3 Die Einführung von Data Governance

2.7.4 Aktuelle Situation

2.7.5 Erkenntnisse

2.7.6 Weiterführendes Material

2.8 Lanxess: Business Intelligence und Stammdatenmanagement bei einem Spezialchemiehersteller

2.8.1 Unternehmensüberblick

2.8.2 Ausgangssituation des Datenmanagements und Business Intelligence 2004–2011

2.8.3 Das Stammdatenmanagement bei Lanxess seit 2011

2.8.4 Aufbau des strategischen Reportings seit 2012

2.8.5 Erkenntnisse

2.8.6 Weiterführendes Material

2.9 Shell: Datenqualität im Produktlebenszyklus in der Mineralölindustrie

2.9.1 Unternehmensüberblick

2.9.2 Ausgangssituation und Handlungsdruck

2.9.3 Durchgängiges Datenmanagement im Produktlebenszyklus

2.9.4 Herausforderungen bei der Umsetzung

2.9.5 Nutzen der neuen Lösung

2.9.6 Erkenntnisse

2.9.7 Weiterführendes Material

2.10 Syngenta: Auslagerung von Datenmanagementaufgaben in der Pflanzenschutzindustrie

2.10.1 Unternehmensüberblick

2.10.2 Ausgangssituation und Ziele der Stammdatenmanagementinitiative

2.10.3 Das Transformationsprojekt und MDM-Designprinzipien

2.10.4 Organisationsstruktur des Stammdatenmanagements

2.10.5 Datenpflegeprozess und Entscheidungskriterien für die Auslagerung

2.10.6 Erkenntnisse

2.10.7 Weiterführendes Material

Literatur

Zusammenfassung

Kapitel 2 zeigt erfolgreiche Beispiele für Stammdatenqualitätsmanagement in der Praxis anhand von zehn Fallstudien, die im CC CDQ durchgeführt wurden. Die Fallstudien decken alle Aspekte des Referenzmodells für das Stammdatenqualitätsmanagement aus Kap. 1 ab.

Die Fallstudien beschreiben Ausgangssituation, Vorgehen und Ergebnisse in den Unternehmen, ohne Bewertungen einzelner Maßnahmen vorzunehmen. Das Kapitel verwendet zentrale Konzepte des Stammdatenqualitätsmanagements jedoch konsistent. Unternehmensspezifische Begriffe wie Rollenbeschreibungen und Anwendungssystemnamen sind beibehalten.

Erfolgsfaktoren sowie Verweise auf weiterführendes Material runden die einzelnen Fallstudien ab.

Das Kompetenzzentrum Corporate Data Quality (CC CDQ) führt Fallstudien zum unternehmensweiten Datenqualitätsmanagement durch, welche die in der Praxis auftretenden Herausforderungen und Lösungsansätze für unterschiedliche Facetten des Datenmanagements dokumentieren. Dieses Kapitel präsentiert eine Auswahl von 10 Fallstudien aus verschiedenen internationalen Großunternehmen. Die folgende Tabelle (Tab. 2.1) listet als Navigationshilfe die Titel aller Fallstudien auf und gibt an, welche Bereiche des Frameworks für Stammdatenqualitätsmanagement (Kap. 1.4) in den beschriebenen Projekten jeweils behandelt werden.

Tab. 2.1
Fallstudienübersicht

DQM-Framework-

Bereiche

Fallstudien

Strategie

Führungssystem

Organisation

Prozesse und Methoden

Architektur

Anwendungssysteme

1) Allianz:

Data Governance und Datenqualitätsmanagement in der Versicherungswirtschaft

√

√

√

√

2) Bayer CropScience:

Datenqualitätscontrolling in der agrochemischen Industrie

√

√

√

√

√

3) Beiersdorf:

Produktdatenqualität in der Konsumgüter-Supply Chain

√

√

√

√

√

4) Bosch:

Datenarchitekturmanagement in einem diversifizierten Technologiekonzern

√

√

√

5) Festo:

Unternehmensweites Produktdatenmanagement in der Automatisierungsindustrie

√

√

√

√

√

6) Hilti:

Durchgängiges Kundendatenmanagement in der Werkzeug- und Befestigungsindustrie

√

√

√

√

7) Johnson & Johnson:

Institutionalisierung des Stammdatenmanagements in der Konsumgüterindustrie

√

√

√

√

8) Lanxess:

Business Intelligence und Stammdatenmanagement bei einem Spezialchemiehersteller

√

√

√

√

√

9) Shell:

Datenqualität im Produktlebenszyklus in der Mineralölindustrie

√

√

√

√

10) Syngenta:

Auslagerung von Datenmanagementaufgaben in der Pflanzenschutzindustrie

√

√

√

2.1 Allianz: Data Governance und Datenqualitätsmanagement in der Versicherungswirtschaft

2.1.1 Unternehmensüberblick

Die Allianz SE ist ein weltweit agierendes Finanzdienstleistungsunternehmen mit Sitz in München[1]. 2006 entstand Allianz Global Corporate & Specialty (AGCS) als Tochterunternehmen aus einer Zusammenführung verschiedener Geschäftsbereiche der Marken „Global Risks“ sowie „Marine & Aviation“.

AGCS bietet Versicherungsdienstleistungen für Unternehmen in 160 Ländern an. Das Leistungsspektrum umfasst u. a. Risikotransfer und andere nicht-traditionelle Lösungen des Risikomanagements, Konzerneigene Versicherung, Claims Services und Internationale Versicherungen (Tab. 2.2).

Tab. 2.2
Kurzprofil Allianz

Allianz SE

Gründung

1890

Branche

Versicherungswesen, Finanzdienstleistungen

Unternehmenssitz

München, Deutschland

Rechtsform

Societas Europaea

Homepage

www.allianz.com

Umsatz (2013)

110,77 Mrd. EUR

Gewinn (2013)

6,34 Mrd. EUR

Mitarbeiter (2013)

147.627

AGCS operiert in einem stark regulierten Markt. Kritische Erfolgsfaktoren sind:

- Bestimmung der Höhe des Risikokapitals sowie Vorhalten der nötigen Liquidität, um für Force-Majeure-Versicherungsfälle gewappnet zu sein

- Maximierung der Gewinnmarge bei gleichzeitig ausreichender Höhe von Rücklagen für das Risikokapital

- Umsetzung und Einhaltung gesetzlicher und behördlicher Auflagen (z. B. Solvency II (EU 2009))

Voraussetzung für diese Fähigkeiten sind Daten in hoher Qualität, denn sie sind einerseits Input für die Berechnung des Risikokapitals und andererseits Basis für die Berichtspflicht im Rahmen von Solvency II. Die grundlegenden Zusammenhänge für die Berechnung des sogenannten Solvenzkapitals gemäß Solvency II stellt Abb. 2.1 dar.

Abb. 2.1
Solvenzkapitalstruktur nach Säule 1 von Solvency 2. (nach KPMG 2011, S. 11)

2.1.2 Ausgangssituation und Handlungsdruck

AGCS hat sich alle zwei Jahre einer Prüfung durch die Bundesanstalt für Finanzdienstleistungsaufsicht (BaFin) zu unterziehen. Nach der Prüfung im Jahr 2010 forderte die BaFin AGCS auf, ein Datenqualitätskonzept vorzulegen und ein unternehmensweites Datenqualitätsmanagement aufzubauen (wie es u. a. auch Solvency II vorschreibt).

Die Analyse der Ausgangssituation vor Umsetzung dieser Vorgabe führte zu folgenden Problemstellungen:

- Unklarheit über Verantwortlichkeiten im Datenqualitätsmanagement: Zwar gab es in einigen Abteilungen vereinzelte Datenqualitätsteams, aber kein unternehmensweites Konzept.

- Fehlende Entscheidungsstrukturen bei Datenqualitätsproblemen: Datenqualitätsprobleme wurden entweder gar nicht behoben oder erst nach mehrstufigen Eskalationsschritten, was dazu führte, dass sich das Unternehmen bezüglich der Datenqualität konstant im „Feuerlöschmodus“ befand.

- Fehlende organisatorische Verankerung des gesamten Datenqualitätsthemas: Keiner Stelle im Unternehmen war klar, wer für die unternehmensweite Koordination des Datenqualitätsmanagements verantwortlich zeichnete.

2.1.3 Das Solvency-II-Projekt

Als Reaktion auf das Ergebnis des Prüfungsberichts durch die BaFin initiierte der Finanzvorstand von AGCS 2011 das Solvency-II-Projekt. Er gründete ein Data-Governance-Team und setzte ein Projekt mit folgenden Zielen auf:

- Definition der wichtigsten Datenqualitätsanforderungen bei der Bewertung von Rückstellungsbedarfen

- Definition der Prozesse und Handlungsanweisungen zur Sicherung der Datenqualität

- Entwurf der Maßnahmen zur Datenqualitätsmessung und -überwachung

Diese Ziele wurden in einen Arbeitsplan überführt. Arbeitspakete waren:

- Entwurf einer unternehmensweiten Richtlinie für das Datenqualitätsmanagement

- Definition von Rollen und Verantwortlichkeiten für das Datenqualitätsmanagement

- Definition von Kriterien zur Messung der Datenqualität

- Entwurf von Prozessen und Abläufen des Datenqualitätsmanagements

- Auswahl und Implementierung eines Softwaresystems zur dauerhaften Messung der Datenqualität

Das Projekt wurde in drei Phasen zwischen 2011 und 2013 umgesetzt. Die erste Phase umfasste die Definition und Zuordnung von Datenqualitätsrollen zu Mitarbeitern sowie die Definition eines unternehmensweiten Verständnisses des Datenqualitätsbegriffs. Die zweite Phase analysierte die Ist-Situation auf Seiten der „Datenproduzenten“, um zu verstehen, wo Daten in welchen Systemen in welchen Prozessschritten erzeugt werden und was im Anschluss daran mit ihnen geschieht. In der dritten Phase legte das Data-Governance-Team ein Regelwerk für die Datenqualität fest, an das sich die Nutzer der Daten zu halten hatten.

2.1.4 Datenqualitätsmanagement bei AGCS

Die Data-Governance-Organisation ist in der Matrixorganisation der AGCS verankert und in der o. a. Richtlinie beschrieben:

- Data Governance Steering Group[2]: Alle Unternehmensfunktionen (Underwriting, Claims etc.) sind in diesem Gremium vertreten. Es ist die höchste Instanz des Datenqualitätsmanagements bei AGCS und genehmigt Standards und Richtlinien und überwacht deren Umsetzung. Außerdem stellt die Steering Group sicher, dass sämtliche Compliance-Anforderungen berücksichtigt sind.

- Data Governance Team: Das Data Governance Team berichtet an den COO (Chief Operating Officer) der Operational Business Transformation-Abteilung an der Schnittstelle zwischen Fachbereichen und Informatik im Unternehmen. Das Data Governance Team entwirft Prozesse im Datenqualitätsmanagement und erarbeitet Standards für die Datenqualität.

- Datenproduzenten: Die Datenproduzenten sind Teil der Fachbereiche. Sie sind für die Bereitstellung und Transformation der Daten verantwortlich.

- Datennutzer: Sie sind ebenfalls Teil der Fachbereiche und nutzen die Daten u. a. für die Risikobewertung.

- Systemverantwortliche: Sie betreuen die Softwaresysteme, in denen die Daten erfasst, verarbeitet und für den Datennutzer bereitgestellt werden.

Abbildung 2.2 zeigt das Zusammenspiel dieser Rollen.

Abb. 2.2
Zusammenspiel der Rollen im Datenqualitätsmanagement bei AGCS. (nach Baghi und Abraham 2013, S. 11)

Um Datenqualität messbar – und damit steuerbar – zu machen, definiert AGCS drei Datenqualitätsmerkmale:

- Vollständigkeit: Daten gelten als vollständig, wenn sie granular genug sind, um Trends zu identifizieren und zugehörige Risiken umfassend zu beschreiben.

- Genauigkeit: Daten sind genau, wenn sie die Wirklichkeit korrekt, also fehlerfrei, abbilden.

- Angemessenheit: Daten sind angemessen, wenn sie für den Geschäftszweck, d. h. die Risikoanalyse und -bewertung, geeignet sind.

Diese Datenqualitätsmerkmale bilden die Grundlage der Datenqualitätsmessung bei AGCS. Um die Messungen zu automatisieren, werden die drei Merkmale in Geschäftsregeln festgehalten. Beispiele für Geschäftsregeln der drei Merkmale sind in Tab. 2.3 dargestellt.

Tab. 2.3
Geschäftsregeln bei AGCS

Geschäftsregel-Beispiel

Vollständigkeit

Das Feld „LoB“ darf nicht leer sein

Genauigkeit

Das Feld „Datum“ muss mit dem korrekten Format befüllt sein

Der Wert im Feld „Prämie“ darf nicht negativ sein

Angemessenheit

Das Datum im Feld „Booked Date“ darf nicht mehr als 40 Tage nach dem Datum im Feld „Bound Date“ liegen (Indikator Prozessqualität)

Beim Entwurf der Prozesse im Datenqualitätsmanagement orientierte sich AGCS an gängigen Qualitätsmanagementstandards wie Six Sigma. Als Prozessvorlage diente insbesondere der sogenannte DMAIC-Zyklus:

- Definieren (D – Define): Dieser erste Schritt umfasst die Definition der Anforderungen an die Datenqualität aus den Fachabteilungen. Die Anforderungen werden durch die o. a. Merkmale, über Geschäftsregeln und Grenzwerte modelliert. ACGS betrachtet bei der Anforderungsdefinition den gesamten Datenlebenszyklus und bindet deswegen auch alle beteiligten Rollen, also Datenproduzenten, Datennutzer und Systemverantwortliche, mit ein.

- Messen (M – Measure): AGCS nutzt SAS DataFlux-Software[3] zur Messung der Datenqualität. Die Messung erfolgt in regelmäßigen Abständen an verschiedenen Messpunkten im Datenlebenszyklus.

- Analysieren (A – Analyze): Die Datennutzer analysieren und priorisieren Datenqualitätsprobleme, die sich aus der Messung ergeben. Beispielsweise führen sie „Root Cause“-Analysen durch, um die Ursachen von Datenqualitätsproblemen herauszufinden, und bereiten Verbesserungsmaßnahmen vor, über welche die Data Governance Steering Group zu entscheiden hat.

- Verbessern (I – Improve): Datenproduzenten, Datennutzer und Systemverantwortliche setzen die Entscheidungen der Data Governance Steering Group um.

- Überwachen (C – Control): Der letzte Schritt überwacht die Verbesserungsmaßnahmen und überprüft, ob sie erfolgreich sind.

Der DMAIC-Zyklus bei AGCS ist in Abb. 2.3 dargestellt.

Abb. 2.3
DMAIC-Zyklus des Datenqualitätsmanagements bei AGCS. (Pfaffenzeller 2012, S. 16)

AGCS nutzt eine DataFlux-Softwarelösung des Unternehmens SAS für die Datenqualitätsüberwachung. Die Lösung greift auf Daten der operativen Systeme zu, analysiert die Datenqualität und stellt die Ergebnisse in einem Datenqualitäts-Cockpit dar[4].

Das Cockpit bietet zwei Sichten auf die Datenqualitätsmessung. Die eine ist für fachliche Anwender bestimmt (z. B. Datenkonsumenten oder Datenproduzenten), die zweite für technische Anwender der Datenquellen (Systemverantwortliche). Im ersten Fall (Abb. 2.4, linke Seite) zeigt das Cockpit die Datenqualität aus Sicht einer bestimmten fachlichen Anforderung, z. B. Solvency II. Dafür werden die Geschäftsregeln ausgewertet, die für diese Anforderung definiert wurden. Der Anwender kann über mehrere Hierarchiestufen vom Berichtskontext der Qualitätsüberprüfung über vordefinierte Risikokategorien und die Quellsysteme bis auf die verletzten Geschäftsregeln und die verantwortlichen Datensätze zugreifen.

Abb. 2.4
Datenqualitätsüberwachung bei AGCS aus Datenkonsumentensicht (links) und Datenquellensicht (rechts). (nach Baghi und Abraham 2013, S. 17)

Dank dieser „Drill-down-Funktionalität“ kann ACGS fehlerhafte Daten detailliert nachvollziehen, weil sowohl Angaben zu den Quellsystemen als auch die Geschäftsregeln, die verletzt wurden, sowie die defekten Daten selbst mitgeführt werden.

Die Datenquellensicht (Abb. 2.4, rechte Seite) zeigt ähnliche Hierarchiestufen. Hier sind die Datenquelle, die Datensätze, die Geschäftsregeln sowie die fehlerhaften Daten selbst angegeben. In dieser Sicht können Systemverantwortliche nachvollziehen, wie sich die Datenqualität in ihren Systemen entwickelt.

Abbildung 2.5 zeigt ein Beispiel eines Datenqualitäts-Cockpits bei AGCS.

Abb. 2.5
Datenqualitätsbericht bei AGCS. (Baghi und Abraham 2013, S. 18)

Die fortlaufende Datenqualitätsüberwachung und -bewertung bei AGCS basiert auf vier Konzepten:

- Sigma-Level: Jeder Datensatz, der mindestens eine Geschäftsregel verletzt, gilt als fehlerhaft. Die Fehlerrate ist das Verhältnis zwischen fehlerhaften Datensätzen und der Gesamtzahl an Datensätzen. Sie kann also einen Wert zwischen 0 und 1 annehmen. Gemäß den „Six-Sigma-Prinzipien“ wird die Fehlerrate auf die Standardabweichung analysiert, sodass ein „Six-Sigma“-Niveau erreicht ist, wenn die Fehlerrate einen Wert zwischen 0,023 und 0,00026 % annimmt.

- Reifegrad: Ein qualitatives Maß, nämlich der Reifegrad, ergänzt den errechneten Sigma-Wert. Der Reifegrad ist das Ergebnis einer Experteneinschätzung und kann die Werte „initial“, „verbessert“, „reif“ sowie „nicht zutreffend“ annehmen.

- Status: Der Status misst die Schwere der Datenfehler und kann die Werte „rot“, „gelb“, und „grün“ annehmen. Die Datenfehler werden anhand der Kritikalität der Geschäftsregeln bewertet, die sie verletzen. AGCS unterscheidet zwischen „signifikanten“ und „kritischen“ Geschäftsregeln. Ist eine kritische Geschäftsregel verletzt (die schwerwiegendste Einstufung), ist der Datenqualitätsstatus rot.

- Fehlerentwicklung: Die Datenqualitätsüberwachung stellt dar, wie sich die Fehlerrate über die Zeit verändert.

2.1.5 Erkenntnisse

Die wichtigsten Erkenntnisse des Projekts waren:

- Regulatorische Anforderungen wie Solvency II zwingen Unternehmen zum Aufbau eines unternehmensweiten Datenqualitätsmanagements. Oft machen erst solche externen Anforderungen den Handlungsdruck im ganzen Unternehmen sichtbar und sorgen für die notwendige Unterstützung durch die Geschäftsleitung des Unternehmens.

- Der Nutzer der Daten (Datenkonsument) definiert die Anforderungen an Datenlebenszyklus und Datenarchitektur.

- Bewährte Ansätze des Qualitätsmanagements (z. B. der DMAIC-Zyklus) können auf das unternehmensweite Datenqualitätsmanagement übertragen werden. Datenqualitätsüberwachung ist dabei ein Prozess, der nicht einmalig, sondern kontinuierlich durchlaufen werden muss.

- Risikomanagement-Ansätze helfen bei der Bewertung der Datenqualität.

- Datenqualitätsüberwachung und Data Governance gehen Hand in Hand. Ohne klare Rollen und Verantwortlichkeiten laufen Maßnahmen zur Sicherung und zur Verbesserung der Datenqualität ins Leere.

- In komplexen Prozess- und Systemlandschaften ist Datenqualität sowohl aus Datenkonsumenten- als auch aus Datenquellensicht zu messen. Nur so sind Ursachenanalysen („Root Cause“-Analysen) möglich.

2.1.6 Weiterführendes Material

Für den Fall von AGCS liegen an verschiedenen Orten Details aus wissenschaftlicher und auch aus praktischer Perspektive vor (Tab. 2.4).

Tab. 2.4
Weiterführendes Material zum Fall von AGCS

Quelle

Titel

Ergebnistyp

Wiss.

Praxis

Baghi und Abraham 2013

Case study: Allianz Global Corporate & Specialty AG – data quality controlling and data governance

Fallstudie CC CDQ

√

√

Pfaffenzeller 2012

Data governance: data governance in an insurance company

Präsentation auf CC CDQ-Workshop

√

Pfaffenzeller 2013

Data governance: data governance in an insurance company

Präsentation auf Praxiskonferenz

√

2.2 Bayer CropScience: Datenqualitätscontrolling in der agrochemischen Industrie

2.2.1 Unternehmensüberblick

Die Bayer CropScience AG ist ein Teilkonzern der Bayer AG[5]. Die Bayer AG gliedert sich in die drei operativen Teilkonzerne Bayer Healthcare, Bayer CropScience, Bayer MaterialScience und drei Dienstleistungsunternehmen Bayer Business Services, Bayer Technology Services und Currenta (Tab. 2.5).

Bayer CropScience (BCS) ist in den Bereichen Pflanzenschutz, Schädlingsbekämpfung außerhalb der Landwirtschaft, Saatgut und Pflanzenbiotechnologie tätig. Mit 22.400 Mitarbeitern und einem Umsatz von 8,8 Mrd. EUR im Geschäftsjahr 2013 ist Bayer CropScience Marktführer im Bereich agrochemischer Produkte. Bayer CropScience entstand 2002 durch die Übernahme von Aventis CropScience durch die Bayer AG.

Tab. 2.5
Kurzprofil Bayer

Bayer AG

Gründung

1863

Branche

Arzneimittel, Pflanzenschutzmittel, Kunststoff (CropScience: Pflanzenschutzmittel)

Unternehmenssitz

Leverkusen, Deutschland

Rechtsform

Aktiengesellschaft

Homepage

www.bayer.de

Umsatz (2013)

40,16 Mrd. EUR (CropScience: 8,8 Mrd. EUR)

Gewinn (2013)

3,19 Mrd. EUR

Mitarbeiter (2013)

113.200 (CropScience: 22.400)

Bayer CropScience ist in zwei operative Geschäftsbereiche gegliedert:

- CropProtection/Seeds: Dieser Geschäftsbereich stellt Pflanzenschutzprodukte her, also Herbizide, Fungizide, Insektizide und Saatgutbehandlungsmittel. Der Teilbereich Seeds züchtet unter dem Einsatz von Biotechnologie Saatgut der Kernkulturen Baumwolle, Raps, Reis und Gemüse.

- Environmental Science: Dieser Geschäftsbereich ist spezialisiert auf den Einsatz außerhalb der Landwirtschaft und bietet Produkte zur Schädlingskontrolle und -bekämpfung in Heim und Garten bis zur Forstwirtschaft an.

Drei Merkmale kennzeichnen den Markt, in dem Bayer CropScience agiert:

- Regulierung: Länderspezifische gesetzliche Auflagen, branchenspezifische Richtlinien sowie behördliche Vorgaben, die sich aus den Eigenschaften der hergestellten Produkte ergeben, regulieren das Marktumfeld von Bayer CropScience. Der Verkauf eines Produkts in einem Land ist nur möglich, wenn Bayer CropScience eine gültige Registrierung besitzt und die chemische Zusammensetzung des Produkts der Registrierung entspricht.

- Forschungs- und Entwicklungsaufwand: Die Entwicklung neuer Produkte ist, ähnlich wie in der pharmazeutischen Industrie, langwierig und mit hohen Investitionen verbunden.

- Saisonalität: Sowohl der Absatz- als auch der Beschaffungsmarkt (Rohstoffe) hängen vor allem vom Wetter ab. Hitze- und Kälteperioden in den Anbaugebieten sorgen für überdurchschnittliche Preisschwankungen und sind schwer zu prognostizieren.

Viele Unternehmen der Branche, wie auch Bayer CropScience, reagieren darauf mit einer Integration der Wertschöpfungskette. Der Begriff „Food Value Chain“ beschreibt die Planung, Steuerung und Kontrolle von Güter- und Informationsflüssen über die gesamte Wertschöpfungskette hinweg vom Landwirt über den Einzelhandel, den Distributor und Großhändler sowie die Pflanzenschutzhersteller bis zum Anbieter von Rohstoffen (Wallich 2013).

2.2.2 Ausgangssituation und Handlungsdruck

Bayer CropScience traf 2007 die Entscheidung, die Geschäftsprozesse weltweit mit folgenden drei Zielen zu harmonisieren (Nachtsheim et al. 2010):

- Verbesserung der Kapitalbedarfs-und Liquiditätsplanung mittels eines durchgängigen Prozesses zur Planung und Steuerung der Produktion und Materialbeschaffung ausgehend von der Absatzplanung in den Regionen

- Verbesserung des Berichtswesens durch eine vereinheitlichte Datengrundlage und ein einheitliches Management Cockpit

- Verbesserung der Qualität der Controlling-Organisation durch ein zentrales Schulungsprogramm

Voraussetzung dafür war eine weltweit einheitliche Anwendungssystemlandschaft. In einem ersten Schritt konsolidierte BCS die Systeme der Landesgesellschaften von mehr als 120 Ländern in drei regionale Systeme (Europa, Asien-Pazifik und Amerika) und harmonisierte die Geschäftsprozesse der zuvor eigenständig operierenden Landesgesellschaften regional. Im Rahmen dieses Projektes übertrug BCS die Stammdaten für Materialien, Kunden und Lieferanten aus den landesspezifischen Systemen in ein zentrales Stammdatensystem, die sogenannte „Golden Box“. Das zentrale System verteilt die Stammdaten an die regionalen Systeme.

Im Anschluss an diese erste Harmonisierung der Systeme der Landesgesellschaften in drei regionale Systeme startete das Projekt „Future System Landscape“ (FSL) mit dem Ziel, ein globales ERP-System zu etablieren (siehe Abb. 2.6). Teilprojekte des FSL-Projekts integrierten die Landesgesellschaften der Regionen in das zentrale ERP-System („Roll-ins“) und harmonisierten die lokalen Stammdaten mit dem bereits vom zentralen System genutzten Datenbestand.

Abb. 2.6
Future System Landscape-Projekt bei Bayer CropScience. (Brauer 2009, S. 11)

Mitte 2008 startete ein Teilprojekt von FSL zur Integration der Supply Chain-Planungsprozesse der Region Asien-Pazifik. Bereits im Kick-off-Workshop traten Schwierigkeiten mit der Bereitstellung der Daten für den Roll-in auf. So stellten die Projektmitarbeiter z. B. Probleme bei der Bedarfskonsolidierung aktiver Wirkstoffe, bei der Produktpreisfindung sowie bei der Programm- und Portfolioplanung fest. Im Rahmen des Workshops gelang es ihnen, diese Probleme auf fehlerhafte Daten unter anderem in der Produkthierarchie zurückzuführen. Außerdem wiesen sie einen Zusammenhang zwischen der mangelnden Datenqualität und einigen Geschäftsprozessen nach.

Für die Probleme in der Bedarfsplanung waren unter anderem Fehler in der Produkthierarchie verantwortlich. Die Produkthierarchie gibt bei Bayer Aufschluss über den Aufbau von Materialien und Produkten sowie ihre organisatorische Zugehörigkeit. Sie ist durch einen 11-stelligen Code beschrieben, der aus fünf Elementen besteht. Der Code definiert die Zugehörigkeit eines Produkts zu Geschäftsbereich, Geschäftseinheit sowie Geschäftssegment und ermöglicht Rückschlüsse auf den Hauptwirkstoff sowie die Zusammensetzung und Aufbereitung eines Produktes. Für jede Produkthierarchie lassen sich alle zugehörigen Produkte ermitteln. Die Qualität der Produkthierarchiedaten ist eine Voraussetzung für die drei Geschäftsprozesse Planung, Berichtswesen und Produktsegmentierung (siehe Abb. 2.7).

Abb. 2.7
Bedeutung der Qualität von Produkthierarchiedaten für Geschäftsprozesse bei Bayer CropScience. (Brauer 2009, S. 17)

Eine Analyse der Datenqualitätsprobleme identifizierte vielfältige Ursachen (siehe Abb. 2.8). Beispiele waren mangelndes Bewusstsein der Mitarbeiter für die Bedeutung der Daten, fehlende Vorgaben zur Erfassung und Pflege der Daten, fehlende Verantwortlichkeiten sowie fehlende Datenqualitätsmessung. Bis zu diesem Zeitpunkt besaß Bayer CropScience keine regelmäßige Datenqualitätskontrolle und keine präventiven DQM-Maßnahmen. Daten wurden nur reaktiv im Einzelfall verbessert, nachdem z. B. im Berichtswesen Fehler bemerkt worden waren, die sich auf mangelnde Datenqualität zurückführen ließen.

Abb. 2.8
Ursachen von Datenqualitätsproblemen bei Bayer CropScience. (Brauer 2009, S. 13)

Die Erkenntnis, dass Datenqualität eine notwendige Voraussetzung für das FSL-Projekt und damit die betriebswirtschaftlichen Ziele der Geschäftsprozessharmonisierung im Unternehmen war, führte zu der Entscheidung, ein unternehmensweites Datenqualitätsmanagementprojekt zu starten.

2.2.3 Aufbau des unternehmensweiten Datenqualitätsmanagements

Data Quality Cockpit-Ziele

Das Data Quality Cockpit ist eine Software, die die kontinuierliche Messung und Überwachung der Datenqualität unterstützt. Funktionale Anforderungen an das Data Quality Cockpit waren:

- Messung der Datenqualität

- Grafische Darstellung der Messergebnisse

- Speicherung der Messergebnisse über einen Zeitraum von mindestens 12 Monaten, um Trends darstellen zu können

- Unterstützung nutzer- und rollenspezifischer Sichten

Weil das Data Quality Cockpit das FSL-Projekt direkt unterstützte, wurde es nicht getrennt projektiert und budgetiert. Es gab also keine Kosten-Nutzen-Analyse für das Cockpit.

Das Data Quality Cockpit verfolgte vier Ziele:

- Bewusstsein schaffen: Fachbereiche und Landesgesellschaften für das Thema Datenqualität sensibilisieren und den Bedarf für ein unternehmensweites Datenqualitätsmanagement aufzeigen.

- Transparenz schaffen: Zusammenhänge zwischen Datendefekten und Geschäftsproblemen aufzeigen und Maßnahmen zur Verbesserung der Datenqualität begründen.

- Mitarbeit stärken: Akzeptanz für die Initiative bei den verantwortlichen Anwendern der Fachbereiche schaffen, um ihre Unterstützung zu sichern.

- Handlungsbedarf identifizieren: Ermittlung des Handlungsbedarfs in verschiedenen Bereichen, um die Datenqualität verbessern zu können und nachhaltig auf einem stabilen Level zu halten.

Die Einführung des Cockpits fand zunächst in den 15 Landesgesellschaften der Region Asien-Pazifik statt. Zu Beginn wurden nur die Materialstammdaten betrachtet. BCS stellte dabei sicher, dass das Cockpit nachträglich um weitere Landesgesellschaften und Datenobjekte erweitert werden kann.

Mitarbeiterziele

Ziele für die Datenqualität sind Teil der Mitarbeiterziele bei Bayer CropScience. Da die Erfassung und Pflege der Daten in den Ländern erfolgt, wurde die Verantwortlichkeit für die Datenqualität den Leitern der Landesgesellschaften übertragen. Diese erhielten die Vorgabe, pro Land einen sogenannten Stammdaten-Koordinator einzurichten, der Datenverantwortlichkeiten und Aufgaben innerhalb des Landes etabliert und Maßnahmen zur Verbesserung der Datenqualität steuert. Die Leiter der Landesgesellschaften erhielten in ihren Jahreszielen die Vorgabe, ein Datenqualitätslevel von 97 % zu erreichen und zu halten.

Grundlage für die Berechnung der Datenqualität sind unternehmensweit gültige Geschäftsregeln, die aufgrund von Problemen in den Geschäftsprozessen identifiziert werden. Das Datenqualitätsziel von 97 % wurde nach einer Aufwand-Nutzen-Bewertung festgelegt.

Geschäftsregeln und Datenqualitätskennzahlen

Datenqualität ist kein Selbstzweck, sondern dient dazu, Geschäftsprozesse unterstützen. Deshalb wurden aus den Anforderungen der Geschäftsprozesse Regeln für die Datenqualität ermittelt. Das Projektteam von Bayer CropScience führte dazu Interviews mit den Prozessexperten. Im Zuge der Interviews wurden 160 Regeln erarbeitet. Um die Vergleichbarkeit und Integrität der Regeln und die Erreichbarkeit von Zielwerten zu gewährleisten, prüfte das Projektteam die ermittelten Regeln auf drei Eigenschaften:

- Messbarkeit: Die Regel ist technisch messbar, d. h. alle vermessenen Daten sind verfügbar und die durch die Regel formulierten Eigenschaften sind vergleichbar.

- Geschäftsrelevanz: Es gibt einen kausalen Zusammenhang zwischen der Regel und den Geschäftszielen des Unternehmens, d. h. die fachliche Auswirkung einer Regelverletzung ist nachvollziehbar.

- Geschäftskonformität: Die Regel ist „nah am Alltagsgeschäft“ und überprüft die Tätigkeiten, die im operativen Tagesgeschäft wirklich durchgeführt werden sollen.

Nach Prüfung dieser Eigenschaften verblieben 53 Regeln, die mit den Prozessexperten in mehreren Iterationen überarbeitet wurden. Abbildung 2.9 zeigt beispielhaft einige ausgewählte Geschäftsregeln für die Validierungsgruppen „Produkthierarchie“ und „Kostenrechnung“.

Abb. 2.9
Beispiele für Datenqualitätsregeln bei Bayer CropScience. (Ebner et al. 2011, S. 16)

Für eine regelmäßige Messung mussten die Werte erstens aggregierbar und zweitens vergleichbar sein. Für die Aggregation werden die Geschäftsregeln verschiedenen Validierungsgruppen wie Produkthierarchie, Kostenstelle, Materialstatus, Kostenrechnung zugeordnet. Die Validierungsgruppen wiederum sind dem übergeordneten Stammdatenobjekt zugewiesen, um bei einer zukünftigen Erweiterung um zusätzliche Stammdatenobjekte die Objekte unterscheiden zu können. Des Weiteren werden die Validierungsgruppen den Landesgesellschaften zugeordnet, die ihrerseits einer der vier Regionen Europa, Nord-, Lateinamerika oder Asien-Pazifik angehören.

Zur Vergleichbarkeit des Messwertes wird aus den einzelnen Regelprüfungen ein einheitlicher Datenqualitätsindex (DQI) gebildet. Der Index berechnet sich als Quotient der Zahl derjenigen Datensätze, die keine einzige Regel verletzen, und der Gesamtzahl an Datensätzen. Der Index kann also Werte im Intervall von 0 und 1 bzw. 0 und 100 % annehmen.

Systemarchitektur und das Data Quality Cockpit

Bayer CropScience führte die Softwarelösung IBM Information Server (IBM IS) gemeinsam mit dem Tool Data Stage zur Validierung der Geschäftsregeln und Bereitstellung der Ergebnisse ein. Die zu prüfenden Datensätze sowie die Messergebnisse werden in einer Oracle Datenbank gespeichert. Das in den IBM IS integrierte Werkzeug Data Stage modelliert die Geschäftsregeln. Abbildung 2.10 zeigt die Systemarchitektur zur Auswertung der Geschäftsregeln und Darstellung der Ergebnisse.

Abb. 2.10
Systemarchitektur des Data Quality Cockpit bei Bayer CropScience. (Brauer 2009, S. 21)

Für die Auswertung der Daten müssen diese zunächst aus dem zentralen Stammdatenserver sowie den regionalen SAP-Systemen exportiert und in den IBM IS geladen werden. Dies geschieht in monatlichen Abständen und umfasst den Datenimport aller beteiligten Landesgesellschaften. Hierbei werden die notwendigen Tabellen der Stammdatenobjekte unverändert übernommen, damit die Datensätze nachverfolgt werden können. Für jede Geschäftsregel kann so genau der defekte Quelldatensatz ermittelt werden.

Die Messergebnisse werden im Intranet mittels Oracle Application Express (APEX)[6] dargestellt. Die Hierarchie der Navigation entspricht den o. a. Aggregationsstufen nach Geschäftsregel (Validierungsregel), Validierungsgruppe, Landesgesellschaft und Stammdatenobjekt und auf oberster Ebene nach Region. Dadurch können die Nutzer von dem globalen DQI, der über alle Regionen, Objekte und Geschäftsregeln hinweg gilt, zu dem für Ihre Gesellschaft gültigen Wert navigieren. Auf oberster Ebene werden die Werte jeder Region wie in Abb. 2.11 einander gegenübergestellt.

Abb. 2.11
Datenqualitätsmessung bei Bayer CropScience. (Ebner et al. 2011, S. 24)

Auf Ebene der Landesgesellschaften werden für jedes Land folgende Werte des DQI angezeigt:

- Ziel-DQI des jeweiligen Landes

- Aktueller DQI der jeweiligen Geschäftseinheit

- DQI der Geschäftseinheit mit der besten Datenqualität

- DQI der Geschäftseinheit mit der schlechtesten Datenqualität

- Durchschnitts-DQI der Region

Das Cockpit zeigt den Namen der Geschäftseinheit mit dem besten DQI an, die schlechteste Geschäftseinheit bleibt anonym. Diese vergleichende Darstellung erzeugt einen gewissen Wettbewerb und motiviert die Mitarbeiter, ihre Daten zu verbessern, um im nächsten Monat möglicherweise an oberster Stelle zu stehen. Gleichzeitig wird vermieden, dass die schlechteste Geschäftseinheit bloßgestellt wird. Abbildung 2.12 zeigt die Gegenüberstellung der Werte der Landesgesellschaften.

Abb. 2.12
Datenqualitätsanalyse nach Landesgesellschaft bei Bayer CropScience. (Ebner et al. 2011, S. 25)

Von Ihrer Landesgesellschaft können die Nutzer über die Geschäftsregeln bis zu dem Datenobjekt navigieren, dessen Geschäftsregel nicht eingehalten wurde (siehe Abb. 2.13). So können die Bayer-Mitarbeiter die Ursachen für die Verschlechterung des DQI ermitteln und notwendige Gegenmaßnahmen einleiten.

Abb. 2.13
Verletzte Datenqualitätsregeln auf Datensatzebene bei Bayer CropScience. (Ebner et al. 2011, S. 26)

Die Darstellung der Ergebnisse und die Navigationsmöglichkeiten im Data Quality Cockpit sind für jeden Mitarbeiter identisch. Die Einstiegsseite des Cockpits kann aber individuell angepasst werden und beispielsweise mit den Auswertungen belegt werden, die für den Mitarbeiter besonders relevant sind. Das Data Quality Cockpit speichert die bisherigen DQI-Ergebnisse, sodass Bayer die Entwicklung der Datenqualität im Zeitverlauf beobachten kann. Da stets die Ergebnisse der letzten 15 Monate vorgehalten werden, ist ein Vergleich mit den letzten vier Quartalen möglich, auch mit dem entsprechenden Quartal des Vorjahres.

2.2.4 Erkenntnisse

Die wichtigsten Erkenntnisse des Projekts waren:

- Datenqualität ist Voraussetzung für Kerngeschäftsprozesse wie die Finanz- und Produktionsplanung.

- Datenqualitätsmanagement ist kein einzelnes Projekt, sondern muss über Data-Governance-Rollen in der Organisation verankert sein.

- Die regelmäßige Messung der Datenqualität ist Voraussetzung für ihr Management und damit ihre Verbesserung.

- Datenqualität muss Bestandteil der Zielvereinbarungen mit Mitarbeitern sein.

Erfolgsfaktoren für die Einführung des Data Quality Cockpits bei Bayer CropScience waren:

- Einfachheit: Eine einzige, klar verständliche Metrik wie der Datenqualitätsindex ist verständlicher und aussagekräftiger als eine Vielzahl abstrakter Metriken.

- Relevanz: Klar definierte kausale Zusammenhänge zwischen Datenqualität und Geschäftsproblemen sichern den Fokus auf die wichtigsten Datenqualitätsprobleme und sichern Mitarbeiter- und Managementunterstützung.

- Fachlichkeit: Fachliches Wissen aus dem Tagesgeschäft ist notwendig, um geschäftskritische Datendefekte zu identifizieren.

- Management: Die Unterstützung der Unternehmensleitung erhöht die Sichtbarkeit und Akzeptanz der Datenqualitätsmessung im Unternehmen.

- Visualisierung: Eine zielgruppengerechte, leicht verständliche und übersichtliche Aufbereitung der Messergebnisse ist Voraussetzung für die Akzeptanz von Datenqualitätsmessungen.

- Vergleichbarkeit: Der Vergleich von Messwerten, z. B. zwischen verschiedenen Ländern, kann die Mitarbeitermotivation erhöhen. Vergleichbare Messwerte ermöglichen auch die unternehmensübergreifende Datenauswertung.

2.2.5 Weiterführendes Material

Für den Fall von Bayer CropScience liegen an verschiedenen Orten Details aus wissenschaftlicher und auch aus praktischer Perspektive vor (Tab. 2.6):

Tab. 2.6
Weiterführendes Material zum Fall von Bayer CropScience

Quelle

Titel

Ergebnistyp

Wiss.

Praxis

Brauer 2009

Master data quality cockpit at Bayer CropScience

Präsentation auf CC CDQ-Workshop

√

Brauer 2012

The master data quality journey at Bayer CropScience

Präsentation auf CC CDQ-Steuerungskreissitzung

√

Ebner und Brauer 2011

Case study on the governance system for master data quality at Bayer CropScience

Wiss. Beitrag in Fachzeitschrift

√

√

Ebner et al. 2011

Fallstudie Bayer CropScience AG – Entwurf und Implementierung geschäftsorientierter Datenqualitätskennzahlen

Fallstudie CC CDQ

√

√

Nachtsheim et al. 2010

„TOP Controlling“-Initiative bei Bayer CropScience

Beitrag in Fachzeitschrift

√

Otto et al. 2010

Measuring master data quality: Findings from a case study

Wiss. Beitrag in Fachkonferenzband

√

√

Weber 2009

Data Governance-Referenzmodell

Dissertation

√

√

2.3 Beiersdorf: Produktdatenqualität in der Konsumgüter-Supply Chain

2.3.1 Unternehmensüberblick

Beiersdorf ist ein global operierendes Konsumgüterunternehmen mit Sitz in Hamburg, das weltweit 150 Tochtergesellschaften unterhält und knapp 17.000 Mitarbeiter beschäftigt[7]. Der Konzern untergliedert sich in zwei Unternehmensbereiche. Das Privatkundengeschäft (Bereich Consumer) mit ca. 5,1 Mrd. € Umsatz im Jahr 2013 umfasst Produkte für Haut- und Körperpflege sowie medizinische Produkte. Der größte Teil des Unternehmensumsatzes geht auf das Produktsortiment der Marke Nivea zurück, einer der ältesten und beliebtesten Marken auf dem globalen Markt für Körperpflegeprodukte. Andere bekannte Produkte in diesem Bereich sind 8 × 4 und Labello für den Massenmarkt sowie Juvena und La Prairie im Luxusgütersegment. Die Palette der angebotenen Medizinprodukte umfasst Heftpflaster, Fixierpflaster, Wundschutz und Verbände, vermarktet unter Markennamen wie Eucerin und Hansaplast. Der zweite Unternehmensbereich tesa (ca. 1 Mrd. € Umsatz im Jahr 2013) umfasst selbstklebende System- und Produktlösungen für Industriekunden und Endverbraucher (Tab. 2.7).

Tab. 2.7
Kurzprofil Beiersdorf

Beiersdorf AG

Gründung

1882

Branche

Konsumgüterindustrie

Unternehmenssitz

Hamburg, Deutschland

Rechtsform

Aktiengesellschaft

Homepage

www.beiersdorf.de

Umsatz (2013)

6,14 Mio. EUR

Gewinn (2013)

543 Mio. EUR

Mitarbeiter (2013)

16.708

Die Organisationsstruktur von Beiersdorf umfasste zum Zeitpunkt der Fallstudie zwei funktionale und drei regionale Verantwortungsbereiche (siehe Abb. 2.14). Die Informationstechnologie wird von Beiersdorf Shared Services gesteuert, einer eigenständigen Shared-Services-Organisation und Tochtergesellschaft von Beiersdorf. Die Organisationseinheit Supply-Chain-Datenprozessmanagement, angesiedelt im Unternehmensbereich Supply Chain Management, verantwortet die Organisation des unternehmensweiten zentralen Produktstammdatenmanagements.

Abb. 2.14
Organisationsstruktur von Beiersdorf und Berichtsweg des Datenprozessmanagement. (Hüner et al. 2011a, S. 144)

2.3.2 Ausgangssituation des Datenmanagements

Die Fallstudie zeigt am Beispiel Beiersdorf die Herausforderungen des unternehmensübergreifenden Datenaustauschs in der Konsumgüterindustrie. Die Partner eines Ökosystems in der Konsumgüterindustrie müssen bei einer großen Zahl an Bestandseinheiten einen effizienten Warennachschub sicherstellen. Dabei müssen sie in der Lage sein, neben den physischen Waren auch die Produktinformationen zeitgerecht und korrekt auszutauschen.

Produktdatenaustausch im Ökosystem

Dazu zeigt Abb. 2.15 einen Ausschnitt des Ökosystems von Beiersdorf, in dem die zentrale Konzernfunktion einen von elf Akteuren darstellt. In der Abbildung wird zwischen unternehmensinternen Datenflüssen (Flüsse 1, 2, 8, und 12), dem Datenfluss zwischen Beiersdorf und Dritten (Flüsse 3, 4, 5, 6, 7, 9, 10, 11, 13, und 14) sowie Datenflüssen zwischen externen Parteien (Flüsse 15 und 16) unterschieden. Anwendungssysteme für den Datenaustausch sind nicht abgebildet.

Abb. 2.15
Produktdatenaustausch im Ökosystem von Beiersdorf. (Schierning 2010, S. 25)

Die zentralen Produktdatenflüsse zwischen Beiersdorf und den weiteren Akteuren des Ökosystems sind im Folgenden genauer erläutert:

- Konzernfunktion: Zentrale Dienste bei Beiersdorf (z. B. Bedarfsplanung, Produktmarketing, Produktentwicklung, Packungsdesign) nutzen und pflegen Produktdaten (siehe [1] in Abb. 2.15) und stellen sie sowohl internen als auch externen Partnern zur Verfügung. Zum Beispiel wird eine Produktrezeptur von der Abteilung Produktentwicklung erstellt und von der Funktion Bedarfsplanung genutzt. Außerdem sind zum Beispiel GTINs oder Nettogewichte in einer Designvorlagenspezifikation [4] für externe Partner enthalten. GTINs sind die weltweit einheitlichen Identifikationsnummern für Artikel.

- Produktionswerk, Lieferant, Drittanbieter, Grafikagentur: Global verteilte Produktionsstätten und externe Produktionspartner nutzen z. B. Artikellisten oder GTINs [2, 7] sowie länderspezifische Designvorlagen [10, 15] und bestellen Rohmaterialien (Positionen von Stücklisten [9]) von Zulieferern.

- Distributionszentrum, Logistikdienstleister, Zollbehörde: Verteilzentren nutzen für die Lagerung und den Transport von Gütern logistische Daten, die von zentralen Unternehmensfunktionen [8] bereitgestellt und von den Produktionsstätten [12] bearbeitet oder ergänzt werden. Externe Dienstleister nutzen ebenfalls logistische Daten sowie Umwelt-, Gesundheits- und Sicherheitsdaten [11, 13]. Zollrelevante Daten [14] müssen den Zollbehörden zur Verfügung gestellt werden.

- Datenpool-Anbieter: Beiersdorf stellt in seinem Datenpool „1Sync“ GTINs [3] zur Nutzung durch Kundenunternehmen [16] bereit.

- Kundenunternehmen: Beiersdorf stellt Kundenunternehmen logistische Daten zur Verfügung, um deren Planungsprozesse zu unterstützen ([6], insbesondere Daten zu Packmaßen).

- Normenorganisation: Beiersdorf fragt bei Standardisierungsorganisationen Daten für die Definition von neuen GTINs [5] an.

In allen genannten Beispielen hängen reibungslose Supply-Chain-Prozesse von hoher Produktdatenqualität ab.

Data Governance und Anwendungslandschaft

Die Aufgaben der Abteilung für Datenprozessmanagement (siehe Abb. 2.14) umfassen charakteristische Pflichten eines Chief Data Steward (Weber et al. 2009), unter anderem die strategische Entwicklung des Stammdatenmanagements und die Weiterentwicklung des zentralen Stammdatensystems. Beiersdorf Shared Services stellt die Systemunterstützung sicher.

Der Leiter Supply Chain ist der „Executive Sponsor“ für das Stammdatenmanagement bei Beiersdorf. Das Datenprozessmanagement-Team hat Ansprechpartner für stammdatenbezogene Fragen in allen zentralen und lokalen Organisationseinheiten. Auf Konzernebene gibt es z. B. einen Verantwortlichen für jede Produktlinie (Nivea Body, Nivea Sun, etc.) aus den Marketingabteilungen. Auf der Ebene der Tochtergesellschaften gibt es üblicherweise pro Land einen Business Data Steward aus dem Materialmanagement.

Die Verantwortung für die Neuanlage eines Stammdatenobjekts für ein bestimmtes Produkt hängt davon ab, auf welchem Markt dieses Produkt verkauft werden soll. Die Produktdaten von Produkten, die nur in einem Land vermarktet werden, werden von den Tochtergesellschaften vor Ort erstellt. Dagegen werden Produktdaten zu international vertriebenen Produkten von der jeweiligen Marke auf Konzernebene generiert. Der Erstellungsort bestimmt auch die Verantwortlichkeiten für die anschließende Pflege der Daten. Etwa 200 Mitarbeiter der zentralen Dienste sind mit der Pflege von globalen Datenattributen betraut, während das Stammdatenmanagement auf lokaler Ebene in der Regel vom Produktmanagement übernommen wird. Beiersdorf verwaltet seine globalen Produktdaten (z. B. Produktkennungen, logistische Daten und Produkthierarchien) in einem zentralen Product-Lifecycle-Management-System (im Folgenden PLM-System), das im Jahr 2004 eingeführt wurde. In regelmäßigen Abständen (d. h. alle drei Stunden) übermittelt das PLM-System neue oder geänderte Produktdaten an vier regionale ERP-Systeme und an einige globale Anwendungssysteme (z. B. ein Entscheidungsunterstützungssystem (BW), ein Planungssystem (APO) und ein Beschaffungssystem (EBP)). Da die Daten direkt in das Zielsystem geschrieben werden, wird Konsistenz innerhalb der Datenbank gewährleistet. Die Systeme werden von Beiersdorf Shared Services unterhalten. Abbildung 2.16 zeigt die Stammdatenflüsse innerhalb der Anwendungslandschaft von Beiersdorf. Die dargestellte Anwendungslandschaft ist charakteristisch für ein global operierendes Unternehmen: Sie umfasst sowohl globale Anwendungen zur Unterstützung von Prozessen, die mehrere Organisationseinheiten betreffen, als auch lokale Anwendungen, die Prozesse in separaten Organisationseinheiten unterstützen (Lehmann 2003).

Abb. 2.16
Stammdatenflüsse innerhalb der Anwendungslandschaft von Beiersdorf. (Schierning 2010, S. 21)

Als Teil des PLM-Systems stellt die Master Data Workbench (MDW) Funktionalitäten für die Erstellung von Stammdaten bereit und gewährleistet damit, dass Stammdaten genau im Moment ihrer Erstellung ins PLM-System übertragen werden. Die Anwender des Systems (ungefähr 150 Personen) arbeiten mit Eingabemasken, die entsprechend dem Produktinnovationsprozess und dem Produktdatenpflegeprozess bei Beiersdorf gestaltet sind. Wichtige PLM-Funktionen (z. B. die Zuteilung einer eindeutigen Kennung oder Prüfroutinen) sind bereits in den Prozess zur Produktdatenanlage integriert, sodass es keine Medienbrüche gibt. Nachdem ein Produktstammdatensatz freigegeben wurde, übermittelt das PLM-System diese Daten an die regionalen ERP-Systeme.

Die externe Weitergabe von Produktdaten an Groß- und Einzelhändler wird mit einem zentralen Produktinformationsmanagement-System (im Folgenden PIM-System) kontrolliert. Das PIM-System wird von den regionalen ERP-Systemen mit globalen und lokalen Stammdaten versorgt. Es übernimmt auch die Datenübertragung an 1Sync, den Datenpool von Beiersdorf. Beiersdorf stellt in diesem Datenpool GTINs für die Nutzung durch Kundenunternehmen bereit.

2.3.3 Projekt zur Messung der Datenqualität

Im Wesentlichen ermöglichen die vorhandenen organisatorischen und technischen Strukturen des Stammdatenmanagements bei Beiersdorf bereits reibungslose länderübergreifende Supply-Chain-Prozesse. Es wurden keine regelmäßig auftretenden Geschäftsprobleme bekannt, die den strategischen Unternehmenszielen zuwiderlaufen (z. B. Einhaltung rechtlicher und regulatorischer Bestimmungen, hohe Service Levels) oder hohe Kosten verursachen. Trotzdem wurde Kritik an der Qualität der Produktdaten laut, insbesondere in Bezug auf die unternehmensübergreifende Nutzung. Zum Beispiel äußerten einige Verteilzentren Beschwerden über die Genauigkeit der Gewichtsangaben für neu eingeführte Produkte. Solche Mängel bei logistischen Daten können zusätzliche Kosten verursachen, z. B. wenn das Palettengewicht den Toleranzbereich übersteigt und Ware neu verpackt und gelagert werden muss.

Diese Beschwerden in Kombination mit dem wachsenden Bewusstsein für die Bedeutung der Produktdatenqualität an den Schnittstellen mit externen Partnern (z. B. Kundenunternehmen, Betreibern von Datenpools, Logistikdienstleistern) veranlasste das zentrale Datenprozessmanagement von Beiersdorf zum Anstoß eines Projekts mit dem Ziel, a) geschäftskritische Datenmängel zu identifizieren, und b) Messwerte für die Datenqualität zur Überwachung dieser Mängel festzulegen. Das Projekt umfasste folgende Phasen:

- Phase I: Scoping. Bestimmung von Datenattributen und Datenqualitätsdimensionen, die als geschäftskritisch eingestuft werden.

- Phase II: Interviews. Identifikation von Geschäftsproblemen, die auf Mängel bei den ausgewählten Attributen zurückzuführen sind (über Interviews mit Vertretern von diversen Partnern im Ökosystem von Beiersdorf).

- Phase III: Analyse. Zusammenfassung der Interviewergebnisse und Identifikation von kritischen Datenmängeln.

- Phase IV: Spezifikation. Spezifikation von Messwerten für die Datenqualität zur Überwachung kritischer Datenmängel.

Phase I: Identifikation kritischer Datenmängel

Da das Produktdatenmodell des PLM-Systems von Beiersdorf über 800 Attribute aufweist, gruppierte das Projektteam diese Attribute in Phase I in Datencluster. Diese Cluster ordnen die Attribute in logische Untergruppen, die bei der weiteren Bearbeitung der Attribute helfen und bereits Hinweise darauf geben, in welchen Geschäftsprozessen diese Attribute benutzt werden (z. B. die Cluster „Stückliste“ oder „Logistische Daten“). Das Projektteam machte eine Vorauswahl von 20 Clustern (mit insgesamt rund 100 Attributen), die in den Interviews untersucht werden sollten. In der Folge wurden vier Datenqualitätsdimensionen bestimmt: Genauigkeit (korrekte Datenwerte?), Vollständigkeit (Datenwerte vorhanden?), Konsistenz (gleiche Datenwerte für ein Attribut in verschiedenen Systemen?) und Aktualität (Datenwerte stets rechtzeitig verfügbar?). Das Team wählte solche Datencluster und Datenqualitätsdimensionen, die in Beschwerden über die Qualität der Produktdaten Erwähnung fanden. Die Dimensionen dienten der Strukturierung der Interviews, d. h. das Team entwarf pro Dimension mehrere Fragen, die für jedes ausgewählte Attribut diskutiert wurden (z. B. „Gibt es fehlerhafte oder ungenaue Daten?“, „Gibt es veraltete Daten?“, „Gibt es inkonsistente Daten in Bezug zu Daten im PLM-System?“).

Phase II: Interviews

In Phase II wurden Interviewpartner ausgewählt und die Interviews durchgeführt. Sieben Interviews deckten wichtige Teile der Supply Chain und wesentliche Komponenten der Produktpalette ab, z. B. Produkte für den Massenmarkt, komplexe Erzeugnisse sowie Produkte aus Eigen- und Fremdfertigung. Alle Interviewten waren seit Jahren bei Beiersdorf beschäftigt (einige seit mehr als 20 Jahren) und kannten sich sehr gut mit den Daten, Prozessen und Systemen des Unternehmens aus. Um die Bedeutung dieser Interviews hervorzuheben, lud der Leiter der Abteilung Supply Chain Development die Interviewteilnehmer ein. Die Interviewten wiesen anhand der Datencluster und Datenqualitätsdimensionen im Interviewleitfaden auf mögliche Probleme in ihren vertrauten Geschäftsprozessen hin und trugen so dazu bei, Datenmängel zu identifizieren und Verbesserungsmöglichkeiten für die internen Abläufe zu diskutieren. Beschwerden über andere Akteure des Ökosystems traten nicht auf. Die Interviewteilnehmer wurden auch nach ihrer allgemeinen Einschätzung der Datenqualität befragt, um weitere Themen oder Probleme aufzudecken, die der Interviewleitfaden nicht abdeckte (z. B. andere Attribute).

Sie wurden anschließend aufgefordert, alle identifizierten Geschäftsprobleme hinsichtlich ursächlicher Datenattribute und Fehlerarten zu beschreiben und die Probleme auf einer Skala von 1 bis 5 einzustufen. Kriterien dafür waren z. B. entstandene Kosten, eine Beeinträchtigung der Dienstleistungsqualität oder das Risiko von Beschwerden. Der Interviewleitfaden enthielt erläuternde Beispiele für die verschiedenen Ausprägungsarten der Bewertungsskala, damit die Interviewteilnehmer die Skala über alle Interviews hinweg einheitlich verstanden und die Interviewergebnisse untereinander verglichen werden konnten.

Phase III: Analyse

In Phase III wurden die Interviewergebnisse zusammengefasst, um erstens die Datenqualitätsprobleme zu identifizieren, die kritisch für das gesamte Ökosystem sind. Auf dieser Basis sollten danach die wichtigsten Datencluster bestimmt werden. Das Ergebnis waren die folgenden sieben Datenqualitätsprobleme:

- Fehlende Angaben zu Temperaturbedingungen für den Transport: In einigen Fällen wurden Produkte aufgrund extremer Außentemperaturen gefroren geliefert. Die Folge waren Kundenbeschwerden und zusätzliche Kosten für die Rücksendung, Qualitätsprüfung und erneute Lieferung. Der Aufbau des PLM-Systems sah keine produktspezifischen Angaben für die Umgebungstemperatur beim Transport vor.

- Kein einheitliches Format für die Produktkennzeichnung (Verfallsdatum): Wie viele andere Unternehmen hatte Beiersdorf in einigen Fällen Probleme mit dem korrekten Format für die Kennzeichnung der Produktverpackungen mit dem Verfallsdatum. Diese Formate unterscheiden sich von Land zu Land und mussten häufig einzeln recherchiert werden, da keine vollständige zentrale Dokumentierung aller gültigen Formate zum Nachschlagen existierte.

- Fehlende Gefahrgutkennzeichnung bei Produktbündeln: Beiersdorf stellt stets sicher, dass Gefahrengüter (z. B. Spraydosen mit Deodorant) entsprechend gekennzeichnet und beschriftet sind. Fehlende oder fehlerhafte Gefahrgutkennzeichnungen waren deshalb bisher nicht bekannt. Jedoch werden Produktbündel für bestimmte Marketingkampagnen (z. B. Auslagen, die eine Tasche mit Shampoo und Deospray enthalten) meist nicht in den Produktionsstätten verpackt, in denen die einzelnen Komponenten hergestellt werden, sondern in den Verteilzentren. In diesem Fall müssen die Stücklisten der kombinierten Produkte einzeln überprüft werden, um festzustellen, ob eine Gefahrgutkennzeichnung notwendig ist. Dieser Prozess wurde in mehreren Interviews als mühsam und risikoreich beschrieben, auch wenn keine konkreten Ausfälle erwähnt wurden.

- Fehlende oder fehlerhafte GTIN: Es gab Fälle, in denen GTINs für logistische Einheiten (z. B. Schrumpfverpackung, Packungseinheit, Palette) fehlten, fehlerhaft oder nicht eindeutig waren (z. B. Produkt-GTINs, die auch für Schrumpfverpackung benutzt wurden) oder nicht mit den Daten übereinstimmten, die an den GS1-Datenpool übermittelt wurden (die GS1 ist eine internationale Organisation, die globale Standards für Supply Chains entwickelt und umsetzt). Die Folge waren Probleme im Vertrieb der Produkte und ein Abfall des Dienstleistungsniveaus.

- Ungenaue oder nicht rechtzeitig verfügbare logistische Daten: Das automatisch errechnete Produktgewicht wurde im PLM-System nicht in allen Fällen durch die nach der Produktion und letzten Anpassungen gemessenen tatsächlichen Werte ersetzt. Bei Produkten mit einer transparenten Verpackung (z. B. Shampoo, das in durchsichtigen Flaschen abgefüllt ist) wurde die Flasche in manchen Fällen auf etwas mehr als das angegebene Füllgewicht bis zum Deckel aufgefüllt, da die Flasche andernfalls etwas leer aussieht. Obwohl sich solche Volumenänderungen im Rahmen des von der GS1 vorgegebenen Toleranzbereichs von 20 % bewegen, können durch erhöhte Palettengewichte Logistikprozesse beeinflusst werden.

- Stückliste nicht rechtzeitig freigegeben: In einigen Fällen waren Stücklisten nicht rechtzeitig verfügbar oder wurden nach dem Freigabedatum mehrmals geändert. Dadurch konnte es zu Verzögerungen im Produktionsprozess, zu zusätzlichem Aufwand in den Produktionsstätten und zu potentiell niedrigerer Dienstleistungsqualität kommen.

- Dokumente nicht rechtzeitig verfügbar: Es gab zudem Fälle, in denen Designvorlagen und technische Zeichnungen nicht rechtzeitig verfügbar waren, was ebenfalls zu Verzögerungen im Produktionsprozess, zu zusätzlichem Aufwand in den Produktionsstätten und zu potentiell niedrigerer Dienstleistungsqualität führte.

Die Messwerte für die Datenqualität basierten zum Großteil auf diesen sieben Problemen. Allerdings wurde das Problem der fehlenden Angaben zu Transport-Temperaturbedingungen nicht als Problem der Datenqualität eingeordnet, da nicht genügend Informationen für die Definition von Schwellenwerten verfügbar waren. Dafür wurden zollrelevante Daten während einer Zwischenpräsentation als ein weiterer kritischer Cluster ausgemacht. Das Projektteam ergänzte daraufhin die Datenqualitätsmesswerte um Prüfregeln für die Aktualität bei den Attributen Commodity Code und Herkunftsland.

Tabelle 2.8 fasst die als kritisch befundenen Datenmängel zusammen (d. h. betroffene Datenattribute und Datenqualitätsdimension) und ordnet sie den Datenflüssen innerhalb des in Abb. 2.15 abgebildeten Ökosystems von Beiersdorf zu. Sie zeigt zudem die Auswirkungen der Datenmängel auf die betroffenen Geschäftsprozesse auf.

Tab. 2.8
Kritische Datenmängel und Einfluss auf Geschäftsprozesse

Datenfluss

Datencluster/Attribut

Datenqualitätsdimensionen

Einfluss auf Geschäftsprozesse

[2]

Stückliste

Aktualität, Änderungshäufigkeit

• Zusätzliche Kosten aufgrund neuer Produktion, wenn Änderungen der Stückliste Produkte unbenutzbar machen

• Beeinträchtigung der Dienstleistungsqualität aufgrund von Verzögerungen in der Produktion

Format der Produktkennzeichnung

Genauigkeit, Vollständigkeit, Änderungshäufigkeita

• Zusätzliche Kosten aufgrund zusätzlicher Arbeit (z. B. Informationen einholen, Kommunikation)

• Zusätzliche Kosten durch Nachbesserungen, wenn der Mangel nicht vor Produktionsbeginn erkannt wird

• Risiko der Geldstrafe durch Aufsichtsbehörden, wenn der Mangel nicht vor Lieferung der Waren erkannt wird

[3]

GTIN

Konsistenz

• Beeinträchtigung der Dienstleistungsqualität, wenn Unstimmigkeiten nicht vor Lieferung der Waren erkannt werden

• Risiko der Geldstrafe durch Aufsichtsbehörden, wenn der Mangel nicht vor Lieferung der Waren erkannt wird

Logistische Daten

Genauigkeit

• Beeinträchtigung der Dienstleistungsqualität, wenn Unstimmigkeiten nicht vor Lieferung der Waren erkannt werden

• Risiko der Geldstrafe durch Aufsichtsbehörden, wenn der Mangel nicht vor Lieferung der Waren erkannt wird

[4]

GTIN

Genauigkeit, Konsistenz

• Zusätzliche Kosten durch Notwendigkeit neuer Designvorlage, wenn der Mangel nicht vor Produktion oder Lieferung erkannt wird

[6]

Gefahrgutkennzeichnung

Vollständigkeit

• Risiko der Geldstrafe durch Aufsichtsbehörden, wenn der Mangel nicht vor Lieferung der Waren erkannt wird

Logistische Daten

Aktualität

• Kosten aufgrund entgangener Erlöse

[7]

Stückliste

Aktualität, Änderungshäufigkeit

• Zusätzliche Kosten aufgrund neuer Produktion oder Nachbesserung, wenn Änderungen der Stückliste bestehende Produkte unbenutzbar machen

• Beeinträchtigung der Dienstleistungsqualität aufgrund von Verzögerungen in der Produktion

[8]

Gefahrgutkennzeichnung

Vollständigkeit

• Zusätzliche Kosten aufgrund zusätzlicher Arbeit (z. B. Informationen einholen, Kommunikation)

GTIN

Genauigkeit, Vollständigkeit, Änderungshäufigkeit

• Zusätzliche Kosten aufgrund zusätzlicher Arbeit (z. B. Informationen einholen, Kommunikation)

• Risiko der Geldstrafe durch Aufsichtsbehörden, wenn der Mangel nicht vor Lieferung der Waren erkannt wird

Logistische Daten

Genauigkeit, Vollständigkeit, Änderungshäufigkeit

• Zusätzliche Kosten aufgrund zusätzlicher Arbeit (z. B. Informationen einholen, Kommunikation), insbesondere hinsichtlich GTINs für Logistikbereiche

[10]

Designvorlagen, technische Zeichnungen

Aktualität

• Beeinträchtigung der Dienstleistungsqualität aufgrund von Verzögerungen in der Produktion

[11]

Gefahrgutkennzeichnung

Vollständigkeit

• Risiko der Geldstrafe durch Aufsichtsbehörden, wenn der Mangel nicht vom Logistikdienstleister erkannt wird

[12]

GTIN

Genauigkeit, Konsistenz, Vollständigkeit

• Zusätzliche Kosten aufgrund zusätzlicher Arbeit (z. B. Informationen einholen, Kommunikation), insbesondere hinsichtlich GTINs für Logistikbereiche

Logistische Daten

Genauigkeit, Änderungshäufigkeit

• Zusätzliche Kosten aufgrund zusätzlicher Arbeit (z. B. Informationen einholen, Kommunikation), insbesondere betreffend Bruttogewicht

[13]

Gefahrgutkennzeichnung

Vollständigkeit

• Risiko der Geldstrafe durch Aufsichtsbehörden, wenn der Mangel nicht vom Logistikdienstleister erkannt wird

Logistische Daten

Genauigkeit

• Zusätzliche Kosten, wenn Ware aufgrund Übertretung des Toleranzbereichs neu verpackt und gelagert werden muss

[14]

Zollrelevante Daten

Aktualität

• Zusätzliche Kosten aufgrund zusätzlicher Arbeit (z. B. Informationen einholen, Kommunikation)

• Beeinträchtigung der Dienstleistungsqualität aufgrund von Verzögerungen in der Produktion

[15]

Designvorlagen, technische Zeichnungen

Aktualität

• Beeinträchtigung der Dienstleistungsqualität aufgrund von Verzögerungen in der Produktion

a Die Dimension Änderungshäufigkeitwurde in der Analysephase ergänzt,

da verschiedene Probleme mit Attributen in Verbindung gebracht wurden, die nach der eigentlichen Freigabe der Daten oft geändert wurden (z. B. Statuswerte in Stücklisten).

Phase IV: Spezifikation von Messwerten für die Datenqualität

Ziel der Phase IV war es, Messwerte für die Datenqualität festzulegen, die eine Überwachung der in den Interviews identifizierten Datenmängel ermöglichen. Die gemessenen Werte für die Datenqualität wurden auf das Intervall [0; 1] normiert, das wie folgt interpretiert wird:

- Bester Wert (1): Kein überprüftes Datenobjekt enthält einen kritischen Mangel.

- Schlechtester Wert (0): Jedes überprüfte Datenobjekt enthält mindestens einen kritischen Mangel.

Die Struktur des Messsystems orientiert sich an den Datenclustern, die als Ursache kritischer Geschäftsprobleme identifiziert wurden (d. h. ein Messwert pro Cluster). Um zu einem späteren Zeitpunkt die ermittelten Messwerte zusammenfassen und vergleichen zu können, wurde eine Berechnungsformel entwickelt, die auf alle Messwerte anwendbar ist. Aus demselben Grund wurde eine einheitliche Struktur für alle Prüfregeln festgelegt. Eine Prüfregel überprüft, ob ein Datenobjekt (das alle Datenattribute umfasst, die ein Produkt ausmachen) alle Eigenschaften aufweist, die von der Regel definiert sind oder ob mindestens ein Kriterium nicht erfüllt ist.

Ein Messwert für Datenqualität wird ermittelt, indem alle für diesen Messwert definierten Prüfregeln (d. h. alle Regeln, die für eine Datenklasse definiert sind) auf diejenigen Datenobjekte angewendet werden, die per Definition durch eine bestimmte Regel überprüft werden sollen. Für jede Prüfregel bestimmt ein Gewichtungsfaktor, mit welchem Gewicht die Regel in den Messwert eingeht. Die sieben Messwerte für die Produktdatenqualität und ihre 32 Prüfregeln sind in einem Reportingtool implementiert. Es analysiert regelmäßig alle Produktdatenobjekte und ermittelt die Messwerte, die monatlich ausgewertet werden.

2.3.4 Erkenntnisse

Die geringe Anzahl von Beschwerden über die Qualität von Produktdaten im Allgemeinen und die Ergebnisse der Interviews weisen darauf hin, dass Beiersdorf mit einer verhältnismäßig geringen Zahl von geschäftskritischen Produktdatenmängeln konfrontiert ist. Dies ist sicherlich auch auf die gute Organisation und technische Unterstützung durch das unternehmenseigene Stammdatenmanagement zurückzuführen. Mängel wie inkonsistente unternehmensinterne Produktdaten, Dubletten oder fehlerhafte Positionen in Stücklisten können größtenteils durch Maßnahmen wie eine zentrale Zuweisung von eindeutigen Produktkennungen, die Integration von Produktdatenpflegeprozessen schon bei der Produktinnovation (siehe MDW in Abb. 2.16) oder eindeutig zugewiesene Aufgaben und Verantwortlichkeiten der Produktdatenpflege vermieden werden.

Dennoch treten bei Beiersdorf noch kritische Dateneffekte auf, insbesondere im Datenaustausch mit anderen Unternehmen. Im Rahmen der Interviews wurden zollrelevante Daten, die von verschiedenen Partnern genutzt werden, darum als wichtiger Cluster ergänzt. Erfreulicherweise werden viele der Mängel (z. B. fehlende Gefahrgutkennzeichnung oder fehlerhafte Kennzeichnung des Palettengewichts) in manuellen Kontrollprozessen durch erfahrene Mitarbeiter erkannt. Solche Prozesse sind nur bedingt automatisierbar und zeigen, dass manuelle Kontrollen auch nach der Implementierung von IT-gestützten Datenqualitätskontrollen weiterhin wichtig sind. Abteilungs- und bereichsübergreifende Datenmanagementprozesse (z. B. die Pflege von GTINs oder das Design von Vorlagen) sind jedoch noch nicht hinreichend definiert. Eine kontinuierliche Überprüfung der Datenmängel, die mithilfe der Messwerte für Datenqualität festgestellt wurden, wird zeigen, ob geplante Maßnahmen (z. B. neue Arbeitsabläufe, überarbeitete Prozesse der Bereitstellung von GTINs, neu definierte Prozesse für die Herstellung von Designvorlagen) die Qualität der Produktdaten nachhaltig verbessern können. Um das ausgearbeitete Messsystem für Datenqualität umzusetzen, hat Beiersdorf ein Folgeprojekt für die Einführung spezifischer Messwerte angestoßen.

Zusammengefasst waren die wichtigsten Erkenntnisse des Projekts:

- Produktdatenqualität ist Voraussetzung für Supply-Chain-Prozesse.

- Anforderungen an die Datenqualität leiten sich aus den Steuerungsgrößen der Geschäftsprozesse und den Anforderungen der Datennutzer ab.

- Datenqualität muss über Datenqualitätsdimensionen operationalisiert und messbar gemacht werden.

2.3.5 Weiterführendes Material

Für den Fall von Beiersdorf liegen an verschiedenen Orten Details aus wissenschaftlicher und auch aus praktischer Perspektive vor (Tab. 2.9).

Tab. 2.9
Weiterführendes Material zum Fall von Beiersdorf

Quelle

Titel

Ergebnistyp

Wiss.

Praxis

Schemm 2008

Stammdatenmanagement zwischen Handel und Konsumgüterindustrie: Referenzarchitektur für die überbetriebliche Datensynchronisation

Dissertation

√

√

Hüner 2010

Methode zur Spezifikation geschäftsorientierter Datenqualitätskennzahlen

Arbeitsbericht CC CDQ

√

√

Hüner 2011

Führungssysteme und ausgewählte Maßnahmen zur Steuerung von Konzerndatenqualität

Dissertation

√

√

Hüner et al. 2011a

Product data quality in supply chains: The case of Beiersdorf

Wiss. Beitrag in Fachzeitschrift

√

√

Grillo 2009

Improvement of Master Data Quality at Beiersdorf

Präsentation auf CC CDQ-Workshop

√

Schierning 2010

MDM @ Beiersdorf: Project DACOTA „Data Defect Identification & Measurement“

Präsentation auf CC CDQ-Workshop

√

Schierning 2012

Consumer-centric Information Management: Exploring Product Information

Präsentation auf CC CDQ-Workshop

√

2.4 Bosch: Datenarchitekturmanagement in einem diversifizierten Technologiekonzern

2.4.1 Unternehmensüberblick

Bosch ist ein weltweit führendes Technologieunternehmen mit einem Jahresumsatz von über 45 Mrd. EUR und mehr als 280.000 Mitarbeitern[8]. Die Bosch-Gruppe besteht aus der Robert Bosch GmbH und etwa 360 Tochter- und Regionalgesellschaften in rund 50 Ländern. Die vier Geschäftsbereiche von Bosch sind Kraftfahrzeugtechnik, Industrietechnik, Gebrauchsgüter und Energie- und Gebäudetechnik (Tab. 2.10).

Tab. 2.10
Kurzprofil Bosch

Robert Bosch GmbH

Gründung

1886

Branche

Mischkonzern: Technologie, Maschinenbau, Dienstleistungen

Unternehmenssitz

Gerlingen, Deutschland

Rechtsform

GmbH

Homepage

www.bosch.de

Umsatz (2013)

46,07 Mrd. EUR

Gewinn (2013)

1,25 Mrd. EUR

Mitarbeiter (2013)

281.381

Diese Geschäftsbereiche umfassen insgesamt 16 Divisionen, die in mehr als hundert Ländern auf der Welt aktiv sind (siehe Abb. 2.17).

Abb. 2.17
Geschäftsbereiche der Bosch-Gruppe. (nach Bosch 2013, S. 21)

2.4.2 Ausgangssituation und Handlungsdruck

Bosch hat in den einzelnen Sparten und Geschäftsbereichen über viele Jahre hinweg Erfahrungen mit dem Datenmanagement gesammelt. Allerdings gab es vor 2006 keine unternehmensweite Initiative für das Stammdatenmanagement bzw. das Datenqualitätsmanagement. Die Vielzahl an bestehenden Aktivitäten verlief unkoordiniert, folgte keinen unternehmensweiten Vorgaben und war von redundanten Aufgaben gekennzeichnet.

Steigende Komplexität in Produkten und Prozessen, kürzere Lebenszyklen, voranschreitende Globalisierung sowie die zunehmende Vernetzung der einzelnen Sparten untereinander erhöhen die Bedeutung der Daten für den Unternehmenserfolg. Das Unternehmen verabschiedete deshalb 2006 eine Konzernrichtlinie für das unternehmensweite Stammdatenmanagement. Die Konzernrichtlinie regelt die folgenden Punkte:

- Gemeinsame Ziele im Stammdatenmanagement

- Gemeinsamer Ordnungsrahmen für das Stammdatenmanagement (Funktionen und Rollen)

- Definition unternehmensweit relevanter Stammdatenklassen (u. a. Daten zu Kontenplänen, Lieferanten, Kunden, Mitarbeitern, Materialien, Kundenhierarchien)

Die Richtlinie regelt zudem den Aufbau eines unternehmensweiten Stammdatenmanagements mit folgenden Zielen (Hatz 2008):

- Eindeutige, verbindliche Zuständigkeiten bei der Ordnungsfunktion für eine Stammdatenklasse (insbesondere bei der Datenpflege) durch eine Stammdatenowner-Organisation

- Einheitliches und konsistentes Datenmodell (z. B. hinsichtlich Struktur und Inhalt) als Basis für effiziente Prozessgestaltung und -abwicklung

- Bereitstellung und Nutzung von IT-Tools zur Stammdatenpflege, -harmonisierung, -konsolidierung und -verteilung

- Einheitliche Methodik für die Bearbeitung von stammdatenrelevanten Aufgaben (z. B. die Erstellung von Konzepten, Umsetzung von IT-Projekten, Ausübung der Ordnungsfunktion) und Prozessen

Die Konzernrichtlinie beschreibt zudem den Ordnungsrahmen für das Stammdatenmanagement bei Bosch. Es unterteilt die Stammdatenaktivitäten in organisatorische/funktionale Aktivitäten (hellgrau gefärbt in Abb. 2.18) und technische Aktivitäten (dunkelgrau gefärbt). Erstere liegen in der Verantwortung der sogenannten Data Owner (Master Data Owner, MDO), letztere in der Verantwortung der zentralen IT-Abteilung. Data Owner können über Anforderungen, Definitionen und Nutzung ihrer jeweiligen Datenklasse bestimmen.

Abb. 2.18
Ordnungsrahmen des Stammdatenmanagements bei Bosch. (Otto 2012a, S. 11)

Boschs Ordnungsrahmen für das Stammdatenmanagement unterscheidet zudem vier Teilfunktionen (siehe Abb. 2.18):

- Das Führungssystem (Governance) legt die Richtlinien für die Bewirtschaftung jeder Stammdatenklasse fest und überwacht die Umsetzung und den Erfolg des Datenmanagements für diese Datenklassen.

- Die Datenbereitstellung (Provisioning) hat mehrere Funktionen: Sie entwirft erstens die Organisation des Datenmanagements (inkl. der Rollenzuordnung) und zweitens die Datenerfassungs- und Datenpflegeprozesse. Drittens ist sie für die Entwicklung eines konzeptionellen Stammdatenmodells zuständig und definiert viertens die Anwendungssysteme, in denen die Daten führend bewirtschaftet werden.

- Die Datennutzung umfasst die Verwendung der Daten in den Geschäftsprozessen. Aufgrund der Komplexität der Aufbauorganisation und der Vernetzung der Sparten nutzen verschiedene Geschäftsprozesse in unterschiedlichen Sparten dieselben Daten.

- Die Funktion „Konzepte und Projekte“ ist für die Weiterentwicklung des Datenmanagements sowie die Anpassung der Daten über ihren Lebenszyklus hinweg verantwortlich. Da sich die Geschäftsprozesse ändern, wandeln sich auch die Anforderungen an die Daten. Beispielsweise wird die Handelsregisternummer im Lieferantenstamm aufgrund gesetzlicher Vorgaben von einem Kann- zu einem Muss-Feld.

Die Stammdatenarchitektur (im Folgenden kurz Datenarchitektur genannt) regelt den Zugriff, die Verteilung und den Fluss der Stammdaten mit dem Ziel, hohe Datenqualität sicherzustellen (DAMA 2009). Sie umfasst auch ein konzeptionelles Stammdatenmodell und die Applikationslandschaft. Der Entwurf einer angemessenen Datenarchitektur war somit eine der wichtigsten Gestaltungsaufgaben bei Bosch, um die erwähnte Konzernrichtlinie umzusetzen. Die Anforderungen an diese Aufgabe und die erwogenen Gestaltungsmöglichkeiten stehen im Mittelpunkt dieser Fallstudie.

Aufgrund des wachsenden Vernetzungsgrads des Unternehmens und der daraus resultierenden Vielzahl an Beziehungen zwischen Datenbereitstellung und Datennutzung stand Bosch vor einer Art „Quadratur des Kreises“ beim Entwurf der Datenarchitekturen für die einzelnen Stammdatenklassen. Zwar verfolgte das Unternehmen grundsätzlich das Ziel, seine Architekturen zu standardisieren, andererseits mussten aber spartenspezifische Anforderungen berücksichtigt werden, die keine vollständige Standardisierung erlaubten. Exemplarische Herausforderungen waren:

- Die Migration auf eine einzige Standardarchitektur wäre in vielen Fällen zu kostspielig und zu riskant – auch aufgrund unterschiedlicher Anwendungssysteme in den einzelnen Sparten.

- Der Harmonisierungsbedarf der Daten unterscheidet sich von Stammdatenklasse zu Stammdatenklasse. So ist er z. B. bei Mitarbeiterdaten vergleichsweise hoch, bei Lieferantendaten jedoch gering.

- Der Reifegrad im Stammdatenmanagement war über das Unternehmen hinweg uneinheitlich.

Bosch entschied, dass diese Faktoren einem Einheits-Architekturansatz („one size fits all“) widersprechen. Infolgedessen beschloss das Unternehmen, mehrere Datenarchitekturmuster zu entwickeln, um sowohl einige Vorteile einer Standardisierung erreichen als auch gleichzeitig individuell auf Anforderungen aus den Sparten eingehen zu können.

2.4.3 Datenarchitekturmuster bei Bosch

Grundlegendes Entwurfsprinzip der Datenarchitektur bei Bosch ist die Berücksichtigung sowohl fachlicher als auch technischer Aspekte. Dieses Prinzip ist bereits im o. a. Ordnungsrahmen verankert und in Abb. 2.19 dargestellt.

Abb. 2.19
Entwurfsprinzip für die Datenarchitektur bei Bosch. (Otto 2012a, S. 8)

Datenarchitekturmuster

Bosch entwickelte vier mit der Konzernrichtlinie konforme Datenarchitekturmuster, aus denen die Data Owner (MDO) wählen können. Die Architekturmuster haben den Vorteil, dass sie anbieter- und lösungsunabhängig sind. Damit ermöglichen sie den Vergleich existierender Angebote für Stammdatenmanagementsysteme am Markt und beschleunigen die Einführung der Stammdatenkonzepte.

Abbildung 2.20 zeigt die vier Datenarchitekturmuster, die bei Bosch als Blaupause für alle Stammdatenklassen gelten.

Abb. 2.20
Datenarchitekturmuster bei Bosch. (Otto 2012a, S. 15)

Muster A beschreibt einen analytischen Ansatz. Sämtliche Aktivitäten zur Datenerfassung und Datenpflege werden in den lokalen Quellsystemen ausgeführt. Die Stammdaten werden periodisch in einen zentralen Stammdaten-Server (MDS) importiert. Der MDS ordnet den Daten eine unternehmensweit gültige, einzigartige Nummer zu und stellt sicher, dass Duplikate identifiziert und bereinigt werden. Die Daten werden allerdings nicht in die Quellsysteme zurückgespielt, sondern lediglich für Analysezwecke im MDS gehalten. Ein klassischer Anwendungsfall für dieses Architekturmuster ist die Konsolidierung von Lieferantenstammdaten für Einkaufsanalysen (z. B. Spend-Analysen).

Muster B beschreibt im Gegensatz dazu einen transaktionalen Ansatz. Dabei fungiert der MDS als „single source of truth“, auf dem die Daten erfasst und gepflegt werden. Die Daten werden dann an angeschlossene Zielsysteme gesendet und können dort nur noch gelesen, aber nicht mehr verändert werden. Auch die Datenqualitätskontrolle findet auf dem MDS statt. Dieses Architekturmuster eignet sich besonders für Daten mit hohen rechtlichen und behördlichen Anforderungen, die nur von einer kleinen Anzahl Nutzern bearbeitet werden. Bosch verwaltet auf diese Weise beispielsweise seinen zentralen Kontenplan.

Muster C nennt Bosch „Koexistenz“. Daten werden zwar in Quellsystemen gepflegt, aber auf einem zentralen MDS qualitätsgesichert (d. h. auf Duplikate geprüft und mit einem eindeutigen Identifikationsschlüssel versehen). Diese Daten werden dann teilweise in die Quellsysteme zurückgespielt, aber vor allem auch in andere Systeme weiterverteilt. Ein typisches Einsatzgebiet für dieses Architekturmuster sind Mitarbeiterdaten: Diese müssen einerseits lokalen Anforderungen genügen, aber andererseits auch zentral für das Personalwesen der gesamten Gruppe einsehbar sein, z. B. für die Planung von Trainingsmaßnahmen.

Muster D ist der parallele Ansatz. Dabei verbleibt die Datenerfassung und Datenpflege lokal und die Datenadministratoren arbeiten auch in ihrer gewohnten Systemumgebung. Mit Hilfe eines Workflows werden diese Datenpflegeaufgaben aber mit den Funktionen des MDS integriert, der auf diese Weise bereits während der Anlage den eindeutigen Schlüssel zuweist und auf Duplikate prüft. Diese Funktionen des MDS sind in die Anwendungssoftware der Quellsysteme integriert. Hier wird beispielsweise die Standardfunktionalität der SAP-Transaktionen MM01 und MM02 zur Anlage und Änderung von Materialstammdaten durch spezifische MDS-Funktionalität ergänzt oder ersetzt. Dieses Architekturmuster findet dort Einsatz, wo die Datenerfassung von lokaler Fachexpertise abhängt und deswegen weiter in der gewohnten Systemumgebung erfolgen soll, es aber auch zentrale Anforderungen gibt (z. B. eine unternehmensweite Sichtbarkeit des Lagerbestands). Ein Beispiel sind Stammdaten zu Ersatzteilen von Maschinen.

Organisationsentwürfe

Bosch unterscheidet anhand von vier Designparametern drei verschiedene Organisationsentwürfe. Die vier Designparameter sind:

- Organisatorische Verankerung der Verantwortung für eine Stammdatenklasse, die im Falle von Bosch stets dezentral ist

- Verantwortung für den Entwurf der Datenpflegeprozesse, die entweder zentral oder dezentral organisiert sein kann

- Verantwortung für die Ausführung der Datenpflegeprozesse, die ebenfalls entweder zentral oder dezentral organisiert sein kann

- Verantwortung für den Datenmodellentwurf

Tabelle 2.11 zeigt die drei möglichen Organisationsentwürfe im Überblick.

Tab. 2.11
Organisationsentwürfe für die Datenarchitektur bei Bosch. (Otto 2012a, S. 17)

Designparameter

I

(Zentraler Ansatz)

II

(Hybrider Ansatz)

III

(Lokaler Ansatz)

Organisatorische Verantwortlichkeit für Stammdatenklasse

Verantwortung liegt beim MDO,zusammen mit Repräsentanten einer Geschäftseinheit und MDF

Design der Datenpflegeprozesse

▪ MDO definiert unternehmensweite Pflegeprozesse(Standard)

▪ MDO definiert Prinzipien für unternehmensweite Pflegeprozesse

▪ Detaillierte Definitionen werden von Geschäftseinheiten erstellt

▪ Keine zentralen Prinzipien durch MDO

▪ Pflegeprozesse werden von Geschäftseinheiten erstellt

Ausführung der Datenpflegeprozesse

▪ Datenpflege durch zentrale MDO Organisation,zusammen mit Geschäftseinheit

▪ Datenpflege durch Geschäftseinheiten

▪ Datenpflege durch Geschäftseinheiten

Design des konzeptuellen Datenmodells

Design durch MDO

Beispiele

▪ Kundenhierarchiedaten

▪ Stammdaten der Konsumenten

▪ Ersatzteile von Maschinen

▪ Stammdaten des Personalwesens

▪ Produkthierarchie

MDO master data owner, MDF master data officer

Da Bosch eine unternehmensweite Verantwortung für einzelne Stammdatenklassen anstrebt, verbleiben die organisatorische Verankerung sowie der Entwurf des konzeptionellen Datenmodells immer an zentraler Stelle, nämlich beim MDO der jeweiligen Stammdatenklasse.

Entscheidungsmatrix für die Datenarchitektur

Aus der Kombination von technischer und organisatorischer Sicht auf die Datenarchitektur entwickelte Bosch eine Entscheidungsmatrix, die sinnvolle Kombinationen der Ansätze aufzeigt (siehe Tab. 2.12).

Tab. 2.12
Entscheidungsmatrix für die Datenarchitektur bei Bosch. (Otto 2012a, S. 18)

Organisatorischer Ansatz

I

(Zentral)

II

(Hybrid)

III

(Lokal)

Technischer Ansatz

A (Analytisch)

〇

◑

●

B (Transaktional)

●

●b

〇

C (Koexistenz)

〇

●a

〇

D (Parallel)

〇

●

〇

〇 Nicht durchführbarer Ansatz (mehr Nachteile als Vorteile), ◑ muss von Fall zu Fall entschieden werden, ● bevorzugter Ansatz

a Bsp. für Mitarbeiterstammdaten

b Bsp. für Kundenstammdaten

Für Bosch kommen fünf Kombinationen in Frage. Der analytische Ansatz wird nur in Kombination mit einem dezentralen Organisationsentwurf verfolgt. Dahinter steckt die Überlegung, dass es nicht sinnvoll ist, Sparten einen zentralen Pflegeprozess aufzubürden, wenn die Daten ohnehin nur für Analysezwecke verwendet werden. Es muss dann lediglich sichergestellt sein, dass die Daten im MDS für das Reporting konsolidiert und von ausreichender Qualität sind.

Alle technischen Ansätze lassen sich mit dem hybriden Organisationsansatz kombinieren, sodass Bosch für die verschiedenen Stammdatenklassen unterschiedliche Architekturen konfigurierte. Grundsätzlich hängt die Wahl des geeigneten technischen Architekturansatzes bei hybridem Organisationsentwurf von vier Faktoren ab:

- Vielfalt der Geschäftsprozesse und Systeme

- Heterogenität der Daten und Datenmodelle

- Dringlichkeit der Anforderungen der Datennutzer

- Machbarkeit und Wirtschaftlichkeit

So wählte Bosch zum Beispiel wie oben angedeutet für die Mitarbeiterstammdaten den „Koexistenz“-Ansatz, da sich die Geschäftsprozesse im Personalwesen stark zwischen den Ländern unterscheiden. Außerdem brauchten die Mitarbeiter an den Quellsystemen schnellen Zugriff auf ihre neu angelegten oder geänderten Daten und konnten nicht auf die Implementierung des transaktionalen oder parallelen Designs warten. Dagegen fiel bei den Kundenstammdaten die Wahl auf den transaktionalen Ansatz (MDS als „single source of truth“), da bei dieser Stammdatenklasse großer Wert auf zentrale Datenpflege gelegt wurde und sich die lokalen Anlageprozesse zudem nicht wesentlich unterscheiden.

Schließlich ist der transaktionale Ansatz neben dem hybriden nur mit einem zentralen Organisationsentwurf zulässig. Bosch implementierte auf Basis der vier Faktoren die passende Architekturkombination für jede Stammdatenklasse.

2.4.4 Erkenntnisse

Die wichtigsten Erkenntnisse des Projekts für den Datenarchitekturentwurf in komplexen Unternehmen waren:

- Architekturmuster helfen, den Bedarf nach Flexibilität und Einzigartigkeit in unterschiedlichen Divisionen und Landesgesellschaften auf der einen Seite und den Druck nach Vereinheitlichung und Komplexitätsreduktion auf der anderen Seite abzuwägen. Die Entscheidung für eine bestimmte Gestaltung der Stammdatenarchitektur kann somit auf Basis transparenter und einheitlicher Kriterien getroffen werden.

- IT-Entwicklungskosten und Kosten für die Prozessanpassung im Fachbereich können ins Gleichgewicht gebracht werden.

- Standardmuster von Softwareanbietern oder „Best Practice“-Lösungen von Beratungs- und Marktforschungsunternehmen reichen nicht aus. Beispielsweise ist der parallele Ansatz auf die Anforderungen großer Unternehmen zugeschnitten, in denen komplexe Prozess- und Systemarchitekturen den Parallelbetrieb erfordern.

- Architekturmuster stärken die Orientierung am internen Kunden des Stammdatenmanagements, also den Fachbereichen, durch Auswahl aus einem Katalog und beschleunigen die Umsetzung des Stammdatenmanagement-Konzepts.

2.4.5 Weiterführendes Material

Für den Fall von Bosch liegen an verschiedenen Orten Details aus wissenschaftlicher und auch aus praktischer Perspektive vor (Tab. 2.13).

Tab. 2.13
Weiterführendes Material zum Fall von Bosch

Quelle

Titel

Ergebnistyp

Wiss.

Praxis

Hatz 2008

BOSCH master data management

Präsentation auf CC CDQ-Workshop

√

Ebner 2014

Entwicklung einer Methode zum Entwurf einer Unternehmensdatenarchitektur

Dissertation

√

√

Otto 2012a

How to design the master data architecture: findings from a case study at Bosch

Wiss. Beitrag in Fachzeitschrift

√

√

Schmidt 2010

Stammdatenintegration

Dissertation

√

√

Otto und Schmidt 2010

Enterprise master data architecture: design decisions and options

Wiss. Beitrag in Fachkonferenzband

√

√

Ebner et al. 2012

Conceptualizing data in multinational enterprises: model design and application

Wiss. Beitrag in Fachkonferenzband

√

√

2.5 Festo: Unternehmensweites Produktdatenmanagement in der Automatisierungsindustrie

2.5.1 Unternehmensüberblick

Festo ist ein weltweit führendes Unternehmen für Automatisierungstechnik und Pneumatik und ein führender Anbieter für technische Aus- und Weiterbildung[9]. Unternehmensziel ist die maximale Produktivität und Wettbewerbsfähigkeit von Kunden in der Fabrik- und Prozessautomatisierung. Festo ist weltweit mit etwa 60 Landesgesellschaften und über 250 Niederlassungen vertreten und beliefert über 300.000 Kunden in mehr als 170 Ländern. Tabelle 2.14 zeigt die Eckdaten des Unternehmens.

Tab. 2.14
Kurzprofil Festo

Festo AG & Co. KG

Gründung

1925

Branche

Pneumatik, Automatisierungstechnik

Unternehmenssitz

Esslingen am Neckar, Deutschland

Rechtsform

AG & Co. KG

Homepage

www.festo.com

Umsatz (2013)

2,3 Mrd. EUR

Gewinn

(nicht ausgewiesen)

Mitarbeiter (2013)

16.700

Das Produktspektrum umfasst sowohl Katalogprodukte als auch kundenspezifische Lösungen. Festo bietet über 30.000 Katalogprodukte in insgesamt mehreren hunderttausend Varianten an. Von über 700 Lieferanten beschafft Festo mehr als 42.000 Einzelteile mit einem Beschaffungsvolumen von ca. 340 Mio. €.

Festos Unternehmensstruktur für die weltweite Marktversorgung ist dreistufig organisiert (Huber 2009):

- Global Production Centers (GPC) bilden das Rückgrat der weltweiten Marktversorgung bei Festo. Die GPCs gewährleisten die Primärversorgung mit Komponenten und Endprodukten und beliefern die Regional Service Centers (RSC). Das Zielsystem der GPCs ist auf niedrige Fertigungskosten und die Bündelung von Kernkompetenzen ausgerichtet. Die zentral organisierten Technical Engineering Centers (TECs) sind je einem GPC zugeordnet und entwickeln die Katalogprodukte.

- Die RSCs haben die Aufgabe, die regionale Marktversorgung für das komplette Produktprogramm über kurze Lieferzeiten sicherzustellen und regional benötigte Varianten zu fertigen.

- In Märkten, welche von RSCs nicht mit ausreichend kurzen Lieferzeiten bedient werden können, übernehmen National Service Centers (NSC) diese Aufgabe und fungieren zugleich als „verlängerte Werkbank“ für kundenspezifische Produktanpassungen.

Erster Ansprechpartner für den Kunden ist die Festo-Landesgesellschaft im Markt bzw. im Land. Die Versorgung der Kunden mit Katalogprodukten ist grundsätzlich über die drei Stufen GPC, RSC und Landesgesellschaft sichergestellt. Kundenspezifische Lösungen entwickeln auf regionaler Ebene die Solution Engineering Centers (SECs), die auf die Anforderungen der zugeordneten Landesgesellschaften reagieren. Sogenannte Mobile Engineering Support-Funktionen (MES) sichern die erforderliche Unterstützung aus regionalen oder zentralen Einheiten. Auf globaler Ebene gibt es keine SEC, weil die kundenspezifische Lösungsentwicklung im Gegensatz zu den Katalogprodukten per definitionem kein Standardisierungspotenzial besitzt. Abbildung 2.21 zeigt diese Unternehmensarchitektur.

Abb. 2.21
Festo innovation network. (Huber 2009, S. 5)

Die Unternehmensstrategie ist geprägt durch folgende Unternehmensziele:

- Wahrung der finanziellen Unabhängigkeit als Familienunternehmen

- Fokussierung auf definierte Wachstumsfelder und Sicherung des Geschäfts in bestehenden Geschäftsfeldern

- Entwicklung einheitlicher Prozesse und deren kontinuierliche Verbesserung im Hinblick auf Kosten, Zeit und Qualität

- Gewährleistung und Förderung der persönlichen Mitarbeiterentwicklung im Sinne eines „Lernunternehmens“

2.5.2 Ausgangssituation und Handlungsdruck des Produktdatenmanagements

Die Kundenorientierung ist zentraler Bestandteil der Unternehmensstrategie, was sich in operativen Leistungsvereinbarungen für die Kunden niederschlägt. Dazu gehören beispielsweise:

- Lieferservice in 176 Ländern

- 24 h am Tag Abhol- und Lieferservice in der Mehrzahl der Niederlassungen

- Auslieferung von mehr als 75 % der Aufträge binnen 24 h innerhalb Europas (bei einem Volumen von bis zu 34.000 Lieferpositionen pro Tag allein in Deutschland)

- Bereitstellung elektronischer Produktinformationen sowohl als CD-ROM- als auch als Online-Katalog in 24 Sprachen

Abbildung 2.22 zeigt die Geschäftsprozesse bei Festo im Überblick. Der Prozess zum Produktlebenszyklus ist einer der zehn Hauptprozesse des Unternehmens (siehe horizontale Balken).

Abb. 2.22
Prozessmodell bei Festo. (Huber 2009, S. 27)

Das Produktdatenmanagement (PDM) richtet sich in seinen Abläufen nach den Phasen des Produktlebenszyklus. Es umfasst sowohl Produktdaten im engeren Sinne, die während der Konzeption, der Entwicklung, der Planung und Produktion sowie bei der Wartung des physischen Produkts benötigt werden (Saaksvuori und Immonen 2008), als auch Daten, die in logistischen Geschäftsprozessen verwendet werden (siehe Abb. 2.23). Hierzu gehören z. B. Einkaufsdaten, MRP-Daten sowie Vertriebsinformationen.

Abb. 2.23
Produktdatenmanagement bei Festo. (Huber 2009, S. 26)

Die zentrale Abteilung Produktlebenszyklusmanagement ist Teil der Organisationseinheit „Technology and Infrastructure“. Sie ist für sechs Aufgabenbereiche verantwortlich:

- Normung und Klassifizierung

- Sachmerkmalsverwaltung

- Grunddatenverwaltung

- Zeichnungsprüfung

- Änderungsmanagement

- Neuheitendaten-Support

Insgesamt arbeiten 27 Mitarbeiter im Produktlebenszyklusmanagement; mehr als die Hälfte davon in der Grunddaten- und Sachmerkmalverwaltung bzw. Normung und Klassifizierung.

Festo nutzt unternehmensweit Standardsoftwaresysteme; zur Unterstützung der kaufmännischen Geschäftsprozesse u. a. die Produkte SAP ERP und SAP PLM (siehe Abb. 2.24). Das Produktdatenmanagement nutzt im Wesentlichen zwei Systeme: Erstens das SAP-ERP-System mit dem Namen „P15“ zur Verwaltung der Produktdaten und zweitens das Softwareprodukt PTC Windchill[10] zur Verwaltung von Dokumentationen zu den Produkten. Das PDM verbindet eine Reihe von Quell- mit Zielsystemen. Wie in Abb. 2.24 zu sehen ist, gehören zu den angebundenen Quellsystemen zum Beispiel Statistiksysteme, Systeme für Kundenapplikationen sowie andere SAP-ERP-Systeme für den Vertrieb, die Produktion und die Logistik.

Abb. 2.24
Systemarchitektur für Produktdaten. (Huber 2009, S. 9)

Abbildung 2.25 zeigt die Architektur für die Verteilung der Produktdaten. Das SAP-System „P15“ verteilt die Produktdaten an die angeschlossenen regionalen SAP-Systeme in Europa, Afrika, Asien und Australien sowie in Amerika. Dort werden die unternehmensweit gültigen Stammdaten um lokale Daten ergänzt, zum Beispiel um Daten für die Lagerhaltung und die Disposition. Festo behandelt auf diese Weise sowohl Neuanlagen als auch Änderungen von Produktstammdaten.

Abb. 2.25
Datenverteilungsarchitektur. (Lehmann 2012, S. 7)

Abbildung 2.26 zeigt einen Auszug aus den zentral bewirtschafteten Produktdaten im SAP-System P15.

Abb. 2.26
Zentrale Produktdaten. (Huber 2009, S. 10)

Das starke Wachstum des Unternehmens Ende der 1990er Jahre führte zu einem Handlungsbedarf im Produktdatenmanagement. Konkret betraf er drei Bereiche:

- Internationalisierung sämtlicher Prozesse einschließlich des Produktdatenmanagements: Das Produktdatenmanagement muss den internationalen Anforderungen einerseits durch höhere Standardisierung von Abläufen begegnen, andererseits aber auch auf länderspezifische Ansprüche eingehen (z. B. Unterstützung von 24 Sprachen).

- Wissenserosion: Eine wachsende Mitarbeiterzahl und zunehmende Zahl an Produktionsstätten führt dazu, dass das Wissen und die Erfahrungen um die eigenen Produkte zunehmend weltweit verteilt sind. Festo hat aber ein Interesse daran, dass dieses Wissen im Sinne der gemeinsamen Prozesse an zentraler Stelle gebündelt wird.

- Effizienzsteigerung: Neue Unternehmensvorgaben verlangen vom Produktdatenmanagement höhere Prozesseffizienz. Dies gilt sowohl für die eigenen Prozesse der Abteilung als auch für seine internen Kunden (z. B. die Konstruktion, Einkauf, Fertigung und Vertrieb).

2.5.3 Projekte im Produktdatenmanagement zwischen 1990 und 2009

Projekt „Auslaufprozesse“

Im Jahr 2002 wurde ein Projekt zur Einführung eines Auslaufprozesses für Produkte eingeführt, um der wachsenden Zahl an Produkten und Produktdaten entgegenzuwirken. Der Prozess wurde Ende 2002 bzw. Anfang 2003 implementiert. Abbildung 2.27 zeigt die kumulierte Zahl an Teilen, die dem Auslaufprozess seit 2002 zugeführt wurden.

Abb. 2.27
Teile in Auslaufprojekten nach Anlagedatum. (Otto und Ofner 2010, S. 15)

Projekt „Teilereduktion“

Auslöser des Projekts zur Teilereduktion war die Erkenntnis, dass die Aufgaben des Produktdatenmanagements im Rahmen der Internationalisierung und des Wachstums nicht kapazitätsneutral wahrgenommen werden können, wenn die Zahl der zu bewirtschaftenden Teile nicht begrenzt wird. Ebenso erhoffte man sich davon eine Verbesserung der Effizienz sowohl in den vor-, als auch in den nachgeschalteten Geschäftsprozessen (z. B. Entwicklung, Einkauf, Produktion).

Ziel der Teilereduktion war also eine Reduktion der Gemeinkosten, welche für die Bewirtschaftung der Teile anfielen (siehe Abb. 2.28). Die Teilereduktion bezieht sich auf sämtliche Materialarten im Unternehmen, wie in Tab. 2.15 dargestellt.

Abb. 2.28
Gemeinkostenwirksame Prozesse. (Huber 2009, S. 21)

Tab. 2.15
Umfang der Teilereduktion

Vollständig bearbeitet

Teilweise bearbeitet

Schrauben

Zylinderstifte (Dubletten)

O-Ringe

Gewindeeinsätze (Dubletten)

Muttern

Spannstifte (Dubletten)

Alu-Halbzeuge

Stahl-Halbzeuge

Scheiben/Ringe (SMV-Daten + Vorzug + Dubletten)

Kolbenstangen

Kugeln (SMV-Daten + Vorzug + Dubletten)

HIBE (Hilfs- und Betriebsstoffe)

Passfedern (SMV-Daten + Vorzug + Dubletten)

Kugellager (SMV-Daten + Vorzug + Dubletten)

Abbildung 2.29 zeigt, wie sich der Teilebestand seit dem Projekt „Teilereduzierung“ entwickelt hat. Durch das Unternehmenswachstum stieg die Gesamtanzahl der Teile trotz des Projekts zwar weiter an, die Neuanlage von Teilen im betrachteten Teilespektrum konnte aber reduziert werden. Zudem wurden viele Teile dem Auslaufprozess zugeführt (Entfernung von Dubletten und Bereinigungsaktionen).

Abb. 2.29
Teilereduktion insgesamt. (Otto und Ofner 2010, S. 17)

In Abb. 2.30 ist am Beispiel des Materials „Stahl-Halbzeuge“ dargestellt, wie sich der Bestand entwickelt hat. In diesem Bereich konnte eine signifikante Reduktion an Teilen erreicht werden.

Abb. 2.30
Teilereduktion am Beispiel „Stahl-Halbzeuge“. (Huber 2009, S. 24)

Projektbewertung

Festo erzielte durch die Projekte folgende qualitative Vorteile:

- Erhöhte Transparenz über Teile und Produkte durch qualitativ hochwertige Datenbestände

- Effizienzsteigerung durch Verwendung von Wiederholteilen und Wiederholgeometrien

- Effizienzsteigerung durch Verwendung von standardisierten Symbolen, Werkstoffen, Texten usw.

- Verbesserung der Produkt- und Prozessqualität durch Verwendung von Standards

- Reduzierung von Markteinführungszeiten durch kürzere Entwicklungszeiten

Der quantifizierbare Nutzen ergibt sich im Wesentlichen aus einer Reduktion der Gemeinkosten für die Bewirtschaftung der Produktdaten. Gemeinkosten fallen – in Analogie zum Lebenszyklus physischer Produkte (VDI 2005) – während des gesamten Lebenszyklus eines Produkts bzw. eines Teils an, also vor der Nutzung des Produktstammdatums, während seiner Nutzung und nachdem es nicht mehr benötigt wird (Tab. 2.16). Grundlage für die Bestimmung der Kosteneinsparungen war eine Arbeitsanalyse in den involvierten Fachbereichen aus den Jahren 2001 und 2002. Festo kalkuliert mit folgenden Kostensätzen bei der Anlage eines Produktstammdatums (Anschaffungsphase) und bei seiner Bewirtschaftung (Nutzungsphase):

Tab. 2.16
Gemeinkostenanalyse

Szenario

Durchschn. Gesamtkosten 2001 und 2002 [TEUR]

Anteil an Aktivitäten mit PDM-Bezug [%]

Neuheiten [%]

Jährliche Gesamtkosten Neuheiten [TEUR]

Änderungen [%]

Jährliche Gesamtkosten Änderungen [TEUR]

F&E

48.256

90

65

28.230

35

15.201

PM

11.923

80

85

8108

15

1431

BM

2456

20

100

491

0

0

Patente

1428

100

100

1428

0

0

Industrial Engineering

2298

100

70

1608

30

689

Value Management

865

100

60

519

40

346

QS

11.468

100

60

6881

40

4587

Katalogverwaltung

2860

100

40

1144

60

1716

Logistik und Lagerhaltung

23.749

100

5

1187

95

22.526

Summe

49.595

46.531

TEUR Tausend Euro, F&E Forschung und Entwicklung, PM Produktmanagement, BM Business Management, QS Qualitätssicherung

- In der Anschaffungsphase sind Kosten in Höhe von 5000 € pro Neuanlage zu veranschlagen. Der Wert errechnet sich aus der Division der Gesamtkosten von 49,6 Mio. € für Neuheiten, dividiert durch 10.000 Neuheiten durchschnittlich p. a. und anschließender Aufrundung auf tausend Euro.

- In der Nutzungsphase kalkuliert Festo mit einem Gemeinkostensatz in Höhe von 500 € p. a. Für diese Berechnung werden ein durchschnittlicher Teilebestand von 120.000 und eine durchschnittliche Lebensdauer von acht Jahren pro Teil vorausgesetzt.

Für das Jahr 2008 ergeben sich unter Annahme dieser Kostensätze und unter Berücksichtigung der Erfolge bei der Teilereduktion und der Vermeidung von Neuanlagen Kosteneinsparungen in Höhe von ca. 12 Mio. € (siehe Tab. 2.17).

Tab. 2.17
Kosteneinsparung 2008

Szenario

Teiledifferenz

Kostensatz [EUR]

Kosteneinsparung [TEUR]

Vermeidung von Neuanlagen

2171

5000

10.855

Vermeidung von Teilebewirtschaftung

2286

500

1143

Summe

11.998

2.5.4 Aktuelle Aktivitäten und Ausblick

Im Zuge der kontinuierlichen Effizienzsteigerung des Produktdatenmanagements laufen derzeit vier Projekte:

- Reorganisation der Verwaltungswerkzeuge

- Bereitstellung von Bibliotheken

- Stammdatenreorganisation

Die Reorganisation der Verwaltungswerkzeuge verfolgt das Ziel, die Medienbrüche und manuellen Schnittstellen beim Datenaustausch zwischen CAD- und SAP-P15-System einerseits und zwischen SAP-P15-System und weiteren Systemen andererseits zu reduzieren (siehe Abb. 2.31).

Abb. 2.31
Reorganisation der Verwaltungswerkzeuge. (nach Lehmann 2012, S. 9)

Die Maßnahme spart in der Systemlandschaft mehr als 50 MS-Excel-Makros ein, welche in den letzten Jahren eingeführt wurden, um das stetig gestiegene Datenvolumen[11] kapazitätsneutral bewältigen zu können. In Zukunft wird ein sogenanntes Extended-Master-Data-System (XMDS) genutzt, in welchem Entwickler und Produktmanager ihre Daten vorab erfassen können, bevor sie ins SAP-P15-System übernommen werden. Diese Daten stehen damit direkt allen berechtigten Anspruchsgruppen zentral zur Verfügung und müssen nicht mehr manuell zusammengeführt werden.

Die Bereitstellung von Bibliotheken soll die Effizienz in der Konstruktion und Entwicklung erhöhen. Einerseits stehen für Norm- und Wiederholteile einheitliche Kataloge zur Verfügung. Hierzu übernimmt Festo zukünftig Produktdaten auch direkt vom Lieferanten. Ebenso gibt es Bibliotheken für Wiederholgeometrien. Schließlich werden auch Bibliotheken für Symbole, Werkstoffe und ähnliche Objekte bereitgestellt, was zu Effizienzvorteilen in der Entwicklung und Konstruktion, aber auch in den nachgelagerten Bereichen führt.

Die Stammdatenreorganisation umfasst ein Portfolio kleinerer Maßnahmen, z. B. die Deaktivierung und Reorganisation von Stammdatenobjekten in den regionalen Systemen (Werkssichten), welche operativ nicht mehr benötigt werden. Somit entfällt für die Werke die Bearbeitung dieser überflüssigen Objekte. Weiterhin werden Änderungsmitteilungen „personalisiert“, d. h. die Mitteilungen werden werksspezifisch erstellt. Der Mitarbeiter im Werk startet die Applikation und bekommt dann nur noch diejenige Änderungsinformation, welche für ihn relevant ist.

2.5.5 Erkenntnisse

Festo identifizierte folgende vier Erfolgsfaktoren für ein wirksames Produktdatenmanagement:

- Bewusstseinsbildung: Alle Hierarchieebenen verstehen, akzeptieren und unterstützen die Absicht, ein „globales Optimum“ in den Geschäftsprozessen zu definieren und einzuführen – selbst wenn es lokal kein Optimum darstellt. Ein Beispiel dafür ist, SAP als weltweit gemeinsames Informationssystem zu nutzen.

- Geschäftsprozessgestaltung: Alle Änderungen und Verbesserungen an Geschäftsprozessen wurden so gestaltet, dass sie weltweit verwendbar und skalierbar sind.

- Werkzeugunterstützung: Für neue Geschäftsprozesse und für die internationale Verwendung stehen Software-Werkzeuge zur Verfügung.

- Zentrale Produktdatenverwaltung: Die Verwaltung der Produktdaten nutzt nicht nur ein zentrales Informationssystem, sondern ist auch in einer zentralen Unternehmensfunktion organisiert.

Abschließend waren die wichtigsten Erkenntnisse des Projekts:

- Harmonisierte Produktdaten sichern Produktdatenqualität und damit durchgängige Geschäftsprozesse von der Konstruktion bis zur Logistik.

- Voraussetzung ist eine integrierte PLM-Systemarchitektur sowie eine zentrale Verantwortung für PLM-Prozesse.

- Produktdaten werden vor der Erfassung ins PLM-System systemgestützt qualitätsgesichert, indem eine „Staging Area“ der eigentlichen SAP-Standardtransaktion vorgeschaltet ist (Lehmann 2012)[12].

- Gemeinkostenanalysen für das Produktdatenmanagement helfen bei der Bereinigung des Teileportfolios.

2.5.6 Weiterführendes Material

Für den Fall von Festo liegen an verschiedenen Orten Details aus wissenschaftlicher und auch aus praktischer Perspektive vor (Tab. 2.18).

Tab. 2.18
Weiterführendes Material zum Fall von Festo

Quelle

Titel

Ergebnistyp

Wiss.

Praxis

Falge 2015

Methode zur Strategieentwicklung für unternehmensweites Datenqualitätsmanagement in globalen Konzernen

Dissertation

√

√

Huber 2009

Internationales Produktdatenmanagement – Methoden und Konzepte

Präsentation auf Praxiskonferenz

√

Lehmann 2012

Boost the collaboration and communication between product development and master data administration

Präsentation auf CC CDQ-Workshop

√

Otto 2012b

Managing the business benefits of product data management: the case of Festo

Wiss. Beitrag in Fachzeitschrift

√

√

Otto und Ofner 2010

Fallstudie Festo AG: Gemeinkostenwirksames Produktdatenmanagement

Fallstudie CC CDQ

√

√

2.6 Hilti: Durchgängiges Kundendatenmanagement in der Werkzeug- und Befestigungsindustrie

2.6.1 Unternehmensüberblick

Hilti beliefert die Bauindustrie weltweit mit technologisch führenden Produkten, Systemen und Dienstleistungen der Werkzeug- und Befestigungstechnik[13]. Der Hauptsitz der Hilti Gruppe befindet sich in Schaan im Fürstentum Liechtenstein. Das Produktspektrum umfasst u. a. Lasermesssysteme, Anker- und Installationssysteme, Bohr- und Abbruchwerkzeuge, Diamantbohrsysteme sowie Trenn- und Schleifgeräte.

Die Hilti AG beschäftigt weltweit rund 21.000 Mitarbeiter in über 120 Ländern. Das Unternehmen betreibt Produktionsstätten sowie Forschungs- und Entwicklungseinrichtungen in Europa, Asien und Lateinamerika (Tab. 2.19).

Tab. 2.19
Kurzprofil Hilti

Hilti AG

Gründung

1941

Branche

Werkzeugherstellung, Befestigungstechnik

Unternehmenssitz

Schaan, Liechtenstein

Rechtsform

Aktiengesellschaft

Homepage

www.hilti.com

Umsatz (2013)

3,59 Mrd. EUR (4,34 Mrd. CHF)

Gewinn (2013)

251 Mio. EUR (304 Mio. CHF)

Mitarbeiter (2013)

21.456

Hiltis Konzernorganisation umfasst die Bereiche Corporate Research & Technology, Supply Chain, Zentrale Konzernbereiche sowie die Business Units. Jedes Geschäftsfeld ist in mehrere Produktlinien unterteilt. Die vorliegende Fallstudie dokumentiert die Maßnahmen zum Qualitätsmanagement von Kundendaten der Abteilung „Market Reach“ (MR), die für alle unternehmensweiten Vertriebs- und Marketingaktivitäten verantwortlich und dem Chief of Global Sales and Marketing unterstellt ist.

Hiltis Geschäft basiert traditionell auf einem Direktvertriebsmodell. So arbeiten zwei Drittel der Mitarbeitenden im Vertriebsbereich und haben täglich weltweit bis zu 200.000 Kundenkontakte. Neben dem Direktvertrieb verfügt Hilti über vier weitere Vertriebskanäle, die zusätzliche Kundenkontaktpunkte darstellen. Neben den Vertriebsmitarbeitern im Außendienst betreibt Hilti eigene Outlets (Hilti Center), Shops in Partnergeschäften (ProShop), Customer Service Center und einen Online-Shop. Abbildung 2.32 zeigt die fünf Vertriebskanäle.

Abb. 2.32
Vertriebskanäle der Hilti AG. (nach Fohrer 2009, S. 8)

2.6.2 Ausgangssituation des Kundendatenmanagements und Handlungsdruck

Hiltis „Vision 2015“ definiert die strategischen Ziele des Unternehmens und hält dabei die Kundenzufriedenheit als eine wichtige Bedingung für das angestrebte „nachhaltige profitable Wachstum“[14] fest. Um hohe Kundenzufriedenheit über alle Vertriebskanäle hinweg zu sichern und gleichzeitig effizient zu arbeiten, ist Hilti auf Kundendaten von hoher Qualität angewiesen. Dies betrifft neben den Daten im ERP-System auch Hiltis zentrales Customer Relationship Management (CRM) System, das z. B. Marketing- und Vertriebsprozesse sowie das Kontakt- oder Kampagnenmanagement unterstützt. Abbildung 2.33 zeigt, dass die Attribute des Kundenstamms den reibungslosen Ablauf wichtiger Geschäftsprozesse direkt beeinflussen.

Abb. 2.33
Vollständige und fehlerfreie Kundendaten als Voraussetzung für CRM-Prozesse. (Fohrer 2012, S. 9)

Trotz der hohen Bedeutung korrekter Kundendaten besaß Hilti bis zum Jahr 2006 noch kein unternehmensweites Datenqualitätsmanagement. Das Unternehmen stellte deshalb folgende drei Risiken im Kundendatenmanagement fest:

- Datennutzung: Hilti verwendet Daten aus unterschiedlichen Systemen sowie aus unterschiedlichen Datenfeldern desselben Systems, um kundenindividuelle Preiskalkulationen zu erstellen. Fehlerhafte Daten in diesen Feldern führen zu falschen Berechnungen und gefährden damit einerseits die Kundenzufriedenheit und andererseits den Umsatzerfolg.

- Datenqualitätsmessung: Da es keine regelmäßige Datenqualitätsmessung der Kundendatenqualität gab, fielen Datendefekte meist erst bei Geschäftsprozessproblemen auf. Die Folge waren zeitintensive Ursachenforschungen und Korrekturmaßnahmen durch die Hilti-Mitarbeiter im Datenmanagement. Zudem gab es keine unternehmensübergreifenden Vorgaben über Datenqualitätsstandards, da die Kundendaten in erster Linie lokal von Mitarbeitern für Berichte oder Kundengespräche gepflegt wurden.

- Datenpflegeprozess: Es existierte kein einheitlich definierter Anlage- und Pflegeprozess für Kundenstammdaten, der den Anforderungen der Außendienstmitarbeiter hinsichtlich Schnelligkeit, Zuverlässigkeit und Mobilität entsprochen hätte.

Von einem verbesserten Datenqualitätsmanagement erhoffte sich die Abteilung für Kundendatenmanagement CDM (engl. customer data management) folgende Vorteile für Hiltis Vertriebs- und Marketingaktivitäten:

- Eine höhere Kundenzufriedenheit und verbesserte Kundenbindung

- Erleichterung der strategischen Vertriebsplanung durch eine verbesserte Kundenanalyse (z. B. Kundensegmentierung)

- Reduzierung der Kosten für das Kontaktmanagement

- Bessere Unterstützung bei der Ausführung von Logistik- und Abrechnungsprozessen

- Reduktion von Datenpflegeaufwänden, die durch fehlerhafte Kundendatensätze verursacht werden

2.6.3 Das Projekt Customer Data Quality Tool

Um diese Ziele zu erreichen, lancierte Hilti im Jahr 2006 das Projekt „Customer Data Quality Tool“ für ein nachhaltiges Datenqualitätsmanagement. Die Abteilung Market Reach finanzierte das Projekt und veranschlagte die Projektdauer auf ein Jahr. Das namensgebende „Customer Data Quality Tool“ war dabei nur eines von mehreren neuen IT-Werkzeugen für die insgesamt vier übergreifenden Maßnahmen. Die vier Maßnahmen Definieren, Vorbeugen, Erkennen und Korrigieren (Abb. 2.34) deckten den gesamten Kundendatenlebenszyklus ab und umfassten sowohl proaktive (vorbeugende) als auch reaktive (nachträgliche) Datenqualitätsmanagementaktivitäten.

Abb. 2.34
Maßnahmen des proaktiven und reaktiven Kundendatenmanagements. (nach Fohrer 2012, S. 11)

Zu Beginn des Projekts stellte die Abteilung Market Reach eine Gruppe von Experten zusammen, welche fortan für das Thema Kundendatenmanagement verantwortlich sein würden. Diese sogenannten lokalen Prozessexperten (engl. local process experts, LPEs) identifizierten zunächst Datenqualitätsprobleme und leiteten davon Geschäftsregeln ab, um diesen Problemen vorzubeugen. Die LPEs hielten dabei Vollständigkeit und Fehlerfreiheit als wichtigste Datenqualitätsdimensionen für Hilti fest.

Das Projektteam definierte folgende Ziele für die Kundendaten-Qualitätsinitiative:

- Schaffung eines Bewusstseins für die Notwendigkeit von Datenqualitätsmanagement auf Seiten der Unternehmensführung mit Hilfe einfacher Schlüsselindikatoren, die interne Leistungsvergleiche ermöglichen

- Schaffung von Transparenz über die Kundendatenqualität

- Einrichtung von Kontroll- und Überwachungsfunktionen, um Trends und Entwicklungen in der Kundendatenqualität permanent zu verfolgen

- Initiierung angemessener Datenbereinigungs- und Qualitätsverbesserungsaktivitäten für die identifizierten Handlungsfelder

- Etablierung von kontinuierlichen Prozessen für die Kundendatenpflege

Definieren: Verantwortlichkeiten

Als erste proaktive Maßnahme definierte Hilti neue Rollen und Verantwortlichkeiten für diverse Datenmanagementprozesse wie die Korrektur von Datendefekten und das Reporting über den Datenqualitätsindex-Status (siehe folgenden Abschnitt zum Daten-Monitoring). Die Rollen befinden sich sowohl auf lokaler als auch auf globaler Organisationsebene (siehe Abb. 2.35).

Abb. 2.35
Rollenmodell und Datenqualitätsmanagementprozesse. (Baghi und Ebner 2013, S. 15)

Die sogenannten Country Manager haben dabei die oberste Verantwortung für das Kundendatenmanagement inne und delegieren Aufgaben an die lokalen Prozessexperten (LPEs). Diese tragen die Verantwortung für das Kundendatenmanagement auf lokaler Ebene und koordinieren die Datenbereinigungs- und Qualitätsverbesserungsaktivitäten auf nationaler und regionaler Ebene. Je nach Art der Datenfelder arbeiten sie mit verschiedenen lokalen Fachabteilungen zusammen (z. B. Vertrieb, Logistik, Marketing oder Buchhaltung) und leiten bei Bedarf Korrekturmaßnahmen ein.

Die LPEs erstellen auch Fehlerkorrekturdateien, die von den Fachabteilungen aus dem Intranet heruntergeladen werden können. Es gibt mehrere Prozesse zur Datenbereinigung. Die LPEs übernehmen Massenbereinigungen, während Änderungen einzelner Datenfelder von den Außendienstmitarbeitern vorgeschlagen und erst nach Freigabe durch den jeweiligen Genehmigungsprozess aktiv werden. All diese Aktivitäten sind dabei in verschiedene existierende Prozesse integriert.

Die Kommunikation zwischen den LPEs und den Fachabteilungen ist bidirektional. Das bedeutet, dass auch die Fachabteilungen Korrekturprozesse initiieren können, wenn sie Probleme in ihren Prozessen erkennen, die sie auf mangelnde Datenqualität zurückführen. In manchen Fällen (z. B. bei Massenänderungen) haben die Fachabteilungen auch das Recht, den LPE zu beauftragen, bestimmte Änderungen durchzuführen.

Vorbeugen: Korrekte Datenerfassung

Als zweite proaktive Kundendatenmanagement-Maßnahme überarbeitete Hilti den Anlageprozess für Kundendaten. Der Prozess wird nun mit einem Workflow, dem „Data Creation Process“, unterstützt, welcher die zuvor erarbeiteten Geschäftsregeln in automatische Datenqualitätschecks umsetzt. Zudem nutzt der Workflow Daten von externen Datenprovidern (z. B. Adressdaten) für weitere Validierungen während des Anlageprozesses. Dies verringert das Risiko, dass schon bei der Neuanlage eines Kundendatensatzes fehlerhafte Daten ins System eingegeben werden (Prinzip des „first time right“). Die Hauptnutzer des Workflows sind sogenannte Customer Service Center, die beim Anlegen von Kundendaten für den ersten Schritt verantwortlich sind. Anschließend hat der Workflow mehrere Genehmigungsstufen.

Erkennen: Datenqualitätsmonitoring

Eine der beiden Maßnahmen des reaktiven Datenqualitätsmanagements bei Hilti ist ein kontinuierliches Datenqualitätsmonitoring, um Transparenz über die unternehmensweite Kundendatenqualität zu schaffen. Dies erforderte erstens einen unternehmensübergreifenden, bei allen beteiligten Abteilungen anerkannten Datenqualitätsindex (DQI) und zweitens ein entsprechendes Tool, das den DQI berechnet und Auswertungen ermöglicht.

Der Datenqualitätsindex bewertet die beiden Attribute Fehlerfreiheit und Vollständigkeit, die zu Beginn als besonders wichtig für Hiltis Kundenprozesse identifiziert wurden. Die Berechnung des DQI basiert auf den Geschäftsregeln, die die kritischen Kundenattribute messen. Als Zielwert wurde ein DQI von mindestens 90 % beschlossen, der über alle Vertriebskanäle und Systeme hinweg (CRM, ERP und Business Intelligence) hinreichend vollständige und fehlerfreie Kundendaten garantieren soll. Dieser Zielwert gilt für alle lokalen Geschäftseinheiten.

Für die Automatisierung der DQI-Berechnung und für das Datenqualitätsmonitoring entwickelte Hiltis interne IT-Abteilung ein eigenes Tool, das „Data Quality Tracking Tool“. Als mögliche Plattformen wurden zunächst Hiltis Business Intelligence (BI)- sowie das ERP-System in Erwägung gezogen. Diese Optionen wurden jedoch verworfen, da die BI-Plattform zum Projektzeitpunkt noch nicht alle benötigten Datenfelder (z. B. Contact) enthielt und im Fall des ERP-Systems befürchtet wurde, dass die regelmäßigen Datenanalyseprozesse die Systemperformance einschränken könnten. Das Projektteam entschied schließlich zugunsten einer Lösung auf Basis von Microsoft Access, welche nun monatlich den DQI berechnet. Vorhandene Datendefekte werden außerdem mittels eines regelmäßigen Monitorings identifiziert. In diesem Fall stößt die verantwortliche Abteilung entsprechende Datenbereinigungsaktivitäten für die betroffenen Attribute an. Die Verantwortlichkeiten für die jeweiligen Datenmanagementprozesse sind dabei in dem oben erwähnten Rollenmodell festgelegt. Abbildung 2.36 zeigt das Data Quality Tracking Tool.

Abb. 2.36
Data quality tracking tool. (Baghi und Ebner 2013, S. 16)

Parallel zum neuen Datenqualitätsindex und zum Monitoring-Tool setzte Hilti auch organisatorische Veränderungen um. So erstellte das Projektteam verschiedene Dokumentationen über Datenprobleme und entwarf einen Trainingsplan, um möglichen Fehlerquellen entgegenzuwirken. Zudem wurden sämtliche Prozesse zum Kundendatenmanagement an den neuen Geschäftsregeln ausgerichtet. Der DQI und das regelmäßige Monitoring schaffen erstmalig Transparenz über die Datenqualität in Hiltis verschiedenen Geschäftsbereichen und Regionen und tragen gemeinsam mit der oben beschriebenen neuen Governance-Struktur dazu bei, dass die verantwortlichen Abteilungen im Falle eines Handlungsbedarfs zügig Datenqualitätsverbesserungen vornehmen können.

Das Monitoring-Tool wurde nach Fertigstellung in allen Niederlassungen ausgerollt, beginnend zunächst mit sieben Ländern. In einem weiteren Schritt wurde die Einführung des Tools mit dem gleichzeitig stattfindenden ERP-Roll-Out verbunden. Seit Ende 2009 ist das Tool in sämtlichen Regionen und Ländern im Einsatz.

Korrigieren: Datenbereinigung und Customer Data Quality Tool

Die Maßnahme mit dem größten Einfluss auf das Tagesgeschäft der Außendienstmitarbeiter war die Einführung des „Customer Data Quality Workflow“ (Customer DQ Workflow). Dieser neue Prozess nutzt eine „Data Correction“ Smartphone-App, die ebenfalls von Hilti selbst entwickelt wurde. Die App gibt den Außendienstmitarbeitern die Möglichkeit, Daten unmittelbar beim Kunden zu erfassen und auch direkt vor Ort einen Korrekturprozess für veraltete oder fehlerhafte Daten anzustoßen. Der Prozess ist damit sowohl dem reaktiven als auch dem proaktiven Datenqualitätsmanagement zuzurechnen. Der typische Prozessablauf ist in Abb. 2.37 dargestellt.

Abb. 2.37
Customer data quality workflow. (Fohrer 2012, S. 14)

Hiltis Außendienstmitarbeiter planen ihre Kundenbesuche mit Hilfe des CRM-Systems, das die relevanten Kundendaten enthält (Schritt 1). Die Daten für die aktuell geplanten Termine laden sich die Mitarbeiter per App auf ihr Smartphone. Wenn während des Ortstermins Fehler in den Kundendaten auffallen oder neue Daten erfasst werden müssen, können die Mitarbeiter einen Änderungsantrag (Change Request) für das betroffene Datenfeld stellen und den korrigierten Wert in der App erfassen (Schritte 2 und 3, siehe Details in Abb. 2.38). Die Voraussetzung dafür ist, dass die Mitarbeiter für das betreffende Feld auch eine Änderungsberechtigung besitzen.

Abb. 2.38
Details aus dem Customer Data Quality Workflow. (nach Fohrer 2012, S. 16–18)

Der Change Request wird dann an den Vorgesetzten, d. h. den Area Sales Manager (ASM) sowie das zuständige Back Office der Region für Kundendaten weitergeleitet. Der Außendienstmitarbeiter kann den Status seines Änderungsantrags über einen „web table“ im Intranet nachverfolgen (Schritt 4). Die beiden Genehmigungsstufen (ASM und Back Office) geben den Antrag nach positiver Prüfung frei (Schritt 5). Daraufhin wird der geänderte Wert des Kundenstamms sowohl in Hiltis ERP-System als auch im CRM-System und der Smartphone-App aktualisiert (Schritt 6).

Mit diesem Workflow nimmt Hilti Änderungen von Kundendaten direkt an der Quelle auf, wo das Eigeninteresse der Vertriebsmitarbeiter an korrekten Daten besonders hoch ist. Die Area Sales Manager und das Back Office können sämtliche Änderungsanträge ihrer Teammitglieder nachvollziehen und z. B. beobachten, bei welchen Kunden und welchen Datenfeldern die meisten Änderungen auftreten. Darüber hinaus sorgt der Workflow für Datenkonsistenz und -Aktualität zwischen Hiltis verschiedenen Systemen, da Änderungen in alle Systeme übernommen werden.

Als letzte reaktive Korrekturmaßnahme führte Hilti noch ein neues Tool zur Bereinigung von Massendaten ein („Mass Maintenance Tool“). Es handelt sich hierbei um eine Eigenentwicklung von Hilti, welche auf dem ERP-System aufsetzt. Das Mass Maintenance Tool ermöglicht in kurzer Zeit Änderungen und Korrekturen in großen Datenbeständen. Die LPEs sind die Hauptnutzer dieses Tools, die damit Änderungen und Korrekturen auf Anweisung der Fachabteilungen ausführen.

2.6.4 Erkenntnisse

Seit der Implementierung der neuen Lösungen für das Kundendatenmanagement hat sich die Qualität der Kundendaten bei Hilti erhöht, wie z. B. die Entwicklung des Datenqualitätsindex im Laufe der Zeit zeigt. Da Hilti laufend neue Geschäftsregeln für die Berechnung des Werts hinzufügt, ist sogar für einen gleichbleibenden DQI eine kontinuierliche Verbesserung des Datenqualitätsmanagements notwendig. Das operative Geschäft wird damit auf vielfältige Weise unterstützt. Zum Beispiel können Vertriebsmitarbeiter nun verbesserte Kundensegmentierungen durchführen und Kunden damit gezielter passende Angebote machen. Dies hat positive Auswirkungen auf die allgemeine Kundenzufriedenheit und sorgt für eine bessere Kundenbindung.

Hilti beurteilte folgende Aspekte als besonders wichtig für den Projekterfolg:

- Unterstützung durch Hiltis Top-Management: Dank des Projektmandats durch die Geschäftsleitung waren die benötigten Änderungen in den Organisationsstrukturen möglich.

- Frühzeitige Definition von Geschäftsregeln: Hilti definierte die notwendigen Geschäftsregeln zu Beginn des Projekts und stellte sicher, dass sie von einem gemeinsamen Verständnis getragen wurden.

- Definition unternehmensweiter Datenqualitätsziele.

- Bereichsübergreifende Zusammenarbeit: Hilti bewertete die intensive Zusammenarbeit aller am Projekt beteiligten Personen sehr positiv, sowohl zwischen lokaler Ebene und der Unternehmenszentrale als auch zwischen den Fachabteilungen und der IT. Von Anfang an wurden die Anforderungen für die neuen Tools an den Bedürfnissen der Fachabteilungen und den dazugehörigen Geschäftsprozesse ausgerichtet. So wurden die Datennutzer z. B. in mehreren intensiven Workshops während des ganzen Projekts miteinbezogen, um in den Fachabteilungen das notwendige Maß an Motivation und aktiver Beteiligung an dem Projekt zu sichern. Die Abteilung Market Reach bewertete die Implementierung und den unternehmensweiten Roll-Out der Lösungen deshalb insgesamt als reibungslos und erfolgreich.

Zusammengefasst waren die wichtigsten Erkenntnisse des Projekts zum Kundendatenmanagement bei Hilti:

- Kundendatenqualität ist eine Voraussetzung für direkte Vertriebsmodelle.

- Kundendatenqualität kann am besten an der Quelle, also beim Vertriebsmitarbeiter, gesichert werden.

- Akzeptanz für Datenqualitätsprozesse steigt durch Closed-Loop-Ansätze, bei denen Vertriebsmitarbeiter direkt von ihren Datenqualitätsverbesserungen profitieren.

- Datenqualitätsmessungen zeigen den Handlungsbedarf und dokumentieren Datenqualitätsverbesserungen.

2.6.5 Weiterführendes Material

Für den Fall von Hilti liegen an verschiedenen Orten Details aus wissenschaftlicher und auch aus praktischer Perspektive vor (Tab. 2.20):

Tab. 2.20
Weiterführendes Material zum Fall von Hilti

Quelle

Titel

Ergebnistyp

Wiss.

Praxis

Baghi und Ebner 2013

Case study: customer data quality management at Hilti

Fallstudie CC CDQ

√

√

Fohrer 2009

Customer data management at Hilti

Präsentation auf CC CDQ-Workshop

√

Fohrer 2012

Driving corporate data quality through the use of consumer technology

Präsentation auf CC CDQ-Workshop

√

2.7 Johnson & Johnson: Institutionalisierung des Stammdatenmanagements in der Konsumgüterindustrie

2.7.1 Unternehmensüberblick

Johnson & Johnson ist ein Fortune-50-Unternehmen, das über 275 Tochterunternehmen in 60 Ländern weltweit besitzt[15]. Johnson & Johnson ist in drei Geschäftsbereiche aufgeteilt: Pharmaceutical, Medical Devices and Diagnostics und Consumer Products. Im Jahr 2013 beschäftigte das Unternehmen 128.000 Mitarbeiter und erzielte einen Umsatz von 55 Mrd. €. Die beiden Bereiche Pharmaceutical und Medical Devices and Diagnostics werden zentral geleitet. Der Bereich Consumer Products hingegen ist in vier geografische Regionen (North America, South America, Asia-Pacific und Europe) unterteilt (Tab. 2.21)[16].

Tab. 2.21
Kurzprofil Johnson & Johnson

Johnson & Johnson

Gründung

1886

Branche

Pharmazeutische Produkte, Medizinprodukte, Diagnostik

Unternehmenssitz

New Brunswick, NJ, USA

Rechtsform

Aktiengesellschaft

Homepage

www.jnj.com

Umsatz (2013)

55,07 Mrd. EUR (71,31 Mrd. USD)

Gewinn (2013)

10,68 Mrd. EUR (13,83 Mrd. USD)

Mitarbeiter (2013)

128.100

2.7.2 Ausgangssituation des Datenmanagements im Bereich Consumer Products und Aktivitäten bis 2008

Neben anderen Unternehmenszielen möchte Johnson & Johnson durch Unternehmensakquisitionen kontinuierlich wachsen. Eine weltweit beachtete Akquisition gab es im Jahr 2006, als Johnson & Johnson die Verbraucherproduktsparte des Konkurrenten Pfizer für 16,6 Mrd. US-Dollar übernahm. Johnson & Johnson hat mittlerweile zwei Drittel seiner Produktion ausgelagert, um sich auf seine Kernkompetenzen konzentrieren zu können. Die Fallstudie behandelt das Datenmanagement im Unternehmensbereich Consumer Products (North America).

Nicht zuletzt aufgrund der beträchtlichen Anzahl an Unternehmenskäufen waren die Geschäftsprozesse bei Johnson & Johnson zu großen Teilen nicht harmonisiert, sondern unterschieden sich stark über die verschiedenen Geschäftsbereiche und Tochterunternehmen hinweg. So gab es zum Beispiel keine unternehmensweiten Richtlinien für den Preisfindungsprozess. Auch ein unternehmensweites Datenmanagement war nicht vorhanden. Stattdessen existierten fünf Datenmanagementgruppen, die unabhängig voneinander arbeiteten.

Ebenso gab es kein unternehmensweites Verständnis zur Definition der wesentlichen Geschäftsobjekte. So wurden zum Beispiel unter der Bezeichnung „Product Samples“ einerseits Werbegeschenke für Kunden verstanden. Dieselbe Bezeichnung wurde aber auch für Werbeartikel verwendet, die an das Verkaufspersonal ausgegeben wurden.

Im Jahr 2005 startete Johnson & Johnson ein Großprojekt, um unternehmensweit SAP ERP einzuführen. Zielsetzung war, für den Bereich Consumer Products ein Standardanwendungssystem für die Planung, die Produktion und den Vertrieb zu nutzen. Das Projekt umfasste auch die Einführung von Softwaretools für die Stammdatenanlage.

Einzelne Datenmanagementprozesse jedoch, wie etwa die Anlage und Pflege von Materialstammdaten, wurden zum Zeitpunkt, als das System in den operativen Betrieb ging, nicht vollständig und detailliert definiert. Diese Prozesse wurden immer noch lokal bzw. regional organisiert und waren dementsprechend heterogen. Da Prozess- und Systemdesign in diesem Projekt nicht genügend aufeinander abgestimmt waren, brachte die Projektinvestition nicht den erwarteten Nutzen.

Handlungsdruck

Hinsichtlich des Datenmanagements hatte Johnson & Johnson mit drei wesentlichen Schwierigkeiten zu kämpfen.

Erstens litten einige Geschäftsprozesse unter Fehlern, die auf Datenqualitätsprobleme hindeuteten. Kunden bekamen oft fehlerhafte Rechnungen zugesandt, LKW mussten an den Verladestationen warten, bis das entsprechende Material im System freigegeben war, in den Fabrikanlagen kam es zu Produktionsverzögerungen und Bestellungen wurden nicht rechtzeitig platziert. Darüber hinaus fehlten im Produkteinführungsprozess Informationen zum Status neuer Produkte und es fehlten klare Verantwortlichkeiten für den Gesamtprozess.

Zweitens bemängelten Betreiber von globalen Datenpools wie dem Global Data Synchronization Network (GDSN)[17] die Datenqualität der Produktdaten, die Johnson & Johnson übermittelte. Auch Kunden kritisierten häufig die Qualität von Logistikdaten wie Produktgewichten und Produktmaßen. Einer von Johnson & Johnsons wichtigsten Kunden teilte mit, dass das Unternehmen bei den Logistikdaten zu den schlechtesten seiner strategischen Lieferanten gehöre.

Drittens beurteilte Johnson & Johnson sein Datenmanagement allgemein als ineffizient. So wendeten die Mitarbeiter im Datenmanagement ca. 80 % ihrer Zeit für die Analyse von Datenfehlern und die Behebung von Datenproblemen auf.

2.7.3 Die Einführung von Data Governance

Gründungsphase

Im Jahr 2008 wurde zusammen mit der Consulting-Sparte von GS1 (einer globalen Standardisierungsorganisation) ein Projekt ins Leben gerufen, um den genannten Kundenbeschwerden objektiv nachzugehen.

GS1 stellte sein CubiScan®[18]-Equipment zur Verfügung, mit dem sämtliche Produkte physikalisch gescannt wurden. Innerhalb eines Monats wurde jedes aktive Produkt auf diese Weise analysiert. Das Ergebnis führte dem Management die Bedeutung des Datenqualitätsproblems vor Augen: Es stellte sich heraus, dass bei weniger als 30 % der Produkte die Daten zu Gewicht und Abmessungen innerhalb der erlaubten 5-%-Fehlertoleranzgrenze lagen.

Im Frühjahr 2008 entschied die Geschäftsführung von Johnson & Johnson deshalb, eine unternehmensweite Abteilung für Enterprise Master Data (EMD) einzurichten, um eine ausreichende Datenqualität im Unternehmen sicherzustellen und Geschäftsprozessfehler zukünftig zu vermeiden.

Der designierte Leiter der EMD-Abteilung wurde beauftragt, die neue Organisation innerhalb von acht Monaten aufzubauen. Er war dafür verantwortlich, alle Geschäftsbereiche davon zu überzeugen, ihre eigenen dezentralen Aktivitäten im Datenmanagement aufzugeben und diese in die neue zentrale Verantwortung zu übertragen. Da die Initiative durch das Mandat der Geschäftsleitung gestützt war, musste nicht mehr über das ob verhandelt werden, sondern die Diskussion konnte auf das wie beschränkt werden. In dieser Phase wandelte sich auch das Verständnis über die Besitzverhältnisse der Daten: Aus der bisherigen Auffassung von „meine Daten“ wurden allmählich „unsere Daten“ – das Verständnis, dass Daten nur einem bestimmten Geschäftsbereich gehören, wich dem Bewusstsein für den gemeinschaftlichen Wert der Daten für das Gesamtunternehmen. Schließlich bekannten sich die Verantwortlichen auf zweiter Führungsebene aller Geschäftsbereiche zu dieser gemeinsamen Initiative.

Eine zentrale Aktivität der Gründungsphase war ein sogenannter „Kaizen“-Workshop, in dessen Rahmen sich Vertreter aus allen Geschäftsbereichen für eine Woche zusammensetzten, um ein gemeinsames Verständnis bezüglich der Definition der wesentlichen Geschäftsobjekte und ihrer Verwendung in unterschiedlichen Geschäftsprozessen zu entwickeln. In dieser Runde waren Repräsentanten aus allen wichtigen Unternehmensfunktionen (Finanzen, Entwicklung, Einkauf usw.) vertreten. An jedem Tag der Woche wurde ein bestimmter Geschäftsprozess (z. B. Einkauf oder Produktion) diskutiert.

Nachdem ein gemeinsames Verständnis der wesentlichen Geschäftsobjekte erarbeitet war, definierte das EMD-Team die Rollen und Verantwortlichkeiten für die Nutzung und Pflege der Stammdaten. Das EMD-Team legte die Verantwortung für jedes einzelne Feld eines Materialtyps fest, sodass schließlich insgesamt 420 Stammdatenattribute zu Buche standen. Anschließend entwickelte das EMD-Team gemeinsam mit den jeweiligen Eigentümern Regeln für die Datenpflege der Attribute. Das Team begann zunächst mit den Regeln, die von den verwendeten Systemen (z. B. SAP) vorgegeben wurden, und entwickelte danach weitere Geschäftsregeln in Rücksprache mit den Experten der Geschäftsprozesse. Eine einfache Geschäftsregel stellt zum Beispiel sicher, dass bei jedem Endprodukt in Johnson & Johnsons Systemen das Attribut „Bruttogewicht“ gepflegt sein muss und dieses Feld nicht leer sein darf.

Externe Perspektiven auf das Thema unterstützten die Aktivitäten während der ersten Projektphase. So wurden EMD-Manager anderer Konsumgüterunternehmen eingeladen, um ihre Ideen und Konzepte zu präsentieren.

Entwicklungsphase

Im Mai 2009 ging die neue, zentrale EMD-Organisation in den operativen Betrieb. Damit übernahm sie die Verantwortung dafür, dass die Daten jedes neuen Produkts rechtzeitig und in der benötigten Qualität vorliegen. Zu Beginn wurden die Verantwortlichkeiten für die Datenobjekte noch nach Datenklassen und Geschäftsbereichen zugewiesen. Mit der Zeit erhielten die beteiligten Personen jedoch immer mehr bereichsübergreifende Verantwortung, sodass es ab Beginn des Jahres 2010 volle regionale Verantwortung für jede existierende Datenklasse gab. Die Verantwortungsstruktur entsprach damit der allgemeinen regionalen Organisationsstruktur des Unternehmens. Während die Mitglieder des EMD-Teams zu Projektbeginn noch in gemeinsamen Räumlichkeiten an jedem der Unternehmensstandorte untergebracht waren, ist das gesamte EMD-Team, das aus 27 Personen besteht (16 interne und 11 externe Mitarbeiter), mittlerweile am Unternehmenshauptsitz angesiedelt.

Die Entwicklungsphase wurde durch jährliche Master Data Summits und ein Steering Committee unterstützt. Das Steering Committee bewertet regelmäßig die übergeordneten Stammdatenprozesse hinsichtlich der Befolgung von Standards, der Erreichung der Qualitätsziele und der pünktlichen Bereitstellung der Daten. Dies geschieht über alle zwölf Abteilungen hinweg, die an der Anlage von Stammdaten beteiligt sind.

Zusätzlich zur neu geschaffenen EMD-Organisation etablierte Johnson & Johnson auch neue unternehmensweite Datenmanagementprozesse. Diese schließen z. B. workflow-unterstützte Prozesse für die Produktdatenanlage und ein Datenqualitätsmonitoring mit ein.

Reifephase

Bis Mitte 2011 hatte das Datenmanagement bei Johnson & Johnson einen hohen Reifegrad erreicht. Die Prozesse für das Datenmanagement sind mittlerweile in das Tagesgeschäft integriert und werden von allen Personen im Unternehmen akzeptiert. Das zentrale Datenmanagementinformationssystem wurde kontinuierlich verbessert. Johnson & Johnson ist heute in der Lage, Produktdaten schnell und in guter Qualität zur Verfügung zu stellen, wenn ein neues Produkt in das Sortiment aufgenommen wird.

2.7.4 Aktuelle Situation

Heute verwenden die Geschäftsprozesse bei Johnson & Johnson Stammdaten (wie z. B. Produktdaten) in konsistenter Art und Weise. Die zentrale EMD-Abteilung hat unternehmensweit ein eindeutiges Verständnis der wesentlichen Datenobjekte geschaffen und hat zudem erreicht, dass alle Geschäftsprozesse die Anforderungen des Datenmanagements berücksichtigen.

Ein Prinzip der EMD-Abteilung im Prozessmanagement lautet, dass die Datenqualität von Geschäftsobjekten sowohl vor als auch während der Nutzung der Daten gesichert sein muss. Dafür werden Konzepte aus dem Lebenszyklus- und Qualitätsmanagement von physischen Gütern auf das Datenmanagement übertragen.

Ein gutes Beispiel eines Geschäftsprozesses, in dem die Datenqualität sichergestellt wird, bevor die entsprechenden Daten zur Verwendung kommen, ist der Prozess zur Einführung neuer Produkte. Während es in der Vergangenheit keine Transparenz bezüglich des Produktstatus gab, werden Produktdaten heute in einem mehrstufigen Prozess verwaltet. Sechs Monate bevor ein neues Produkt an den Handel ausgeliefert wird, übermittelt Johnson & Johnson sowohl den Händlern als auch GS1 vorläufige Produktdaten (wie z. B. Informationen zur Verpackung). Drei Monate vor Produktauslieferung werden dann die endgültigen Daten zu Abmessungen und Gewicht des Produktes übermittelt, welche umgehend im SAP-ERP-System eingefroren werden. Zusätzlich wurde ein sogenanntes „Packaging Lab“ am Unternehmenshauptsitz eingerichtet, in dem jedes neue Produkt vor der Erstauslieferung mithilfe des CubiScan-Geräts gescannt wird. Auf diese Weise wird der Prozess der Produkteinführung genutzt, um Produktdaten zu verifizieren, bevor ein Produkt zum ersten Mal ausgeliefert wird.

Heute legt die EMD-Abteilung jedes Jahr rund 3000 Stammdatensätze für Endprodukte und 11.000 Stammdatensätze für Rohmaterial an. Letzteres schließt sowohl Rohmaterial im eigentlichen Sinne als auch halbfertige Materialien, Experimentiermaterial und Ersatzteile mit ein. Das Datenqualitätslevel beträgt heute 99,991 % (berechnet aus dem Verhältnis der Anzahl fehlerfreier Datensätze gemäß den definierten Geschäftsregeln zu der Gesamtzahl der Datensätze im SAP-ERP-System).

Abbildung 2.39 zeigt die Systemlandschaft, die Johnson & Johnson heute für die Anlage von Materialstammdaten verwendet. Die führende Datenquelle ist dabei das SAP-ERP-System, das unternehmensweit genutzt wird. Darüber hinaus hat das EMD-Team weitere Informationssysteme entwickelt, um die benötigte Datenqualität bei Anlage und Pflege der Datensätze sicherzustellen. Alle verwendeten Systeme basieren auf der CranSoft-Plattform von BackOffice Associates[19].

Abb. 2.39
Systemlandschaft bei Johnson & Johnson. (Otto 2013, S. 15)

Die Funktionen der einzelnen Systeme und die von ihnen erzeugten Berichte sollen im Folgenden kurz beschrieben werden:

- Die Data Garage speichert täglich eine Kopie aller produktiven SAP-Daten.

- Das Stammdaten-Cockpit ist ein Analyse- und Reporting-Tool für die Datenqualität. Es überprüft, ob Stammdatensätze die definierten Regeln verletzen und den Qualitätsanforderungen entsprechen.

- cMat ist ein Workflow-Management-System, das die Anlage von Stammdatensätzen unterstützt. Johnson & Johnson prüft die einzugebenden Daten auf Qualität, bevor sie in den Standardtransaktionen des ERP-Systems gebucht werden. Der Datenfluss durch diese Bereitstellungsbereiche (Staging Areas) stellt sicher, dass nur fehlerfreie Datensätze für den jeweils nächsten Bearbeitungsschritt zugelassen werden und setzt damit das „first time right“-Prinzip um.

- Data Dialysis Trigger Reports: Die Informationen aus dem Stammdaten-Cockpit steuern zusammen mit den Statusberichten aus cMat den Prozess zur Anlage der Materialstammdaten.

- Der Production Validation – Bericht überwacht Änderungen und Fehler in wichtigen Datenfeldern bei allen vorhandenen Materialien.

- Die Stammdaten-Testberichte werden vom Stammdaten-Cockpit erzeugt. 350 unterschiedliche Berichte und Anfragen sind dabei möglich.

- Die Management-Reports liefern Kennzahlen zu Datenqualität und Aktualität pro Abteilung oder für Geschäftseinheiten.

Die Systemlandschaft unterstützt die Sicherung der Datenqualität sowohl vor als auch während der Nutzung der Daten. Das Workflow-Management-System cMat ist dabei das zentrale Anwendungssystem. Es stellt sicher, dass Stammdaten sowohl für Endprodukte als auch für Rohmaterial rechtzeitig und in der benötigten Qualität bereitstehen. Nachdem ein Mitarbeiter ein neues Material angefordert hat, bietet cMat vier verschiedene Qualitätsstadien: „customer ready“, „source ready“, „make ready“ und „delivery ready“. Abbildung 2.40 zeigt ein Beispiel eines Workflow-Statusberichts, der im Cockpit für Materialstammdaten dargestellt wird. Dabei stehen die Zeilen für die Qualitätsstadien und geben an, welche Phasen das Stammdatenobjekt bereits erfolgreich durchlaufen hat.

Abb. 2.40
Workflow Status Report bei der Anlage von Materialstammdaten. (Otto 2013, S. 16)

War die Datenqualität in den ersten Jahren des neuen Jahrtausends mit unter 30 % korrekter Produktdatensätze noch sehr schlecht, so hat Johnson & Johnson mittlerweile ein Six-Sigma-Level erreicht: Am 1. Juli 2012 entsprachen 99,99966 % aller Stammdatensätze den vorgegebenen Datenqualitätsregeln.

Abbildung 2.41 zeigt die Entwicklung des Datenqualitätsindex bei Johnson & Johnson. Dieser berechnet sich aus dem Verhältnis der Anzahl fehlerfreier Materialstammdatensätze zur Gesamtzahl an Materialstammdatensätzen. Ein Datensatz wird als fehlerhaft angesehen, sobald er mindestens eine der definierten Datenqualitätsregeln verletzt. Der erste, noch recht überschaubare Satz an Regeln wurde in der ersten Projektphase definiert. Mittlerweile gibt es bei Johnson & Johnson rund 400 Datenqualitätsregeln, welche täglich geprüft und ggf. modifiziert werden. Dies ist notwendig, um der starken Marktdynamik in der Konsumgüterbranche, speziell auf dem nordamerikanischen Markt, gerecht zu werden.

Abb. 2.41
Entwicklung des Datenqualitätsindex. (Otto 2013, S. 18)

Wie deutlich erkennbar ist, knickt die Kurve in Abb. 2.41 zweimal stark nach unten ab. Der erste Knick im September 2011 war die Folge einer Datenmigration nach einem weiteren Unternehmenskauf. Der zweite, nicht ganz so ausgeprägte Knick im Januar 2012 ist auf den gewählten Messzeitpunkt zurückzuführen. Dieser war der 1. Januar 2012, ein Sonntag. An diesem Tag entsprach das Kalenderjahr nicht dem Fiskaljahr – eine Unstimmigkeit, die sich bereits am nächsten Tag, dem 2. Januar, auflöste. Die Testlogik wurde daraufhin angepasst.

2.7.5 Erkenntnisse

Johnson & Johnson konnte in nur drei Jahren viele der gesteckten Data Governance – Ziele erreichen. Die Gründung der EMD-Abteilung ebnete den Weg für das übergeordnete Ziel, die Datenqualität durch unternehmensweites Datenmanagement zu verbessern.

Tabelle 2.22 zeigt die Entwicklung von sechs Datenmanagementkompetenzen, von denen fünf auf der Ebene des Gesamtunternehmens neu entwickelt werden mussten.

Tab. 2.22
Entwicklung der Datenmanagementkompetenzen

Datenmanagementkompetenz

Stand Anfang 2008

Stand Anfang 2012

Data Strategy Management

Auf Ebene des Gesamtunternehmens nicht vorhanden

• EMD-Ziele aus Geschäftszielen abgeleitet

• Unterstützung durch Executive Management

• Kontinuierliches Managementreporting

Data Quality Management

Überhaupt nicht vorhanden

• Datenqualitätsprozesse und -werkzeuge sind etabliert und werden kontinuierlich verbessert, sowohl vor als auch während der Datennutzung

Data Stewardship

Nur auf Ebene der einzelnen Geschäftsbereiche vorhanden; keine Koordination auf der Ebene des Gesamtunternehmens

• Klare Verantwortlichkeiten für die einzelnen Datenklassen

• Zentrales EMD-Team mit Stewardship-Verantwortung

Data Lifecycle Management

Kein unternehmensweites Konzept vorhanden

• Workflow-unterstützter Prozess für die Anlage und Pflege von Stammdatensätzen

• Prozess für die Deaktivierung von Stammdatensätzen ist in Entwicklung

Data Architecture Management

Keine einheitliche Definition der wesentlichen Geschäftsobjekte

Zentrale Datenquelle ist das SAP-ERP-System

• Unternehmensweit einheitliches Verständnis der wesentlichen Geschäftsobjekte (z. B. „Product Samples“)

• Das SAP-ERP-System ist die führende Datenquelle

Database Management

SAP-ERP-System

SAP-ERP-System

Johnson & Johnson konnte im Laufe der Zeit drei wesentliche Faktoren identifizieren, die eine positive Auswirkung auf die unternehmensweite Data Governance hatten.

Erstens ist heute unumstritten, dass der wesentliche Impuls für die Initiative von außerhalb des Unternehmens kam. Es gab zwar auch innerhalb des Unternehmens schon immer Treiber des Datenqualitätsmanagements, jedoch war das Bewusstsein unternehmensintern nicht stark genug ausgeprägt. Erst als von Kundenseite die Kritik immer deutlicher geäußert wurde, konnte sich ein entsprechendes Problembewusstsein im Unternehmen bilden.

Zum Zweiten war es extrem wichtig, dass die Verantwortlichen nach der als Weckruf empfundenen Kritik des Kunden schnell mit der notwendigen unternehmensweiten Reichweite handelten. Während bis dahin Datenqualitätsprobleme als verteilt im Unternehmen auftretende, unzusammenhängende Phänomene betrachtet wurden, realisierte Johnson & Johnson nun, dass dieses Problem von unternehmensweiter Relevanz war und damit auch auf dieser Ebene angegangen werden musste.

Drittens wird bei Johnson & Johnson heute als unverzichtbar angesehen, die Datenqualität täglich zu überwachen und die Analyseergebnisse zu dokumentieren. So kann Johnson & Johnson die Auswirkungen bestimmter Vorfälle auf die Datenqualität nachverfolgen. Dadurch kann sich das Unternehmen besser auf Ereignisse in der Zukunft einstellen und versuchen, die negativen Auswirkungen dieser Ereignisse auf die Datenqualität zu verringern. Darüber hinaus war es auch wichtig zu erkennen, dass über eine kontinuierliche Messung und Überwachung der Datenqualität und ihre Anhebung auf das Six-Sigma-Level klar gezeigt werden kann, dass Data Governance tatsächlich eine positive Auswirkung auf die Datenqualität hat. Dieser Beweis ist äußerst hilfreich, um den betriebenen Aufwand für ein ständiges Weiterentwickeln der Data Governance im Unternehmen und gegenüber allen Mitarbeitern erklären zu können.

Zusammengefasst waren die wichtigsten Erkenntnisse bei Johnson & Johnson:

- Qualitätsprobleme von Material- und Produktdaten schlagen sich in allen Geschäftsprozessen nieder; deshalb müssen Anforderungen an die Datenqualität auch vom gesamten Produktlebenszyklus abgeleitet werden.

- Die dauerhafte Verbesserung der Datenqualität erfordert eine organisatorische Verankerung des unternehmensweiten Datenqualitätsmanagements.

- Automatisierte digitale Datenqualitätsprüfungen durch Geschäftsregeln müssen mit halbmanuellen, physischen Prüfungen (hier mithilfe des CubiScan-Geräts) kombiniert werden. Die Korrektheit der Daten wird so durch Prüfung am Realweltobjekt sichergestellt.

- Workflows und Bereitstellungsbereiche (Staging Areas) vor der Datenübernahme ins ERP-System verhindern die Erfassung fehlerhafter Daten und sichern die Datenqualität im Produktivsystem.

- Die Übertragung von bewährten Qualitätsmanagementsystemen wie Six Sigma auf das Datenqualitätsmanagement erleichtert die Umsetzung und erhöht die Akzeptanz.

2.7.6 Weiterführendes Material

Für den Fall von Johnson & Johnson liegen an verschiedenen Orten Details aus wissenschaftlicher und auch aus praktischer Perspektive vor (Tab. 2.23):

Tab. 2.23
Weiterführendes Material zum Fall von Hilti

Quelle

Titel

Ergebnistyp

Wiss.

Praxis

Otto 2013

On the evolution of data governance in firms: The case of Johnson & Johnson consumer products North America

Wiss. Beitrag in Herausgeberband

√

√

Viman und Otto 2012

Data governance: Learning from the past: J&J case study

Präsentation auf Praxiskonferenz

√

Wailgum 2012

Data and information governance at Johnson & Johnson

Beitrag in Fachzeitschrift

√

2.8 Lanxess: Business Intelligence und Stammdatenmanagement bei einem Spezialchemiehersteller

2.8.1 Unternehmensüberblick

Lanxess ist ein deutscher Spezialchemiekonzern mit Sitz in Köln. Das Unternehmen ging 2004 aus der ehemaligen Chemie- und Teilen der Polymersparte der Bayer AG hervor. Lanxess beschäftigt ca. 17.000 Mitarbeiter in 31 Ländern und ist weltweit an 52 Produktionsstätten vertreten. Das Kerngeschäft von Lanxess besteht in der Entwicklung, Herstellung und dem Vertrieb von Kunststoffen, Kautschuken, Zwischenprodukten und Spezialchemikalien. Das breite Produktspektrum und die 14 Geschäftseinheiten sind in die drei Segmente Performance Polymers, Advanced Intermediates und Performance Chemicals gegliedert. Kernkompetenzen sind chemisches Know-how, Anwendungs-Know-how, flexibles Asset-Management und Kundennähe (Tab. 2.24).

Tab. 2.24
Kurzprofil Lanxess

Lanxess AG

Gründung

2004

Branche

Spezialchemie

Unternehmenssitz

Köln, Deutschland

Rechtsform

Aktiengesellschaft

Homepage

www.lanxess.de

Umsatz (2013)

8,3 Mrd. EUR

Gewinn (2013)

− 159 Mio. EUR

Mitarbeiter (2013)

17.343

Diese Fallstudie zeigt, dass Stammdatenmanagement und hohe Datenqualität eine notwendige Grundlage für Business Intelligence (BI)-Projekte mit aktueller Informationstechnologie sind.

2.8.2 Ausgangssituation des Datenmanagements und Business Intelligence 2004–2011

Nach der Ausgründung aus der Bayer AG besaß Lanxess zunächst eine fragmentierte IT-Landschaft mit 26 ERP-Systemen unterschiedlicher Anbieter. Auf der Reportingseite betrieb das Unternehmen ein ebenfalls von Bayer übernommenes Business Warehouse (BW). Das Business Warehouse enthielt Daten von verschiedenen Divisionen, denen unterschiedliche Datenmodelle zugrunde lagen. Diese uneinheitliche Datengrundlage erlaubte weder ein globales Reporting, noch genügte es den Ansprüchen der lokalen Geschäftseinheiten an ein vertrauenswürdiges und nutzerfreundliches Berichtswesen. Lokale Anwender schufen daraufhin zahlreiche Einzellösungen in Form von eigenen Accessdatenbanken oder Exceltabellen, welche die IT-Landschaft weiter fragmentierten. Auf ERP-Seite zählten schlechte Wartbarkeit und mangelnde Upgradefähigkeit der Systeme auf neuere Softwareversionen zu den größten Herausforderungen.

Um diese Probleme zu beheben, führte Lanxess zwischen 2004 und 2011 ein unternehmensweites Projekt zur Konsolidierung der IT-Landschaft durch. Nach erfolgreicher Projektumsetzung bestand die neue IT-Landschaft von Lanxess nur noch aus folgenden Systemen:

- 1 globales Stammdatensystem

- 2 ERP-Systeme

- 1 globales Reportingsystem (SAP BW)

Das Stammdatensystem und die umgebenden Data Governance – Strukturen werden im folgenden Abschnitt genauer beschrieben.

Das neue globale Reportingsystem deckte über 90 % des gesamten Geschäfts ab und ermöglichte Berichte wie z. B. Cost-Center, Product Costing, Profitability Analysis, Sales & Distribution, Material Management und Transport Management – Berichte (jeweils tagesaktuell) sowie Konzernkonsolidierung, Budgetplanung, Global P&L und Global Inventories – Berichte (monatsaktuell).

2.8.3 Das Stammdatenmanagement bei Lanxess seit 2011

Data Governance umfasst nach dem Verständnis von Lanxess alle Mitarbeiter, Prozesse und IT-Systeme, die einen angemessenen und konsistenten Umgang mit Daten im gesamten Unternehmen sicherstellen (Rosenhagen 2014). Lanxess verzeichnete 2013 ein monatliches Wachstum seiner Stammdaten um ca. 700 neue Kundenstammdatensätze, ca. 500 neue Lieferantenstammdatensätze sowie etwa 1000 neue Materialstammdatensätze. Um diesen Zuwachs zu bewältigen und die weltweite Versorgung der Geschäftsprozesse mit verlässlichen Stammdaten zu gewährleisten, hat Lanxess eine Data Governance-Organisation geschaffen, die ein zentrales Stammdaten-Support-Team, eine Stammdatenarchitektur mit vier Hauptbestandteilen sowie definierte Rollen und Verantwortlichkeiten einschließt.

Organisation und Prozesse

Lanxess etablierte eine zentrale Abteilung am Hauptsitz, die als globale Unterstützungsabteilung für stammdatenbezogene Aufgaben fungiert. Die Hauptfunktionen dieser Abteilung sind:

- Professionelle Beratung und Support für das zentrale Stammdatensystem

- Vertrags- und Lizenzmanagement

- Verteilung von Stammdaten an alle relevanten Systeme von Lanxess

- Schulung und Beratung für Mitarbeiter in den Geschäftseinheiten hinsichtlich der Nutzung von Stammdaten und ihrer Prozesse

Darüber hinaus legte Lanxess eine „Data Owner“-Organisation fest, die Rollen und Verantwortlichkeiten für alle zentralen Stammdatenklassen (Lieferanten, Kunden, Materialien) definiert. Diese ist in Abb. 2.42 dargestellt.

Abb. 2.42
Aufbau der Data-Owner-Organisation bei Lanxess. (Rosenhagen 2014, S. 34)

Der links unten in der Abbildung erwähnte Stammdatenprozess bezieht sich auf einen workflowgestützten Anlage- und Pflegeprozess für Lieferanten-, Kunden- und Materialstammdaten, der die globalen Datenpflegeprozesse vereinheitlicht hat. Gemeinsam mit dem Rollenkonzept stellt dieser Workflow sicher, dass alle neu angelegten Stammdatensätze sowohl systemseitig als auch von den jeweiligen Verantwortlichen auf Richtigkeit geprüft werden, sodass nur Datensätze hinreichender Datenqualität in das zentrale MDM-System gelangen. Voraussetzung für diesen Workflow war eine Unterscheidung in globale und lokale Stammdatenattribute und eine entsprechende Rollenzuteilung. Der Workflow überbrückt Organisations- und Systemgrenzen.

Aktuell gibt es allerdings noch eine hohe Zahl von Mitarbeitern, die lokal Stammdaten über den Workflow anfragen und genehmigen (allein für Lieferanten sind weltweit über 600 Personen involviert). Dies bringt Nachteile hinsichtlich der Datenqualität sowie der Prozessdauer und -kosten mit sich, sodass Lanxess den Aufbau von regionalen Stammdatenzentren plant. Damit soll die Zahl der beteiligten Personen reduziert werden, um die Prozessqualität zukünftig weiter zu verbessern und gezielter Mitarbeiterschulungen anbieten zu können.

Systeme

Das globale Stammdatensystem basierend auf SAP MDM, das im Rahmen der Systemkonsolidierung implementiert wurde, ist das Herzstück der neuen Lanxess-Stammdatenarchitektur. Sie besteht vereinfacht gesprochen aus vier Hauptkomponenten:

- MDM-System: Die zentrale Stammdatendatenbank

- SAP NetWeaver: Ein Web-Portal, das den Stammdatenworkflow einschließlich Business Rules implementiert. Diese Benutzerschnittstelle ist in mehreren Landessprachen realisiert

- Business Objects Data Service: Eine Lösung für automatische Adress- und andere Validierungen

- SAP PI: Eine Middleware, die das zentrale Stammdatensystem mit 21 Zweitsystemen verbindet und die Verteilung der globalen Stammdaten in diese Systeme umsetzt

Der oben schon erwähnte Workflow bringt mehrere Vorteile mit sich. So bietet er bei der Anlage oder Änderung von Stammdaten eine automatische Überprüfung auf Dubletten und automatisch vorausgefüllte Felder und Konsistenzprüfungen, um Fehler bei der manuellen Dateneingabe zu minimieren. Außerdem haben Lanxess-Mitarbeiter durch den Workflow stets Transparenz über den aktuellen Status einer Stammdaten-Anfrage und die Durchlaufzeit des Prozesses kann einfach gemessen werden.

Um die Übersicht über solche und weitere Kennzahlen zu erhalten, implementiert Lanxess im Rahmen der Data Governance-Initiative „EXPAND“ ein Kennzahlen-Framework für das globale Stammdatenmanagement. Mehrere Kennzahlen sollen im Intranet in einem Portal für die Anwender aus den Geschäftseinheiten zur Verfügung stehen. Ein Überblick über den Umfang des Kennzahlen-Frameworks ist in Abb. 2.43 wiedergegeben.

Abb. 2.43
Kennzahlen-Framework von Lanxess. (nach Rosenhagen 2014, S. 30)

2.8.4 Aufbau des strategischen Reportings seit 2012

Anforderungen

Nach Abschluss der Systemkonsolidierung und Aufbau des Stammdatenmanagements stand Lanxess eine konsolidierte Datenbasis für eine Bandbreite operativer und taktischer Berichts- und Planungsanforderungen zur Verfügung. Sie bot jedoch noch nicht die notwendigen Funktionalitäten für fortgeschrittene strategische Reporting-Ansprüche.

Deshalb startete Lanxess ab Anfang 2012 ein Folgeprojekt im Bereich Business Intelligence (BI). Das Projekt „REMIX“ (Re-engineering Management Information) hatte zum Ziel, die Systemlandschaft weiterzuentwickeln und neue strategische BI-Anforderungen zu unterstützen. Genauer standen vier Ziele im Vordergrund:

- Strategische Funktionen: Zusätzlich zu den oben genannten Berichten sollten nun auch weitere Funktionen wie eine Umsatz- & Margen-Analyse mit Simulation, eine globale Kostenanalyse, ein Top-Management-Reporting in Form von Cockpits sowie zukünftig auch weitere Funktionen ermöglicht werden.

- Standards: Trotz des neuen zentralen BW-Systems griffen Anwender in den Geschäftsbereichen weiterhin häufig auf ihre eigenen Reporting-Frontends zurück. Diese meist Microsoft Office-basierten Tools wurden oft als schneller und bedienungsfreundlicher empfunden als das Reportingtool „Business Explorer“, welches in das BW integriert ist. Eine neue Standardlösung sollte den Bedarf für solche Behelfslösungen reduzieren.

- Performance & Usability: Neue Lösungen mussten leicht bedienbar und leistungsfähig sein, um von den Anwendern angenommen zu werden.

- Flexibilität: Neue Berichte sollten durch den Anwender anpassbar sein, um die Abhängigkeit vom IT-Support zu reduzieren und für eine höhere Anwenderzufriedenheit zu sorgen („self-service BI“).

Für eine Pilotumsetzung wurden zwei Reporting-Szenarien ausgewählt, die das Unternehmen als besonders wichtig einstufte. Das erste war eine dynamische Umsatz- & Margen-Simulation (kurz: Margen-Simulation), das zweite ein leistungsfähiges Management-Cockpit.

Das Szenario Margen-Simulation sollte ermöglichen, die Auswirkungen von Veränderungen im Wettbewerbsumfeld und von strategischen Entscheidungen (z. B. im innerbetrieblichen Handel) auf die Margenentwicklung der verschiedenen Geschäftseinheiten zu simulieren und damit besser einschätzbar zu machen. Eine solche Analyse ist für das Unternehmen sehr wertvoll, da die Chemieindustrie erstens stark von externen Bedingungen wie z. B. der Rohstoffpreisentwicklung abhängt und Lanxess zweitens Wertschöpfungsschritte an unterschiedlichen seiner global verteilten Produktionsstandorte vornimmt, sodass der innerbetriebliche Handel sehr wichtig für das Ergebnis einiger Lanxess-Geschäftsbereiche ist. Die Auswirkungen von Veränderungen dieser unterschiedlichen internen und externen Parameter auf das Gesamtunternehmen sowie die einzelnen Geschäftsbereiche waren bislang nur schwer einschätzbar.

Das Szenario Management-Cockpit sollte dem Top-Management detailliert und komfortabel Konzernkennzahlen darstellen und zudem die bisherigen aufwändigen Prozesse für die Konzernkonsolidierung vereinfachen. Das Management wollte außerdem mit kurzen Reaktionszeiten auch auf tiefere Berichtsebenen durchgreifen können. Beide gewünschten Funktionalitäten standen mit der bisherigen Reportinglandschaft nicht zur Verfügung, sodass nach einer neuen IT-Lösung gesucht wurde.

Hintergrund zu In-Memory Computing und Toolauswahl

In-Memory Datenbank-Technologie, auch In-Memory Computing genannt, ist eine Technologie, die in den letzten fünf Jahren einige Aufmerksamkeit erhalten hat. 2013 zählte die Analystenfirma Gartner In-Memory Computing zu einem der Top-10 Technologietrends (Gartner 2013). In-Memory Datenbanken halten den Großteil des Datenbestandes nicht auf einer Festplatte, sondern im Hauptspeicher, was erhebliche Geschwindigkeitsvorteile bei Datenzugriffen im Vergleich zum Festplatten-I/O bietet (Gill 2007, S. 61). Kombiniert mit modernen Datenbankkonzepten wie Spaltenorientierung mit seinem höheren Potenzial für Datenkompression verspricht In-Memory Computing auch bei großen Datenmengen hohe Datenverarbeitungsgeschwindigkeiten. Obwohl die Technologie schon in den 1980er Jahren beschrieben wurde, ist sie erst seit einigen Jahren dank fallender Preise für die entsprechende Hardware und der zunehmenden Verbreitung von 64-bit-Architekturen, die einen größeren Arbeitsspeicher direkt ansprechen können, für den Unternehmensalltag tauglich geworden. In-Memory Computing gilt als eine der Technologien, die für die Lösung von Big Data-Anforderungen geeignet ist; vor allem für jene Anwendungsfälle, die besonders schnelle Datenverarbeitung benötigen.

Lanxess zog darum für die beschriebenen Szenarien In-Memory Computing-Lösungen in Betracht. Da das Unternehmen zuvor noch keine Erfahrung mit dieser Technologie gesammelt hatte, fand mit Unterstützung eines externen Dienstleisters ein Anbietervergleich statt, um ein geeignetes Tool auszuwählen. Die neue IT-Lösung sollte vor allem drei Anforderungen genügen:

- Funktionalität: Leistungsfähige Unterstützung der beiden geplanten Szenarien, Cockpit und Margen-Simulation

- Kompatibilität mit der bisherigen IT-Landschaft und angemessener Implementierungsaufwand

- Hohe Anwendungsfreundlichkeit, um die Nutzerakzeptanz sicher zu stellen

Nach dem sechswöchigen Auswahlprozess entschied sich Lanxess für eine Kombination aus den Produkten SAP BW on HANA als Backend und arcplan als Frontend. Abbildung 2.44 veranschaulicht die verschiedenen Bewertungsperspektiven und Schritte des Auswahlprozesses.

Abb. 2.44
BI-Toolauswahl. (Hömberg 2013, S. 12)

Implementierung und neue Funktionen am Beispielszenario Margen-Simulation

Nach der Softwareauswahl implementierte Lanxess die Szenarien im Jahr 2013 als Pilotanwendungen zunächst in einer (Cockpit) bzw. zwei (Margen-Simulation) Geschäftseinheiten. Voraussetzung dafür war eine neue Datenmodellierung für das BW on HANA, in das daraufhin die notwendigen Daten aus dem bisherigen BW migriert wurden. Lanxess wählte einen „Greenfield“-Ansatz, d. h. sämtliche Datenmodelle wurden für die neuen Anwendungen neu entwickelt, um erstens die aktuelle Geschäftssicht abzubilden und zweitens die vereinfachte Datenmodellierung der SAP HANA – Datenbank auszunutzen. Im Rückblick wurde dies als einer der Erfolgsfaktoren von Projekt REMIX angesehen, da auf diese Weise mit alten überflüssigen Datenmodellen „aufgeräumt“ werden konnte.

Mit der Umsatz- und Margen-Simulationsanwendung können Lanxess-Planer sowohl auf Geschäftsbereichs- als auch auf Unternehmensebene komplexe Szenarien analysieren und simulieren. Damit können unter anderem die folgenden Fragen beantwortet werden: „Wie viel verdienen wir an einem einzelnen Kunden/ an einer Kundengruppe/an folgenden Produktgruppen?“ oder „Wie verändern sich die jeweiligen Margen bei anderen Werten für Rohstoffpreise, Frachten, Energiepreise etc?“ Im Gegensatz zu den vorhandenen Planungstools z. B. aus dem Supply Chain Planning stehen hier nicht die Produktionsplanung und damit Mengengerüste im Fokus, sondern die finanzielle Ergebnissicht wie Kunden- und Produktprofitabilität. Abbildung 2.45 zeigt einige der Eingabeparameter, die mit der Simulations-Engine berücksichtigt werden können.

Abb. 2.45
Umsatz- und Margen-Reporting. (Schuster 2013, S. 6)

Nachdem die neuen Lösungen in den Pilot-Geschäftsbereichen erfolgreich implementiert und letzte technische Herausforderungen bewältigt sind, die in erster Linie auf die geringe Maturität der In-Memory Computing-Produkte zurückzuführen sind, sollen sie in den verbleibenden 12 (bzw. 13) Geschäftsbereichen ausgerollt werden. Daraufhin können die alten Lösungen abgeschaltet werden. Es sind bereits weitere Szenarien auf den neuen In-Memory Computing-Lösungen geplant.

2.8.5 Erkenntnisse

Diese Fallstudie zeigt, dass eine einheitliche Sicht auf die Unternehmensdaten die Basis für fortgeschrittene Datenanalysen und ein zukunftsfähiges Berichtswesen sind. Die Konsolidierung von ERP-Systemen und eine „Single Source of Truth“ sind einerseits Voraussetzung für ein reibungsloses operatives Geschäft, bilden darüber hinaus aber auch die Grundlage für komplexere strategische BI-Anforderungen. Der Zusammenhang zwischen dem IT-Befähiger, der In-Memory Computing-Lösung, und dem realisierten Geschäftsnutzen lässt sich anhand eines „Business Dependency Networks“ darstellen (Bärenfänger et al. 2014). Wie Abb. 2.46 zeigt, bewährt sich die neue Technologie nicht nur im direkten Geschäftsalltag, sondern sie trägt auch zu den übergeordneten strategischen Unternehmenszielen bei.

Abb. 2.46
Business-Dependency-Network für In-Memory Computing bei Lanxess. (Bärenfänger 2014, S. 25)

Zusammengefasst waren die wichtigsten Erkenntnisse bei Lanxess:

- Konsolidierte und saubere Unternehmensdaten sind Voraussetzung für fortgeschrittene BI-Lösungen.

- Ein systemgestützter Workflow für den Stammdatenpflegeprozess mit klaren Rollen und Verantwortlichkeiten stellt sicher, dass Stammdaten zügig und unter gesicherter Qualität in zentralen und lokalen Anwendung zur Verfügung stehen.

- In-Memory Computing-Technologie kann dazu eingesetzt werden, komplexe Simulationen mit großen Datenmengen durchzuführen und ein für Endnutzer flexibles Berichtswesen zu etablieren.

2.8.6 Weiterführendes Material

Für den Fall von Lanxess liegen an verschiedenen Orten Details aus wissenschaftlicher und auch aus praktischer Perspektive vor (Tab. 2.25).

Tab. 2.25
Weiterführendes Material zum Fall von Lanxess

Quelle

Titel

Ergebnistyp

Wiss.

Praxis

Bärenfänger 2014

Value potential of in-memory data management

Arbeitsbericht CC CDQ

√

√

Rosenhagen 2014

Master Data Management @ Lanxess

Präsentation auf CC CDQ-Workshop

√

Schuster 2013

Re-engineering management information at Lanxess

Präsentation auf Praxiskonferenz

√

2.9 Shell: Datenqualität im Produktlebenszyklus in der Mineralölindustrie

2.9.1 Unternehmensüberblick

Shell ist eine globale Unternehmensgruppe im Energie- und Petrochemiemarkt. Mit 92.000 Mitarbeitern ist Shell in über 70 Ländern vertreten und erwirtschaftet einen Gewinn von über 16 Mrd. USD (Tab. 2.26).

Tab. 2.26
Kurzprofil Shell

Shell

Gründung

1907

Branche

Mineralöl, Erdgas

Unternehmenssitz

Den Haag, Niederlande

Rechtsform

Public limited company

Homepage

www.shell.com

Umsatz (2013)

348,46 Mrd. EUR (451,24 Mrd. USD)

Gewinn (2013)

12,76 Mrd. EUR (16,53 Mrd. USD)

Mitarbeiter (2013)

92.000

Das Geschäft von Shell gliedert sich in zwei Bereiche. Das Upstream-Geschäft kümmert sich um die Erschließung neuer Öl- und Gasreserven. Das Downstream-Geschäft zielt darauf, in den Absatzmärkten mit den Öl- und Gasreserven Umsatz zu generieren. Zum Downstream-Geschäft gehören die Produktion, die Distribution und die Vermarktung von Ölprodukten und Chemikalien. Shell ist an mehr als 25 Raffinerien weltweit mit einer Kapazität von insgesamt über 3 Mio. Barrel pro Tag beteiligt. Das Unternehmen verfügt über 1500 Lagertanks, 150 Distributionseinrichtungen und mehr als 44.000 Tankstationen weltweit.

2.9.2 Ausgangssituation und Handlungsdruck

Das Produktlebenszyklusmanagement (PLM) ist für die Markteinführung, das Management sowie für den Auslauf der Produkte zuständig und liefert damit einen wichtigen Beitrag zu Shells Downstream-Strategie. Voraussetzungen für einen effektiven und effizienten PLM-Prozess sind Produktdaten hoher Qualität.

Das Unternehmen identifizierte folgenden Handlungsdruck in Bezug auf das Datenmanagement für den PLM-Prozess:

- Niedrige Datenqualität

- Lange Durchlaufzeit bei der Anlage von Produktdaten

- Hohe Komplexität des Prozesses zur Anlage von Produktdaten

- Wissenslücken im PLM-Prozess

- Fehlende Leistungskennzahlen

Eine Ursache-Wirkungs-Analyse zeigte zudem, dass die verschiedenen Probleme im PLM-Prozess voneinander abhängig waren (Abb. 2.47).

Abb. 2.47
Ursache-Wirkungsanalyse der Datenqualitätsprobleme bei Shell. (Tan 2013, S. 9)

Die Probleme im Datenmanagement für den PLM-Prozess führten dazu, dass zwei Drittel aller Anfragen für neue Produkte nicht rechtzeitig bearbeitet wurden und die Anlage neuer Produkte durchschnittlich 23 Tage benötigte.

2.9.3 Durchgängiges Datenmanagement im Produktlebenszyklus

Zum Re-engineering seines PLM-Prozesses nutzte Shell „Lean Six Sigma“-Methoden. Über einen Zeitraum von zwei Jahren wurden sechs Projekte durchgeführt:

- Verbesserung der Systemunterstützung des PLM-Prozesses

- Definition „globaler“ und „lokaler“ Geschäftsregeln zur Steuerung des Produktanlageprozesses

- Entwicklung eines Werkzeugs zur automatischen Belegung von Feldern („Auto Population“) bei der Produktanlage

- Einführung einer SAP-Stammdatenlösung

- Einführung eines Workflow-Managementsystems für die Produktanlage

- Reduktion manueller Tätigkeiten im Produktanlageprozess

Die sechs Projekte standen zwar unter einer gemeinsamen Steuerung. Jedoch musste jedes einzelne Projekt für sich wirtschaftlich sein. Shell nutzte den sogenannten DMAIC-Ansatz, um einerseits die Wirtschaftlichkeit zu Projektbeginn zu bestimmen und um andererseits den Nutzenbeitrag der implementierten Lösung für das Unternehmen zu überwachen.

Im Kern des neuen Datenmanagements für den PLM-Prozess stehen die Geschäftsregeln. Sie erleichtern die Erfassung von Produktstammdaten durch sogenannte „Smart Request Forms“, steuern die Vorbelegung von Feldern sowie den gesamten Workflow über verschiedene Rollen im Erfassungsprozess.

Abbildung 2.48 zeigt illustrativ die Funktion des Smart Request Form.

Abb. 2.48
Smart Request Form bei Shell. (Tan 2013, S. 11)

2.9.4 Herausforderungen bei der Umsetzung

Eine Herausforderung resultierte aus der Komplexität des Unternehmens. Shell operiert in mehr als 70 Ländern weltweit, was die Identifikation derjenigen Geschäftsregeln erschwerte, die den Anlageprozess für Produktdaten steuern. Zusätzlich sind unterschiedliche Rollen im Anlageprozess involviert. Beispiele für Rollen sind Produktmanager, Data Owner und Datenadministratoren. Zudem war der Anlageprozess auf eine Vielzahl verschiedener Applikationssysteme verteilt.

Darüber hinaus war im Projekt die Expertise nicht immer verfügbar, die zum Entwurf der Benutzerschnittstelle und der Funktion des Smart Request Form erforderlich war. Anfangs war lediglich ein einziger Datenanalyst in Teilzeit mit dem Entwurf des Werkzeugs betraut. Kompetenzen für Prozessanalyse, Workflow-Design und Schulung der Anwender waren kaum vorhanden. Die Mitarbeiter des PLM-Prozesses und Mitglieder des Datenteams eigneten sich die nötigen Fähigkeiten selbst an, um das Projekt erfolgreich abschließen zu können.

Das Projekt war nicht mit dem Budget ausgestattet, wie es typischerweise für Workflow-Implementierungen bei Shell der Fall ist. Die Budgetrestriktion zwang das Projektteam, sich auf die wesentlichsten Funktionalitäten zu beschränken.

Eine weitere Herausforderung entstand durch den temporären Parallelbetrieb der herkömmlichen und der neuen Lösung mit dem Smart Request Form. Insgesamt mussten mehr als 200 Anwender für das neue System geschult werden.

Schließlich musste das Projektteam das interne Governance and Audit – Team davon überzeugen, dass der neue Prozess nicht gegen behördliche, gesetzliche oder anderweitige Vorgaben und Regeln verstieß.

2.9.5 Nutzen der neuen Lösung

Die neue Datenmanagement-Lösung liefert einen Nutzenbeitrag für das Unternehmen. Das interne Controlling analysierte die Lösung und bewertete die jährlichen Kosteneinsparungen auf mindestens 2 Mio. USD.

Der Nutzen entsteht hauptsächlich durch Zeit und Qualitätsvorteile, u. a.:

- Reduktion der Durchlaufzeit bei komplexen Produktneuanlagen um 86 % auf 3,3 Tage

- Reduktion der Durchlaufzeit bei normalen Produktneuanlagen um 64 % auf 2,1 Tage

- Fristgerechte Neuanlage bei 92 % der Anfragen (Steigerung um 33 Prozent)

- Steigerung der „first time right“-Anlagen von 90 auf 97 %

- Steigerung der Prozesstreue bei der Produktneuanlage von 96 auf 99 %

Abbildung 2.49 illustriert ausgewählte Nutzensteigerungen.

Abb. 2.49
Verbesserung des Neuanlageprozesses von Produkten bei Shell. (Tan 2013, S. 18)

2.9.6 Erkenntnisse

Shell kam nach Abschluss des Projekts zu einer Reihe von Erkenntnissen, die bei der Weiterentwicklung der Lösung und bei vergleichbaren Vorhaben berücksichtigt werden. Zum einen stellt eine Steigerung der Datenqualität für Shell einen Beitrag zum Komplexitätsmanagement dar, weil Durchlaufzeiten reduziert und die Prozesstreue erhöht werden. Zahlreiche manuelle Aktivitäten sowie Schleifen im Prozess wie bei der alten Lösung waren Komplexitätstreiber und konnten abgebaut werden. Zum anderen machte Shell gute Erfahrungen damit, schrittweise vorzugehen und nicht die „große Lösung“ auf einen Schlag realisieren zu wollen. Drittens war eine enge Abstimmung zwischen Fachbereichen, Datenteam und IT-Abteilung während der gesamten Laufzeit des Projekts erfolgskritisch. Zudem waren – trotz der damit verbundenen Herausforderungen – Change Management und Schulungen Voraussetzung für die Akzeptanz der Nutzer der neuen Lösung und damit für ihren Nutzenbeitrag insgesamt.

2.9.7 Weiterführendes Material

Für den Fall von Shell liegen an verschiedenen Orten Details aus wissenschaftlicher und auch aus praktischer Perspektive vor (Tab. 2.27).

Tab. 2.27
Weiterführendes Material zum Fall von Shell

Quelle

Titel

Ergebnistyp

Wiss.

Praxis

Self 2011

Data quality in Shell

Präsentation auf Fachkonferenz

√

√

Self 2013

Shell’s global data quality journey

Buchbeitrag

√

√

Tan 2013

Shell’s Product Lifecycle Management (PLM) End to End (E2) data process improvement story

Präsentation auf CC CDQ-Workshop

√

2.10 Syngenta: Auslagerung von Datenmanagementaufgaben in der Pflanzenschutzindustrie

2.10.1 Unternehmensüberblick

Die Syngenta AG ist ein global operierendes Großunternehmen der Agrochemiebranche[20]. Das Unternehmen mit Hauptsitz in Basel (Schweiz) produziert und vertreibt Pflanzenschutzmittel und Saatgut für den internationalen Markt. Es entstand im Jahr 2000 durch eine Fusion der Agrarsparten von Novartis und AstraZeneca. Syngenta geht von einer wachsenden Weltbevölkerung und einer damit in Zusammenhang stehenden steigenden Nachfrage nach Nahrungsmitteln aus. Um die Menschen zu ernähren und Nachhaltigkeit zu gewährleisten, müssen Produktionssteigerungen mit höherer Ressourceneffizienz erreicht werden als bisher (Syngenta 2014) (Tab. 2.28).

Tab. 2.28
Syngenta

Syngenta

Gründung

2000

Branche

Agrochemie

Unternehmenssitz

Basel, Schweiz

Rechtsform

Aktiengesellschaft

Homepage

www.syngenta.com

Umsatz (2013)

11,34 Mrd. EUR (14,69 Mrd. USD)

Gewinn (2013)

1,38 Mrd. EUR (1,79 Mrd. USD)

Mitarbeiter (2013)

28.149

Die Unternehmensstrategie von Syngenta basiert auf drei Säulen, nämlich erstens der Integration der Bereiche Pflanzenschutzmittel und Saatgut, um umfassende Lösungen anbieten zu können, zweitens weiterer Innovationen sowohl im chemischen als auch im biologischen Bereich, um auch künftig neue Märkte zu erschließen und drittens der Werterzeugung für seine Kunden und Aktionäre.

Die bei Syngenta durchgeführte Fallstudie analysiert die Entwicklungen, die im Rahmen eines Stammdatentransformationsprojekts und verbunden mit der Auslagerung der Datenpflegeprozesse an einen externen Dienstleister stattfand. Betrachtet wird die gesamte, globale Organisation des Unternehmens mit einem speziellen Fokus auf die interne Stammdatenmanagementorganisation (im Folgenden auch kurz „MDM-Organisation“ genannt) und auf die Auslagerung einiger Stammdatenpflegeprozesse auf den externen Anbieter.

2.10.2 Ausgangssituation und Ziele der Stammdatenmanagementinitiative

Im Jahr 2007 startete Syngenta das unternehmensweite Restrukturierungsprogramm „Sustainable Excellence“. Das Programm bestand aus drei Hauptbereichen: „Business Process Management – Change and Sustain“ (bezogen auf Unternehmensfunktionen wie Finanzen, Human Resources und Supply Chain Management), „Business Process Support“ (Unterstützung von Projekten) und „Data and Information Management“ (mit Bezug auf das Thema Stammdatenmanagement) (Bauer und Murphy 2011). Abbildung 2.50 zeigt den Programmaufbau.

Abb. 2.50
Übersicht zum Syngenta-Restrukturierungsprogramm „Sustainable Excellence“. (Bauer und Murphy 2011, S. 7)

In der Vorbereitungsphase des Programms führte Syngenta für den Bereich Stammdatenmanagement eine Untersuchung durch, die folgende Probleme aufdeckte (Bauer 2009):

- Es gab keine klaren Verantwortlichkeiten für global gültige Unternehmensstammdaten

- Geschäftsprozesse waren kaum standardisiert und automatisiert

- Die Prozesse für die Pflege der Stammdaten waren ineffizient und uneinheitlich

- Niedrige Datenqualität wirkte sich negativ auf die Geschäftsprozesse aus

Die Untersuchung basierte auf Interviews mit Verantwortlichen aus allen Geschäftsbereichen sowie auf Online-Umfragen. Insgesamt wurden dazu im September und Oktober 2007 136 Personen befragt. Die vorliegende Fallstudie war nicht Bestandteil dieser Untersuchung, nutzt aber deren Ergebnisse.

Im Detail stellte sich die Ausgangssituation in Bezug auf das Stammdatenmanagement wie folgt dar:

- Das Stammdatenmanagement war in „funktionalen Silos“ organisiert (wurde also in den einzelnen Geschäftsbereichen und Linienabteilungen dezentral durchgeführt). Ein unternehmensweites Stammdatenmanagement existierte nicht.

- Auf der Ebene des Gesamtunternehmens gab es keine standardisierten oder harmonisierten Prozesse.

- Es gab keine klaren MDM-Verantwortlichkeiten und expliziten MDM-Rollen (also keine Data-Governance-Strukturen).

- Die Datenhaltung war redundant, inkonsistent und oft unvollständig.

- Für die Anlage von Stammdaten waren keine Service Levels oder Qualitätskennzahlen definiert.

- Der Prozess für die Anlage von Stammdaten wurde durch eine hohe Anzahl von Schnittstellen zwischen den Systemen sowie komplexe Systemarchitekturen erschwert.

Da eine niedrige Datenqualität nicht per se kritisch ist, analysierte Syngenta detailliert die Auswirkungen der Datenqualität auf die Business Performance. Hierbei fielen z. B. folgende Prozessfehler auf:

- Verspätete Warenlieferung an den Kunden infolge fehlerhafter Materialdaten

- Probleme bei der Abrechnung von Lieferungen infolge fehlerhafter Kundendaten

- Falsche Verpackung und/oder Beschriftung von Produkten

- Hoher Aufwand für die Ermittlung von Beständen aufgrund von niedrigem Vertrauen in die vom Warenwirtschaftssystem bereitgestellten Informationen

Um solche Probleme zu beheben, war früher bei Syngenta ein hoher Aufwand durch Doppelarbeit (z. B. für manuelle Suche nach korrekten Informationen) sowie häufig auch das Einleiten von „Firefighting“-Maßnahmen erforderlich.

Um Abhilfe zu schaffen, startete Syngenta ein Transformationsprojekt für das Stammdatenmanagement. Ziel war eine neue MDM-Organisation, die zentrale Stammdaten-Services für das gesamte Unternehmen anbietet. Der Fokus lag dabei auf den Materialstammdaten für Pflanzenschutzmittel und Saatgut sowie auf Kunden-, Lieferanten-, Human Resource (HR)- und Finanzstammdaten.

2.10.3 Das Transformationsprojekt und MDM-Designprinzipien

Syngenta veranschlagte für das gesamte Transformationsprojekt einen Zeitrahmen von drei Jahren. Abbildung 2.51 zeigt die drei Hauptphasen des Projekts.

Abb. 2.51
Transformationsprojekt bei Syngenta. (nach Reichert 2014, S. 80)

Die erste Phase des Projekts, die im April 2009 begann, bestand in erster Linie aus Planungsaktivitäten. Im Mittelpunkt stand die konzeptionelle Herausforderung, die MDM-Grundlagen zu entwickeln, die z. B. die neue Stammdaten-Organisationsstruktur sowie neue Vorgaben und Prozesse zur Stammdatenpflege umfassten. Das Projektteam stimmte die Konzeption des Stammdatenmanagements mit den unterschiedlichen Interessengruppen im Unternehmen sowie den Zielen der verschiedenen Linienabteilungen ab.

Das strategische Ziel der neuen Organisationsstrukturen beschrieb Syngenta mit drei Losungen:

- „Ein Team“: Alle MDM-Ressourcen stehen unter einer gemeinsamen Führung

- „Ein Weg“: Sicherstellung eines standardisierten Ansatzes für die Bereitstellung qualitativ hochwertiger Stammdaten

- „Ein Tool“: Ein zentrales MDM-Tool für alle Datenpflegeprozesse

Die neue MDM-Organisation sollte als Stewardship-Organisation fungieren, die Stammdatenprozesse mittels Service Level Agreements und Kennzahlen-Systemen betreibt und damit alle Stammdatenmanagementaktivitäten unterstützt. Dazu wurden acht Designprinzipien definiert (Tab. 2.29).

Tab. 2.29
Designprinzipien für das Stammdatenmanagement bei Syngenta

Designprinzip für MDM

Beschreibung

Prozessstandardisierung und -automatisierung

Das Stammdatenmanagement erfolgt über standardisierte Prozesse, die mit einem zentralisierten Workflow-Tool unterstützt werden.

Alle nutzenden Prozesse der Stammdaten sind identifiziert und definiert

Data Ownership in der Linienabteilung

Die Workflows beinhalten eingebettete Kontrollen, Data-Ownership-Rollen und Freigabemechanismen für die Linienabteilungen.

Sie sind auditierbar und transparent durch ein entsprechendes Reporting

Datenqualität

In die Workflows sind Datenqualitätschecks eingebettet.

Standardisierte Tools und Prozesse unterstützen die Pflegeprozesse der wichtigsten Stammdatenobjekte.

Alle datennutzenden Systeme müssen die Daten aus diesen Prozessen verwenden.

Als „Single Point of Truth“ für die Stammdatenschlüsselelemente fungiert das SAP Data Repository

Data Governance/Business Service

Die MDM-Organisation hat die Ownership und die Stewardship für die Prozesse inne.

Technischer Support wird von der IT-Abteilung bereitgestellt.

Verantwortlichkeiten und Rollen sind entlang von drei Bereichen definiert: Data Content Ownership, Process Ownership und Technical Ownership.

Die Workflows werden so konfiguriert, dass sie den Anforderungen der verschiedenen Verantwortlichkeiten, Rollen und Bereiche Rechnung tragen

Change Governance

Die Linienabteilungen initiieren Änderungen an Stammdaten.

Änderungsanfragen werden von dem definierten Verantwortlichen geprüft und zur weiteren Bearbeitung zugeordnet

Zukunftssichere und skalierbare Lösungen

Systemübergreifende Skalierbarkeit wird bei jedem neuen IT-Tool von Beginn an eingeplant (z. B. Enterprise Portal).

Das Architektur-Team prüft und bewilligt jede Stammdatenlösung und stellt sicher,

dass den übergeordneten organisatorischen und technischen Anforderungen des Unternehmens Rechnung getragen wird

Prozesstransparenz und -kontrolle

Das Stammdatenmanagement sichert einheitliche Prozesse für Erstellung, Erweiterung, Aktualisierung,

Berichte und Prüfung von Stammdaten mit adäquater Qualitätssicherung.

Prozesskennzahlen-Reports ermöglichen ein kontinuierliches Monitoring der definierten Prozesse

Systemübergreifender Ansatz

Bei der Migration der Stammdaten in das SAP-System werden Referenzta-bellen befüllt.

Sowohl während der Migration als auch im normalen Betrieb werden Deduplikationsroutinen implementiert.

Kundenstammdaten können zum Teil über verschiedene Geschäftsbereiche hinweg geteilt werden,

zum Teil handelt es sich aber auch um bereichsspezifische Daten

Die zweite Phase des Transformationsprojekts begann im vierten Quartal 2009 und beinhaltete im Wesentlichen die Implementierung der MDM-Grundlagen in den drei Dimensionen Organisation, Prozesse und Technologien. Diese Phase ermöglichte eine erste Einsparung von Ressourcen, da einige der Leadership-Rollen innerhalb der MDM-Organisation zusammengelegt werden konnten.

Außerdem implementierte Syngenta in der zweiten Phase die zuvor entwickelte Roadmap für die Auslagerung sich wiederholender Datenpflegeprozesse an einen externen Dienstleister. Dieser ist ein weltweiter Anbieter von IT-Dienstleistungen mit über 100.000 Mitarbeitern und Sitz in Indien. Die Auslagerung begann im Jahr 2010 mit dem Prozess zur Anlage von Materialstammdaten für Saatgut. Bis zum Jahr 2012 folgte die Auslagerung der Datenpflegeprozesse aller anderen Stammdatenklassen, d. h. der Prozesse für Material-, Lieferanten-, Kunden-, HR- und Finanzstammdatenmanagement.

Die dritte Phase des Transformationsprozesses begann Anfang 2011. In dieser Phase ging es vorwiegend um den weiteren Ausbau der zentralen Services der MDM-Organisation sowie die kontinuierliche Überprüfung der in Phase 1 entwickelten Grundlagen. Syngenta legte eine Zielgröße für die MDM-Organisation von 50 Personen fest, die mit der Auslagerungsinitiative erreicht werden sollte. Der Schwerpunkt der internen MDM-Organisation verlagerte sich von der Datenpflege hin zu einer Data Stewardship-Funktion.

Die folgenden Abschnitte beschreiben Syngentas neue Organisationsstruktur sowie weitere Details des Auslagerungsprozesses genauer.

2.10.4 Organisationsstruktur des Stammdatenmanagements

Unter Berücksichtigung der oben genannten Designprinzipien definierte Syngenta sechs neue Rollen für die neue MDM-Organisation:

- Head of MDM: Der Head of MDM leitet die MDM-Organisation und stellt sicher, dass die Anforderungen der Linienabteilungen an das Stammdatenmanagement in Leitlinien, Strategien und Prozessen Berücksichtigung finden.

- Lead Steward: Die Lead Stewards entwickeln die globalen Richtlinien und Prozesse für die von ihnen verantworteten Stammdatenobjekte und garantieren, dass alle Workflows und Prozesse des Stammdatenmanagements global gepflegt, überwacht und verbessert werden. Darüber hinaus sind die Lead Stewards maßgeblich an der Definition der SLAs (Service Level Agreements) der Stammdaten-Organisation beteiligt und überwachen deren Erfüllung. Außerdem stellen sie sicher, dass die Datenqualität überwacht wird, und halten bei Bedarf die regionalen Verantwortlichen dazu an, Qualitätsverbesserungsmaßnahmen einzuleiten. Schließlich sind sie auch zuständig für ein regelmäßiges Kennzahlen-Reporting gegenüber dem für das jeweilige Datenobjekt verantwortlichen Governance-Gremium.

- Data Architect: Der Data Architect ist dafür verantwortlich, dass das Stammdatenmanagement die Geschäftsprozesse durch passende Systeme und Prozesse unterstützt, z. B. mit einheitlichen Stammdaten-Workflows. Er berät zudem den Head of MDM und die Lead Stewards hinsichtlich Stammdatenstrukturen und -anwendungen, damit Best Practices unternehmensweit bekannt sind und angewendet werden können. Außerdem verantwortet er Projekte der MDM-Organisation hinsichtlich Zeit, Kosten, und Qualität und leitet datenobjektübergreifende Stammdatenprojekte.

- Regional Steward: Die Regional Stewards stellen sicher, dass alle Stammdatenmanagementprozesse und -workflows einer bestimmten geografischen Region definiert, gepflegt, überwacht, optimiert und mit überregionalen Prozessen abgestimmt werden. Sie sind zudem verantwortlich für die Qualität der regional gültigen Stammdaten und Stammdatenmanagementsysteme.

- Data Analyst: Die Data Analysts kontrollieren alle Stammdatenmanagementprozesse und -workflows einer bestimmten geografischen Region und leiten den kontinuierlichen Verbesserungsprozess. Sie überwachen zudem die Qualität der Stammdaten im System und leiten bei Bedarf entsprechende Qualitätsverbesserungsmaßnahmen ein. Außerdem unterstützen sie stammdatenbezogene Projekte.

- Data Specialist: Die Data Specialists führen die Aufgaben des Stammdatenmanagements in den entsprechenden Workflows gemäß den in den SLAs definierten zeitlichen und qualitätsbezogenen Vorgaben operativ aus. Außerdem unterstützen sie die Linienabteilungen in allen Fragen rund um das Stammdatenmanagement. Ebenso unterstützen sie Data Stewards und Data Analysts durch Analysen und Qualitätsverbesserungsmaßnahmen.

Während die Rollen „Head of MDM“, „Lead Steward“ und „Data Architect“ für die globale Ebene des Gesamtunternehmens definiert werden, sind die Rollen „Regional Steward“, „Data Analyst“ und „Data Specialist“ nur für die regionale Ebene vorgesehen. In den meisten Fällen wurden bei Syngenta für die Besetzung der neuen Rollen Personen ausgewählt, die zur Ausübung der jeweiligen Rolle nicht umziehen und ein Büro in einer anderen Region beziehen mussten. Grundlegendes Entscheidungskriterium für die Besetzung der MDM-Organisation war, dass Mitarbeiter, die mehr als die Hälfte ihrer Arbeitszeit für das Stammdatenmanagement aufwendeten (egal ob auf strategischer oder auf operativer Ebene), zu Mitgliedern dieser Organisation gemacht wurden. Eine weitere Integration der Linienabteilungen wurde über den Workflows zur Anlage von Stammdaten sichergestellt. Abbildung 2.52 gibt eine Übersicht über die neue MDM-Organisation bei Syngenta. Diese wurde im April 2009 bekanntgegeben und ging im November 2009 in den operativen Betrieb.

Abb. 2.52
Übersicht zur MDM-Organisation bei Syngenta. (Reichert 2014, S. 76)

Alle Rollen auf globaler Ebene sind mit Vollzeitstellen besetzt. Lead Stewards können zwar lokal angesiedelt sein, dürfen aber nicht mit der Ausübung regionaler Rollen betraut werden, damit es keine Überschneidungen von Verantwortlichkeiten gibt. Regionale Rollen sind stets in der geografischen Region angesiedelt, für die sie tätig sind. Der Regional Head of MDM ist dem Regional Steward direkt übergeordnet und ist keine explizite MDM-Rolle, sondern erfüllt reguläre regionale Managementaufgaben. Eine Person kann auch mehrere regionale Rollen übernehmen. Die Gesamtzahl der Mitarbeiter der MDM-Organisation betrug vor der Auslagerung etwa 110 FTE, davon 80 auf Data-Specialist-Ebene (Ausführung des Datenpflegeprozesses) und 30 auf Design- und Managementebene (Definition von Standards und Prozessen sowie Überwachung der Abläufe). Die erste Projektphase endete mit der abgeschlossenen MDM-Grundlagen-Definition und dem „go live“ der MDM-Organisation.

Syngentas globale MDM-Organisation (in Abb. 2.53 die beiden dunkelgrauen Blöcke in der Mitte) verantwortet nach dem neuen Betriebsmodell noch alle Aktivitäten, die mit Prozessdesign und Prozessänderungen verbunden waren, sowie darauf bezogene Verbesserungsaktivitäten und Anwendertrainings. Zudem überwacht die MDM-Organisation alle ausgelagerten Prozesse. Syngenta etablierte dafür zwei Teams in der MDM-Organisation: Erstens wurde ein Stammdatenservice-Team namens „Syngenta Service Delivery & Operations Team“ aufgebaut, welches die Interaktion mit dem ersten externen Anbieter unterstützt und die damit verbundenen Prozesse für Datenanlage, -säuberung und Service Level Agreements überwacht. Zweitens interagiert das „Syngenta Domain MDM Team“ mit der IT (Block links in der Abbildung), um die neu entworfenen Prozesse zu implementieren und Probleme zu behandeln. Der IT-Partner ist (unabhängig von der MDM-Auslagerungs-Initiative) ebenfalls ein externer Dienstleister. Stammdatenanfrager („Master Data Requestors“, der Block rechts oben in der Abbildung) sind Nutzer in den Linienabteilungen, die die Anlage oder Änderung von Stammdaten beantragen.

Abb. 2.53
Syngenta-Betriebsmodell (unter Einbezug externer Partner). (Fischer 2013, S. 9)

Intern arbeiten heute bei Syngenta (wie nach der ersten Phase des Transformationsprozesses festgelegt) 50 Mitarbeiter in der MDM-Organisation. Auf Seiten des externen Anbieters sind rund 100 Personen für das Stammdatenmanagement von Syngenta tätig. Da der Anbieter global agiert, arbeitet die Belegschaft dort in Schichten, wodurch eine Verfügbarkeit von 20 h am Tag garantiert ist. Dies kommt der ebenfalls weltweit verteilten Belegschaft von Syngenta zugute. Syngenta konnte somit konnte die Mitarbeiterzahl von rund 110 im Jahr 2009 um ca. 50 % reduzieren und diesen Anteil auf den externen Anbieter übertragen.

Drei wesentliche Gründe waren für Syngenta bei der Entscheidung für die Auslagerung entscheidend:

1.

Reduzierung der Prozesskosten in der Stammdatenpflege durch Auslagerung der eigentlichen Anlage- und Pflegeaktivität an das Service Center in Indien.

2.

Fokussierung auf die Kernkompetenzen des Unternehmens: Die Pflegeprozesse von Datenlebenszyklen sind nicht die Kernkompetenz des Unternehmens und können somit von einem externen, spezialisierten Anbieter geleistet werden.

3.

Skalierbarkeit: Das jährliche Wachstum von Syngenta von 7 bis 10 % verlangt eine schnelle Anpassung an sich verändernde Anforderungen. Der externe Partner ist in der Lage, innerhalb kurzer Zeit Ressourcen für die Stammdatenmanagementprozesse frei zu machen, entweder durch Neueinstellungen oder durch Verfügbarmachung zusätzlicher interner Ressourcen. Da das Geschäft mit Pflanzenschutzmitteln und Saatgut in höchstem Maße saisonal verläuft, kann die Bereitstellung von Ressourcen gut geplant und dann auch umgesetzt werden.

Aspekte wie z. B. absolute Kosteneinsparungen oder vermehrte Standardisierung waren keine wesentlichen Treiber der Auslagerungs-Initiative, da dies auch durch interne Offshoring-Aktivitäten hätte erreicht werden können (indem z. B. eine interne Serviceorganisation in einem Niedriglohnland aufgebaut wird).

2.10.5 Datenpflegeprozess und Entscheidungskriterien für die Auslagerung

Der Datenpflegeprozess über den kompletten Datenlebenszyklus hinweg (die Kernaktivität des externen Anbieters) ist für alle Stammdatenobjekte einheitlich (Abb. 2.54). Ein Beispiel soll die Interaktion der verschiedenen Rollen verdeutlichen:

Abb. 2.54
Datenpflegeprozess (Erstellung und Erhalt) bei Syngenta. (Fischer 2013, S. 11)

Eine Linienabteilung benötigt neue Stammdaten, weil ein Datensatz für einen neuen Anbieter angelegt werden soll. Die grundlegenden Informationen zu diesem Anbieter (z. B. sein Name und die Adresse) werden in ein Antragsformular (welches auf Microsoft Sharepoint oder Infopath basiert) eingegeben. Nach der Erstanlage des Datensatzes muss eine zweite Rolle innerhalb der Linienabteilung die Anfrage genehmigen (Trennung der Rollen aus Compliance-Gründen, „4-Augen-Prinzip“). Nach der Genehmigung wird der Prozess an die MDM-Organisation, repräsentiert durch den externen Anbieter, übergeben. Dort wird der neue Datensatz dann validiert (z. B. auf Schreibfehler überprüft) und komplettiert (z. B. durch Ergänzung der Bankverbindung des Anbieters).

Am Ende des Prozesses werden die Daten in das System hochgeladen und so für den Anfrager verfügbar gemacht. Der externe Anbieter ist direkt an die operativen Systeme von Syngenta angebunden, wodurch der Aufwand für das Schnittstellenmanagement und die Auseinandersetzung mit redundanter Systeminfrastruktur reduziert wird. Der Client Engagement Manager, eine weitere neue Rolle als Teil des Service Delivery & Operations Teams der internen MDM-Organisation bei Syngenta, verantwortet Prozessdesign und -Ausführung. Alle Datensätze werden in englischer Sprache gehalten.

Syngenta entscheidet anhand eines Kriterienkatalogs, ob Datenpflegeaktivitäten in das Dienstleistungsangebot der MDM-Organisation aufgenommen werden und ob sie für die Auslagerung an den externen Anbieter in Frage kommen. Diese Prozesse und Services[21] können entweder von der MDM-Organisation oder von der jeweiligen Linienabteilung identifiziert und vorgeschlagen werden. Tabelle 2.30 führt diese Kriterien auf.

Tab. 2.30
Kriterien für die Serviceidentifikation bei Syngenta

Kriterium

Beschreibung

Gleichheit und Wiederholung

Der Prozess verläuft in seiner Gesamtheit stets annähernd identisch und besteht aus einzelnen routinemäßig wiederkehrenden Aktivitäten.

Der Prozess tritt zudem regelmäßig auf

Ressourcenintensivität

Der Prozess ist zeitaufwändig und kann von einem externen, spezialisierten Anbieter schneller und effizienter abgewickelt werden

Leichte Beschreibbarkeit

Prozessbeschreibungen sind immer präzise und einfach formuliert und können schon nach kurzer Einarbeitung verstanden werden.

Jede Prozessbeschreibung folgt den vorgegebenen Geschäftsregeln, welche dokumentiert werden können

Nutzung von Standardtechnologien

Um den Prozess auszuführen, sind keine speziellen Tools oder spezielles Fachwissen notwendig

Keine ausgedehnte verbale Interaktion mit den Anforderern der Fachbereiche notwendig

Nach dem ersten Informationsaustausch kann der Prozess ohne verbale Interaktion zwischen den Anforderern der Fachbereiche und den Datenerfassern im Shared Service Center ausgeführt werden

Geringe Änderungshäufigkeit

Ein gerade ausgelagerter Prozess sollte nicht gleich wieder verändert werden müssen.

Wenn Änderungen am Prozess absehbar sind, sollte dies schnellstmöglich kommuniziert werden

Keine Einbeziehung von geistigem Eigentum von Syngenta

Während der Ausführung des Prozesses werden keine Informationen verwendet und ausgetauscht,

die zum Kern des geistigen Eigentums von Syngenta zählen

Ortsunabhängigkeit

Der Prozess kann von überall aus ausgeführt werden.

Es besteht keine Notwendigkeit, den Prozess an einem bestimmten Ort oder in einer bestimmten geografischen Region auszuführen

Nachdem ein neuer Service (dessen Prozess ganz oder teilweise ausgelagert werden soll) auf die oben genannten Kriterien hin untersucht wurde, prüft Syngenta ihn hinsichtlich der folgenden 10 Punkte. Erst wenn diese Merkmale erfüllt sind, kann ein Service operativ genutzt werden.

1.

Umfang und Reichweite des Services sind festgelegt: Der funktionale und technische Umfang sowie die geografische Reichweite des Services werden festgelegt. Die Abgrenzung zu anderen möglichen Serviceprovidern innerhalb eines Ende-zu-Ende-Services ist klar.

2.

Dokumentation ist verfügbar: Sowohl für die Ende-zu-Ende-Prozessübersicht als auch für den Servicebereitstellungsprozess existiert eine Dokumentation.

3.

Aktivitätenliste, Teamgröße, Rollenprofile und Arbeitsstunden sind festgelegt: Die benötigten Ressourcen werden kalkuliert und festgelegt (basierend auf einer vollständigen Liste der Aktivitäten, die in die MDM-Organisation überführt werden sollen). Saisonale Spitzen werden berücksichtigt.

4.

Anspruchsgruppen sind identifiziert: Anspruchsgruppen sind die Hauptnutzer, die Mitglieder des Offshore-Teams, der Service Delivery Manager, die Data Analysts, die fachlichen Datenanforderer sowie Eskalationskontakte. Verteilerlisten werden erstellt und über Microsoft Sharepoint verwaltet.

5.

SLAs sind festgelegt und Service-Kennzahlen sind definiert und werden regelmäßig gemessen: SLAs werden gemäß den Geschäftsanforderungen definiert und mit dem Lead Steward festgelegt. Die Definition und Messung der Service-Kennzahlen wird festgelegt, ebenso wie die Rückverfolgbarkeit von Anfragen.

6.

Zugang zu den Systemen ist festgelegt und sichergestellt: Für alle relevanten Systeme werden die Nutzerrollen definiert, erzeugt und sichergestellt.

7.

Technischer Support und Skalierbarkeit ist validiert: Das Modell für den Technischen Support wird unter Einbeziehung aller involvierten Akteure festgelegt.

8.

Eskalationsprozesse und dazugehörige Personen sind festgelegt: Für jede geografische Region werden ein Eskalationsprozess sowie die darin involvierten Personen und Rollen festgelegt.

9.

Datenqualität wird regelmäßig gemessen und bewertet: Das Datenqualitätslevel, zu welchem der Service übernommen wurde, wurde definiert und abgestimmt. Das Datenqualitätsmanagement und die Messung der Datenqualität werden festgelegt.

10.

Schulungsmaßnahmen sind durchgeführt: Maßnahmen für die Schulung der Servicepartner (vor Ort und offshore) und der Hauptnutzer werden durchgeführt.

Nach Implementierung der Services erstellt Syngenta monatliche Performance Reports. Diese unterscheiden sowohl nach den verschiedenen Stammdatenobjekten (Material, Anbieter, Kunden etc.) als auch nach Gesamtprozessperformance und Performance der MDM-Organisation (Abb. 2.55). Für jeden Report sind Details auf regionaler und auf Länderebene verfügbar, wodurch interne Best-Practice-Vergleiche möglich sind.

Abb. 2.55
MDM-Servicereporting bei Syngenta. (Fischer 2013, S. 19)

2.10.6 Erkenntnisse

Mit der Etablierung der MDM-Organisation im Jahr 2009 und der Auslagerung von ersten Datenpflegeprozessen ab 2010 konnte Syngenta folgende Verbesserungen erzielen: Neues, für die Datenpflegeprozesse benötigtes Personal ist beispielsweise innerhalb von drei Monaten verfügbar (Anwerbungs- und Einstellungsprozess inklusive Schulung). Im Vergleich zur bisherigen internen Verfahrensweise konnte dieser Prozess beschleunigt werden. Syngenta erreichte zudem einen höheren Grad an Standardisierung sowohl in Bezug auf die Datenpflegeprozesse als auch hinsichtlich der betroffenen Geschäftsprozesse. Zudem profitiert Syngenta nun von Qualitätskennzahlen und Datenqualitätsmessungen ebenso wie von Messungen der Servicequalität über Service Level Agreements und einer höheren Transparenz hinsichtlich der Business Performance.

Im Rahmen des Transformationsprozesses und vor allem im Rahmen der Auslagerungsinitiative war Syngenta aber auch mit einigen Herausforderungen konfrontiert. So muss z. B. sichergestellt werden, dass es zu keiner Externalisierung von schützenswerten Informationen oder von geistigem Eigentum kommt. Außerdem konnte als weiteres Risiko auf der operativen Ebene eine gewisse Demotivation bei den Syngenta-Mitarbeitern festgestellt werden, die eine Veränderung ihrer gewohnten Arbeitsweise befürchten.

Zusammengefasst waren die wichtigsten Erkenntnisse bei Syngenta:

- Die Organisation des unternehmensweiten Datenqualitätsmanagements muss zentrale und dezentrale sowie verschiedene funktionale Interessen im Unternehmen berücksichtigen.

- Bei der Organisation des unternehmensweiten Datenqualitätsmanagements sind strategische, taktische und operative Aufgaben zu unterscheiden.

- Strategische Aufgaben sind zentral zu organisieren, operative Aufgaben wie die Datenerfassung können weiterhin dezentral gelöst werden oder gar an externe Dienstleister ausgelagert werden.

- Leistungsvereinbarungen regeln das operative Datenmanagement und ermöglichen die Leistungskontrolle.

2.10.7 Weiterführendes Material

Für den Fall von Syngenta liegen an verschiedenen Orten Details aus wissenschaftlicher und auch aus praktischer Perspektive vor (Tab. 2.31):

Tab. 2.31
Weiterführendes Material zum Fall von Syngenta

Quelle

Titel

Ergebnistyp

Wiss.

Praxis

Bauer 2009

Creating a Worldwide Master Data Management Organization for Syngenta

Präsentation auf CC CDQ-Workshop

√

Bauer und Murphy 2011

Master Data Management Outsourcing of MDM Activities – A case study

Präsentation auf CC CDQ-Workshop

√

Fischer 2013

Global Master Data Services at Syngenta

Präsentation auf CC CDQ-Workshop

√

Moltes und Raymond 2010

KPI Dashboard MDM Syngenta

Präsentation auf CC CDQ-Workshop

√

Reichert 2014

Methode zur Einführung von Stammdaten-Management als betriebliche Unterstützungsfunktion

Dissertation

√

√

Open Access Dieses Kapitel wird unter der Creative Commons Namensnennung-Nicht kommerziell 4.0 International Lizenz (http://creativecommons.org/licenses/by-nc/4.0/deed.de) veröffentlicht, welche für nicht kommerzielle Zwecke die Nutzung, Vervielfältigung, Bearbeitung, Verbreitung und Wiedergabe in jeglichem Medium und Format erlaubt, sofern Sie den/die ursprünglichen Autor(en) und die Quelle ordnungsgemäß nennen, einen Link zur Creative Commons Lizenz beifügen und angegeben, ob Änderungen vorgenommen wurden.

Literatur

Baghi, Ehsan; Abraham, Rene: Case Study: Allianz Global Corporate & Specialty AG – Data Quality Controlling and Data Governance. St. Gallen, Universität St. Gallen, Institut für Wirtschaftsinformatik, 2013. – Fallstudie. Bericht-Nr BE HSG/CC CDQ. Version 1. 0, 2013-10-31. Auf Anfrage von den Autoren verfügbar

Baghi, Ehsan; Ebner, Verena: Case Study: Customer Data Quality Management at Hilti. St. Gallen, Universität St. Gallen, Institut für Wirtschaftsinformatik, 2013. – Fallstudie. Bericht-Nr BE HSG/CC CDQ 26. Version 1. 0, 2013-09-15. Auf Anfrage von den Autoren verfügbar

Bärenfänger, Rieke: Study Report: Value Potential of In-Memory Data Management. St. Gallen, Universität St. Gallen, Institut für Wirtschaftsinformatik, 2014. – Arbeitsbericht. Bericht-Nr BE HSG/CC CDQ 31. Version 1. 0, 2014-11-06. Auf Anfrage von den Autoren verfügbar

Bärenfänger, Rieke; Otto, Boris; Österle, Hubert: Business value of in-memory technology – multiple-case study insights. In: Industrial Management & Data Systems 114 (2014), Nr. 9, S. 1396–1414. – DOI http://dx.doi.org/10.1108/IMDS-07-2014-0212 CrossRef

Bauer, Antje: Creating a worldwide Master Data Management Organization for Syngenta (5. Competence Center Corporate Data Quality Workshop (CC CDQ 2), 2009-09-29). Vevey, 2009. – Präsentation. Auf Anfrage von den Autoren verfügbar

Bauer, Antje; Murphy, Carole: Master Data Management, Outsourcing of MDM Activities – A Case Study (31. Competence Center Corporate Data Quality Workshop (CC CDQ 3), 2011-09-22). Bregenz, 2011. – Präsentation. Auf Anfrage von den Autoren verfügbar

Bosch: Geschäftsbericht 2013. Stuttgart, 2014. Abgerufen 2014-10-14 von http://www.bosch.com/content2/publication_forms/de/downloads/Bosch_Geschaeftsbericht_2013.pdf

Brauer, Berthold: Master Data Quality Cockpit at Bayer CropScience (4th Workshop of the Competence Center Corporate Data Quality (CC CDQ2), 2009-06-25). Luzern, 2009. – Präsentation. Auf Anfrage von den Autoren verfügbar

Brauer, Berthold: The Master Data Quality Journey at Bayer CropScience (Steering Committee Meeting of the Competence Center Corporate Data Quality (CC CDQ2), 2012-05-10). St. Gallen, 2012. – Präsentation. Auf Anfrage von den Autoren verfügbar

Ebner, Verena; Brauer, Berthold: Case study on the governance system for master data quality at Bayer CropScience. In: HMD – Praxis der Wirtschaftsinformatik 48 (2011), Nr. 279, S. 64–73CrossRef

Ebner, Verena; Hüner, Kai; Otto, Boris: Fallstudie Bayer CropScience AG – Entwurf und Implementierung geschäftsorientierter Datenqualitätskennzahlen. St. Gallen, Universität St. Gallen, Institut für Wirtschaftsinformatik, 2011. – Fallstudie. Bericht-Nr BE HSG/CC CDQ/18. Version 1. 0, 2011-01-19. Auf Anfrage von den Autoren verfügbar

Ebner, Verena: Entwicklung einer Methode zum Entwurf einer Unternehmensdatenarchitektur. St. Gallen, Universität St. Gallen, Institut für Wirtschaftsinformatik, Dissertation, 2014

Ebner, Verena; Otto, Boris; Österle, Hubert: Conceptualizing Data in Multinational Enterprises: Model Design and Application. In: Atzeni, P.; Cheung, D.W.; Ram, S. (Hrsg.): Conceptual Modeling Vol. 7532: Lecture Notes in Computer Science. Berlin Heidelberg: Springer, 2012, S. 531–536. – DOI 10.1007/978-3-642-34002-4_42CrossRef

Europäische Union: Richtlinie 2009/138/EG des Europäischen Parlaments und des Rates vom 25. November 2009 betreffend die Aufnahme und Ausübung der Versicherungs- und der Rückversicherungstätigkeit (Solvabilität II). In: Amtsblatt der Europäischen Union L 335/2, 2009

Falge, Clarissa: Methode zur Strategieentwicklung für unternehmensweites Datenqualitätsmanagement in globalen Konzernen. St. Gallen, Universität St. Gallen, Institut für Wirtschaftsinformatik, Dissertation, 2015

Fischer, Frank: Global Master Data Services at Syngenta (35. Competence Center Corporate Data Quality Workshop (CC CDQ 4), 2013-06-12). Vevey, 2013. – Präsentation. Auf Anfrage von den Autoren verfügbar

Fohrer, Markus: Customer Data Management at Hilti (5. Competence Center Corporate Data Quality Workshop (CC CDQ 2), 2009-09-29). Vevey, 2009. – Präsentation. Auf Anfrage von den Autoren verfügbar

Fohrer, Markus: Driving Corporate Data Quality Through the Use of Consumer Technology (10. Competence Center Corporate Data Quality Workshop (CC CDQ 3), 2012-09-21). Bregenz, 2012. – Präsentation. Auf Anfrage von den Autoren verfügbar

Gartner Inc.: Gartner Identifies the Top 10 Strategic Technology Trends for 2013. – Internetquelle. Aktualisierungsdatum 2012-10-23. Abgerufen 2013-07-28 von: http://www.gartner.com/newsroom/id/2209615

Gill, John J.: Shifting the BI Paradigm with In-Memory Database Technologies. In: Business Intelligence Journal 12 (2007), Nr. 2, S. 58–63

Grillo, Federico: Improvement of Master Data Quality at Beiersdorf (3. Competence Center Corporate Data Quality Workshop (CC CDQ 2), 2009-04-22). Mörfelden, 2009. – Präsentation. Auf Anfrage von den Autoren verfügbar

Hatz, Albert: BOSCH Master data Management. (6. Competence Center Corporate Data Quality Workshop (CC CDQ 1), 2008-01-16). St. Gallen, 2008. – Präsentation. Auf Anfrage von den Autoren verfügbar

Hömberg, Heiner: SAP NetWeaver BW on HANA @ LANXESS (SAP & VCI-Forum 2013, 2013-06-06). Düsseldorf, 2013. – Präsentation

Huber, Josef: Internationales Produktdatenmanagement – Methoden und Konzepte (IRR Technology Stammdaten-Management Forum, 2009-10-06). Bad Homburg, 2009. – Präsentation. Auf Anfrage von den Autoren verfügbar

Hüner, Kai M.: Methode zur Spezifikation geschäftsorientierter Datenqualitätskennzahlen. St. Gallen, Universität St. Gallen, Institut für Wirtschaftsinformatik, 2010. – Arbeitsbericht. Bericht No. BE HSG/CC CDQ/13, Version 1.0, 2010-10-31. Auf Anfrage von den Autoren verfügbar

Hüner, Kai M.: Führungssysteme und ausgewählte Maßnahmen zur Steuerung von Konzerndatenqualität, St. Gallen, Universität St. Gallen, Institut für Wirtschaftsinformatik, Dissertation, 2011

Hüner, Kai M.; Otto, Boris; Österle, Hubert: Product data quality in supply chains: The case of Beiersdorf. In: Electronic Markets 21 (2011a), Nr. 2, S. 141–154. – DOI 10.1007/s125250110059xCrossRef

KPMG: Solvency II: A closer look at the evolving process transforming the global insurance industry. – Internetquelle. Abgerufen 2014-07-31 von: https://www.kpmg.com/US/en/IssuesAndInsights/ArticlesPublications/Documents/solvency-II.pdf

Lehmann, Andreas: Boost the collaboration and communication between product development and master data administration. (7. Competence Center Corporate Data Quality Workshop (CC CDQ 3), 2012-02-16). Berlin, 2012. – Präsentation. Auf Anfrage von den Autoren verfügbar

Lehmann, Hans: An object-oriented architecture model for international information systems? Exploring a possible approach. In: Journal of Global Information Management 11 (2003), Nr. 3, S. 23–35. – DOI 10.4018/9781591404682.ch001CrossRef

Moltes, Caroline; Raymond, Jean: KPI Dashboard MDM Syngenta (8. Competence Center Corporate Data Quality Workshop (CC CDQ 2), 2010-04-10). Essen, 2010. – Präsentation. Auf Anfrage von den Autoren verfügbar

Nachtsheim, Stephanie; Suwelack, Dirk; Cunitz, Olaf: „TOP Controlling“-Initiative bei Bayer CropScience. In: Zeitschrift für Controlling & Management 54 (2010), Nr. 2, S. 102–106CrossRef

Otto, Boris: How to design the master data architecture: Findings from a case study at Bosch. In: International Journal of Information Management 32 (2012a), Nr. 4, S. 337–346. – DOI 10.1016/j.ijinfomgt.2011.11.018CrossRef

Otto, Boris: Managing the Business Benefits of Product Data Management: The Case of Festo. In: Journal of Enterprise Information Management 25 (2012b), Nr. 3, S. 272–297. – DOI http:// dx.doi.org/10.1108/17410391211224426

Otto, Boris: On the Evolution of Data Governance in Firms: The Case of Johnson & Johnson Consumer Products North America. In: Sadiq, S. (Hrsg.): Handbook of Data Quality – Research and Practice. Berlin: Springer, 2013, S. 93–118CrossRef

Otto, Boris; Ebner, Verena; Hüner, Kai: Measuring Master Data Quality: Findings from a Case Study. In: Proceedings of the 16th Americas Conference on Information Systems (AMCIS) (2010-08-14/18). Lima, 2010

Otto, Boris; Schmidt, Alexander: Enterprise Master Data Architecture : Design Decisions and Options. In: Proceedings of the 15th International Conference on Information Quality (ICIQ) (2010-11-12/14). Little Rock, 2010

Otto, Boris; Ofner, Martin: Fallstudie Festo AG: Gemeinkostenwirksames Produktdatenmanagement. St. Gallen, Universität St. Gallen, Institut für Wirtschaftsinformatik, 2011. – Fallstudie. Bericht-Nr BE HSG/CC CDQ/25. Version 0.95, 2010-07-29. Auf Anfrage von den Autoren verfügbar

Pfaffenzeller, Rudolf: Data Governance: Data Governance in an insurance company (32. Competence Center Corporate Data Quality Workshop (CC CDQ 4), 2012-11-23). Stuttgart, 2012. – Präsentation. Auf Anfrage von den Autoren verfügbar

Pfaffenzeller, Rudolf: Data Governance: Data Governance in an insurance company (Data Governance Conference Europe 2013/Master Data Management Summit Europe 2013 (IRM UK), 2013-04-16). London, 2013. – Präsentation. Auf Anfrage von den Autoren verfügbar

Reichert, Andreas: Methode zur Einführung von Stammdaten-Management als betriebliche Unterstützungsfunktion. St. Gallen, Universität St. Gallen, Institut für Wirtschaftsinformatik, Dissertation, 2014

Reichert, Andreas; Otto, Boris; Österle, Hubert: Externalization of master data management activities: The case of chemicals company Syngenta. In: Journal of Enterprise Information Management. – Unter Begutachtung

Rosenhagen, Achim: Master Data Management @ LXS (41. Competence Center Corporate Data Quality Workshop (CC CDQ 4), 2014-09-10). Frankfurt, 2014. – Präsentation. Auf Anfrage von den Autoren verfügbar

Saaksvuori, Antti; Immonen, Anselmi: Product Lifecycle Management. 3. Aufl. Berlin: Springer, 2008

Schierning, Andreas: Data quality metrics at Beiersdorf – Project DACOTA: Data Defect Identification and Measurement (10. Competence Center Corporate Data Quality Workshop (CC CDQ 2), 2010-09-23). Leipzig, 2010. – Präsentation. Auf Anfrage von den Autoren verfügbar

Schierning, Andreas: Consumer-Centric Information Management: Exploring Product Information (Business Engineering Forum, 2012-09-20). Bregenz, 2012. – Präsentation. Auf Anfrage von den Autoren verfügbar

Schuster, Hermann: Re-engineering Management Information at LANXESS: Business Information powered by BW on HANA (2013-05-07). 2013. – Präsentation. Abgerufen 2014-07-28 von: download.sap.com/germany/download.epd?context=400C342EB644976EF6F63296FBAA8D67A9A0A958D250F976BB24F58AA48FC46DD2794BF6EE3F2F96F835994256CF3BBA7EDE09DB141CDE72

Self, Ken: Data Quality in Shell: Building IQ Knowledge and Skills. In: Koronius, A., Gao, J. (Hrsg.): 16th International Conference on Information Quality (ICIQ) (2011-11-18/20). Adelaide, 2011. – Keynote-Vortrag

Self, Ken: Shell’s Global Data Quality Journey. In: Sadiq, S. (Hrsg.): Handbook of Data Quality – Research and Practice. Berlin: Springer, 2013

Syngenta: Annual Review 2013. Basel, 2014. – Internetquelle. Abgerufen 2014-10-14 von http:// www.annualreport.syngenta.com/assets/pdf/Syngenta_AnnualReview_2013.pdf

Tan, Leesin: Shell’s Product Lifecycle Management (PLM) End to End (E2E) Data Process Improvement Story (36. Competence Center Corporate Data Quality Workshop (CC CDQ 4), 2013-10-10). St. Gallen, 2013. – Präsentation. Auf Anfrage von den Autoren verfügbar

VDI (Verein Deutscher Ingenieure): VDI Richtlinie 2884: Beschaffung, Betrieb und Instandhaltung von Produktionsmitteln unter Anwendung von Life Cycle Costing (LCC). Düsseldorf: VDIVerlag, 2005

Viman, Claude; Otto, Boris: Data Governance: Learning from the Past: J&J Case Study (SAPPHIRE and ASUG Annual Conference, 2012-05-16). Orlando, 2012. – Präsentation. Auf Anfrage von den Autoren verfügbar

Wailgum, Thomas: Data and Information Governance at Johnson & Johnson. ASUG News. – Internetquelle. Aktualisierungsdatum 2012-06-19. Abgerufen 2015-01-11 von http://www.asugnews.com/article/data-and-information-governance-at-johnson-johnson

Wallich, Paul: Everything you always wanted to know about big AG: Selling to the world, not feeding it. In: IEEE Spectrum Special Report: The Age of Plenty (2013). – Abgerufen 2014-10-31 von: http://spectrum.ieee.org/energy/environment/everything-you-always-wanted-to-knowabout-big-ag

Weber, Kristin: Data Governance-Referenzmodell: Organisatorische Gestaltung des unternehmensweiten Datenqualitätsmanagements. St. Gallen, Universität St. Gallen, Institut für Wirtschaftsinformatik, Dissertation, 2009

Weber, Kristin; Otto, Boris; Österle, Hubert: One Size Does Not Fit All – A Contingency Approach to Data Governance. In: ACM Journal of Data and Information Quality 1 (2009), Nr. 1, S. 4:1–4:27

Fußnoten

[1]

Diese Fallstudie basiert auf der im CC CDQ durchgeführten Fallstudie Baghi und Abraham (2013).

[2]

Die Organisationseinheiten werden in allen Fallstudien gemäß dem jeweiligen unternehmensinternen Sprachgebrauch bezeichnet, d. h. teilweise auf Englisch.

[3]

Eine Softwareproduktgruppe des Unternehmens SAS für Anforderungen im Datenqualitätsmanagement und Stammdatenmanagement.

[4]

Während das Cockpit nur die bereits festgelegten Datenqualitätsregeln prüfen kann, stellt die neue Governance-Struktur von AGCS auch sicher, dass neue Regeln zügig umgesetzt werden. Wenn einem Datennutzer oder Produzenten neue Mängel auffallen, entwickelt das Data Governance Team neue Regeln, die nach Abnahme durch die Data Governance Steering Group im DataFlux-Tool implementiert werden.

[5]

Diese Fallstudie basiert auf der im CC CDQ durchgeführten Fallstudie Ebner et al. (2011a).

[6]

Eine Entwicklungsumgebung des Unternehmens Oracle für Web-Anwendungen, die auf Oracle-Datenbanken aufsetzt.

[7]

Diese Fallstudie basiert auf der im CC CDQ durchgeführten und unter Hüner et al. (2011a) publizierten Fallstudie.

[8]

Diese Fallstudie basiert auf der im CC CDQ durchgeführten und unter Otto (2012a) publizierten Fallstudie.

[9]

Diese Fallstudie basiert auf der im CC CDQ durchgeführten Fallstudie Otto und Ofner (2010).

[10]

Eine Software des Unternehmens PTC für das Lebenszyklusmanagement von Produktdaten.

[11]

Die Zahl der Zeichnungsänderungen hat sich im Zeitraum von 2001 bis 2008 verdoppelt.

[12]

Die Staging Area ist ein Daten-Bereitstellungsraum, in dem Daten zur Qualitätsprüfung und –bereinigung zwischengespeichert werden, bevor sie in die Zieldatenbank geladen werden. Die Staging Area bietet damit technische Unterstützung für das „first time right“ – Prinzip im Datenqualitätsmanagement.

[13]

Diese Fallstudie basiert auf der im CC CDQ durchgeführten Fallstudie Baghi und Ebner (2013).

[14]

Für Details siehe https://www.hilti.de/vision-2015.

[15]

Diese Fallstudie basiert auf der im CC CDQ durchgeführten und unter Otto (2013) publizierten Fallstudie.

[16]

Weitere Informationen zu Johnson & Johnsons Geschäftsbereich Consumer Products unter: http://www.jnj.com/connect/about-jnj/company-structure/consumer-healthcare.

[17]

Siehe http://www.gs1.org/gdsn.

[18]

Siehe http://www.cubiscan.com/.

[19]

Eine Plattform zur Web-Anwendungsentwicklung des Unternehmens Backoffice Associates, das auf Qualitätsmanagement- und Stammdatenmanagementlösungen spezialisiert ist.

[20]

Diese Fallstudie basiert auf der im CC CDQ durchgeführten und unter (Reichert et al. 2015), unter Begutachtung publizierten Fallstudie.

[21]

Prozesse sind die internen Abläufe. Services sind die Dienstleistungen, die das MDM (intern und extern) den Fachabteilungen zur Verfügung stellt.

© Der/die Autor(en) 2016

Boris Otto

und Hubert ÖsterleCorporate Data Quality10.1007/978-3-662-46806-7_3

3. Methoden und Werkzeuge des Datenqualitätsmanagements

Boris Otto1   und Hubert Österle2

(1)

Fraunhofer Institut für Materialfluss und Logistik, Dortmund, Deutschland

(2)

Business Engineering Institute St. Gallen, St. Gallen, Schweiz

Boris Otto (Korrespondenzautor)

Email: boris.otto@iml.fraunhofer.de

Hubert Österle

Email: hubert.oesterle@bei-sg.ch

3.1 Methode zur Umsetzung der DQM-Strategie

3.1.1 Aufbau der Methode

3.1.2 Beispieltechniken der Methode

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

3.2.1 Ausgangssituation in Unternehmen

3.2.2 Reifegradmodelle und Benchmarking als Steuerungsinstrumente

3.2.3 EFQM-Exzellenzmodell für das Stammdatenqualitätsmanagement

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

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

3.3.1 Herausforderungen der Geschäftspartnerdatenpflege

3.3.2 Der Lösungsansatz des kooperativen Datenmanagements

3.3.3 Die Corporate Data League

3.4 Weitere Methoden und Werkzeuge des CC CDQ

Literatur

Zusammenfassung

Kapitel 3 beschreibt drei ausgewählte Werkzeuge für das Stammdatenqualitätsmanagement. Die drei Werkzeuge sind Ergebnisse des CC CDQ, die sich durch eine breite Anwendbarkeit (DQM-Strategiemethode und DQM-Reifegrad-Assessment) bzw. einen hohen Innovationsgrad (Corporate Data League) auszeichnen. Abschnitt 3.4 listet alle Ergebnisse des CC CDQ auf und verweist auf weiterführende Quellen hierzu. Die Mehrheit der Ergebnisse findet Anwendung in den Fällen in Kap. 2.

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

3.1 Methode zur Umsetzung der DQM-Strategie

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

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

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

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

3.1.1 Aufbau der Methode

Die Methode besteht aus vier Phasen:

1.

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

2.

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

3.

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

4.

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

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

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

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

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

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

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

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

3.1.2 Beispieltechniken der Methode

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

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

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

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

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

- Datenklassen

- Regionen und Länder

- DQM-relevante Kernprozesse

- Verwendete Anwendungssysteme (optional)

- Verweis auf die relevanten Unternehmensziele für die Organisationseinheit

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

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

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

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

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

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

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

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

- Allgemeine Beschaffungskosten

- Folgekosten der Beschaffung

- Betriebs- und Hilfsstoffe

- Instandhaltungskosten/Ersatzteile (inkl. Änderungskosten)

- Außerbetriebnahmekosten

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

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

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

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

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

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

- Welche spezifischen Ressourcen werden den Projekten zugewiesen?

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

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

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

3.2.1 Ausgangssituation in Unternehmen

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

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

Tab. 3.1
Typische Fragestellungen von DQM-Verantwortlichen

Aufbau und Etablierung

Weiterentwicklung im Regelbetrieb

Wie ist die aktuelle Situation des Datenqualitätsmanagements im Unternehmen? Welche Fähigkeiten, Strukturen und Informationssystemen sind bereits vorhanden?

Wie kann der Fortschritt und Erfolg aller Aktivitäten des Datenqualitätsmanagements (u. a. Projekte, Initiativen, Programme, operative Aufgaben) überwacht und regelmäßig an die Geschäftsführung berichtet werden?

Wo ist der Handlungsbedarf am größten? Welche Maßnahmen müssen in welcher Reihenfolge zur Verbesserung der Datenqualität aufgesetzt werden?

Wie ist der Erfolg dieser Aktivitäten zu bewerten? Rechtfertigt der Nutzen weiterer Investitionen in das Datenqualitätsmanagement die Kosten?

Wie ist der Nutzen einzelner Datenqualitätsmaßnahmen zu bewerten? Wie können Entscheidungsvorlagen aufbereitet und kommuniziert werden, um Unterstützung von Entscheidern zu erhalten?

Wie sollte das Portfolio an Datenqualitätsmanagement-Aktivitäten weiterentwickelt werden? Welche Maßnahmen sind besonders erfolgsversprechend?

Wie gehen andere erfolgreiche Unternehmen vor?

Wie gehen andere erfolgreiche Unternehmen vor?

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

3.2.2 Reifegradmodelle und Benchmarking als Steuerungsinstrumente

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

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

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

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

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

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

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

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

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

3.2.3 EFQM-Exzellenzmodell für das Stammdatenqualitätsmanagement

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

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

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

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

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

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

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

Steuerungscockpit

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

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

Benchmarking-Datenbank

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

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

Good Practice-Datenbank

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

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

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

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

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

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

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

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

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

3.3.1 Herausforderungen der Geschäftspartnerdatenpflege

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

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

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

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

3.3.2 Der Lösungsansatz des kooperativen Datenmanagements

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

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

Abb. 3.11
Redundante Pflege von Geschäftspartnerdaten. (eigene Darstellung)

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

Abb. 3.12
Gemeinschaftliche Pflege von Geschäftspartnerdaten. (eigene Darstellung)

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

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

3.3.3 Die Corporate Data League

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

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

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

Datenmodell

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

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

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

- Steuer(identifikations)nummer

- Hierarchien (legal, geographisch, organisatorisch)

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

- Zertifizierungen, z. B. SAS70 oder ISO 9000

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

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

Data Governance-Konzept und Funktionalitäten

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

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

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

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

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

Business Vocabulary und semantisch annotierte Referenzdaten im CDL-Portal

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

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

3.4 Weitere Methoden und Werkzeuge des CC CDQ

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

Tab. 3.2
Weitere Methoden und Werkzeuge des CC CDQ

Analysemodell für den Nutzen des Produktinformationsmanagements (PIM) (Osl und Otto 2007)

Referenzarchitektur für die überbetriebliche Datensynchronisation zwischen Handel und Konsumgüterindustrie (Schemm 2008)

Funktionsarchitektur für unternehmensweites Stammdatenmanagement (Otto und Hüner 2009)

Referenzmodell für Data Governance (Weber 2009)

Methode zur Spezifikation geschäftsorientierter Datenqualitätskennzahlen (Hüner 2010)

Methode zur Stammdatenintegration (Schmidt 2010)

Führungssysteme zur Steuerung von Konzerndatenqualität (Hüner 2011)

Semantisches MediaWiki für das fachliche Metadatenmanagement (Hüner et al. 2011b, c)

Referenzmodell für das unternehmensweite Datenqualitätsmanagement (Otto 2011b; Otto et al. 2011)

Typologie von Data-Governance-Modellen (Otto 2011c)

Referenzmodell für das Management von Geschäftsregeln (Otto et al. 2011)

Anforderungskatalog für das Stammdatenmanagement der Zukunft (Otto und Ofner 2011)

Ansatz zur Integration von Datenqualität in das Geschäftsprozessmanagement (Ofner et al. 2012; Ofner 2013)

Beschreibungsmodell für semantische Informationssystemstandards (Otto et al. 2012)

Konzept zum Management des Lebenszyklus von Stammdaten (Ofner et al. 2013b)

Methode zum Entwurf einer Unternehmensdatenarchitektur (Ebner 2014)

Methode zur Einführung von Stammdaten-Management als betriebliche Unterstützungsfunktion (Reichert 2014)

Methode zur Strategieentwicklung für unternehmensweites Datenqualitätsmanagement in globalen Konzernen (Falge 2015)

Ansätze zur ökonomischen Bewertung von Datenqualität (Otto 2015)

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

Open Access Dieses Kapitel wird unter der Creative Commons Namensnennung-Nicht kommerziell 4.0 International Lizenz (http://creativecommons.org/licenses/by-nc/4.0/deed.de) veröffentlicht, welche für nicht kommerzielle Zwecke die Nutzung, Vervielfältigung, Bearbeitung, Verbreitung und Wiedergabe in jeglichem Medium und Format erlaubt, sofern Sie den/die ursprünglichen Autor(en) und die Quelle ordnungsgemäß nennen, einen Link zur Creative Commons Lizenz beifügen und angegeben, ob Änderungen vorgenommen wurden.

Literatur

Baskarada, Sasa; Gao, Jing; Koronios, Andy: Agile Maturity Model Approach to Assessing and Enhancing the Quality of Asset Information in Engineering Asset Management Information Systems. In: Proceedings of Business Information Systems (2006), S. 4–17

Batini, Carlo; Scannapieco, Monica: Data Quality. Concepts, Methodologies and Techniques. Berlin: Springer, 2006

Bitterer, Andreas: Gartner’s Data Quality Maturity Model. Stamford: Gartner Research, 2007

Camp, Robert C.: Benchmarking: The search for industry best practices that lead to superior performance. Milwaukee: Quality Press, 1989

DataFlux: The Data Governance Maturity Model. Cary, North Carolina: DataFlux, 2007

Dhillon, Balbir S.: Life Cycle Costing: Techniques, Models, and Applications. New York: Routledge, 1989. – ISBN 2881243029

Ebner, Verena: Entwicklung einer Methode zum Entwurf einer Unternehmensdatenarchitektur. St. Gallen, Universität St. Gallen, Institut für Wirtschaftsinformatik, Dissertation, 2014

EFQM: Framework for Corporate Data Quality Management: Assessing the Organization’s Data Quality Management Capabilities. Brussels: EFQM Press, 2011

Falge, Clarissa: Methode zur Strategieentwicklung für unternehmensweites Datenqualitätsmanagement in globalen Konzernen. St. Gallen, Universität St. Gallen, Institut für Wirtschaftsinformatik, Dissertation, 2015

Geissdörfer, Klaus; Gleich, Ronald; Wald, Andreas: Standardisierungspotentiale lebenszyklusbasierter Modelle des strategischen Kostenmanagements. In: Zeitschrift für Betriebswirtschaft 79 (2009), Nr. 6, S. 693–715. – DOI 10.1007/s1157300902567

Hüner, Kai M.: Methode zur Spezifikation geschäftsorientierter Datenqualitätskennzahlen. St. Gallen, Universität St. Gallen, Institut für Wirtschaftsinformatik, 2010. – Arbeitsbericht. Bericht No. BE HSG/CC CDQ/13, Version 1. 0, 2010-10-31. Auf Anfrage von den Autoren verfügbar

Hüner, Kai M.: Führungssysteme und ausgewählte Maßnahmen zur Steuerung von Konzerndatenqualität, St. Gallen, Universität St. Gallen, Institut für Wirtschaftsinformatik, Dissertation, 2011

Hüner, Kai; Brauer, Berthold; Otto, Boris; Österle, Hubert: Fachliches Metadatenmanagement mit einem semantischen Wiki. In: HMD – Praxis der Wirtschaftsinformatik 48 (2011b), Nr. 277, S. 98–108

Hüner, Kai; Otto, Boris; Österle, Hubert: Collaborative management of business metadata. In: International Journal of Information Management 31 (2011c), Nr. 4, S. 366–373. – DOI 10.1016/j. ijinfomgt.2010.12.002

IMG: PROMET PM – Methodenhandbuch für das Projektmanagement. St. Gallen: Information Management Group, 1999

Lee, Yang W.; Strong, Diane M.; Kahn, Beverly K.; Wang, Richard Y.: AIMQ: A methodology for information quality assessment. In: Information & Management 40 (2002), S. 133–146. – DOI 10.1016/S03787206(02)000435

Legner, Christine: Benchmarking informationssystemgestützter Geschäftsprozesse. St. Gallen, Universität St. Gallen, Institut für Wirtschaftsinformatik, Dissertation, 1999

Ofner, Martin: Datenqualität aus Prozessperspektive: Methoden und Modelle. St. Gallen, Universität St. Gallen, Institut für Wirtschaftsinformatik, Dissertation, 2013

Ofner, Martin; Otto, Boris; Österle, Hubert: Integrating a data quality perspective into business process management. In: Business Process Management Journal 18 (2012), Nr. 6, S. 1036–1067. – DOI 10.1108/14637151211283401

Ofner, Martin; Otto, Boris; Österle, Hubert: A Maturity Model for Enterprise Data Quality Management. In: Enterprise Modelling and Information Systems Architectures 8 (2013a), Nr. 2, S. 4–24.– DOI 10.1007/s407860130002z

Ofner, Martin; Straub, Kevin; Otto, Boris; Österle, Hubert: Management of the Master Data Lifecycle: A Framework for Analysis. In: Journal of Enterprise Information Management 26 (2013b), Nr. 4, S. 472–491. – DOI 10.1108/JEIM-05-2013-0026

Osl, Philipp; Otto, Boris: Framework für die Nutzenargumentation des Produktinformationsmanagements. In: HMD – Praxis der Wirtschaftsinformatik 44 (2007), Nr. 258, S. 35–44

Otto, Boris; Hüner, Kai: Funktionsarchitektur für unternehmensweites Stammdatenmanagement. St. Gallen, Universität St. Gallen, Institut für Wirtschaftsinformatik, 2009. – Arbeitsbericht. Bericht- Nr BE HSG/CC CDQ 14. Version 1.0, 2009-05-31. Auf Anfrage von den Autoren verfügbar

Otto, Boris; Kokemüller, Jochen; Weisbecker, Anette; Gizanis, Dimitros: Stammdatenmanagement: Datenqualität für Geschäftsprozesse. In: HMD – Praxis der Wirtschaftsinformatik 48 (2011), Nr. 279, S. 5–16. – DOI 10.1007/BF03340582

Otto, Boris; Ofner, Martin: Strategic Business Requirements for Master Data Management Systems. In: Proceedings of the 17th Americas Conference on Information Systems (AMCIS) (2011-08- 04/04). Detroit, 2011. – Auch auf Slideshare und Research Gate verfügbar.

Otto, Boris: Quality Management of Corporate Data Assets. In: Praeg, C.P.; Spath, D. (Hrsg.): Quality Management for IT Services: Perspectives on Business and Process Performance. Hershey, PA: IGI Global, 2011b, S. 193–209. – DOI 10.4018/978-1-61692-889-6

Otto, Boris: A Morphology of the Organisation of Data Governance. In: Proceedings of the 19th European Conference on Information Systems (ECIS) (2011-06-09/11). Helsinki, 2011c. – Auch auf Slideshare und Research Gate verfügbar.

Otto, Boris; Folmer, Erwin; Ebner, Verena: A characteristics framework for Semantic Information Systems Standards. In: Information Systems and e-Business Management 10(2012), Nr. 4, S. 571–602. – DOI 10.1007/s10257-011-0183-3.

Otto, Boris: How to design the master data architecture: Findings from a case study at Bosch. In: International Journal of Information Management 32 (2012a), Nr. 4, S. 337–346. – DOI 10.1016/j.ijinfomgt.2011.11.018

Otto, Boris: Quality and Value of the Data Resource in Large Enterprises. In: Information Systems Management Journal 32 (2015), Nr. 3. – Zur Veröffentlichung angenommen

Pierce, Elizabeth; Dismute, Wendell S.; Yonke, C. Lwanga: The State of Information and Data Governance – Understanding How Organizations Govern Their Information and Data Assets. Little Rock: International Association for Information and Data Quality, 2008

Project Management Institute: A Guide to the Project Management Body of Knowledge: PMBOK Guide. Newton Square: Project Management Institute, 2013

Reichert, Andreas: Methode zur Einführung von Stammdaten-Management als betriebliche Unterstützungsfunktion. St. Gallen, Universität St. Gallen, Institut für Wirtschaftsinformatik, Dissertation, 2014

Rosemann, Michael; De Bruin, Tonia: Towards a Business Process Management Maturity Model. In: Bartmann, D., Rajola, F., Kallinikos, J., Avison, D., Winter, R., Ein-Dor, P. et al. (Hrsg.): Proceedings of the Thirteenth European Conference on Information Systems (ECIS 2005) (2005-05-26/28). Regensburg, 2005

Schemm, Jan: Stammdatenmanagement zwischen Handel und Konsumgüterindustrie: Referenzarchitektur für die überbetriebliche Datensynchronisation. St. Gallen, Universität St. Gallen, Institut für Wirtschaftsinformatik, Dissertation, 2008

Schmidt, Alexander: Entwicklung einer Methode zur Stammdatenintegration. St. Gallen, Universität St. Gallen, Institut für Wirtschaftsinformatik, Dissertation, 2010

VDI (Verein Deutscher Ingenieure): VDI Richtlinie 2884: Beschaffung, Betrieb und Instandhaltung von Produktionsmitteln unter Anwendung von Life Cycle Costing (LCC). Düsseldorf: VDI Verlag, 2005

Weber, Kristin: Data Governance-Referenzmodell: Organisatorische Gestaltung des unternehmensweiten Datenqualitätsmanagements. St. Gallen, Universität St. Gallen, Institut für Wirtschaftsinformatik, Dissertation, 2009

Weber, Kristin; Otto, Boris; Österle, Hubert: One Size Does Not Fit All – A Contingency Approach to Data Governance. In: ACM Journal of Data and Information Quality 1 (2009), Nr. 1, S. 4:1–4:27

Fußnoten

[1]

Eine vollständige Beschreibung der Methode ist in der Dissertationsschrift Falge (2015) zu finden.

[2]

Siehe http://www.corporate-data-excellence.ch/EFQM-Framework.pdf.

[3]

Siehe http://www.shop.efqm.org/publications/.

[4]

Siehe http://www.efqm.org.

[5]

Siehe http://www.corporate-data-excellence.ch.

[6]

Siehe https://www.corporate-data-league.ch.

[7]

Siehe https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ciq.

[8]

Siehe https://www.corporate-data-league.ch/meta/index.php/Main_Page.

[9]

Siehe http://www.omg.org/spec/SBVR/.

© Der/die Autor(en) 2016

Boris Otto

und Hubert ÖsterleCorporate Data Quality10.1007/978-3-662-46806-7_4

4. Erfolgsfaktoren und Sofortmaßnahmen

Boris Otto1   und Hubert Österle2

(1)

Fraunhofer Institut für Materialfluss und Logistik, Dortmund, Deutschland

(2)

Business Engineering Institute St. Gallen, St. Gallen, Schweiz

Boris Otto (Korrespondenzautor)

Email: boris.otto@iml.fraunhofer.de

Hubert Österle

Email: hubert.oesterle@bei-sg.ch

4.1 Erfolgsfaktoren des Datenqualitätsmanagements

4.2 Sofortmaßnahmen auf dem Weg zum erfolgreichen Datenqualitätsmanagement

Zusammenfassung

Kapitel 4 fasst die wesentlichen Erfolgsfaktoren des Stammdatenqualitätsmanagements zusammen und beschreibt in Checklistenform Sofortmaßnahmen, die unmittelbar nach Projektstart angegangen werden sollten. Sowohl Erfolgsfaktoren als auch Sofortmaßnahmen sollen einen schnellen Einstieg ins Thema gewährleisten und Projektleitern und Linienverantwortlichen erste Handlungsempfehlungen an die Hand geben.

4.1 Erfolgsfaktoren des Datenqualitätsmanagements

Die folgende Tab. 4.1 fasst den aktuellen Wissensstand zu Erfolgsfaktoren im Datenqualitätsmanagement aus Forschung und Praxis zusammen. Die Erfolgsfaktoren sind den sechs Bereichen des Frameworks für Datenqualitätsmanagement (siehe Kap. 1.4) zugeordnet.

Tab. 4.1
Erfolgsfaktoren des Datenqualitätsmanagements

DQM-Gestaltungsbereich

Erfolgsfaktoren

DQM-Strategie

• Die DQM-Strategie ist aus der Geschäftsstrategie abgeleitet

• Ein klares Mandat ist für das DQM erteilt

Führungssystem für DQM

• DQM-Ziele sind im Führungssystem des Unternehmens integriert

• Der Reifegrad des DQM wird kontinuierlich gemessen

• Datenqualität ist operationalisiert und über Datenqualitätskennzahlen messbar

Organisation des DQM

• Rollen und Verantwortlichkeiten für die Aufgaben im Datenqualitätsmanagement sind intern wie extern (z. B. beim Outsourcing) definiert

• DQM-Rollen werden so weit möglich von bestehenden Funktionsträgern übernommen (z. B. Prozessverantwortliche)

• Alle Mitarbeiter im Unternehmen verstehen die Bedeutung von Datenqualität

DQM-Prozesse und - Methoden

• Der gesamte Datenlebenszyklus von der Entstehung der Daten bis zur Archivierung oder Löschung ist transparent, dokumentiert und geführt

• Geschäftsregeln zur Sicherung der Datenqualität sind aus den Geschäftsprozessen abgeleitet

• First time right: Daten werden bei der Erfassung korrekt erfasst

DQM-Architektur

• Globale und lokale Daten sind definiert

• Für globale Daten ist eine Architektur für die Datenhaltung und -verteilung definiert und umgesetzt

DQM-Anwendungssysteme

• Anforderungen an Software-Systeme zur DQM-Unterstützung sind definiert und entsprechende Systeme sind im Einsatz

4.2 Sofortmaßnahmen auf dem Weg zum erfolgreichen Datenqualitätsmanagement

Aus den Fallstudien sowie aus den Arbeiten des CC CDQ seit 2006 lassen sich folgende Sofortmaßnahmen ableiten, die beim Aufbau des Datenqualitätsmanagements helfen:

- „Scoping“: Ausgehend von den strategischen Datennutzern im Unternehmen (Controlling, Compliance Office, Vertrieb etc.) identifizieren Sie unternehmensweit genutzte (globale), geschäftskritische Datenobjekte.

- „Trägerprojekt“: Nutzen Sie ein strategisches Projekt im Unternehmen, anhand dessen Sie den Nutzen des Stammdatenqualitätsmanagements kontinuierlich illustrieren können. Beispiele sind Projekte zur ERP-Konsolidierung, zur unternehmensweiten Geschäftsprozessharmonisierung, zur Integration von Unternehmenszukäufen und dem Aufbau spartenübergreifender Leistungsbündel („Systemgeschäft“). Derartige Trägerprojekte haben den Vorteil, dass sie viele Gruppen im Unternehmen adressieren, also beispielsweise die Geschäftsleitung, Projekt- und Abteilungsleiter sowie Sachbearbeiter in einzelnen Unternehmensfunktionen.

- Governance: Ohne Spielregeln können Sie die Datenqualität nicht dauerhaft verbessern. Identifizieren Sie also mögliche Data Owner und übertragen Sie Verantwortung für Datenklassen. Häufig sind geeignete Data Owner Geschäftsprozessverantwortliche mit dem höchsten Leidensdruck durch mangelhafte Qualität der entsprechenden Daten, also z. B. der Leiter des Zentraleinkaufs im Fall von Lieferantenstammdaten. Besetzen Sie anschließend das Data Governance Board mit den anderen Prozessverantwortlichen. Nutzen Sie zudem die bestehende Gremienlandschaft, um unnötige Bürokratie zu vermeiden.

- Datenqualitätsmessung: Leiten Sie Anforderungen an Datenqualität aus den Führungsgrößen der Geschäftsprozesse ab, indem Sie analysieren, welche Datenobjekte und welche Datenqualitätsdimensionen geschäftskritisch für die Geschäftsprozesse sind. Identifzieren Sie die Ursachen für Fehler und stellen Sie Geschäftsregeln auf, mit deren Hilfe Sie Datenqualität regelmäßig messen („ohne Messung kein Management“).

- Datenqualitätsziele: Setzen Sie Data Ownern betriebswirtschaftlich sinnvolle Datenqualitätsziele. Lassen Sie „Luft“ für zukünftige Verbesserungen.

- Haftbarkeit: Verankern Sie Datenqualitätsziele im Zielsystem von Data Ownern und Datenstewards, um persönlichen Bezug herzustellen. Befähigen Sie die Mitarbeiter, ihre Ziele zu erreichen, indem Sie geeignete Werkzeuge und Methoden bereitstellen.

- „DQ by design“: Entwerfen Sie Datenlebenszyklus und Datenarchitektur unter Datenqualitätsanforderungen. Nutzen Sie die Geschäftsregeln, um zu verhindern, dass Daten mangelnder Qualität in die Systeme eingegeben werden können („first time right“). Stellen Sie sicher, dass Geschäftsprozesse und Informationssysteme nicht gegen die Datenqualitätsregeln verstoßen.

- Nutzenbeitrag: Stellen Sie regelmäßig den Nutzwert des Stammdatenqualitätsmanagements in den verschiedenen Geschäftsprozessen und Unternehmensfunktionen dar. Nutzen Sie bewährte Kommunikationskanäle im Unternehmen (Intranet, Newsletter, Unternehmenszeitschrift etc.).

Open Access Dieses Kapitel wird unter der Creative Commons Namensnennung-Nicht kommerziell 4.0 International Lizenz (http://creativecommons.org/licenses/by-nc/4.0/deed.de) veröffentlicht, welche für nicht kommerzielle Zwecke die Nutzung, Vervielfältigung, Bearbeitung, Verbreitung und Wiedergabe in jeglichem Medium und Format erlaubt, sofern Sie den/die ursprünglichen Autor(en) und die Quelle ordnungsgemäß nennen, einen Link zur Creative Commons Lizenz beifügen und angegeben, ob Änderungen vorgenommen wurden.

Glossar

Begriff

Definition

Bestandsdaten

Eine Datenart, die Angaben über einen Lagerbestand gibt und eine hohe Änderungshäufigkeit aufweist

Bewegungsdaten

Eine Datenart, die Angaben über Aufträge, Lieferungen, Rechnungen, Zahlungen, etc. sammelt und eine hohe Änderungshäufigkeit aufweist. Änderungsdaten geben Aufschluss über Aktivitäten der Kerngeschäftsobjekte

Big Data

Datensätze, die so groß (Terabytes, Exabytes) und vielfältig (von Sensor- bis Social Media-Daten) sind, dass sie neue leistungsfähige Technologien zur Speicherung, Management, Analyse und Visualisierung benötigen

Business Engineering

Die methodenorientierte und modellbasierte Konstruktionslehre für Unternehmen des Informationszeitalters

CAD

Engl. „computer-aided design“: Rechnerunterstütztes Konstruieren, d. h. der Entwurf eines Produkts mit Hilfe von IT

Data Governance

Ein unternehmensweites Rahmenkonzept, das festlegt, welche Entscheidungen im Umgang mit Daten zu treffen sind und wer sie trifft. Darunter fällt die Definition von Rollen, Verantwortlichkeiten/Pflichten und Rechten im Umgang mit der Ressource Daten im Unternehmen

Data Governance verfolgt dabei das Ziel, den Wert der Daten im Unternehmen zu maximieren. Während Data Governance festlegt, wie Entscheidungen zu treffen sind, fällt das Datenmanagement solche Entscheidungen und setzt sie operativ um

Data Owner (Dateneigner)

Eine Rolle in der Data Governance -Organisation, die für bestimmte Datenobjekte verantwortlich ist (englisch „accountable“). Der Data Owner ist meist ein Vertreter des Managements eines Fachbereichs (z. B. Leiter Zentraleinkauf, Leiter Supply Chain Management).

Daten

Eine formalisierte, d. h. für die weiterführende Verarbeitung, Interpretation und Kommunikation geeignete, Repräsentation von Geschäftsobjekten oder Geschäftsvorfällen

Aus informationstechnischer Sicht werden verschiedene Datenaggregationsebenen unterschieden, beginnend mit dem Datenelement auf der untersten Stufe über das Datenobjekt, den Datensatz, Tabellen, Datenbanken, bis zum Unternehmensdatenbestand

Datenarchitektur

Definiert ein unternehmensweit einheitliches Modell der Konzerndaten (das Konzerndatenmodell ). Es beschreibt außerdem die Datenverteilungs- und Datenhaltungsarchitektur. Diese beschreiben, welche Daten in welchen Systemen gespeichert werden, welche Systeme „single source of truth“ für welche Datenobjekte bzw. -attribute sind, sowie die Datenflüsse zwischen den Systemen

Datenintegration

Die Zusammenführung von Daten verschiedener Datenquellen mit gleicher Bedeutung zu einem einheitlichen Datensatz. Diese Integration kann physisch erfolgen, z. B. in einem Data Warehouse, oder virtuell, d. h. die Daten verbleiben in den Quellsystemen, werden aber mit einer einheitlichen Sicht abgefragt.

Datenlebenszyklus

Die Entwicklung eines Datensatzes in den Unternehmens-IT-Systemen von der Anlage bis zur Löschung. Wird auch als „CRUD“ bezeichnet, eine Abkürzung für die Datenbankoperationen Create, Read/Retrieve, Update und Delete

Datenmanagement

Trifft Entscheidungen und führt Maßnahmen durch, die den unternehmensweiten Umgang mit Daten betreffen (während die Data Governance mit der Definition der Verantwortlichkeiten etc. den Rahmen dafür schafft).

Das Datenqualitätsmanagement von Stammdaten gehört zu den wichtigsten Teilaufgaben des Datenmanagements

Datenmodell

Stellt Datenobjekte und ihre Beziehungen zueinander dar. Datenmodelle bilden die Grundlage für eine Datenintegration auf konzeptioneller Ebene sowie die Verbesserung von Datenqualität , z. B. hinsichtlich Verringerung von Datenredundanz. Datenmodelle sind Bestandteil der Datenarchitektur

Datenobjekt

Repräsentiert aus Sicht des Datenmanagements ein Geschäftsobjekt eines Unternehmens. Mehrere Datenobjekte werden mit einem Datenmodell beschrieben

Gelegentlich wird auch zwischen Datenobjekttypen (den Klassen/Typen) und Datenobjekten (ihren Instanzen) unterschieden. Wir verzichten hier auf diese Unterscheidung und sprechen in beiden Fällen von Datenobjekten

Datenqualität

Ein Maß für die Eignung der Daten für bestimmte Anforderungen in Geschäftsprozessen, in denen sie verwendet werden. Datenqualität ist ein mehrdimensionales, kontextabhängiges Konzept, das nicht mit einem einzigen Merkmal, sondern anhand verschiedener Datenqualitätsdimensionen beschrieben und gemessen werden kann

Das angestrebte Level der Datenqualität richtet sich somit nach den Anforderungen in den Geschäftsprozessen und -funktionen, die diese Daten nutzen, z. B. dem Einkauf, Vertrieb oder dem Berichtswesen. Eine niedrige Datenqualität schmälert den Wert der Datengüter im Unternehmen, weil ihre Nutzbarkeit gering ist. Unternehmen sind bestrebt, mit dem DQM eine von der Geschäftsstrategie geforderte Datenqualität zu erreichen

Datenqualitätsdimensionen

Die wichtigsten Dimensionen, anhand derer Datenqualität beurteilt werden kann, sind:

• Korrektheit: Sachlich richtige Übereinstimmung der Daten mit den Eigenschaften des Objekts in der realen Welt, das sie repräsentieren sollen

• Konsistenz: Übereinstimmung mehrerer Datenversionen desselben realen Objekts, die z. B. in unter- schiedlichen Informationssystemen gehalten werden

• Vollständigkeit: Komplettes Vorhandensein aller notwendigen Werte/Attribute eines Datensatzes

• Aktualität: Übereinstimmung der Daten zu jeder Zeit mit dem aktuellen Status des realen Objekts und zeitgemäße Anpassung der Daten, sobald sich das reale Objekt ändert

• Verfügbarkeit: Zugänglichkeit der Daten für Datennutzer zum gewünschten Zeitpunkt

Datenqualitätskennzahl

Ein quantitatives Maß für Datenqualität . Ein Datenqualitäts-Messsystem misst Datenqualitätsmesswerte an Messpunkten mit einer bestimmten Messfrequenz. Datenqualitätskennzahlen operationalisieren Datenqualitätsdimensionen . Ein Beispiel ist die Überprüfung eines Datenelements anhand von Geschäftsregeln . Als englisches Synonym für „Kennzahl“ ist auch die Abkürzung „KPI“ (Key Performance Indicator) gebräuchlich

Datenqualitätsmanagement (DQM)

DQM, das qualitätsbewusste Management der Konzerndaten, ist eine Teilfunktion des Datenmanagements und analysiert, verbessert und sichert die Datenqualität im Unternehmen. Das DQM umfasst sämtliche Aktivitäten, Verfahren und Systeme, um die von der Geschäftsstrategie geforderte Datenqualität zu erreichen. Das DQM überträgt u. a. Qualitätsmanagementansätze für physische Güter auf immaterielle Güter wie Daten

Präventives DQM: Vorbeugende Vermeidung von Datendefekten mit negativer Auswirkung auf die Datenqualität

Reaktives DQM: Entdecken und Beheben von bestehenden Datendefekten

Datenqualitätsmessung

Die regelmäßige Überprüfung der Datenqualität der zentralen Datensätze im Rahmen von DQM . Zum Beispiel kann monatlich die Datenqualität der wichtigsten Attribute anhand definierter Geschäftsregeln gemessen werden. Ein Datensatz, der nicht alle Regeln erfüllt, gilt als defekt

Datenschutz

Schutz der Daten gegen unbefugte Zugriffe Dritter sowie Schutz von personenbezogenen Daten (z. B. Kundendaten) bei der Datenverarbeitung gemäß den geltenden gesetzlichen Bestimmungen

Datensteward

Eine Rolle in der Data Governance -Organisation, die für Entwicklung eines einheitlichen Datenmodells für die übergreifend verwendeten Geschäftsobjekte zuständig ist (englisch „responsible“). Der Datensteward ist zudem oft für den Aufbau des Stammdatenmanagements zuständig und stellt sicher, dass die Governance-Regeln eingehalten werden

Datentyp

In Programmiersprachen bezeichnen Datentypen die Arten und Wertebereiche von Objekten, z. B. Ganze Zahlen, Kommazahlen, Zeichenketten etc.

Im Kontext der Digitalisierung und Big Data werden als verschiedene Datentypen auch strukturierte und unstrukturierte Daten unterschieden: Strukturierte Daten bezeichnen Daten, die in Datenmodellen definiert sowie in den relationalen Datenbanken eines Unternehmens abgelegt und damit leicht zugänglich und interpretierbar sind. Unstrukturierte Daten sind dagegen schwer zugängliche und interpretierbare Daten wie Textdateien oder Bilder

Digitale Services

Dienstleistungen aller Art für Konsumenten (und Unternehmen), bei denen die Informationstechnologie eine zentrale Rolle spielt, z. B. bei der Leistungserbringung oder der -abrechnung.

Digitalisierung

Megatrend des 21. Jahrhunderts, bei dem neue Formen der Informationstechnologie alle Bereiche von Wirtschaft und Gesellschaft verändern. Die Durchdringung aller Lebensbereiche mit IT äußert sich z. B. in Entwicklungen wie neuen digitalen Geschäftsmodellen, der Industrie 4.0, oder der Konsumerisierung

First time right

Ein Prinzip des präventiven Datenqualitätsmanagements , gemäß welchem Daten möglichst bei erstmaligem Erfassen in einem Informationssystem korrekt sein sollten, um nicht (zu meist höherem Aufwand) nachträglich bereinigt werden zu müssen

Geschäftsregel (Business Rule)

Eine Regel, die Ausführung und die Leistung von Geschäftsprozessen definiert und beschränkt, um die Prozessausführung und sein Ergebnis in gewünschter Weise sicher zu stellen. Geschäftsregeln formalisieren damit die Richtlinien (engl. business policies) im Unternehmen. Sie können in einer formalisierten Beschreibung in IT-Systemen verwendet werden

GTIN (Global Trade Item Number)

Eine Identifikationsnummer, mit der Artikel weltweit eindeutig identifiziert werden können. Die Nummer wird von der GS 1 (Global Standards One), einer weltweiter Organisation zur Vereinheitlichung von Standards, vergeben und verwaltet

Industrie 4.0

Die vierte industrielle Revolution im 21. Jahrhundert, in der die physische mit der virtuellen Welt verschmilzt („cyber-physische Systeme“). Maschinen und Produkte werden internetfähig („Internet der Dinge“) und damit die Daten, die bislang nur in der Fabrik verfügbar waren, dem gesamten Unternehmen und seinen Geschäftspartnern zugänglich. Daten werden ohne Zeitverzug, ohne menschliches Zutun und viel detaillierter und exakter als zuvor erfasst

Informationen

Eine Sichtweise fasst Informationen als zweckbezogenes Wissen auf, das während der menschlichen Kommunikation ausgetauscht wird, während eine zweite Sichtweise eine reine Informationsverarbeitungsperspektive einnimmt, in der Daten die Bausteine von Information sind. Demnach werden Daten zu Informationen „verarbeitet“.

Kerngeschäftsobjekt

Die zentralen Akteure (Geschäftspartner, Kunden, Lieferanten, Mitarbeiter), Produkte (inkl. Materialien) und Betriebsmittel (Anlagen etc.) eines Unternehmens. Diese sind informationstechnisch als Stammdaten repräsentiert

Kerngeschäftsobjektmodell

Modell der wichtigsten Kerngeschäftsobjekte und ihrer Beziehung zueinander. Für die informationstechnische Umsetzung wird das Kerngeschäftsobjektmodell in ein Konzerndatenmodell überführt. Das Kerngeschäftsobjektmodell ist ein zentrales Ergebnis des Datenqualitätsmanagements , weil es die Voraussetzung für ein unternehmensweit einheitliches Verständnis der Daten und damit auch für die intendierte Nutzung der Daten ist

Konsortialforschung

Eine Methode zur Zusammenarbeit von Forschung und Praxis in der gestaltungsorientierten Wirtschaftsinformatikforschung. Dabei arbeiten Forscher mit mehreren Partnerunternehmen an einem Thema von gemeinsamem Interesse. Die Forschungsergebnisse sind „Artefakte“ (z. B. Methoden oder Modelle), die zur Lösung praktischer Probleme beitragen

Konsumentenzentrierung

Konsumentenzentrierung ist ein Prinzip des Business Engineerings , gemäß dem neue oder verbesserte Geschäftslösungen ausgehend von den Bedürfnissen des Konsumenten (out-side-in) entwickelt werden. Gestaltungsziel ist im Business Engineering im Wesentlichen der Unternehmenswert. Die Unternehmen richten ihre Prozesse, Führungssysteme usw. an den Konsumenten aus

Ausdruck dieses Prinzips sind z. B. kundenindividuelle Massenproduktion (mass customization), also Individualisierung von Produkten und Dienstleistungen nach individuellem Geschmack hinsichtlich Funktionen und Design, die Mitgestaltung von Produkten durch Kunden und Konsumenten, z. B. über Feedback- und Produktenwicklungsplattformen von Unternehmen (co-creation/crowdsourcing) und die Beeinflussung der öffentlichen Meinung von Produkten und Unternehmen durch den Konsumenten über Social Media (z. B. Foodwatch.org).

Konsumerisierung

Mit Konsumerisierung bezeichnen wir die Bereitstellung von digitalen Geräten und Services für alle Lebensbereiche von Konsumenten. Gestaltungsziel ist die Lebensqualität der Menschen im Sinne eines Life Engineering . Zur Lebensqualität gehören neben der Befriedigung der Grundbedürfnisse wie Essen und Trinken oder Gesundheit auch Bedürfnisse wie Anerkennung in der Bezugsgruppe

Die Konsumerisierung ist der Ausgangspunkt für die Konsumentenzentrierung . In vielen Fällen geht es aber nicht um die bessere Ausrichtung vorhandener Produkte und Dienstleistungen auf die Konsumenten, sondern um neue Konsumentenlösungen wie soziale Netzwerke, digitale Spiele oder die persönliche Finanzverwaltung

Konzerndaten

Sogenannte „globale“ Stammdaten , die für das gesamte Unternehmen gelten. Im Gegensatz dazu gelten „lokale“ Stammdaten nur für einen Geschäftsbereich, einen Standort oder eine Unternehmensfunktion

Konzerndatenmodell

Ein Datenmodell auf Unternehmensebene für die Kerngeschäftsobjekte und ihre Beziehung zueinander. Basiert auf dem Kerngeschäftsobjektmodell

Life Engineering

Eine neue Forschungsdisziplin zusätzlich zum Business Engineering , das sich mit der Lebensqualität, den Bedürfnissen der Konsumenten und den Möglichkeiten zu deren Befriedigung sowie dem Beitrag digitaler Services beschäftigt

Metadaten

Daten über Daten, z. B. Definitionen, Wertelisten, Zugriffsberechtigungen

Referenzdaten

Konzerndaten , die extern definiert sind und über Unternehmensgrenzen hinweg einheitlich verwendet werden, z. B. Länder- und Währungscodes sowie Geodaten

Six Sigma

Ein Ansatz aus dem Qualitätsmanagement im Produktionsumfeld, der als Leistungsziel nur 3,4 Fehler pro eine Million Instanzen vorsieht

Staging Area

Ein Daten-Bereitstellungsraum, in dem Daten zur Qualitätsprüfung und -bereinigung zwischengespeichert werden, bevor sie in die Zieldatenbank geladen werden. Die Staging Area bietet damit technische Unterstützung für das „ first time right “ – Prinzip im Datenmanagement

Stammdaten

Informationsobjekte, die Kerngeschäftsobjekte (Kunden, Lieferanten, Produkte, etc.) repräsentieren und somit unabhängig und fundamental für eine Organisation sind. Stammdaten müssen referenziert werden, um Transaktionen durchführen zu können. Sie verändern sich im Gegensatz zu Bewegungs - oder Bestandsdaten vergleichsweise selten

Diese Daten müssen innerhalb eines Unternehmens über mehrere Organisationseinheiten hinweg eindeutig identifiziert und einheitlich interpretiert werden sowie in hinreichender Datenqualität vorliegen, um erfolgreiche Geschäftsprozesse und ein vertrauenswürdiges Berichtswesen zu gewährleisten. Dies ist die Aufgabe des Stammdatenmanagements

Stammdaten(klassen)attribute

Die Charakteristika, die einen Stammdatensatz beschreiben, z. B. Name, Rechtsform und Adresse eines Lieferanten. Unternehmen müssen festlegen, welche Attribute einer Stammdatenklasse von einem zentralen Stammdatenmanagement verwaltet werden und welche in der lokalen Verantwortung von Organisationseinheiten liegen sollen. Dies richtet sich z. B. nach der unternehmensweiten Verwendung der Attribute sowie nach Kosten-/Nutzen-Einschätzungen

Stammdatenklasse

Gruppiert Stammdaten der gleichen Kategorie oder Art, z. B. Kundendaten oder Lieferantendaten

Stammdatenmanagement

Alle Aktivitäten, Methoden und (IT-)Werkzeuge zur Modellierung, Verwaltung, Bereitstellung sowie zum Datenqualitätsmanagement von Stammdaten . Das Ziel ist, eine unternehmensweit einheitliche Wahrheit über die Kerngeschäftsobjekte bereit- und sicherzustellen („single source of truth“) und damit Datennutzer in diversen Geschäftsprozessen im gesamten Unternehmen zu unterstützen

TCO (Total Cost of Ownership)

TCO (dt.: Gesamtbetriebskosten) ist ein Abrechnungsverfahren, das zum Ziel hat, neben den Anschaffungskosten von Produkten auch alle weiteren Kosten zu berücksichtigen, die im Laufe der Betriebslaufzeit anfallen

TQM (Total Quality Management)

Ein ganzheitlicher Ansatz zum Qualitätsmanagement aus dem Produktionsumfeld, der zeigt, dass die Summe der Kosten aller reaktiven Maßnahmen im Qualitätsmanagement die Kosten eines präventiven Qualitätsmanagement übersteigt. Das gilt für materielle wie für immaterielle Güter wie z. B. Daten

Sachverzeichnis

A

Ausgangssituation

Auslagerung von Daten

B

Bestandsdaten

Bewegungsdaten

Big Data

Business Engineering

Business Rule siehe Geschäftsregel

C

CAD (Computer-aided Design)

D

Data Governance

Einführung

Versicherungswirtschaft

Data Owner (Dateneigner)

Daten

Auslagerung

Definition

Information

Mängel, kritische

strukturierte

Umgang

unstrukturierte

Datenarchitektur

Management

zentrale, Limitation

Datenarchitekturmanagement, diversifizierter

Technologiekonzern

Datenintegration

Datenlebenszyklus

Datenmanagement

Anforderungen

Ausgangssituation

Auslagerung

Bestandteile

Dezentralisierung

Handlungsdruck

Herausforderungen

kooperatives

Produktlebenszyklus

qualitätsorientiertes

Datenmanagementkompetenz

Datenmodell

relationales

Datenobjekt

Attribute

geschäftskritisches

Instanziierung

Datenqualität

Treiber

Datenqualitätscontrolling, agrochemische

Industrie

Datenqualitätsdimensionen

geschäftskritische

Datenqualitätskennzahl

Datenqualitätsmanagement

Anforderungen

Ausgangssituation

Benchmarking-Plattform

DMAIC-Zyklus

Erfolgsfaktoren

Herausforderungen

Methode

Reifegrad-Assessment

Treiber

Versicherungswirtschaft

Datenqualitätsmessung

Akzeptanz

fehlende

Datenschutz

Anforderungen

gesetzliche Regelung

Datensteward

Datentyp

Digitale Services

Digitalisierung

Trends

DMAIC-Zyklus

DQM siehe Datenqualitätsmanagement

E

EFQM-Exzellenzmodell

F

Finanzstammdaten

First time right-Prinzip

G

Geoinformation

Geschäftsregel

Ableitung aus Datenqualitätsproblem

Datenqualitätsmessung

Definition

Eigenschaften

kritische

Management

Messbarkeit

signifikante

Validierung

Versicherungswirtschaft

Global Trade Item Number siehe GTIN

GTIN (Global Trade Item Number)

fehlende

Mangel

I

Industrie 4.0

Information

Informationsfluss

Informationsobjekt

Informationsquelle

Informationssicherheit

Informationssystem

Informationstechnik

K

Kerngeschäftsobjekt

Kerngeschäftsobjektmodell

Konsortialforschung

Konsumentenzentrierung

Konsumerisierung

Konzerndaten

Einheitlichkeit

Management

Konzerndatenmodell

Konzerndatenqualität

Kundeninformation

Kundenstammdaten

L

Lieferantenstammdaten

Life Engineering

Lokationsinformation

M

Materialstammdaten

Metadaten

Definition

Management

Mitarbeiterstammdaten

P

Produktdatenmanagement

Automatisierungsindustrie

Produktdatenqualität, Konsumgüter-Supply

Chain

Produktinformation

Netzwerkanalyse

Produktlebenszyklus, Datenmanagement

Produktstammdaten

R

Referenzdaten

Referenzdaten-Repository

S

Six Sigma

Staging Area

Stammdaten

Stammdatenattribute

Stammdatenklasse

Stammdaten-Koordinator

Stammdatenmanagement

Design

Konsumgüterindustrie

Organisationsstruktur

Spezialchemiehersteller

Stammdatenmanagementinitiative

Stammdatenobjekt

Stammdatenorganisation

Stammdatenqualität

Stammdatenqualitätsmanagement

EFQM-Exzellenzmodell

Erfolgsfaktoren

Trägerprojekt

Stammdatentransformationsprojekt

Steuerungsinformation

T

TCO (Total Cost of Ownership)

Total Cost of Ownership siehe TCO

Total Quality Management siehe TQM

TQM (Total Quality Management)

V

Vertriebsinformation