Einführung von Master Data Management auf Basis eines Architekturmodells

Transkript

1 Einführung von Master Data Management auf Basis eines Architekturmodells als Masterarbeit an der Wirtschafts- und Sozialwissenschaftlichen Fakultät der Universität Bern eingereicht bei Prof. Dr. Gerhard Knolmayer Institut für Wirtschaftsinformatik von Rentsch, Adrian Peter von Trub i. E. (BE) im 13. Semester Matrikelnummer: Studienadresse: Waldheimstrasse Bern (Tel ) ( Bern,

2 Zusammenfassung Master Data Management (MDM) ist ein umfassendes Daten-Steuerungskonzept aus Organisations-, Prozess- und Technologiekomponenten. Es umschreibt die Entflechtung einzelner Datensilos durch Anpassungen in der Organisation und der Informationsarchitektur. Dem zugrunde liegt die Vision des freien Datenflusses zwischen den Systemen in Echtzeit. Die vorliegende Arbeit befasst sich mit der Einführung von MDM in bestehende Unternehmenslandschaften. Es zeigt sich, dass die Begrifflichkeiten rund um MDM nur schwer voneinander abgrenzbar sind. MDM steht als Steuerungsinstrument zur Sicherung der Datenqualität über die evolutionäre Integration der Informationsverarbeitung im Spannungsfeld verwandter Managementkonzepte wie Metadatenmanagement, Stammdatenmanagement oder Data Warehousing. Gestützt auf die erarbeitete Systemarchitektur vermittelt das Referenz-Vorgehensmodell zur Einführung von MDM eine Idee, was bei einem solchen Entwicklungsprozess zu beachten ist. Auch wenn eine Gegenprüfung der Ergebnisse aus Sicht der Praxis fehlt, unterstreicht die Arbeit einen wichtigen Aspekt: Umfassende IT-Projekte bedürfen einer abgestimmten Zusammenarbeit zwischen dem Geschäftsbereich und der technischen Abteilung.

3 Management Summary Master data management (MDM) is a comprehensive concept of data management including components from re-organisation, process engineering and specific technology tools. It describes the process of deconcentrating single data stores by adapting the operational and organizational structure within a business environment to its new IT architecure. The basic vision and ambition of these reengineering tasks is to achieve free data flow among systems in real-time. The exposition at hand pays attention to the implementation process of master data management. The conceptual part of the exposition proofs that exclusive and exhaustive definitions of relevant terms relating to MDM pose a serious scientific challenge. MDM as a management instrument to ensure data quality through an evolutionary information integration process is challenged to other management concepts like meta data management, the related german term Stammdatenmanagement or data warehousing. The reference procedure model provides a view on the development process of a MDM system based on the own-built system architecture. Although these findings are not evaluated and tested in an existing business environment, there is an important aspect to mention: Broad IT projects require a well-coordinated alignment between business and IT strategies or activites.

4 Inhaltsverzeichnis I Inhaltsverzeichnis Inhaltsverzeichnis I 1 EINLEITUNG Ausgangslage Problemstellung Abgrenzung des Forschungsgegenstandes Stand der Forschung Zielsetzung der Arbeit Methodisches Vorgehen Aufbau der Arbeit 11 2 GRUNDLAGEN VON MASTER DATA MANAGEMENT Begriffsklärung Arten von Daten Sicherung der Datenqualität Rolle der Datenintegration Master Data Management als Methode Abgrenzung von verwandten Konzepten Beweggründe Geschäftsseite als Haupttreiber Nutzenpotenziale Gefahren und Herausforderungen Zu starke Fokussierung auf die Technologie Kein inkrementeller Ansatz bei der Einführung von MDM Fehlendes Data Governance Programm Irrglauben der problemlosen Konsensfindung Unstrukturierte Auswahl der Architektur Ignorieren von Datenqualitäts- und Metadatenmanagement Master Data Management als Silver Bullet 49

5 Inhaltsverzeichnis II 2.4 Anwendungsfelder Customer Data Integration Identity Management 54 3 ENTWICKLUNG EINER SYSTEMARCHITEKTUR VON MASTER DATA MANAGEMENT Wichtigste Komponenten Datenmodellierung Data Governance Datenintegration Architekturansätze Ordnungsrahmen der Systemarchitektur Struktur Vorgehen Eigene Systemarchitektur Generischer Aufbau: Grundarchitektur Vorgaben auf Unternehmensebene Rahmenbedingungen aus dem Datenmanagement MDM-Kern: Entwicklungsstufen der Integration MDM-Kern: Weitere Elemente Gesamtarchitektur 92 4 ENTWICKLUNG EINES VORGEHENSMODELLS FÜR MASTER DATA MANAGEMENT Referenzmodellierung Anforderungen an die Einführung von Master Data Management Vorgehensvorschläge aus der Literatur Kritische Erfolgsfaktoren Eigenes Vorgehensmodell Generischer Aufbau: Modellrahmen Change Management: Einführung als Strukturwandel Projektmanagement: Steuerung der Einführung Datenmanagement: Rahmenbedingungen Zusammenspiel zwischen Datenintegration und BPR 107

6 Inhaltsverzeichnis III MDM Initiative: Ablauf einer Einführung Komplettes Vorgehensmodell ZUSAMMENFASSUNG UND AUSBLICK 115 Abbildungsverzeichnis 117 Tabellenverzeichnis 119 Abkürzungsverzeichnis 120 Literaturverzeichnis 125 Selbstständigkeitserklärung 141 Veröffentlichung der Arbeit 142

7 Kapitel 1: Einleitung 1 1 Einleitung Master Data Management (MDM) als junger Denkansatz zur datengestützten Steuerung der Kerngeschäfte eines Unternehmens umschreibt die Entflechtung der einzelnen Datensilos durch Anpassungen in der Organisation (Ablauf- und Aufbauorganisation) und der Informationsarchitektur. Es entsteht die Vision des freien Datenflusses zwischen den Systemen in Echtzeit. 1 Technologisch geht diese Vision einher mit dem generellen Trend zur Zentralisierung der Informationstechnik (IT). 2 MDM wird von den technischen Fachleuten als Erweiterung bestandener Techniken wie Data Warehousing (DWH), Business Intelligence (BI), Datenqualitätsmanagement (DQM) oder Metadatenmanagement angesehen. Die Bestrebung nach Integration der Systeme und Daten ist also nicht neu. Durch Einführung rechtlich vorgeschriebener Kontrollprozesse (z. B. Sarbanes-Oxley Act SOX) sind die Unternehmen jedoch vermehrt gezwungen, den strategischen Fokus zu öffnen und eine integrierte Sicht auf ihre Tätigkeiten einzunehmen. MDM als ganzheitliches Konzept aus Organisations-, Prozess- und Technologiekomponenten kann hierbei unterstützen. 3 Die vorliegende Masterarbeit beschäftigt sich nun eingehend mit MDM. Die folgenden Kapitel umrahmen und positionieren die thematischen Schwerpunkte sowie das methodische Vorgehen. 1.1 Ausgangslage Die vom Beratungsunternehmen Information Meta Group IMG (Schweiz) AG in ihrem Methodenhandbuch für den Entwurf von Geschäftsprozessen beschriebenen Entwicklungen in der Betriebswirtschaft haben heute durchaus noch ihre Gültigkeit. Kurze Produktlebenszyklen, komplexe Technologien und die hohen Qualitätsanforderungen an Produkte und Dienstleistungen bedeuten nach wie vor grosse Herausforderungen für die Unternehmen in ihrer Leistungserstellung. 4 Merkmale dieser Entwicklung im heutigen Umfeld sind z. B. Produktinnovationen, dynamische Kun Vgl. Wadehra (2007). Vgl. Russom (2006). Vgl. Radha (2007). Vgl. IMG (1997), S. 8 ff.

8 Kapitel 1: Einleitung 2 denbeziehungen oder der stetige Wandel von organisatorischen Strukturen. 5 Folgen daraus sind die Neukomposition ganzer Wertschöpfungsketten und IT-Landschaften sowie die nötig werdenden Anpassungen in der Integrationsarchitektur. Eine zentrale Rolle spielen dabei die Entscheidungen im Bereich Datenintegration. Einheitlich definierte Stammdaten als Grundstock der Geschäftstätigkeit ermöglichen bspw. erst ganzheitliche Analysen und Planungen innerhalb des Unternehmens oder entlang der Wertschöpfungskette. 6 Unternehmensgrenzen werden dabei nicht selten verwischt. Dem zeitnahen Austausch von Informationen über die Grenzen hinweg fällt so eine nicht zu vernachlässigende Bedeutung zu. 7 Was aber sind die strategischen Gründe für die Neugestaltung ganzer Geschäftsprozesse? Österle 2006 nennt in einem Vortrag einige Geschäftsmodelle der nahen Zukunft, welche v. a. die Komplexität der Leistungserstellung erhöhen. 8 Am interessantesten sind hier im Kontext von MDM die Fusions- und Übernahmegeschäfte. Durch den Zusammenschluss mindestens zweier Unternehmen oder durch die Einverleibung von Konkurrenten entstehen u. a. in der Systemlandschaft neue Rahmenbedingungen wie z. B. unterschiedliche Architekturstandards oder verschiedene Datendefinitionen. Weiter hat sich typischerweise die Informationsvielfalt durch die Vielzahl neuer, nicht integrierter Quellsysteme schlagartig erhöht. 9 Für das erfolgreiche Weiterbestehen des Unternehmens ist es wichtig, die Übersicht über die oft inkonsistente Datenflut nicht zu verlieren. Dazu müssen gezwungenermassen bestehende Beziehungen zwischen Entitäten 10 überdacht und ergänzt sowie im radikalen Fall die vorhandenen (Geschäfts-) Prozesse aufgebrochen und neu zusammengestellt werden. Kurzfristig sind gemäss Ansicht des Verfassers inkonsistente Kundendaten noch verkraftbar. Anders sieht es aus, wenn es dem Management nicht mehr möglich ist, sich ein Bild über die finanziellen Angelegenheiten im Unternehmen machen zu können. 11 Rechtzeitig verfügbare, konsistente und korrekte Finanzzahlen sind bei der strategi Vgl. Waddington (2004), S. 5. Vgl. Gehrmann (2008). Vgl. Gokhale (2007), S. 14. Vgl. Österle (2006), F. 10. Vgl. Teachey (2007). Zum Begriff der Entität siehe Chen (1976), S. 10: An entity is a thing which can be distinctly identified. A specific person, company, or event is an example of an entity. Vgl. Griffin (2005a), S. 54.

9 Kapitel 1: Einleitung 3 schen Ausrichtung und der Steuerung eines Unternehmens unabdingbar, v. a. wenn es sich in einem strukturellen Wandel befindet. Zusammengefasst geht es also hauptsächlich um die Frage der Datenqualität. Eine tiefe Datenqualität beeinträchtigt die Geschäftstätigkeit im Unternehmen und über die Unternehmensgrenzen hinweg. Probleme treten dann auf, wenn Finanzberichte nicht mehr rechtzeitig verfügbar oder Kundendaten betroffen sind. Dadurch werden diverse Nutzenpotenziale nicht erschlossen. Der Ablauf der Geschäftsprozesse wird beeinträchtigt, indem Verträge nicht eingehalten werden können und die Zufriedenheit der Kunden sinkt. Unkoordinierte und redundant ausgeführte Prozesse bringen unnötige Zusatzkosten. 12 MDM als prozessorientiertes und von der Geschäftsseite getriebenes Konzept unterstützt das Unternehmen dabei, diese Probleme bewusst anzupacken. Dies geschieht hauptsächlich durch das Einnehmen einer integrierten Sichtweise auf die eigenen Hauptdaten ( master data ), wobei deren Steuerung in einem Data Warehouse (analytisch-orientiert), im operationalen Umfeld (operational-orientiert) oder in einer separaten MDM-Umgebung (unternehmensweit) möglich ist. 13 Tatsache ist, dass viele Unternehmen seit einigen Jahren mit dem Gedanken spielen, MDM einzuführen bzw. ein MDM-System bereits installiert haben Problemstellung In einer sehr euphorischen Stimmung verspricht sich gemäss Ansicht des Verfassers die Literatur von MDM zu oft die Heillösung verschiedenster betriebswirtschaftlicher Probleme und Herausforderungen. 15 Die Abgrenzung des Forschungsgebietes gestaltet sich als schwierig, was die thematisch vielfältigen Beiträge zu MDM erklären kann. Diese Aussage wird bspw. durch die Liste von 15 möglichen Themenfeldern mit integrationswürdigem Charakter von McKnight 2006 gestützt Vgl. Otto/Silbermann (2007). Vgl. McKnight (2006), S. 13. Vgl. hierzu diverse im Literaturverzeichnis aufgeführte Beiträge und Artikel. Vgl. Sherman (2007b). Vgl. McKnight (2006), S. 13 f.

10 Kapitel 1: Einleitung 4 Das Bedürfnis nach einheitlichen Lösungen bei Integrationsbemühungen ist durchaus verständlich, stellen doch einige Autoren fest, dass Daten immer mehr zu einem wichtigen Vermögenswert innerhalb des Unternehmens werden. Und wichtige Vermögenswerte müssen strategisch erfasst und aktiv gesteuert werden. Dies war bisher nicht immer der Fall. 17 Eine aktive Steuerung z. B. bei Zusammenschlüssen oder Übernahmen setzt voraus, dass die Evolution der Entitäten und ihrer Beziehungen ersichtlich ist, um ein präzises Bild von der Datenumgebung zu erhalten. Bisherige Lösungen wie ein Data Warehouse (DW) oder Operational Data Stores (ODS) sind dazu nicht in der Lage. 18 Diese Lücke sollen die Ideen von MDM schliessen, die, wie andere Konzepte auch, im Unternehmen als (Gross-) Projekt eingeführt werden (z. B. Enterprise Ressource Planning ERP, Customer Relationship Management CRM). 19 Aufgrund der bisherigen Überlegungen zum Thema MDM sind folgende Fragestellungen bei der Ausarbeitung der vorliegenden Masterarbeit von Interesse: Was wird zurzeit unter dem Begriff MDM gemeinhin in der Literatur verstanden und wie grenzt er sich zu verwandten Konzepten ab? Welche konkreten Anwendungsfelder von MDM sind in der Praxis denkbar? Mit welchen Funktionalitäten/Komponenten von MDM wird gearbeitet? Wie lassen sich diese Komponenten in einer Systemarchitektur darstellen? Wie sehen die bisherigen Vorgehensvorschläge bei der Einführung von MDM aus? Wie lassen sich die Vorgehensvorschläge zu einem Referenz-Vorgehensmodell zusammenfügen? Vgl. Fleckenstein (2007a), S. 1, Griffin (2006a), Newman (2005), S. 2, Wise (2008). Vgl. Fleckenstein (2007b), S. 8. Vgl. Kapitel 4.

11 Kapitel 1: Einleitung Abgrenzung des Forschungsgegenstandes Um die Vielschichtigkeit des Begriffs erfassen zu können, sind die Untersuchungen zu MDM breit angelegt. Die Vorstellung, dass die evolutionären Geschäftsanforderungen im Datenmanagementbereich hauptsächlich über den Umgang und die Definition von sog. Masterdaten erfüllt werden können 20, ist sicherlich nicht ganz unschuldig an dieser Vielschichtigkeit. Diese breite Auslegung des Untersuchungsgegenstandes erlaubt für die vorliegende Arbeit ausserhalb der zentralen Begrifflichkeiten keine vertiefte Auseinandersetzung. Die hier vorgestellten Ergebnisse 21 verkörpern deshalb vielmehr eine Metasicht auf das Themengebiet. In einer wissenschaftlichen Diskussion lässt sich MDM in das Themengebiet des Informationsmanagements (IM) einordnen. Krcmar 2005 hat die Besonderheiten des IM in einem Referenzmodell festgehalten. Dieses Modell unterteilt IM in vier Hauptbereiche: Führungsaufgaben, Informationswirtschaft, Informationssysteme und Informations-/Kommunikationstechnik. 22 Die vorliegende Arbeit behandelt nun MDM aus der Sicht vom Management der Informationssysteme. Dabei geht es um Fragen der Abstimmung organisatorischer und technischer Elemente von MDM, von dessen Einführung (als Informationssystem) man sich eine effektivere und effizientere Befriedigung des vorhandenen Informationsbedarfs in den einzelnen Unternehmensbereichen verspricht, z. B. durch Datenintegration. Der Fokus liegt auf dem Zusammenspiel von Daten und Prozessen und im Rahmen der Vorgehensmodellentwicklung auf dem Management von Anwendungsentwicklungsprojekten. 23 Auf technische Fragen aus dem Management der Informations-/Kommunikationstechnik wird nur punktuell eingegangen (z. B. Aufbau der Infrastruktur auf Systemebene) Vgl. McKnight (2006), S. 12. Vgl. Kapitel 3 (Systemmodell) und Kapitel 4 (Vorgehensmodell). Vgl. Krcmar (2005), S. 47 ff. Vgl. Krcmar (2005), S. 102 ff. Vgl. Krcmar (2005), S. 210 ff.

12 Kapitel 1: Einleitung Stand der Forschung Im deutschsprachigen Raum kennt man MDM v. a. unter dem Begriff Stammdatenmanagement. Stammdatenmanagement beschränkt sich nicht allein auf die Informationsmodellierung und die Festlegung, in welchen Systemen diese gehalten werden, sondern umfasst vielmehr zahlreiche betriebswirtschaftliche und organisatorische Fragestellungen. 25 Geprägt wurde der Begriff weiter von der SAP AG, welche mit ihrem ERP-System generell und im Speziellen mit dem Modul SAP NetWeaver Master Data Management 26 zu einem der grössten Verkäufer von MDM-Lösungen geworden ist. 27 MDM als Konzept unter dieser Bezeichnung taucht in der wissenschaftlichen Literatur erst seit rund vier Jahren auf, mit Schwerpunkt im englischsprachigen Raum. Im Gegensatz zu deutschen Fachzeitschriften oder Magazinen wird es als neue Disziplin behandelt und nicht als Synonym zu Stammdatenmanagement. 28 Viele Ausführungen drehen sich dabei um die Entität Kunde, welche unter dem Begriff Customer Data Integration (CDI) zusammengefasst werden. Nebst Beiträgen in Fachzeitschriften finden sich ebenfalls einige white papers von ERP-Systemanbietern, die auch Lösungen in der Datenintegration anbieten. 29 Ein Blick in die Vergangenheit zeigt, dass Datenintegration nicht neu ist. Dieses Problem begann mit dem Betrieb einer Vielzahl von Anwendungen innerhalb eines Unternehmens, welche bei der Ausübung der Geschäftsprozesse unerlässlich wurden. Selbst kleine Institutionen kamen so zu (Transaktions-) Datenbeständen mit widersprüchlichen Informationen. Die Integration der Transaktionssysteme erfolgte über viele Wege, z. B. mittels batch reporting, replication, federated reporting, operational data stores oder enterprise data warehouses (EDW). 30 Diese EDW und unternehmensweite Repositories waren in den 90er-Jahren die eingesetzten Lösun Legner/Otto (2007), S. 2. Vgl. Heilig (2007). Vgl. Preimesberger (2007). Vgl. Kapitel Vgl. Cisco Glossary (2008). Diese Dokumente sind kritisch zu beurteilen, da sie z. T. werbegeprägte Formulierungen enthalten und es dadurch an einer differenzierten Haltung des Autors gegenüber dem behandelten Thema fehlen kann. Vgl. Fleckenstein (2007b), S. 7.

13 Kapitel 1: Einleitung 7 gen, um sich eine gesamtheitliche/analytische Sicht über das Unternehmen zu verschaffen. Damit die zu untersuchende Datenmenge überschaubar blieb, wurden innerhalb der EDW sog. Data Marts aufgesetzt. 31 Diese Lösungen hatten jedoch in transaktionsorientierten Geschäftsprozessen ein Manko: Die Datenintegration fand nur auf der analytischen Ebene statt, da die Daten lediglich unidirektional von der operationalen Umgebung zum EDW kopiert wurden. Eine Rückführung integrierter Daten in die einzelnen operationalen Datensilos war nicht vorgesehen. Der Kreislauf schloss sich so nicht. Es bedurfte also eines Systems mit dynamischen Komponenten, welches eine Integration der in diversen Kern-/Subprozessen verwendeten Hauptdaten (z. B. Kundendaten, Materialwirtschaft) und Anwendungen sowie die bidirektionale Datensynchronisation ermöglicht. 32 Einen ersten Schritt in diese Richtung geschah durch die Einführung von ERP-Systemen, welche in den administrativen Hauptprozessen eines Unternehmens die Vielzahl von Legacy-Systemen (veraltete, traditionelle IT-Systeme) abgelöst hatten. 33 Die Verknüpfung solcher ERP-Systeme (Backoffice) mit CRM-Systemen (Frontoffice) über bekannte Konnektor- Architekturen 34 liess z. B. erstmalig die finanzorientierte Analyse und den Datentausch von Kundendaten in Echtzeit zu. 35 Die Vision des freien Datenflusses zwischen den Systemen sieht aber nicht nur die Verbindung von einigen wenigen Anwendungen vor. Vielmehr geht es um die Integration ganzer Bereiche sowie der betroffenen Arbeitsabläufe und der daran beteiligten Menschen. MDM wird demnach für Unternehmen zentral, in welchen diverse Kern-/Subprozesse auf die inhaltlich gleiche Datenbasis zugreifen. Integrierte Daten von hoher Qualität werden so zum Ausgangspunkt neuer Geschäftsmodelle und Dienstleistungen an den internen/externen Kunden. 36 Das Studium der Literatur hat schliesslich gezeigt, dass für einige wenige Entitäten (z. B. CDI) nebst den systemtheoretischen Abhandlungen bereits fertige Lösungsan Vgl. Gruman (2006b), S. 33. Vgl. McKnight (2006), S. 13. Vgl. Sherman (2007a). Vgl. Gruman (2006a), S. 29. Vgl. Zornes (2006). Vgl. Atkinson (2007), S. 44.

14 Kapitel 1: Einleitung 8 sätze (technischer Natur) existieren. Die Verbindung/Integration mehrerer Entitäten stellt dabei die aktuelle Herausforderung dar Zielsetzung der Arbeit Das übergeordnete Ziel der vorliegenden Arbeit ist die Beschreibung der Einführung von MDM basierend auf einem Architekturmodell. Daraus lassen sich zwei Teilziele ableiten. Das erste Teilziel umfasst die Erarbeitung einer Systemarchitektur. Das zweite Teilziel beinhaltet die Herleitung eines Referenz-Vorgehensmodells, welches den Einführungsprozess einer MDM-Lösung beschreibt (Abbildung 1). Abbildung 1: Zielsetzung der Arbeit. 38 Dazu werden in einem einführenden Teil die theoretischen Grundlagen zum Thema MDM erarbeitet. Es sollen dabei die wichtigsten Begriffe definiert und voneinander abgegrenzt sowie die Beweggründe und Herausforderungen einer MDM-Einführung untersucht werden. Auf den theoretischen Erkenntnissen aufbauend, soll anschliessend im ersten Hauptteil der Arbeit eine eigene Systemarchitektur von MDM entwickelt und dargestellt werden. Dies fördert das Verständnis für MDM als umfassendes Management- bzw. Steuerungskonzept. Das EIM Adoption Model von Logan/Newman 2006 zeigt hier mögliche Sichtweisen auf MDM. Es bildet dadurch den Ordnungsrahmen für die Systemarchitektur Bekannt unter der Bezeichnung Multi-Entity MDM. Vgl. Kapitel Darstellung des Verfassers.

15 Kapitel 1: Einleitung 9 Der zweite Hauptteil der Arbeit befasst sich mit der Entwicklung eines Vorgehensmodells zur Vorbereitung eines Unternehmens auf ein umfassendes MDM bzw. zur Einführung dieses Steuerungskonzepts in die Geschäftstätigkeit eines Unternehmens. Es soll dabei ein Referenz-Vorgehensmodell mit Hilfe der Methode der Referenzmodellierung erstellt werden. Dabei lassen sich zwei Unterziele festlegen: 1. Einen Überblick bestehender Vorgehensvorschläge der Literatur erarbeiten. 2. Anforderungen für die Referenzmodellierung aus der Literatur ableiten. 1.6 Methodisches Vorgehen Das Literaturstudium hat gezeigt, dass unter einzelnen Begriffen teilweise verschiedene Sachverhalte verstanden werden. Im Grundlagenteil zu MDM werden deshalb einleitend die relevanten Begriffe auf Basis der verschiedenen Ansichten aus der Fachliteratur definiert und von verwandten Konzepten abgegrenzt. Beweggründe zur Einführung von MDM (z. B. Nutzenpotenziale) und die Gefahren resp. Herausforderungen dabei setzen die Begrifflichkeiten in den interessierten Kontext. Die Auseinandersetzung mit zwei typischen Anwendungsfeldern schliesst die theoretischen Überlegungen ab. Im ersten Hauptteil der Arbeit werden zu Beginn die einzelnen Komponenten von MDM im Detail vorgestellt und ein Ordnungsrahmen für die folgenden Modellierungsarbeiten definiert. Daraus entsteht eine eigene Systemarchitektur. Dieses Architekturmodell bringt die bisherigen Ausführungen in Beziehung zueinander und fördert im Sinne der dieser Arbeit zugrunde liegenden Zielsetzung das Verständnis für MDM. In diesem Rahmen erfolgt im nächsten Schritt bzw. dem zweiten Hauptteil der Arbeit die Entwicklung eines eigenen Vorgehensmodells als Referenzmodell zur Einführung von MDM. Ein Vorgehensmodell soll allgemein helfen, einen komplexen Ablauf/Prozess zu ordnen und über diese Abfolge den Überblick zu bewahren. 39 Die Ausgestaltung des betrachteten Prozesses Einführung von MDM orientiert sich an vorhandenen Vorgehensvorschlägen der Literatur, da ein eigentliches Referenz- 39 Vgl. Filß et al. (2005), S. 184.

16 Kapitel 1: Einleitung 10 Vorgehensmodell bisher fehlt. Anforderungen an das Referenz-Vorgehensmodell werden dabei über einen Vergleich der Vorgehensvorschläge mit den ERP- Erfolgsfaktoren abgeleitet. Die vorher skizzierte Systemarchitektur liefert bei diesen Überlegungen den inhaltlichen Rahmen. Festzuhalten gilt an dieser Stelle, dass das betrachtete Thema erst seit rund vier Jahren in der Literatur vertieft behandelt wird. 40 Deshalb stützen sich die Ausführungen v. a. auf Beiträge in Fachzeitschriften und Empfehlungen aus der Beraterbranche, indem die Meinungen und Ansichten der Autoren in Form von Anforderungen zusammengetragen und zu einem für diese Arbeit adäquaten Gesamtbild zusammengesetzt werden. Wo Berührungspunkte zu verwandten Managementkonzepten bestehen (z. B. Datenintegration), wird auf einschlägige Fachliteratur zurückgegriffen. Die dieser Arbeit zugrunde liegende Forschungsmethodik orientiert sich am sog. Information Systems Research Framework von Hevner et al Der Entwicklung von Informationssystemen ( design science ) und deren Strukturen wird als (iterativer) Prozess zur Bewältigung konkreter Geschäftsprobleme ( problem-solving paradigma 41 ) verstanden. Dieser Prozess lässt sich in build und evaluate unterteilen. Die Ergebnisse daraus ( constructs, models, methods, instantiations ) nennen die Autoren artifacts. 42 Abbildung 2 stellt das Framework schematisch dar. Abbildung 2: Information Systems Research Framework Vgl. Kapitel 1.4. Vgl. Hevner et al. (2004), S. 76. Vgl. Hevner et al. (2004), S. 78. In Anlehnung an Hevner et al. (2004), S. 80.

17 Kapitel 1: Einleitung 11 Das anwendbare (und relevante) Wissen wird in der vorliegenden Arbeit aus der Literatur zusammengetragen. 44 Im Entwicklungsprozess entstehen dabei die Artifakte Systemarchitektur und Referenz-Vorgehensmodell auf Makroebene als Ergänzung an die bisher vorhandene Wissensbasis. 45 Sie decken technologische (z. B. Architektur), organisatorische (z. B. Rollen, Ablauf, Aufbau) und personenbezogene (z. B. während des organisatorischen Wandels) Aspekte von MDM ab. 46 Eine vertiefte Überprüfung der Ergebnisse im Sinne des umfangreichen Evaluationsprozesses findet dagegen nicht statt. 47 Der komplette Forschungsprozess gemäss Hevner et al kann deshalb nicht als abgeschlossen bezeichnet werden. 48 Ob die Ergebnisse schliesslich auch im informationstechnischen Umfeld eine Relevanz besitzen, muss in weiteren Studien abgeklärt werden. Denkbar ist jedoch ein Wissensbeitrag im Bereich der Zusammenarbeit (Vgl. Alignment 49 ) zwischen IT und dem Geschäftsbereich eines Unternehmens Aufbau der Arbeit Die vorliegende Arbeit ist in fünf Kapitel gegliedert (Abbildung 3). Nach den einleitenden Ausführungen zur Problemstellung, Zielsetzung und zum methodischen Vorgehen wird im zweiten Kapitel auf die Grundlagen von MDM eingegangen. Dabei geht es zuerst um die Klärung der wichtigsten Begriffe und deren Abgrenzung von verwandten Konzepten des Datenmanagements bzw. der Datenintegration. Weiter von Interesse sind in diesem theoretischen Teil die Beweggründe für den Einsatz von MDM sowie die erwarteten Nutzenpotenziale. Nebst einigen Vorteilen gibt es auch Herausforderungen, welchen man sich bei der Einführung/beim Betrieb von MDM bewusst sein sollte. Die Nennung zweier Anwendungsgebiete von MDM schliesst den Theorieteil ab. Im dritten Kapitel bzw. dem ersten Hauptteil der Arbeit werden die Theoriebausteine zu einer Systemarchitektur zusammengeführt. Dies geschieht Vgl. Hevner et al. (2004), S. 87 f., Abschnitt Guideline 5: Research Rigor. Vgl. Hevner et al. (2004), S. 81 ff., Abschnitt Guideline 1: Design as an Artifact. Vgl. Hevner et al. (2004), S. 84 f., Abschnitt Guideline 2: Problem Relevance. Vgl. Hevner et al. (2004), S. 85 ff., Abschnitt Guideline 3: Design Evaluation. Vgl. Hevner et al. (2004), S. 86 ff., Abschnitt Guideline 6. Design as a Search Process. Vgl. Henderson/Venkatraman (1999). Vgl. Hevner et al. (2004), S. 87, Abschnitt Guideline 4: Research Contribution.

18 Kapitel 1: Einleitung 12 über die detaillierte Auseinandersetzung mit den wichtigsten Komponenten von MDM und deren Modellierung in Teilmodellen gemäss dem definierten Ordnungsrahmen. Auf dieser Systemarchitektur aufbauend, erfolgt im vierten Kapitel bzw. dem zweiten Hauptteil die Herleitung eines Referenz-Vorgehensmodells zur Einführung von MDM in einem Unternehmen. Als Referenzmodell zeigt es die wichtigsten Elemente und Zusammenhänge in einem MDM-Programm. Abbildung 3: Aufbau der Arbeit Darstellung des Verfassers.

19 Kapitel 2: Grundlagen von Master Data Management 13 2 Grundlagen von Master Data Management Die Einführung von MDM im Unternehmen ist ein umfangreiches und langfristiges Projekt. Umfangreich deshalb, weil der Vision entsprechend das Ziel der Integrationsbemühungen eine ganzheitliche Sicht auf die Geschäftstätigkeit ist. Der langfristige Horizont beruht auf der Tatsache, dass dieses z. T. tief greifende Umstrukturieren nicht ohne weiteres durchführbar ist. In der Transformation von verteilten zu integrierten Daten und Arbeitsabläufen kann es kulturelle, regulatorische, technische oder geschäftliche Gründe geben, warum die bestehenden Systeme (vorläufig) beibehalten werden. Man spricht vielmehr vom Zustand der permanenten Evolution, während der auf inkrementelle Art und Weise nur diejenigen Bereiche umgestaltet werden, deren Integration geschäftlichen Mehrwert bringen. 52 Getrieben durch diesen Gedanken (Geschäftssicht) und unterstützt durch vorhandene IT wird der Endzustand der vollkommenen Integration nie erreicht, da die Geschäfts- und Datensicht sich ständig wandeln. MDM ist demnach vielmehr ein Programm als ein einmaliges Projekt. 53 Folgende Kapitel umrahmen nun die Grundlagen von MDM. Nachdem die wichtigsten Begriffe vorgestellt wurden (Kapitel 2.1), erfolgt eine Analyse der Beweggründe zur Einführung von MDM (Kapitel 2.2) und allfälliger Gefahren und Herausforderungen dabei (Kapitel 2.3). CDI, Identity Management (IDM) oder Finanzreporting sind weiter typische Anwendungsfelder von MDM. Sie schliessen die Ausführungen zum theoretischen Teil ab Vgl. Gehrmann (2008). Vgl. Twentyman (2007), S. 27.

20 Kapitel 2: Grundlagen von Master Data Management Begriffsklärung Der Begriff MDM vereint viele Ausdrücke und Abkürzungen aus dem Bereich der Systemintegration. Auf die wichtigsten wird in der Folge eingegangen Arten von Daten Die Unterscheidung von Datenarten ist ein zentraler Bestandteil bei der Auseinandersetzung mit MDM. Die Abgrenzung der einzelnen Begriffe erfolgt meist über deren Verwendungszweck im sowie über die (z. T. subjektive) Sicht auf den Leistungserstellungsprozess. Dies führt zu Abweichungen in der Wahrnehmung der einzelnen Typen. Während der Einführung von MDM scheint es deshalb wichtig, konsistente und möglichst überschneidungsfreie Definitionen zu finden. Im deutschsprachigen Raum kennt man v. a. die Unterteilung von Daten in Stammdaten, Bewegungsdaten und Bestandesdaten (Tabelle 1). Da diese Definitionen einen klaren zeitlichen und zweckgebundenen Bezug zu deren Verwendung im Leistungserstellungsprozess aufweisen, ist eine Präzisierung gemäss Ansicht des Verfassers nicht nötig. Auf sprachliche Abgrenzungsschwierigkeiten wird in Kapitel eingegangen.