2. Fallstudien zur Datenqualität

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

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

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.

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:

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:

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

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.

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

Abbildung 2.2 zeigt das Zusammenspiel dieser Rollen.

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

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.

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:

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

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.

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.

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

Die wichtigsten Erkenntnisse des Projekts waren:

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

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.

Bayer CropScience ist in zwei operative Geschäftsbereiche gegliedert:

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

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

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

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.

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

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.

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.

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:

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.

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.

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

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.

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.

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

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.

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.

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.

Die wichtigsten Erkenntnisse des Projekts waren:

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

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

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

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.

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.

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

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

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

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.

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:

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.

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.

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.

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:

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

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). Diese Geschäftsbereiche umfassen insgesamt 16 Divisionen, die in mehr als hundert Ländern auf der Welt aktiv sind (siehe Abb. 2.17).

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:

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

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.

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

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:

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.

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.

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

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.

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

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.

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:

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.

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

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

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.

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

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.

Die Unternehmensstrategie ist geprägt durch folgende Unternehmensziele:

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

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

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.

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

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.

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.

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

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

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.

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

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.

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

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

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

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

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.

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

Abschließend waren die wichtigsten Erkenntnisse des Projekts:

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

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

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.

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.

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:

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:

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.

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:

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.

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.

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.

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.

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.

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:

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

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

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

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.

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.

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.

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.

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.

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.

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

Die Funktionen der einzelnen Systeme und die von ihnen erzeugten Berichte sollen im Folgenden kurz beschrieben werden:

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.

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.

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.

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.

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:

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

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

Diese Fallstudie zeigt, dass Stammdatenmanagement und hohe Datenqualität eine notwendige Grundlage für Business Intelligence (BI)-Projekte mit aktueller Informationstechnologie sind.

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:

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

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.

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.

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.

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.

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:

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.

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:

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.

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.

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.

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.

Zusammengefasst waren die wichtigsten Erkenntnisse bei Lanxess:

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

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

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.

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:

Eine Ursache-Wirkungs-Analyse zeigte zudem, dass die verschiedenen Probleme im PLM-Prozess voneinander abhängig waren (Abb. 2.47).

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.

Zum Re-engineering seines PLM-Prozesses nutzte Shell „Lean Six Sigma“-Methoden. Über einen Zeitraum von zwei Jahren wurden sechs Projekte durchgeführt:

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.

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

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

Abbildung 2.49 illustriert ausgewählte Nutzensteigerungen.

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.

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

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

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.

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.

In der Vorbereitungsphase des Programms führte Syngenta für den Bereich Stammdatenmanagement eine Untersuchung durch, die folgende Probleme aufdeckte (Bauer 2009):

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:

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:

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.

Syngenta veranschlagte für das gesamte Transformationsprojekt einen Zeitrahmen von drei Jahren. Abbildung 2.51 zeigt die drei Hauptphasen des Projekts.

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:

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

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.

Unter Berücksichtigung der oben genannten Designprinzipien definierte Syngenta sechs neue Rollen für die neue MDM-Organisation:

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.

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.

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:

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

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:

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.

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.

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.

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:

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