Fallstudien zur Datenqualität

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

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¹. 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

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²: 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

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³ 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⁴.

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

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⁵. 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 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)⁶ 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

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⁷. 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

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

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

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⁸. 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

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)

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)

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

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⁹. 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

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¹⁰ 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

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

• 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

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¹¹ 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)¹².

• 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

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¹³. 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

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“¹⁴ 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

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¹⁵. 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)¹⁶.

Tab. 2.21 Kurzprofil Johnson & Johnson

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)¹⁷ 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®¹⁸-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¹⁹.

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

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

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

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

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

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

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²⁰. 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

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

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²¹ 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

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