Lade Inhalt...

Customer Data Integration - analytischer Produktvergleich

Diplomarbeit 2006 83 Seiten

Informatik - Wirtschaftsinformatik

Leseprobe

INHALTSVERZEICHNIS

1 Situationsanalyse und Zielsetzung
1.1 Historischer Rückblick in die Datenintegration
1.2 Zielsetzung und Aufbau der Arbeit

2 Keine einheitliche Kundensicht durch operative Systeme
2.1 Operative versus dispositive Daten
2.2 Datenaufgaben und -prozesse
2.3 Datenqualitäts- und -integrationsprobleme

3 Stammdatenmanagement
3.1 Unterschiedliche Sichtweisen
3.2 Herausforderungen an ein effizientes Stammdatenmanagement
3.2.1 Einführungsanforderungen und Funktionsvielfalt
3.2.2 Systemintegration versus Datenintegration
3.3 SAP Master Data Management
3.3.1 Enterprise Service Architecture
3.3.2 SAP MDM-Komponenten
3.3.3 SAP MDM – abschließende Beurteilung
3.4 Hyperion System 9 BI-Plattform
3.4.1 Business Performance Management
3.4.2 Vorteile des Hyperion-Ansatzes
3.5 Hyperion System 9 MDM - Funktionsvielfalt
3.6 Hyperion-MDM-Lösung – abschließende Beurteilung

4 Customer Data Integration
4.1 CDI – Grundlagen und Begriffsabgrenzung
4.2 Customer Data Integration - Marktübersicht
4.2.1 Marktstellung - CDI
4.2.2 Entstehung von kombinierten CDI-Lösungen
4.3 Customer Data Integration: Bewertungskriterien
4.3.1 Anforderungen an die Unternehmen
4.3.2 Bewertungskriterien
4.4 Customer Data Integration – Implementierungsarten im Vergleich
4.4.1 Wichtige Vorbedingungen
4.4.2 Customer-Built Data Hub
4.4.3 Fixed Transaction Hub
4.4.4 Match & Link Cross-Reference Hub
4.4.5 Adaptive Transaction Hub

5 Customer Data Integration - Produktübersicht
5.1 Oracle Customer Data Hub
5.1.1 Anbieterprofil
5.1.2 Produkt- und Funktionsvielfalt
5.1.3 Abschließende Beurteilung
5.2 DWL Customer™
5.2.1 Anbieterprofil
5.2.2 Produkt- und Funktionsvielfalt
5.2.3 Abschließende Beurteilung
5.3 Siebel Universal Customer Master
5.3.1 Anbieterprofil
5.3.2 Produkt- und Funktionsvielfalt
5.3.3 Abschließende Beurteilung

6 Management Summary

Quellenverzeichnis

Abkürzungsverzeichnis

1 Situationsanalyse und Zielsetzung

In den vergangenen Jahren wurde die Softwareindustrie sowohl von Globalisierung und Zusammenschlüssen, Privatisierung und Deregulierung von Märkten als auch durch die Reduzierung der Innovations- und Produktlebenszyklen stark beeinflusst. Ein immer stärker wachsender Kosten- und Wettbewerbsdruck nötigt die Unternehmen zur Einführung neuer innovativer Lösungsansätze [WOLF98, S. 746]. Konzepte wie e-Business, Customer Relationship Management (CRM), Business Intelligence (BI), Data Warehouse (DW) oder Supply Chain Management sind einige Ausprägungen davon.

Die stetige Ausweitung der Datenbasis, die massive Veränderung des Marktumfeldes und immer höhere interne und externe Anforderungen an Transparenz und Fundierung der Entscheidungen sind zwingend in die Kalküle einer erfolgreichen Unternehmens-steuerung einzubeziehen [KEMP04, S. 7]. Althergebrachte Einzelsysteme zur Managementunterstützung können diesen Anforderungen nicht mehr genügen. Isolierte oder punktuelle Lösungsansätze sind nicht ausreichend, da sie nur einzelne Aspekte behandeln und häufig auf isolierten Datenbasen aufbauen. Integrierte Lösungsansätze sind somit erforderlich und es erscheint durchaus gerechtfertigt, bei grundlegenden Umorientierungen im Bereich der IT-basierten Managementunterstützung neue Begrifflichkeiten zu verwenden [KEMP04, S. 8].

Marktbedingungen haben Organisationen gezwungen, sich von einer Produktorientierung weg zu bewegen und mehr kundenorientiert zu werden. Unternehmen erkennen die Notwendigkeit, den Kunden in die Mitte ihrer operativen Geschäftsprozesse zu stellen. Die Fähigkeit, operativen Transaktionen Kundenwissen und einheitliche Kundensicht in Echtzeit zu injizieren, ist die Grundlage für einen wirkungsvollen Kundendienst sowie eine Verkaufsstrategie. Neben den kulturellen und unternehmerischen Herausforderungen, stehen Unternehmen mehreren technischen Herausforderungen entgegen, die diese Transformation erfordern, um die erwünschte Kunden-Zentralisierung zu erreichen. Von der Technologieperspektive heraus besteht die größte Herausforderung in der Implementierung eines kundenzentralen Modells, da Kundendaten über mehrere unterschiedliche Geschäftsbereiche (Data Warehouses, Data Marts, operative Systeme u. a.) gespeichert und gehandhabt werden. Sogar innerhalb eines Geschäftsbereiches existieren einige Back- und Front-Office-Systeme, die über eigene Kundeninformationen verfügen. Die Konsequenzen dieser Datenstruktur sind fragmentierte Kundendaten, die über mehrere Systeme hinweg verteilt sind und zur Erzeugung von redundanten Datensätzen und mehrfach angelegten Kundenprofilen führen [CORR05, S. 2].

Diese Arbeit widmet sich Datenintegrationskonzepten wie Customer Data Integration und Stammdatenmanagement.

1.1 Historischer Rückblick in die Datenintegration

Integration ist ein „Urthema“ der Wirtschaftsinformatik. Bereits in den 70er Jahren des 20. Jahrhunderts wurden mit dem Kölner Integrationsmodell sowie den Arbeiten von Scheer und Mertens Integrationsansätze mit dem Ziel einer detaillierten, möglichst vollständigen, unternehmensweiten Modellierung von Daten bzw. Funktionen als Grundlage der Entwicklung integrierter Anwendungssysteme erarbeitet. Ende der 80er Jahre des 20. Jahrhunderts erlebte diese Diskussion in Zusammenhang mit unternehmensweiten (Daten-)Modellen und computerintegrierter Fertigung einen ersten Höhepunkt. Neben rein daten-, datenfluss-, funktions-, prozess-, methoden- oder programmorientierten Integrationsansätzen wurden Anfang der 90er Jahre des 20. Jahrhunderts Gesamtarchitekturen mit einer Vielzahl von Integrationssichten und –ebenen vorgeschlagen [MAUR03, S. 4].

Der Euphorie hochintegrierter Gesamtmodelle folgte jedoch bald die Ernüchterung, dass monolithische Integrationsmodelle in komplexen Organisationen nicht mit vertretbarem Aufwand erstellt und insbesondere gewartet werden können. Einerseits fehlten für einige Modelle die dazu notwendigen Verdichtungs- und Verfeinerungsoperationen. Andererseits schien die Tendenz zu dezentraler Informationsverarbeitung den Sinn unternehmensweiter Modelle grundsätzlich in Frage zu stellen [MAUR03, S 4].

Häufig wechselnde Schlagworte wie Management Information Systems, Decision Support Systems und Executive Information Systems stehen jedoch für den mäßigen Erfolg, den die Anbieter bis Mitte der 90er Jahre in diesem Markt erringen konnten [SCHI99, S. 1]. Seitdem werden mit ganz anderen konzeptionellen Ansätzen wie Data Warehouse, OLAP, Business Intelligence Tools und Data Mining neue, erfolgsversprechende Lösungen zum Aufbau entscheidungsorientierter Informationssysteme (EIS) etabliert. Damit diese EIS aber auch mit richtigen und vor allem einheitlichen Daten versorgt werden, sind in den letzten Jahren operative Lösungen im Bereich der Customer Data Integration und des Stammdatenmanagements entstanden.

1.2 Zielsetzung und Aufbau der Arbeit

In dieser Arbeit sollen ausgewählte Customer-Data-Integration-Implementierungsarten und -produkte anhand von geeigneten Kriterien untersucht und bewertet werden. Die vorliegende Ausarbeitung ist in drei Abschnitte unterteilt:

- Zuerst sollen im Rahmen einer Geschäftsumgebung von operativen Systemen die Problemstellungen von Datenqualität und –integration dargestellt werden. Kundendaten sind im Unternehmen von ausschlaggebender Bedeutung. Hierzu werden die grundlegendsten Probleme ihrer Integration im Unternehmen behandelt.
- Der zweite Abschnitt umfasst die Themen - Master Data Management (Stammdatenmanagement) und Customer Data Integration als einen Spezialfall der Datenintegration. Einerseits wurden diese zwei Konzepte absichtlich abgegrenzt, da ihnen eine hohe Bedeutung der Datenintegration zugewiesen wird. Andererseits bezieht sich Master Data Management (MDM) auf verschiedene Datenarten (z. B. Produkte, Umsätze, Kunden), während der Customer-Data-Integration-Ansatz (CDI) hauptsächlich auf Kundendaten fokussiert ist.
- Der Schwerpunkt der Ausarbeitung liegt auf den Customer-Data-Integration-Produkten. Ziel ist, auf Basis der angestellten Bewertungskriterien und des anschließenden CDI-Implementierungsarten-Vergleichs eine Übersicht und ausführliche Analyse über drei Customer-Data-Hub-Produkte führender Softwareanbieter zu geben.

In Kapitel 2 erfolgt eine Einführung in die Grundlagen der Datenverwaltung. Neben der Erläuterung von dispositiven und operativen Daten werden hier die wichtigsten Datenaufgaben und –prozesse (Datenintegration und -speicherung) beleuchtet. Anschließend werden Datenintegrations- und Datenqualitätsprobleme in operativen Systemen beschrieben. Mit einer Darstellung der Kundendatenproblematik und die daraus entstehenden Inkonsistenzen und Ineffizienzen schließt das Kapitel ab.

Gegenstand von Kapitel 3 ist das Stammdatenmanagement. Nach Beleuchtung der zugrundeliegenden theoretischen Überlegungen, unterschiedliche Sichtweisen und Herausforderungen (technische Anforderungen an die Systeme), wird die entsprechende Umsetzung innerhalb des SAP- und Hyperion-Master-Data-Managements untersucht und bewertet. Hierbei wurden die Produkte SAP MDM und Hyperion 9 MDM analy-

siert, da sie auf eine unterschiedliche Art und Weise das Stammdatenmanagemet-Problem angehen und lösen.

In Kapitel 4 wird zunächst der Oberbegriff Customer Data Integration definiert. Da dieses Kapitel den Hauptakzent der Arbeit setzt, wird hier im weiteren Verlauf eine CDI-Marktübersicht mit Prognosen über den Marktzuwachs und –expandierung anhand von Quellen des Customer-Data-Integration-Institutes dargestellt. Danach werden die Anbieter von CDI-Lösungen bezüglich ihrer Fähigkeit zur Ausführung von Aufgaben und ihrer Vision über CDI Hubs bewertet. Hier zeigen Analysen von Gartner in seinem „Magic Quadrant for CDI Hubs 2005“ welche Position Anbieter im CDI-Markt nach bestimmten Kriterien einnehmen. Der Fokus liegt in diesem Kapitel auf den Bewertungskriterien anhand deren im folgenden Kapitel vier CDI Hub-Implementierungsarten untersucht werden. Nach einer Abwägung der Vor- und Nachteile, der in der Praxis am meisten bevorzugten „Implementation Styles“, werden diese jeweils beurteilt.

Kapitel 5 bildet den Schwerpunkt der vorliegenden Ausarbeitung. In diesem Kapitel werden konkrete CDI Hubs von den Softwareherstellern Oracle, DWL und Siebel Systems vorgestellt. Anhand der Ergebnisse aus Kapitel 4 (siehe Kap. 4.4 Implementierungsarten im Vergleich) erfolgt eine ausführliche Beschreibung zu jedem Produkt bezüglich seiner Funktionsvielfalt, Architektur, Integrations- und Erweiterungspotenziale sowie Skalierbarkeit, Kompatibilität u. a. In den abschließenden Bewertungen wird zu jedem Produkt auf konkrete Schwächen/Stärken hingedeutet. Darauf aufbauend werden Vorschläge zur Verbesserung und Weiterentwicklung gemacht.

Kapitel 6 beinhaltet eine Bewertung der Ergebnisse und einen Ausblick auf weitere Entwicklungen in diesem Themenumfeld.

2 Keine einheitliche Kundensicht durch operative Systeme

Während Customer-Relationship-Management- und Business-Intelligence-An-wendungen sowie andere betriebliche Anwendungssysteme Organisationen zur Annäherung und Gewinnung ihrer Kunden verhelfen, schafft es keine Anwendung alleine, eine zuverlässige Grundlage aufzubauen, um eine vertrauenswürdige, zentralisierte und einheitliche Kundensicht zu unterstützen [SIPE05b].

In den Hauptindustriesektoren wie Finanzdienstleistungen, Versicherungen, Telekommunikation und Biowissenschaften kann die gegenwärtige Dateninfrastruktur weder zuverlässige, vereinheitlichte Kundensichten (Customer Views) über operative Echtzeit-Systeme an Mitarbeiter liefern, noch kann sie die Datenintegration bei Data Warehouses und analytischen Systemen aufrechterhalten wie z. B. bei Änderung von Datenquellen [SIPE05a].

Folglich wird in diesem Kapitel auf die wesentlichen Probleme der Datenintegration und –qualität innerhalb von operativen Systemen eingegangen.

2.1 Operative versus dispositive Daten

Je nach der Art der unterstützenden Arbeitsinhalte können Informationssysteme in operative und dispositive Systeme unterschieden werden, wobei die zugehörigen Daten dieser Systeme in operative und dispositive Daten unterteilt werden [DROD90, S. 552]. Operative Daten werden von Administrations-, Dispositions- und Abrechnungssystemen generiert und/oder verarbeitet. Große Teile der operativen Daten werden hierbei von sog . Online-Transaction-Processing-Systemen (OLTP-Systemen) erzeugt, bei denen mehrere Benutzer im Teilhaberbetrieb sich derselben Systeme und Datenbestände bedienen, wie beispielsweise bei Auskunfts-, Buchungs- und Bestellsystemen [KEMP04, S. 13 ff.]. In Abgrenzung zu den operativen Daten werden die für managementunterstützende Systeme erforderlichen Daten als dispositive Daten bezeichnet.

Bis weit in die 90er Jahre hinein konnten managementunterstützende Systeme meist ausschließlich auf eigene, herstellerspezifische und daher isolierte Datenbestände zugreifen. Wie Abbildung 2.1 zeigt, wurden zur Befüllung dieser Datenbereiche Kopien und Extrakte aus den verschiedenen operativen internen und externen Datenquellen gezogen.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2.1: Historisch gewachsene Datenversorgung managementunterstützender Systeme [KEMP04, S. 15]

Diese Vorgehensweise weist jedoch erhebliche Nachteile auf [KEMP04]:

- Beeinträchtigung der Performance der operativen Systeme durch mehrfaches Kopieren und Extrahieren.
- Inkonsistenz des dispositiven Datenmaterials, da die zu unterschiedlichen Zeitpunkten durchgeführten Kopier- und Extraktionsprozesse aufgrund des fortlaufenden Betriebs der operativen Transaktionssysteme nicht die gleichen Datenwerte liefern.
- Erhöhung des Aufwandes und der Fehleranfälligkeit, da die betriebswirtschaftliche Harmonisierung des Datenmaterials für jedes einzelne System individuell durchgeführt werden muss.
- Unerwünschte Nebenwirkungen durch das Löschen und Ändern von Daten in vorgelagerten dispositiven Systemen, die nicht selten als zusätzliche Datenquellen herangezogen werden.

2.2 Datenaufgaben und -prozesse

Bevor die Daten überhaupt als operativ oder dispositiv bezeichnet werden können, müssen diese erst gesammelt werden. Eine Sammlung von Daten, die in Entscheidungssituationen zur Verfügung stehen sollen, umfasst die zwei Hauptaufgaben der Datenintegration und der Datenspeicherung. Dabei ist die Berücksichtigung des Metadatenmanagements (Datendokumentation) sowie der Datenqualitätssicherung von großer Bedeutung. In der Datenverarbeitung werden unter Metadaten allgemein alle Arten von Informationen verstanden, die für die Analyse, den Entwurf, die Konstruktion und die Nutzung eines Informationssystems erforderlich sind [VADU01, S. 273]. Metadaten liefern sowohl eine betriebswirtschaftlich-semantische als auch eine technisch-strukturelle Beschreibung der Daten. Sie dienen der Dokumentation der Informationsobjekte, insbesondere hinsichtlich ihrer Speicherparameter, Herkunft, Struktur, Zusammensetzung und inhaltlichen Beschreibung [BANG03a, S.3].

Datenintegration :

Nachdem die Führungsinformationssysteme immer leistungsfähiger geworden sind, liegt das Problem bei der Einführung eines kompletten Informationssystems sehr oft auf Seiten der Informationsbasis [SCHI99, S. 14].

Der Sammlung aller wichtigen Daten und deren Aufbereitung zu entscheidungsrelevanten Informationen kommt eine sehr große Bedeutung zu.

So umfasst die Datenintegration eine der Kernaufgaben der betrieblichen Informationstechnologie. Laut Gartner Group wenden Unternehmen mehr als 35% ihrer IT-Budgets für die Integration von Applikationen auf. Die Datenintegration wird auch in Zukunft eine entscheidende Rolle spielen, da die Anzahl der betrieblichen Anwendungssysteme trotz Einsatzes integrierter Standardanwendungssoftware weiter hoch sein wird und die anwendungsübergreifende Abwicklung von Geschäftsprozessen und der sie begleitende Informationsaustausch den Nutzen des Einsatzes von Informationstechnologie erhöht [BANG04, S. 2].

Die Datenintegration ist die Schnittstelle zwischen verschiedenen Applikationstypen und hat damit die weitergehende Aufgabe der Transponierung von Daten zwischen unterschiedlich ausgerichteten Datenmodellen. Ein Beweis dafür liefern die ETL-Prozesse, die zur Integration von Daten aus operativen Systemen für ein Data Warehouse zuständig sind. Im Rahmen der Datenintegration werden Daten aus verschiedenen Vorsystemen in die Datenhaltungskomponenten überführt. Da dieser Prozess 50-80 % des Aufwandes in Anspruch nimmt, kommt der Datenintegration eine besondere Bedeutung zu [BANG03a, S. 4 f.].

Nachdem die Daten in einen konsistenten und homogenen Zustand überführt wurden und wenn sie keine unterschiedlichen Datenformate und andere Inkonsistenzen aufweisen, werden sie in ein Data Warehouse integriert.

Datenspeicherung :

Entscheidungsrelevante Daten werden in dedizierten Datenbanken gespeichert, die nur zu diesem Zweck aufgebaut werden. Die Kernidee ist die Schaffung einer themenorientierten, integrierten, zeitbezogenen und dauerhaften Sammlung von Daten zur Entscheidungsunterstützung des Managements – dem Data Warehouse [BANG03a, S. 5]. Grundsätzlich sind die operativen Informationssysteme (OIS) nach den betrieblichen Funktionen im Unternehmen ausgerichtet (z. B. Materialwirtschaft, Vertrieb und Finanzbuchhaltung), während ein Data Warehouse themenorientiert nach Objekten (Produkte, Kunden, Märkte etc. ) aufgebaut ist. Beim Zugriff auf operative Informationssysteme werden immer Abfragen der aktuellen Ist-Situation ausgeführt, während es sich bei einer Data-Warehouse-Abfrage lediglich um eine zeitbezogene Aussage handelt. Im Gegensatz zu einem operativen Informationssystem werden die Informationen bei einem Data Warehouse dauerhaft gesammelt. Das Data Warehouse Konzept kann also als eine umfassende, unternehmensweite Datensammlung verstanden werden.

Aus dieser unternehmensweiten Informationsplattform können bei Bedarf kleinere Datenbestände, Data Marts genannt, für spezielle Analyseaufgaben erzeugt werden. Data Marts sind funktions- oder abteilungsspezifisch aufgebaute Data Warehouses, die ansonsten die Eigenschaften eines Data Warehouse besitzen [BANG03a, S.6].

2.3 Datenqualitäts- und -integrationsprobleme

In der betrieblichen Praxis hat sich seit Mitte der 90er Jahre eine neue Begrifflichkeit entwickelt und dort auch umfassend etabliert. „ Business Intelligence“ (BI) heißt der vielschichtige Begriff und lässt sich primär auf Überlegungen der Gartner Group aus dem Jahre 1996 zurückführen [KEMP04, S. 2]. Chamoni und Gluchowski sehen in BI einen Sammelbegriff „zur Kennzeichnung von Systemen, die auf der Basis interner Leistungs- und Abrechnungsdaten sowie externer Marktdaten in der Lage sind, das Management in seiner planenden, steuernden und koordinierenden Tätigkeiten zu unterstützen“ [CHAM04, S. 119].

Die Datenqualität ist ein wesentliches Problem von Business-Intelligence-Systemen, da operative Systeme in der Regel Daten schlechter Qualität liefern. Diese Qualitätsmängel sind z. B. fehlende, mehrfach vorkommende, falsch verknüpfte, falsch definierte und natürlich auch einfach inhaltlich falsche Daten. Mängel in der Datenqualität werden wegen der höheren Anforderungen an die Datenverarbeitung häufig erst in Business-Intelligence-Systemen entdeckt. Dieses Problem liegt vor allem an der Überprüfung der Daten in den Vorsystemen (Data Profiling) und während der Datenintegrationsprozesse [BANG03a]. Nicht nur Business-Intelligence-Anwendungen sind von Datenqualitätsproblemen betroffen. Eine Reihe von weiteren Problemen hindern Unternehmen daran, eine reibungslose Datenintegration durchzuführen und eine einheitliche Datenbasis zu errichten.

Die sehr wichtigen Kundendaten sind auch von der allgemeinen Datenintegrationsproblematik betroffen. Im Folgenden wird auf diese eingegangen [SIPE05b]:

- Kundendaten sind in mehreren Silos angelegt und eingesperrt (z. B. in Data Warehouses, Data Marts und externen Quellen): CRM-Anwendungen und multifunktionale Kanalknoten wie Websites und Call Centers schaffen eine Umgebung, in der Informationen eines einzelnen Kunden über zahlreiche Datenbanksilos, in unterschiedlichen Geschäftsbereichen oder Produktsparten gestreut sind. Bedenklich ist, dass die gleichen Kundeninformationen durch jede Anwendung kopiert, für andere Geschäftsprozesse neu erstellt oder wiederholt in verschiedenen Data Warehouses gespeichert werden. Angesichts dieser Datenzerstreuung, -verdopplung und dieses Datenkonflikts ist das Ziel eines jeden Unternehmens feste Kundenbeziehungen auf Dauer herzustellen, zum Scheitern verurteilt.

- Kundendaten sind im Besitz unterschiedlicher Unternehmensbereiche: Da-tenunzuverlässigkeit ergibt sich aus den ungenauen und inkonsequenten Kundenreferenzdaten ab, die über verschiedene IT-Systeme innerhalb eines Unternehmens doppelt geführt werden. Unterschiedliche Geschäftsbereiche und Unternehmenseinheiten haben ihre eigenen Systeme und Datenquellen, die Kundeninformationen enthalten, welche für ihr Geschäft relevant sind. Häufig enthalten sie aber auch Referenzdaten, die in einem Widerspruch zu anderen Kundenreferenzdaten in der Organisation stehen. Zusätzlich sind diese Kundendaten von der ganzen Organisation nicht leicht zu benutzen oder zugänglich. Während viele Firmen Data Warehouses errichteten, die selektierte Kundeninformationen sammeln, dienen die meisten ihrer Werkzeuge nur für logische Analysen wie zur Segmentierung und Rentabilitätsvorhersagen.
- Viele dieser Datenquellen sind an unternehmensspezifische Datenmodelle angepasst und das Standardisieren auf dem Datenmodell eines einzelnen Anwendungsanbieters ist nicht leicht durchführbar: Jede Anwendung hat ein Datenmodell, welches über seine eigenen Anwendungsdaten verfügt. Zusätzlich erfordern jedes Data Warehouse und jede externe Datenquelle ihr eigenes Datenmodell. Mit all diesen gegenseitig inkompatiblen Datenmodellen glauben viele Firmen, dass sie bezüglich des Datenmodells standardisieren müssen, das für ihre CDI-Lösung geeignet ist. Dabei entstehen folgende Probleme [SIPE05b]:

Erstens ist es extrem schwierig, das mit diesen Anwendungen in Verbindung stehende Datenmodell zu ändern oder zu erweitern, da es sehr aufwendig ist, Daten aus anderen Anwendungen und externen Datenquellen zu konsolidieren, die außerhalb des Bereichs von den Anwendungsparametern des Anbieters liegen. Viele Unternehmen besitzen Kundendaten, die meistens über 20 bis 30 Datenquellen zerstreut sind. Außerdem üben üblicherweise die Anwendungen von einem Anbieter die Kontrolle über 10-20% dieser Quellen aus. Der Rest der Datenquellen, einschließlich der externen Datenquellen müssen so abgebildet und umgewandelt werden, dass eine Integrierung von Daten in das Anbieter-Datenmodell möglich ist. Folglich bedeutet das Standardisieren auf dem Anbieter-Datenmodell mehr, und nicht weniger Aufwand.

Zum Zweiten sind diese Modelle auch komplex und enthalten zu viele fremde Attribute, die nicht für eine CDI-Lösung erforderlich sind, da die Anbieter-Anwendungs-datenmodelle ursprünglich so entwickelt wurden, um eigene Anwendungen zu unterstützen. Dies führt nicht nur zur Vervielfältigung von unnötigen Daten im Customer Hub und zur Verschlechterung der Systemleistung, sondern macht das Abbilden, Importieren, und Hinzufügen von neuen Datenquellen unnötig kompliziert.

- Heterogene Architektur und Werkzeuge haben eine unterschiedliche Technik der Datenintegration: Als die Datensilos zusammenbrachen, haben die erhöhten Konnektivitäts- und Integrationsbemühungen neue Datenunverträglichkeiten in der Datenmodellierung, Datensemantik, Datenqualität und der Datenverwaltung entdeckt. Eine Schwäche ist bei den Datenwerkzeugen (ETL/EII/DQ) zu sehen, da sie keinen Rahmen für das Handhaben von kompletten Aufgabenreihen anbieten, die von einer CDI-Lösung erfordert werden. Jedes dieser Werkzeuge zusammen mit zahlreichen Enterprise-Application-Integration-Technologien (EAI), trägt begrenzt zur gesamten Datenintegration innerhalb der IT-Landschaft – Anwendung-zu-Anwendung-Integration, Datentransportierung zum Single Warehouse und Reinigung einzelner Quellen etc [SIPE05b].
- Legacy Data Hubs (z. B. wie CIF) sind weder leicht zu erweitern noch können sie abgeschafft werden: Organisationen, die Legacy Data Hubs betreiben, schätzen den Wert von sauberen und genauen Kundeninformationen, aber sind durch Beschränkungen der älteren Generation von Customer-Information-File-Systemen (CIF) frustriert. Diese Systeme haben die Unternehmen gezwungen, einen strengeren Produktfokus zu befolgen anstatt auf den Kunden zu fokussieren und verloren an Flexibilität, indem sie Daten aus Drittquellen zusammenmischten. Jedoch unterstützen weiterhin die Legacy Data Hubs diese noch wertvolle historische Kundeninformation, die innerhalb der neuen Customer-Data-Integration-Plattform/Infrastruktur zugänglich sein müssen [SIPE05b].
- Die meisten Datenwerkzeuge funktionieren nur entweder in Batch- oder in einem Echtzeitmodus, aber nicht in beiden: Z. B. sind EAI- und EII-Werkzeuge entworfen, um in Echtzeit zu funktionieren, während ETL-Werkzeuge in einem Batch – Reihenfolge von Aufgaben – funktionieren. Jedes dieser Werkzeuge deckt einen kleinen Bedarf der Anforderungen an einen Customer-Data-Integration-Ansatz, allerdings sind ihre Funktionalitäten auf bestimmte Zwecke eingeschränkt.
ETL-Werkzeuge (Extrahieren, Transportieren, Laden) wurden entwickelt, um große Datenbestände in einem Batch-Modus zu verschieben, während EII-Werkzeuge (Enterprise Information Integration) die Aufgabe haben, über ungleiche Quellen verteilte Abfragen in Echtzeit auszuführen. Infolgedessen unterstützt jede dieser Optionen effektiv nur eine einzelne Datenmodalität; (Batch oder Echtzeit, aber nicht beide). Da die Kundendaten untrennbar mit den operativen und den strategischen Geschäftsprozessen eines Unternehmens verbunden sind, wie z. B. Order-to-Cash-Prozesse (vom Auftrag bis zur Zahlung) oder Analysen über Rentabilität, müssen sie rechtzeitig jedem Geschäftsprozess zur Verfügung stehen [SIPE05b].
- Bedeutende Datenqualitätsprobleme und kontroverse Semantik (Metadaten) sind innerhalb der Datenquellen verbreitet: Während es Transaktionssysteme zur Datenaufzeichnung (z. B. Gebührenerfassung) gibt, gibt es kein einziges zuverlässiges „System der Aufzeichnung“ zur Darstellung von Kundenprofilen innerhalb des Unternehmens. Daten über Kundenprofile werden über verschiedene IT-Systeme innerhalb eines Unternehmens, mit großen Mengen an Redundanzen und einem hohen Grad an Unbeständigkeit und Ungenauigkeit verteilt. Wie eine operative Anwendung einen Kunden beschreibt, kann sich vollkommen von der Beschreibung einer anderen operativen Anwendung unterscheiden und zu semantischen Unbeständigkeiten und verstärkten Datenzuverlässigkeitsproblemen führen.

Eine kurze Zusammenfassung der erläuterten Probleme:

- Mehrere getrennte Kunden-Systeme: Viele Unternehmen versuchen mit knappen Ressourcen Daten in den vielen Systemen wie im Data Warehouse oder in den operativen Systemen und in den externen Marketing-Datenbanken zu reinigen. Dabei verwenden sie unterschiedliche Werkzeuge, die unterschiedlichen Richtlinien und Einschränkungen unterliegen.

- Das Ergebnis ist ineffizient, da kontroverse Informationen schwierig zu verwenden sind. Zum Beispiel entdecken viele High-Tech-Firmen, dass sie mehrere unterschiedliche Kunden-Definitionen und Quellsysteme haben und somit ihre Fähigkeiten reduziert bleiben, ihren Kunden konsistente Sachkenntnisse anzubieten.
- Mehrfach schlecht integrierte technische Komponenten: Unternehmen müssen ihre Lösungen auf der Basis einer Mischung aus sich gegenseitig überlappenden Technologien zusammenbauen. EAI- und ETL-Produkte sorgen für die Datenerhal-

tung, aber sie müssen eng mit daten-reinigenden und -anpassenden Lösungen in Verbindung stehen, damit Duplikate rationalisiert werden. Außerdem ist die Interaktion mit einer kundenspezifischen Datenbank nötig, um dort die Ergebnisse zu speichern und zu handhaben. Jedes System hat häufig sein eigenes Management und einen Administrationsplatz und verursacht dadurch ein Labyrinth aus kundenspezifischen Beziehungen und getrennten Prozessen.

Mehrere Beispiele könnten hier aufgezählt werden, was aber den Rahmen dieser Arbeit sprengen würde. All diese Beispiele führen gemeinsam zu ein und demselben Problem, nämlich der kontroversen operativen Systeme und deren mehrfach integrierten technischen Komponenten. Außerdem ist eine Stammdatenintegration auch sehr schwierig, wenn keine einheitliche technologische Basis existiert.

Bei dem Customer-Data-Integration-Ansatz handelt es sich exakt um die Behandlung solcher Probleme, wobei eine CDI-Lösung ihre Behebung gewährleisten soll. Auf dieses Konzept wird in den folgenden Kapiteln näher eingegangen

3 Stammdatenmanagement

Ein Stammdatenmanagement ist für die ständige Synchronisierung, Historisierung und Versionierung von Stammdaten über verschiedene Systeme hinweg zuständig.

In großen Unternehmen gibt es im Durchschnitt 50 operative Systeme und alle enthalten Stammdaten. Da ist die Synchronisierung eine gewaltige Aufgabe, die aber nur die Hälfte vom Stammdatenmanagement ausmacht. Die andere Hälfte resultiert aus der Erkenntnis, dass Stammdaten sich im Zeitablauf ändern, d. h, dass sie einen Lebenszyklus haben. Zum Beispiel ändert sich die Geschichte der Aktien bei einer Börse ständig und muss dementsprechend vorgehalten werden, etwa um einen Index im Zeitablauf vergleichbar zu machen. Gleiches gilt bei einer Balanced Scorecard, wenn Kennzahlen geändert werden. Um die Performance vergleichbar zu messen, müssen die verschiedenen Versionen dokumentiert werden [MAUR03, S. 32].

Die Anzahl an Beispielen über in den operativen Systemen eines Unternehmens unterschiedlich verteilte Stammdaten ist groß. Daher wird es in diesem Kapitel auf die wesentlichen Merkmale eines Stammdatenmanagements eingegangen. Außerdem werden im Folgenden die Voraussetzungen für eine vollständige Prozess- und Datenintegration behandelt. Zum Schluss werden zwei Produkte der Firmen SAP (SAP Master Data Management) und Hyperion (Hyperion 9 Master Data Management) analysiert und bewertet.

3.1 Unterschiedliche Sichtweisen

In Abbildung 3.1 wird eine Übersicht über die Positionierung der Software-Anbieter im Master-Data-Management-Markt dargestellt. Manche Anbieter schaffen neue MDM-Lösungen, während andere einfach existierende Software-Lösungen neu „verpacken“. In dieser Matrix sind aktuelle Angebote positioniert, die auf unterschiedliche Art und Weise das Master-Data-Management-Problem lösen.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 3.1: Master Data Management – unterschiedliche Sichtweisen [ORCH05]

Erläuterungen zu der Abbildung [ORCH05]:

- Auf der horizontalen Achse werden die Unternehmen, die eine End-to-end-MDM-Lösung liefern mit denjenigen, die nur einen Teil des Master Data Managements bewältigen können, verglichen.
- Auf der vertikalen Achse werden Lösungen, die jede Art von Stammdatenaufgaben handhaben können mit anderen, die nur auf bestimmte Bereiche (z. B. Kunden, Produkte) oder andere Datenangelegenheiten (in ERPs, Analytics) beschränkt sind, verglichen.

EII (Enterprise Information Integration) [ORCH05]: Solche Lösungen ermöglichen eine Abfrage in mehreren Datenquellen über Informationsstrukturen hinweg, damit eine einheitliche Echtzeitansicht über Daten generiert werden kann. Das löst aber nur einen kleinen Teil des MDM-Problems, hauptsächlich weil ein Master Data Management ein „echtes“ Repository mit bestimmten Datenverwaltungseigenschaften zur Verfügung stellen muss.

ETL (Extraction Transforamtion Loading) und EAI (Enterprise Application Integration): Diese Art Lösungen können genutzt werden, um Stammdaten in die Informationsstruktur zu integrieren. Trotzdem ist Master Data Management nicht nur auf die Datenintegration eingeschränkt [ORCH05].

BI (Business Intelligence): Mehrere Business-Intelligence-Anbieter haben eine MDM-Software in ihre BI-Plattform integriert (siehe Hyperion Master Data Management). Diese Lösungen fokussieren auf analytische Stammdaten, um BI-Ergebnisse zu verbessern. Eine MDM-Lösung ermöglicht den Business-Usern einen raschen Änderungsablauf der Referenzdaten. In dieser Hinsicht ergänzen sich Business Intelligence und MDM gegenseitig, da Business-Users meistens bei der Nutzung des BI-Systems Änderungen in den Stammdaten vornehmen.

MDM in ERPs: Anbieter von Packaged Composite Applications (PCA) verbessern ihre Plattform mit MDM (siehe SAP MDM). Bei einer PCA handelt es sich meist nicht um eine komplexe Lösung, sondern lediglich um eine Anwendung, mit der sich eine ganz bestimmte Aufgabenstellung erledigen lässt. Diese MDM-Eigenschaften sind häufig auf das Enterprise Ressource Planing (ERP) begrenzt und sind außerdem schwierig an andere Kontexte anpassbar (z. B. die Verwaltung von Stammdaten in mehreren ERP-Instanzen).

Vertical MDM (PIM, CDI, SDM): Historisch wurde das Master Data Management aus kombinierten Vertikal-Lösungen wie PIM (Produkt Information Management), CDI (Customer Data Integration) oder SDM (Spend Data Management) gebildet. Eine vertikale Lösung einzuführen, kann für das Unternehmen riskant sein, da diese auf einen spezifischen Bereich (z. B. Kunden) begrenzt ist und häufig ein eigenes Modell für Kundendaten mitliefert. Stammdaten umfassen alle Referenzdaten über das Unternehmen hinweg, abgesehen von ihren Eigenschaften, weil das Hauptziel eines Master Data Managements die Vereinheitlichung von allen Stammdatenarten (Produkte, Kunden, Regeln u. s. w.) ist.

MDM Pure Play: Neue reine MDM-Lösungen (Pure-play) sind in den letzten Jahren aufgetaucht. Sie versuchen allen MDM-Anforderungen - generisch (Modelle, die nicht auf eine spezifische Art von Daten begrenzt sind) und End-to-end (den gesamten Stammdaten-Lebenszyklus handhabend) - zu erfüllen.

3.2 Herausforderungen an ein effizientes Stammdatenmanagement

Unabhängig von der Branche setzen die meisten Unternehmen häufig unterschiedliche ERP- und Legacysysteme ein . Das hat die Konsequenz, dass den Geschäftsprozessen Informationen über Kunden, Partner und Produkte zugrunde liegen, die auf unterschiedliche Art und Weise in den Systemen abgebildet sind. Werden die Daten manuell erfasst, kommen weitere Inkonsistenzen hinzu [SAPA03, S. 1f.]:

- Mehrfache Abspeicherung von gleichen Datensätzen (Redundanz).
- Manche Datensätze können unternehmensweit nicht abgerufen werden.

Da Unternehmensanwendungen immer komplexer werden und ständig größere Datenmengen erzeugen, wird das Problem zusätzlich verschärft. Dennoch müssen die Mitarbeiter mit den inkonsistenten Datensätzen arbeiten und auf dieser Basis wichtige Entscheidungen treffen. Der Mangel an einheitlichen Stammdaten führt deshalb leicht zu Fehlentscheidungen, welche die Effizienz beeinträchtigen sowie die Kundenzufriedenheit und Rentabilität gefährden. Das Datenchaos kann beispielsweise vielversprechende Geschäfte zum Scheitern bringen.

Eine von TowerGroup, Reuters und Capco durchgeführte internationale Studie belegt, dass zum Beispiel im Bereich Finanzdienstleistungen 30 Prozent der Börsengeschäfte aufgrund schlecht gepflegter Referenzdaten nicht zustande kommen. Die Hälfte der befragten Unternehmen verwaltet ihre Daten in zehn oder mehr Systemen, acht Prozent in über 150 Systemen. Vor allem weltweit agierende Unternehmen sind auf einheitliche Stammdaten angewiesen. Denn nur auf dieser Basis können zum Beispiel Führungskräfte, die an weit auseinander liegenden Standorten arbeiten, eine gemeinsame Customer-Relationship-Management-Strategie für wichtige globale Kunden entwickeln.

Auch für viele Unternehmen, die mit einer virtuellen IT-Landschaft arbeiten, sind Stammdaten ein wichtiger Erfolgsfaktor [SAPA04]

Die Verwaltung dieser Stammdaten kann jedoch eine große Herausforderung sein. Außerdem tragen Geschäftsprozesse ohne konsistente Stammdaten kaum zur Wertschöpfung bei und können sich sogar negativ auf die Wettbewerbsfähigkeit eines Unternehmens auswirken. In der Vergangenheit hat es sich jedoch meist als schwierig erwiesen, Stammdatenkonsistenz über alle Systeme einer verteilten IT-Umgebung hinweg zu erreichen. So kommt es, dass Zweigniederlassungen oft unabhängig von der Muttergesellschaft arbeiten. Auch Fusionen und Übernahmen schaffen Probleme im Hinblick auf einheitliche Stammdaten. Während auf der technischen Ebene die bei einer Übernahme neu hinzugekommenen Softwarelösungen relativ problemlos eingebunden werden können, wird die tatsächliche Integration auf Prozessebene in vielen Fällen durch grund-legende Abweichungen zwischen den verschiedenen Stammdatenmodellen behindert [SAPA04, S. 7].

Master Data Management (Stammdatenverwaltung) ermöglicht zuverlässige systemübergreifende, unternehmensweite Prozesse und Analysen und stellt auf diese Weise sicher, dass alle an einem Prozess Beteiligten Zugang zu denselben Daten und Informationen haben. Aus diesem Grund bietet eine Lösung, die sowohl die Konsolidierung der Stammdaten als auch ihre Bereitstellung über Systemgrenzen hinweg ermöglicht, einen entscheidenden Wettbewerbsvorteil.

3.2.1 Einführungsanforderungen und Funktionsvielfalt

Um MDM erfolgreich in eine heterogene IT-Umgebung einzuführen, wird mehr als eine Integration von Systemen erwartet. Stammdaten müssen in ihrem systemübergreifenden Gesamtkontext in allen Geschäftsprozessen nachvollzogen und unterstützt werden. Unternehmen sind sich über die Geschäftsvorteile richtig verwalteter Daten im Klaren, können sich jedoch nicht die Ausfallzeiten leisten, die mit der unternehmensweiten Implementierung großer Softwarepakete einhergehen. Hinzu kommt, dass nach Jahren umfangreicher IT-Investitionen jetzt begrenzte Budgets zur Verfügung stehen und die meisten Unternehmen bestrebt sind, die vorhandene Ausstattung weiter zu nutzen und nicht zu ersetzen. Daher muss jede MDM-Lösung folgende Eigenschaften aufweisen [SAPA03a, S. 7]:

- Schnell und ohne Änderung der bestehenden Systemlandschaft implementierbar.
- Durch flexible Geschäftsprozesse und Abbildung der Organisationsstrukturen auf die geschäftlichen und organisatorischen Anforderungen des Unternehmens zugeschnitten.
- Schrittweise implementierbar, so dass das Tagesgeschäft möglichst wenig gestört wird.
Konsolidierung von Inhalten: Jede MDM-Lösung erfordert die Konsolidierung von Stammdatenobjekten aus verschiedenen Systemen. Hierzu werden die folgenden Funktionen benötigt [SAPA03a, S. 7]:
- Suche nach Stammdatenobjekten über verknüpfte Systeme hinweg.
- Erkennung von identischen oder ähnlichen Objekten.
- Bereinigung von Objekten nach Bedarf.

Nach der Konsolidierung werden die Daten aus verschiedenen Systemen in ein Data Warehouse übertragen. Dort kann zwecks zentraler, unternehmensweiter Analyse und Berichtserstellung auf die Daten zugegriffen werden. Um Störungen auf ein Minimum zu beschränken, muss die MDM-Lösung in der Lage sein, Stammdaten ohne Anpassung der Ursprungssysteme zu konsolidieren. Dies lässt sich durch Verwendung von unternehmensweit gültigen Objekttypattributen erreichen, die identische und ähnliche Stammdatenobjekte in der gesamten Systemlandschaft einander zuordnen. So können verschiedene Datenformate und -strukturen in verschiedenen Systemen im gesamten erweiterten Unternehmen beibehalten werden. Darüber hinaus muss die Zuordnung

Identischer Datenobjekte bei jeder Änderung aktualisiert werden, damit nicht im Laufe der Zeit eine Harmonisierung unterschiedlicher Identifikatoren erforderlich wird. Dieser Ansatz der flexiblen und nicht störenden Datenkonsolidierung bildet die Grundlage für zunehmend nützlicher werdende Geschäftsanalysen, die von der Genauigkeit der unternehmensweiten Daten profitieren. Dadurch werden wichtige neue Möglichkeiten eröffnet (z. B die Erstellung präziser globaler Ausgabenanalysen oder zentralisierte Lieferantenproduktkataloge)

[...]

Details

Seiten
83
Jahr
2006
ISBN (eBook)
9783638584258
Dateigröße
1.5 MB
Sprache
Deutsch
Katalognummer
v66132
Institution / Hochschule
Bayerische Julius-Maximilians-Universität Würzburg
Note
2,3
Schlagworte
Customer Data Integration Produktvergleich

Autor

Zurück

Titel: Customer Data Integration - analytischer Produktvergleich