Stammdatenmanagement mit SAP Master Data … Kapitel 2 In diesem Kapitel betrachten wir die wesentlichen strategi- schen Entscheidungen, die die Grundlage für den Einsatz von SAP

LeseprobeDieses Buch zeigt Ihnen, wie Sie das »Öl des 21. Jahrhunderts« op-timal in Ihrem Unternehmen vorhalten und nutzen. In dieser Lese-probe widmen sich die Autoren der Frage, was Sie bei der Planung und Implementierung Ihrer Stammdateninitiative beachten sollten: von der Zielsetzung über die Toolauswahl bis zu den Implementie-rungsszenarien. Am Ende der Leseprobe finden Sie das Inhaltsver-zeichnis, die Einleitung und das gesamte Stichwortverzeichnis.

Oliver Lauffer, Jan Rauscher, René Zimmermann

Stammdatenmanagement mit SAP Master Data Governance473 Seiten, gebunden, Juni 2016 69,90 Euro, ISBN 978-3-8362-3887-8

www.sap-press.de/3969

»Einsatz und Design von SAP Master Data Governance« (Auszug) »Einleitung«

Inhaltsverzeichnis

Index

Die Autoren

Leseprobe weiterempfehlen

SAP-Wissen aus erster Hand.

https://www.rheinwerk-verlag.de/stammdatenmanagement-mit-sap-master-data-governance_3969/?GPP=lpn

mailto:?body=Leseproben-Empfehlung: �Stammdatenmanagement mit SAP Master Data Governance� von SAP PRESS, http://gxmedia.galileo-press.de/leseproben/3969/leseprobe_sappress_stammdatenmanagement_mit_sap_master_data_governance.pdf&subject=Leseprobe: �Stammdatenmanagement mit SAP Master Data Governance�

79

Kapitel 2

In diesem Kapitel betrachten wir die wesentlichen strategi-schen Entscheidungen, die die Grundlage für den Einsatz von SAP MDG bilden, sowie die wesentlichen Eckpunkte der Lösung. Die Fragestellungen aus diesem Kapitel werden Sie während der gesamten Laufzeit eines MDG-Projekts begleiten.

2 Einsatz und Design von SAP Master Data Governance

Wenn Sie sich im Unternehmen dafür entschieden haben, ein Projektim Bereich Stammdatenmanagement anzugehen, sind die nächstenSchritte die Definition der Ziele und die Auswahl der dafür geeigne-ten Tools. Wie wir im Vorfeld gesehen haben, gibt es bei den unter-schiedlichen möglichen Stakeholdern auch die unterschiedlichstenBeweggründe, Budget für solch ein Projekt freizugeben. Aus diesemGrund ist es entscheidend, hier einen klaren Umfang und das Ziel desProjekts festzulegen. Hierzu werden wir uns in diesem Kapitel ver-schiedene Themenbereiche ansehen, die auf jeden Fall mit allenStakeholdern zusammen definiert werden müssen. Alle diese Punktesollten auch in einem Projekthandbuch beschrieben und akzeptiertsein. Basierend auf diesen Grundsatzdefinitionen der Stakeholderwird der Arbeitsauftrag an das spätere Projektteam erteilt.

2.1 Zielsetzung und Tools definieren

GründeBevor wir jedoch in die Details einsteigen sollten, wir uns einmal vorAugen führen, welche Gründe es für solch ein Projekt geben könnte,da diese dann auch den Projekt-Setup entsprechend beeinflussen:

� Übernahme eines weiteren Unternehmens und damit bedingteZusammenlegung und Harmonisierung der Stammdaten

� Einführung eines neuen zentralen ERP-Systems in einer Unterneh-mensgruppe und Abschaltung der unterschiedlichen bisherigenERP-Systeme

3887.book Seite 79 Montag, 6. Juni 2016 4:16 16


80

� Anforderungen von außerhalb des Unternehmens, die mit der bis-herigen Stammdatenqualität in dieser Form nicht erfüllt werdenkönnen

� Identifizierte Einsparpotenziale innerhalb des Unternehmens, diedurch harmonisierte Stammdaten erreicht werden sollen

Umfang undDetaillierungsgrad

Der Grund für das Projekt bestimmt auch den Umfang und Detaillie-rungsgrad. In Abbildung 2.1 sehen Sie eine Übersicht möglicher Rei-fegrade der weltweiten Harmonisierung und Integration innerhalbdes Unternehmens. Aus diesen drei Stufen lassen sich auch bereitsdie Anforderungen für die Zukunft und Themengebiete innerhalbdes Projekts erkennen. Während sich die Themen auf der erstenStufe noch ziemlich autark betrachten und auch bearbeiten lassen,steigt bereits bei Stufe zwei der Aufwand für die Integration deutlichan. Auf der dritten Stufe endet er in völlig integrierten End-to-End-Prozessen.

Abbildung 2.1 Anspruch an die eigene Organisation – Reifegrad

Genau diese Integration ist auch der hauptsächliche Treiber für denGesamtaufwand im Projekt. Dies muss in der Projektplanung ent-sprechend berücksichtigt werden, geht leider aber viel zu oft verlo-ren. Aus diesem Grund müssen Sie hier unbedingt darauf achten,dass solch ein Projekt eben deutlich mehr als eine reine technischeSystemumstellung ist.

Migration/Harmonisierung

einer Organisations-

einheit

Fit für generelleIntegration

GlobalesReporting

E Harmonisierung innerhalb E eines gegebenen RahmensE Support einer ERP-EinführungE Zentrale E StammdatenorganisationE Zentrales System mind. für E MARA-Daten

E Definition der Rahmen-E bedingungen für einfache E zukünftige IntegrationE Erstellung wiederverwend-E barer LogikE Definition von WorkflowsE Definition wiederverwendbarer E Migrationstools (ETL)

E Detaillierterer E HarmonisierungsgradE Erweiterung des Umfangs der E Stammdatenobjekte E Sicherstellung von Stabilität E im Reporting-ProzessE Setup von erweiterten E Verantwortlichkeiten

1 2 3

Grad der weltweiten Harmonisierung/Integration und Datenqualität

niedrig mittel hoch


Zielsetzung und Tools definieren 2.1

81

Umfang festlegenNachdem der Grund und die Anforderung definiert sind, geht esauch darum, den Umfang der Stammdaten festzulegen, die harmoni-siert werden sollen. Sie müssen also angeben, welche Stammdaten-objekte in welcher Tiefe bearbeitet werden sollen. Die Objekte selbstergeben sich normalerweise schon aus dem Grund für das Projekt.Hierbei wird sehr schnell klar, ob z.B. der Materialstamm, Kunden,Lieferanten oder weitere Objekte bearbeitet werden sollen. Aller-dings muss auch noch die Tiefe der Bearbeitung festgelegt werden.Sie müssen also definieren, ob z.B. nur Nummernkreise harmoni-siert werden oder ob eine komplette inhaltliche Harmonisierung derDatensätze durchgeführt wird. Abhängig von diesen Ergebnissenerfolgt die Entscheidung für das zentrale Tool, also welche Domänenvon SAP MDG eingesetzt werden sollen. In Abbildung 2.2 sehen Sie,dass neben dem zentralen Tool noch viele weitere Aspekte und Toolsin Betracht kommen und auch mit den jeweiligen Verantwortlichendiskutiert werden sollten. Auf den ersten Blick sehen Sie vier Haupt-themenblöcke, auf die wir im Folgenden genauer eingehen:

� Strategie und Governance

� Technologie und System

� Prozesse

� Organisation

Abbildung 2.2 Zusammenspiel der Bereiche für Zieldefinition

Strategie und Governance Technologie und System

Prozesse Organisation

E Datenmigration (ETL-Tools)E Daten-Qualitätsreports

E WorkflowsE (end to end)E MDM/MDG

E RessourcenE Ausbildung

E Zentrale Datenpflegeabteilung/RolleE Erreichbarkeit

E PflegeprozessE KonsolidierungE Produktlebens-E zyklus (PLM)E Migrations-/Integrationsprozesse

E Betriebsanweisungen (SOP)E Organisatorisches Change-ManagementE DateneignerE Datenqualitäts-E konzept

Technologieund System

Strategieund Governance

OrganisationProzesse

Wertschöpfungskette

IT-Systemlandschaft

Stammdatenmanagement



82

2.1.1 Strategie und Governance

Während des Projekts sollten Sie immer im Blick behalten, wie dasProjekt auch nachhaltig zum Erfolg des Unternehmen beitragen kann,damit die geleistete Arbeit nicht nach einiger Zeit wieder hinfällig ist.Denn was hilft eine erfolgreiche Harmonisierung der Daten, wenndirekt danach die Anlage und Pflege neuer Daten wieder willkürlichund ohne klare Anweisung erfolgt? Unser Ziel ist es also, Konzepte zuentwickeln, mit denen Sie die Datenqualität auf eine nachhaltige Artund Weise sicherstellen. Typische Instrumente hierzu sind z.B.Betriebsanweisungen (Standard Operating Procedures), mit denen denzukünftigen Benutzern ein Handbuch für die tägliche Arbeit an dieHand gegeben wird, in dem die einzelnen Arbeitsschritte sowie klareRegeln dokumentiert sind. Diese Anweisungen sind die Basis für eineweltweit einheitliche Arbeitsweise innerhalb des Unternehmens. Umüberprüfen zu können, ob dadurch die Datenqualität stabil bleibtoder sich verbessert hat, wird auch ein entsprechendes Datenquali-tätskonzept benötigt. Schließlich lässt sich Qualität ja nur dann mes-sen und vergleichen, wenn auch definiert ist, was denn Datenqualitätbedeutet, und Vergleichswerte vorhanden sind. Weitere Informatio-nen zu diesen Themen finden Sie in Abschnitt 2.4, »Bedeutung derStammdaten-Roadmap«.

2.1.2 Technologie und System

Neben der Entscheidung für den Umfang von Master Data Gover-nance gibt es weitere technologische Entscheidungen. So wird keinStammdatenprojekt ohne entsprechende Tools zur Harmonisierungder Daten sowie eine entsprechende Datenmigration auskommen.Detaillierte Informationen zur Datenmigration finden Sie in Ab-schnitt 2.7, »Datenmigration und Datenharmonisierung im Projekt«.Auch das Thema Datenqualität findet sich auf der technischen Seitewieder. Hier sollten gemäß der Definition im Datenqualitätskonzeptverschiedene Reports und Auswertungstools zur Verfügung gestelltwerden, mit denen in regelmäßigen Abständen die Qualität der imSystem vorhandenen Daten überprüft werden kann.

Datenpflege-prozess

Zu den technischen Aspekten gehört auch der technische Aufbau desDatenpflegeprozesses. Wie muss ein geführter Workflow im Systemaufgebaut sein, damit er umgesetzt werden kann? Hierbei sindhauptsächlich zwei Entscheidungen zu treffen. Die erste Entschei-


Zielsetzung und Tools definieren 2.1

83

dung ist die Bearbeiterfindung, bei der die Benutzer einzeln oder inBenutzergruppen zusammengefasst den verschiedenen Schritten desWorkflows zugeordnet werden. Gemäß dieser Zuordnung werdendann die einzelnen Benachrichtigungen und Arbeitsschritte denjeweiligen Gruppen zugeteilt. Hier muss man sich also auch organi-satorisch darüber im Klaren sein, welche Mitarbeiter in den Daten-pflegeprozess eingebunden werden und für welche Bereiche siezuständig sein sollen. Der zweite Punkt ist erst seit SAP MDG 7.0relevant, denn seit dieser Version können gewisse Schritte innerhalbeines Workflows parallelisiert werden.

Aufgaben parallelisieren

In Abbildung 2.3 sehen Sie solch eine Unterscheidung. Bei den pa-rallelen Schritten werden mehrere Bearbeiter zeitgleich über die fürsie bereitstehenden Aufgaben benachrichtigt und können diese ent-sprechend abarbeiten. Allerdings handelt es sich hier nicht um einekomplette Parallelität, und es ist nur möglich, zeitgleich mit mehre-ren Änderungsanträgen an einem Datensatz zu arbeiten, wenn mansich auf unterschiedlichen Entitäten und damit auch unterschiedli-chen Änderungsantragstypen befindet. Weitere Informationen zudiesem Thema finden Sie in Abschnitt 3.2, »Datenmanagement inSAP Master Data Governance«.

Abbildung 2.3 Paralleler vs. sequenzieller Workflow

…. PLA

….

QUA

ATR

PTS

CO ….

… PLA …. CO …



84

2.1.3 Prozesse

Auch für die Prozesse müssen Sie einige Entscheidungen treffen undZiele innerhalb des Projekts definieren. Dies fängt bei den im Projektbenötigten Prozessen zur Harmonisierung und Migration der Datenan. Hierfür müssen Sie, passend zum verwendeten Tool, die Abläufefestlegen. Über die Projektlaufzeit hinaus sind dann vor allem dieProzesse zur Datenpflege entscheidend. Hierbei sollte auch schon andas Product Lifecycle Management (PLM) gedacht werden. Dabei gehtes darum, auch einen Prozess zum Ausphasen von nicht mehr benö-tigten Materialien zu definieren. Hierfür bieten sich die im SAP-Datenmodell vorhandenen Materialstatusfelder an. Hier lassen sichnach festgelegten Regeln die Werte beim Erreichen bestimmterZustände in SAP Master Data Governance setzen. Basierend auf die-sen Zuständen lässt sich auch im Standard-ERP ein Customizing ein-richten. Wir empfehlen, diese Themen bereits frühzeitig im Projektmit den bisherigen und zukünftigen Prozessverantwortlichen inWorkshops anzugehen.

2.1.4 Organisation

Auch wenn wir uns bisher hauptsächlich mit den technischen The-men beschäftigt haben, geht es bei solch einem Projekt aber auch umdie zukünftige organisatorische Ausrichtung des Unternehmens imStammdatenbereich. Dies ist von besonderer Bedeutung, da die hiergetroffenen Entscheidungen weitreichenden Einfluss haben können.Eine Fragestellung ist hierbei, ob die Datenpflege in einer zentralenoder einer dezentralen Stammdatenorganisation passieren soll.

Zentrale oderdezentrale

Datenpflege

Während bei einer dezentralen Organisation die Hoheit über dieDatenpflege in den unterschiedlichen Ländern oder Funktionsberei-chen liegt, bedeutet eine zentrale Organisation, dass nur wenigeMitarbeiter an einem zentralen Standort für die Pflege der Datenzuständig sind. Bei dieser Entscheidung sollten Sie auch die Perso-nalabteilung oder eventuell den Betriebsrat miteinbeziehen. Sie hatauch entsprechenden Einfluss auf den Workflow: Entweder müssendezentral mehrere unterschiedliche Bereiche im Datenpflegepro-zess miteinander verbunden werden, oder es muss ein Weg gefun-den werden, auf dem alle benötigten Informationen für einenDatensatz bei der zentralen Pflegeorganisation ankommen. Alleinan diesen beiden Fragestellungen sieht man bereits, dass das Thema


Implementierungsszenarien 2.2

85

Organisation eine zentrale Rolle in solch einem Projekt spielensollte. Weitere Informationen hierzu finden Sie in Abschnitt 2.8,»Change- und Stakeholder-Management im Projekt«. In diesenBereich fallen auch Entscheidungen zu Ausbildung und Training derBenutzer.

Zusammenfassung

Sie haben in diesem Kapitel gesehen, dass in einem solchen Projekt sehrviele Entscheidungen zu treffen und Ziele zu definieren sind, die auf denersten Blick nicht sichtbar sind. Genau dies zeigt auch wieder die zentraleBedeutung der Stammdaten in einem integrierten System und verdeut-licht, warum viele Projekte in diesem Bereich das geplante Budget über-schreiten, falls diese Themen nicht von Anfang an berücksichtigt werden.

2.2 Implementierungsszenarien

Ist die Entscheidung für den Einsatz von SAP Master Data Governanceeinmal getroffen, müssen Sie weitere technische Fragen beantworten.Hierbei ist die enge Zusammenarbeit der IT-Abteilung und der Pro-zessverantwortlichen auf der Business-Seite extrem wichtig. Im End-effekt ist in allen Projekten dieser Art die IT-Abteilung eines Unter-nehmens der Dienstleister und das Business der interne Kunde. Fürdie Kollegen aus der IT geht es am Ende darum, wie das neue SAP-Sys-tem aus einer technischen Perspektive aus aufgebaut werden soll.Hier spielen sicher sehr viele technische Aspekte eine Rolle, und esgibt auch eine Vielzahl von Entscheidungen, die intern in der IT-Abteilung getroffen werden können. Auf der anderen Seite hat abergerade das Design der Prozesse und deren Anforderungen einen ent-scheidenden Einfluss.

Hub- oder Co-Deployment

Die Grundsatzfrage besteht darin, ob das MDG-System auf dem glei-chen Server wie das klassische SAP ERP installiert werden soll (Co-Deployment) oder ob hier eine Trennung der Systeme vorgenommenwird (Hub-Deployment). Beide Varianten haben durchaus ihreDaseinsberechtigung und je nach Anforderung auch entscheidendeVor- oder Nachteile. Es gibt kein generelles Richtig oder Falsch, son-dern jedes Unternehmen sollte unbedingt die Zeit investieren, dies inWorkshops mit allen Beteiligten auszuarbeiten. Leider werden hierauch oft die Zeit und der Aufwand gescheut, um alle Leute an einen



86

Tisch zu holen, oder man konzentriert sich viel zu sehr auf die IT-Sichtweise und vergisst dabei die Business-Verantwortlichen. Dieskann fatale Folgen haben, da dies eine Entscheidung darstellt, dienicht einfach schnell rückgängig gemacht werden kann, wenn die ers-ten Probleme auftauchen. Die Entscheidung für eine Systemarchitek-tur stellt das Fundament dar. Bei der Entscheidungsfindung sollteauch berücksichtigt werden, welche SAP-MDG-Domänen im Unter-nehmen eingesetzt werden sollen. So hat z.B. MDG-M für die Pflegedes Materialstammes andere Anforderungen aus Business-Sicht alsMDG-BP zur Pflege der Kunden- und Lieferantendaten. WeitereDetails zu den Unterschieden innerhalb der MDG-Domänen findenwir in Abschnitt 3.2, »Datenmanagement in SAP Master Data Gover-nance«.

TypischeEinsatzszenarien

Schauen wir uns hier also einmal zuerst die möglichen Szenariengenauer an. Es gibt auf der einen Seite die beiden HauptszenarienHub- oder Co-Deployment, die auch am verbreitetsten sind. Zusätz-lich ist es auch möglich, die beiden Szenarien zu mischen. Daraufgehen wir nur kurz ein, da es nur selten genutzt wird. Wenn Siedann die technischen Unterschiede verstanden haben, werden wiruns mit den Fragen beschäftigen, die sich jeder Projektbeteiligte zumZeitpunkt der Systemvorbereitung und vor der Architekturentschei-dung stellen sollte.

2.2.1 Hub-Deployment

In Abbildung 2.4 sehen Sie den typischen Aufbau eines Hub-Deploy-ment-Szenarios. Auf der einen Seite läuft SAP MDG als eigenes Sys-tem auf einem eigenen Server. Auf der anderen Seite sehen Sie dieApplikationsebene mit SAP ERP und weiteren Systemen. In solcheinem Szenario kann SAP MDG direkt über eine Standard-ALE-Ver-teilung angebunden werden. Diese Variante benötigt kein SAP Pro-cess Orchestration (SAP PO), ist jedoch weniger flexibel. Das heißt,die Daten werden einfach 1:1 aus dem Hub in das empfangende Sys-tem übertragen. Wird hier eine gewisse Flexibilität benötigt, sosollte auf SAP PO zurückgegriffen werden.

SAP-PO-Mappingund Prozess-

steuerung

SAP Process Orchestration ist der Nachfolger von SAP Process Inte-gration (SAP PI; davor SAP XI). Dies ist eine zentrale Schnittstelle,über die die gesamte Datenverteilung gesteuert wird. Innerhalb die-ser Schnittstelle können z.B. verschiedene Mappings vorgenommen



87

werden. Dies wird vor allem dann interessant, wenn nicht nur SAPERP, sondern auch ein Drittsystem versorgt werden soll. Neben demMapping von Daten ist SAP Process Orchestration auch das zentraleSteuerelement, in dem alle Informationen über den Prozessablaufdefiniert und hinterlegt werden.

Abbildung 2.4 Systemlandschaft beim Hub-Deployment

AnwendungsfälleFolgende Anwendungsfälle lassen sich typischerweise in SAP ProcessOrchestration abbilden:

� Mapping von einzelnen Feldern:Das Feldmapping ist für die Verbindung der Datenmodelle ent-scheidend. Die Informationen, die es in einem sendenden Systemgibt, müssen nicht zwingend an gleicher Stelle im empfangendenSystem abgelegt sein. Dies ist hauptsächlich der Fall, wenn es sichnicht bei allen Systemen um SAP-Systeme, sondern auch um Sys-teme von Drittanbietern handelt. Ein klassisches Beispiel hierfürsind Adressdaten. Die Ablage von Namen, Ansprechpartnern oderauch Zusatzinformationen ist oft auf unterschiedliche Art undWeise gelöst. Durch das passende Feldmapping in SAP ProcessOrchestration kann so jederzeit der Wert aus Feld A in System 1 inFeld B in System 2 verteilt werden.

� Eine weitere typische Anforderung bei der Verteilung von Datenist das Wertemapping. Das heißt, dass die Information zwarschon in einer gewissen Form vorliegt, die Werte in den verwen-deten Prüftabellen der Systeme jedoch nicht identisch sind. Diesbezieht sich meist auf das verwendete Schlüsselattribut. Nehmenwir als Beispiel die Situation, dass die Information »Ja« aus demeinen System in das andere übermittelt werden soll. »Ja« kann

* SAP Process Orchestration. Nicht zwingend notwendig

WeitereSAP-Systeme

z.B. CRM, BI …

SAP ERP

Fremdsysteme

SAP MDG SAP PO*



88

jetzt »Ja«, »J«, »Yes«, »Y« oder einfach nur ein Flag »X« sein. Sinddie Werte in den zur Validierung der Daten verwendeten Prüf-tabellen unterschiedlich, wird das System immer einen Fehler beider Übertragung der Daten ausgeben. Also wird hier eine entspre-chende Übersetzung der Daten benötigt.

In Abbildung 2.5 ist ein Aufbau für die oben beschriebenen Feld-bzw. Wertemappings grafisch dargestellt. Hierbei ist auch ersicht-lich, dass viele unterschiedliche Systeme mit verschiedensten Regelnfür ein und dasselbe Feld aus dem sendenden System hinterlegt wer-den können.

Abbildung 2.5 SAP Process Orchestration: Mapping für Feld und Daten

SAP PO undHub-Deployment

Schauen wir uns noch ein paar weitere typische Anwendungeninnerhalb von SAP Process Orchestration und deren Verwendung inKombination mit einem Hub-Deployment an:

� Es ist nicht immer zwingend notwendig oder oftmals sogar explizitnicht gewünscht, alle Daten aus dem zentralen Stammdatensystemauch auf allen empfangenden Systemen zur Verfügung zu stellen.Dies lässt sich durch SAP PO in Kombination mit dem Hub-Deploy-

Fieldmapping Datenfeld

Fieldmapping Dateninhalt

SAP PO

SAP PO

Feld Inhalt

Gefahr X

Feld Inhalt

Name3 Maier

SAP MDG

Feld Inhalt

Name1 Maier

Feld Inhalt

Nam Maier

Feld Inhalt

NNam Maier

SAP MDG

Feld Inhalt

Gefahr Ja

Feld Inhalt

Gefahr Ja

Feld Inhalt

Gefahr Yes



89

ment sehr einfach steuern. Zunächst werden alle Daten aus demMDG-System an SAP PO übermittelt und dort zur weiteren Verar-beitung zur Verfügung gestellt. Innerhalb von SAP PO kann nundefiniert werden, welche Systeme welche Daten in welchem Um-fang empfangen sollen. Dies erfolgt dann natürlich auch immer inKombination mit eventuellen inhaltlichen Mappings.

� Neben der selektiven Verteilung an ausgesuchte Systeme ist aucheine Verteilung mit Bedingungen möglich. Das heißt, eine Vertei-lung der Daten findet abhängig vom Erfüllungsgrad bestimmterRegelwerke statt, die sich flexibel definieren lassen. Diese Regel-werke können entweder in SAP PO oder aber schon innerhalb vonSAP MDG eingerichtet werden. Auch hier lassen sich diese Regelnbeliebig kombinieren. So kann z.B. die Verteilung auf ausgewählteSysteme nicht nur durch Fixwerte beschrieben, sondern auchabhängig vom Pflegegrad oder der Qualität eines Datensatzesbestimmt werden. Ein typisches Beispiel ist die Verwendung desglobalen oder werksübergreifenden Materialstatus. Über diesesFeld ist es möglich, bestimmte Prozesse im klassischen SAP ERP zublockieren oder mit Warnungen zu versehen. So haben Produk-tions-, Einkaufs- und Vertriebsprozesse unterschiedliche Anforde-rungen an den Pflegegrad eines Datensatzes. In SAP MDG bietetsich nun die Möglichkeit, solche Etappenziele im Pflegeprozessmit einem bestimmten Materialstatus zu verbinden. Jedes Mal,wenn solch ein Ziel erreicht wird, wird der Statuswert im Materi-alstamm entsprechend nach oben gesetzt. Erst wenn im Vorfelddefinierte Werte erreicht werden, erfolgt eine Verteilung an die inder Regel hinterlegten empfangenden Systeme.

� Eine weitere Option ist die Definition von zeitlichen Abläufen.Oftmals wird gewünscht, den Zeitraum zur Pflege der Datensätzeund deren produktiven Einsatz zeitlich voneinander zu trennen.Die unterschiedlichen Domänen von SAP MDG bieten hier einenunterschiedlichen Funktionsumfang. Details hierzu finden Sie inAbschnitt 3.2, »Datenmanagement in SAP Master Data Gover-nance«. Schauen wir uns aber hierzu einmal zwei typische Bei-spiele aus dem Alltag an:

– Im ersten Beispiel geht es um den Finanzbereich (DomäneMDG-F). In Ihrem Unternehmen soll für das nächste Jahr eineneue Kontenplanstruktur eingerichtet werden. Dies kann z.B.durch innerbetriebliche Optimierungen oder durch die Integra-



90

tion einer weiteren Firma notwendig werden. Diese neue Struk-tur soll ab dem 01.01. des Folgejahres gültig sein. Je nach Größedes Unternehmens kann solche eine Kontenplanstruktur sehrgroß werden, sie muss aber am 01.01. zum produktiven Einsatzzur Verfügung stehen. Es ist nicht sinnvoll, dass dann jemandgenau an diesem Tag diese Daten anlegen muss, abgesehendavon, dass es in den meisten Fällen weder zeitlich noch perso-nell möglich ist.

– In der zweiten Situation kündigt ein Großkunde oder LieferantIhrer Firma einen Umzug des Firmensitzes an. In unserem Sys-tem finden sich einige Hundert oder sogar Tausend Datensätzefür Liefer- oder Rechnungsadressen sowie die dazugehörigenAnsprechpartner. Natürlich besteht nun auch hier der Wunsch,diese Datensätze schon im Vorfeld im System pflegen zu kön-nen, sie aber erst am Tag des Geschäftsbeginns am neuen Fir-mensitz produktiv zu schalten.

In beiden Beispielen geht es also darum, die Daten zur richtigenZeit in der notwendigen Qualität zur Verfügung zu stellen, gleich-zeitig aber die Arbeitslast entsprechend im Vorfeld zu verteilen. InMDG-F gibt es dazu schon eine spezielle Standardfunktionalität,die wir in Abschnitt 3.8.2, »Editionen innerhalb von MDG-Finan-cial«, detailliert beschreiben. Steht uns diese Funktionalität in denanderen MDG-Domänen nicht zur Verfügung, bestehen zwei wei-tere Möglichkeiten: eine kundenspezifische Entwicklung in SAPMDG, mit der die speziellen Anforderungen abgedeckt werdenkönnen, oder SAP PO mit einem Hub-Deployment. In Abbildung2.6 sehen Sie, wie man mit SAP PO eine zeitgesteuerte Verteilunggestaltet.

Hier gibt es jedoch ein paar Einschränkungen, die Sie im Vorfeldkennen sollten. Schauen wir uns deswegen noch einmal das Beispielder zu ändernden Adressdaten an. Diese Datensätze können nun imVorfeld bereits in MDG-BP überarbeitet werden. Solange noch keineVerteilung der Daten durch SAP PO erfolgt, hat dies erst einmal kei-nen Einfluss auf die produktiv genutzten Daten in SAP ERP. Dasheißt, hier kann SAP PO als Gateway benutzt werden, um die Datenerst zum gewünschten Datum ins ERP zu verteilen. Hierbei mussaber unbedingt beachtet werden, dass dann in dem Zeitfenster zwi-schen der Pflege und der gewünschten Verteilung kein weiteresUpdate des Datensatzes aus SAP MDG gemacht werden kann. Im



91

Normalfall wird es eher selten sein, dass an diesen Datensätzen vordem Update auf die neue Adresse nun noch weitere Änderungennotwendig sind. Aber auch über diese Wahrscheinlichkeit sollte mansich Gedanken machen. Ansonsten würde die neue Adresse schonbereits mit der nächsten Änderung an weiteren Datenfeldern insERP-System laufen, da der Datensatz nicht explizit gesperrt ist.

Abbildung 2.6 Zeitgesteuerte Verteilung mit SAP PO als Workaround

IDoc oder Webservice

Haben Sie sich in einem Hub-Deployment für den Einsatz von SAPPO entschieden, müssen Sie entscheiden, ob die Daten über SAP POdirekt per IDoc oder per Webservice verteilt werden sollen. Bei bei-den Technologien handelt es sich um Standardfunktionalitäten vonSAP, wobei das IDoc die ältere, aber auch sehr stabile Technologiedarstellt. Schauen wir uns auch hier zuerst einmal die Unterschiedean, bevor wir auf die jeweiligen Vor- und Nachteile eingehen.

Bei einem IDoc handelt es sich im Endeffekt um eine elektronischauswertbare einfache ASCII-Textdatei in einem definierten Format.

SAP MDG

Str.

Feld InhaltDatum

23.02.16 Hauptstr. 1

SAP MDG

Str.

Feld InhaltDatum

25.02.16 Nebenstr. 5

SAP MDG

Str.

Feld InhaltDatum


SAP PO

Str.

Feld InhaltGültig ab


SAP PO

Str.



SAP PO

Str.



SAP ERP

Str.

Feld InhaltDatum


SAP ERP

Str.

Feld InhaltDatum


SAP ERP

Str.

Feld InhaltDatum




92

Die Idee dahinter war es, Transaktionen zu beschleunigen, Transak-tionskosten zu verringern und Medienbrüche zu vermeiden. Gleich-zeitig werden bei einem IDoc auch Statusinformationen zum Daten-satz selbst übermittelt. Das heißt, sowohl auf einem sendenden alsauch auf einem empfangenden System lässt sich immer sehen, obder Datensatz übertragen bzw. in der Datenbank verbucht werdenkonnte. Hierbei werden bei der automatisierten Verbuchung diegleichen Prüfungen durchlaufen wie bei einer manuellen Eingabeder Daten.

Der Webservice ist die neuere Technologie. Es handelt sich dabei umein XML-basiertes Protokoll für den Informationsaustausch in einerdezentralen, verteilten Umgebung. In Tabelle 2.1 finden sich dieVor- und Nachteile beider Technologien.

Vor- undNachteile des Hub-

Deployments

Nachdem wir nun das Thema Hub-Deployment und die wichtigstendamit verbundenen technischen Bereiche ausführlich betrachtet ha-ben, schauen wir hier uns die Vorteile und Nachteile nochmals in derZusammenfassung an.

Vorteile

� Da SAP MDG im Hub über eigene Datenbanktabellen verfügt, gibtes eine Trennung der Stammdaten von den Daten, die im ERPdirekt verwendet werden. So sind Daten, die nur für Drittsysteme

IDoc Webservice

+ stabile Technologie – Service benötigt eigenes Design-Tool

+ Fachkenntnis weit verbreitet – Fachkenntnis nicht so weit verbreitet

+ IDoc für alle MDG-Domänen verfügbar

– Service nicht für alle MDG-Domänen verfügbar

+ Recht einfaches Handling beim Aufbau und Monitoring

– Service nicht für alle MDG-Domänen verfügbar

– Anbindung an Drittsysteme benötigt IDoc-Konverter

+ einfachere Anbindung an Nicht-SAP-Systeme

– pro Datenelement ein IDoc, Risiko falscher Reihenfolge bei Problemen

+ mehrere Datenelemente in einem Service, z.B. bei Adressdaten

Tabelle 2.1 IDoc vs. Webservice



93

benötigt werden, nicht im ERP sichtbar und tauchen auch nicht inallen Transaktionen oder Reports als mögliche Daten- oder sogarFehlerquellen auf.

� Die Entwicklungszeiten von SAP MDG und SAP ERP sind nichtidentisch. Im Moment gibt es deutlich häufiger neue Patchlevel fürSAP MDG als für das klassische ERP. Durch das Hub-Deploymentkönnen die Releasezyklen und Wartungsfenster der Systemegetrennt gesteuert werden, und das ERP-System ist nicht voneinem Update des MDG-Systems betroffen.

� SAP bietet verschiedene Wartungsverträge mit unterschiedlichenReaktionszeiten. Je schneller die Reaktionszeit ist, desto höher istauch der Preis. Für ein produktives ERP ist eine schnelle Lösungabsolut essenziell. Für SAP MDG reicht eventuell jedoch ein nied-rigerer Support-Level aus.

� Durch die Trennung der beiden Systeme ERP und MDG könnenAktivitäten wie Datenmappings usw. auf der Schnittstelle (z.B.SAP PO) ausgeführt werden.

� Gerade in Projektphasen gibt es zeitliche Restriktionen, die durchdie verschiedenen Testzyklen vorgegeben werden. Durch zweiunabhängige Systeme können auch hier MDG-spezifische Ent-wicklungen getrennt vom ERP-System umgesetzt werden.

Nachteile

� Jedes zusätzliche System verursacht erheblichen Zusatzaufwandbei Unterhalt und Wartung, wie weitere Hardwarekosten, aberauch zusätzliche Lizenzen und Arbeitsaufwand bei der IT-Basis.

� Es muss sichergestellt sein, dass das Customizing und die Prüfta-bellen auf den beiden Systemen identisch sind. Dies bedeutet ent-weder sehr viel manuelle Arbeit oder den Einsatz eines weiterenTools zur synchronen Verteilung aller Einstellungen. Hier sollteder SAP Solution Manager zum Einsatz kommen.

� Die Schnittstellen zwischen den beiden Systemen bieten zwarviele Vorteile, bringen jedoch wieder zusätzlichen Aufwand mitsich. Hierfür muss das entsprechende Know-how vorhanden sein.Außerdem muss jede existente Schnittstelle auch gewartet werdenund bei möglichen Updates ebenfalls auf die weitere Funktionali-tät geprüft werden.



94

� Das ERP-System bietet bereits im Standard verschiedene Validie-rungsregeln, das heißt, abhängig von einem bestehenden Custo-mizing sind nur bestimmte Werte zulässig. Außerdem lassen sichsteuernde Inhalte, wie z.B. eine Basismengeneinheit oder einChargenkennzeichen, nicht mehr ändern, wenn auf einem Mate-rial schon einmal eine Warenbewegung stattgefunden hat. DieseInformationen über Warenbewegungen sind im MDG-Hub-Sys-tem jedoch nicht verfügbar. Das heißt, eine Validierung muss hierauf eine andere Art und Weise gelöst werden. Dies kann auf derorganisatorischen Ebene sein, sodass solche steuernden Felder nurvon bestimmten Personen gepflegt werden können, oder tech-nisch muss die bereits im Standard des ERP existierende Lösungim MDG-Hub nachgebaut werden.

2.2.2 Co-Deployment

Nachdem wir uns im vorigen Abschnitt ausführlich mit dem Setupals Hub-Deployment beschäftigt haben, schauen wir uns hier nuneinmal die Installation von SAP MDG im Co-Deployment an. In solcheinem Szenario werden das klassische SAP ERP und SAP MDG aufdem gleichen Server installiert. In Abbildung 2.7 sehen Sie solch eineSystemlandschaft.

Abbildung 2.7 Systemlandschaft beim Co-Deployment

Tabellen werdengeteilt

Da sowohl das klassische ERP als auch SAP MDG auf dem gleichenServer laufen, teilen sich diese Systeme auch die entsprechendenDatenbanktabellen. Dies ist ein entscheidender Unterschied zu derSystemlandschaft, in der SAP MDG als Hub installiert ist, und bringtauch entsprechende technische Vorgaben mit sich. Da die Datenbank

SAP MDG& SAP ERP

WeitereSAP-Systeme

z.B. CRM, BI …

Fremdsysteme



95

geteilt wird, liegt die Staging Area von SAP MDG ebenfalls direkt aufdiesem Server (Details dazu finden Sie in Abschnitt 3.2, »Datenma-nagement in SAP Master Data Governance«). Dadurch ist eine Vertei-lung der Daten von SAP MDG ins ERP über eine Middleware wieSAP PO nicht notwendig. Genau dies nimmt einem aber auch all dieflexiblen Möglichkeiten aus Abschnitt 2.2.1, »Hub-Deployment«.Hier ist es also auch wichtig, sich über Einschränkungen im Klaren zusein. Speziell im Hinblick auf die zukünftige Strategie des Unterneh-mens kann eine Entscheidung für ein Co-Deployment aktuell zwareinige Vorteile bieten, aber langfristig zu statisch sein. Je nachdem,wie das Unternehmen organisatorisch aufgestellt ist, sollte man sichauch sehr genau überlegen, ob wirklich alle Daten, die über denGovernance-Prozess in SAP MDG angelegt und gepflegt werden,auch in den Tabellen, Transaktionen und Reports des SAP-ERP-Sys-tems sichtbar oder sogar benutzbar sein sollen. Dies ist vor allemdann kritisch, wenn es im Unternehmen viele unterschiedliche IT-Systeme gibt, die zwar mit Stammdaten aus dem MDG-System ver-sorgt werden sollen, selbst jedoch keinen Bezug zum SAP-ERP-Sys-tem besitzen. Dies hat dann zur Folge, dass alle Daten, die z.B. nurfür spezielle Prozesse oder in Gesellschaften, die noch ihr eigenesERP-System betreiben, benötigt werden, auch in den Stammdaten-tabellen des ERP-Systems verfügbar sind, obwohl sie auf diesem Sys-tem niemals für einen operativen Prozess eingesetzt werden. Dies istfür User verwirrend, außerdem müssen Auswertungen von diesenDaten bereinigt werden.

DatensicherheitHier spielen auch Datensicherheit und Berechtigungen eine Rolle:Während sich Daten in Tabellen, die einer Organisationseinheit wieWerk, Lagerort, Buchungskreis usw. durch entsprechende Berechti-gungen den passenden Usern zugänglich gemacht werden können,lässt sich dies in den organisationseinheitenübergreifenden Tabellennicht so einfach realisieren und die Daten sind für jeden Benutzerzugänglich.

Vorteile

� SAP MDG und ERP auf einem System reduzieren zunächst die Kos-ten für die Systemlandschaft. Es wird kein separater Server für SAPMDG benötigt. Außerdem ist auch der Wartungsaufwand für dieSAP-Basis des Unternehmens geringer.



96

� Customizing-Einstellungen des ERP sind automatisch auch für denMDG-Bereich gültig. Es muss keine spezielle Umgebung oder einProzess zur Harmonisierung und zum Transport der Customizing-Einstellungen zwischen ERP und SAP MDG eingerichtet werden.

� Standardvalidierungsregeln des ERP können auch direkt im MDG-System verwendet werden. Auch Validierungen, die auf transakti-onalen Daten wie Beständen oder Bestellungen basieren, sinddurch den direkten Zugriff auf die ERP-Daten möglich.

Nachteile

� Alle in SAP MDG gepflegten Daten werden in den gemeinsamgenutzten Tabellen des SAP-ERP-Systems gespeichert und tauchendamit in Transaktionen und Reports auf dem ERP-System auf, auchwenn diese Materialien, Kunden, Lieferanten usw. nur in Umsys-temen benötigt werden.

� Es ist nicht möglich, flexibel auf unterschiedliche Wartungsfensterdes SAP-ERP- und des MDG-ERP-Systems einzugehen. Gerade dieskann aber durch den unterschiedlichen Innovationsgrad der beidenProdukte von großem Vorteil sein. Im Co-Deployment heißt diesaber, dass ein häufigeres System-Upgrade des MDG auch direktenEinfluss hat und eine daraus resultierende Systemwartung des SAPERP bedingt.

� Es sind keine getrennten Entwicklungszyklen in einer Projektum-gebung möglich. Auch gekapselte Entwicklungen im MDG-Umfeldfinden auf dem ERP-Server statt und bedingen somit auch jeweilsein passendes Zeitfenster für Test und Transport. Auch ein entspre-chender Regressionstest auf den SAP-ERP-Prozessen wird damit not-wendig.

� Ein möglicherweise notwendiges Feld oder Inhaltsmapping fürunterschiedliche empfangende Systeme lässt sich nicht so einfachimplementieren. Natürlich kann auch hier SAP PO zur Verteilungder Daten an Drittsysteme eingesetzt werden, allerdings im Gegen-satz zum Hub-Deployment erst, nachdem die Datensätze bereits inden gemeinsam genutzten Tabellen des SAP-ERP-Systems vorhan-den sind.

� Unterschiedliche Standardfunktionalitäten der verschiedenen MDG-Domänen lassen sich nicht durch Workarounds innerhalb der Pro-cess Orchestration zwischen dem MDG- und SAP-ERP-System aus-gleichen.



97

2.2.3 Hybrid-Hub- und Co-Deployment

Neben den beiden klar abgetrennten Szenarien aus Abschnitt 2.2.1und 2.2.2 gibt es auch ein Hybridszenario, also eine Vermischungder beiden Konzepte. Solch einen Fall sehen Sie in Abbildung 2.8.Hierbei werden zwei Installationen von SAP MDG verwendet. Dieerste läuft auf einem eigenen Server als Hub-Umgebung, die zweitebefindet sich auf dem gleichen Server wie das klassische SAP ERPund teilt sich damit auch die darunter liegenden Datenbanken.

Abbildung 2.8 Systemlandschaft als Hybrid-Deployment

Vor- und NachteileDie Idee hinter solch einer Systemlandschaft ist es, die Vorteile beiderSzenarien zu vereinen und quasi das Beste aus beiden Welten zubekommen. Hierbei sind ebenfalls wieder verschiedene Konstellatio-nen möglich, z.B. nach MDG-Domänen unterschiedene Installatio-nen. So könnte MDG-BP für Kunden und Lieferanten getrennt aufdem Hub laufen, während MDG-M für den Materialstamm auf demSAP-ERP-Server aufsetzt und somit in den Validierungsregeln auch aufBewegungsdaten des SAP ERP zurückgreifen kann. Neben solch einerTrennung gemäß den MDG-Domänen ist aber auch eine Trennunginnerhalb einer Domäne denkbar. Nehmen wir einmal MDG-M fürden Materialstamm als Beispiel. Wir wie zuvor gesehen haben, bietetdie gemeinsame Verwendung der Tabellen einige Vorteile in Bezugauf die Datenvalidierung im Anlage- oder Update-Prozess. Gleichzei-tig ist es aber ein großer Nachteil, wenn alle Materialstammdaten auf

* SAP Process Orchestration. Nicht zwingend notwendig

WeitereSAP-Systeme

z.B. CRM, BI …

SAP ERP

Fremdsysteme

SAP MDG SAP PO*SAP MDG



98

einem System verfügbar sind und jeder User auch die Basisdaten ein-sehen kann. In solch einem Fall wäre es denkbar, die Basisdaten (imSAP-System die MARA-Daten) auf einem Hub-System zu pflegen,während die organisationseinheitsspezifischen Daten (z.B. MARC-und MARD-Datentabellen) auf dem Co-Deployment-MDG in einemFolge-Workflow gepflegt und ergänzt werden. Dies hat den Vorteil,dass wirklich nur diejenigen Basisdaten auf dem SAP-ERP-System vor-handen sind, die dann später in den jeweiligen Werken bzw. Lager-orten im täglichen Produktivbetrieb benötigt werden. Solch ein Setupeiner Systemlandschaft ist also durchaus möglich und bietet auch fürspezielle Anforderungen sehr flexible Möglichkeiten. Allerdings istsie eher theoretischer Natur und in der Realität ein wirklicher Exot.

Vorteile

� Datentrennung über unterschiedliche Systeme und trotzdem Vali-dierungsmöglichkeiten auf transaktionalen Daten

� flexible und vielseitige Aufteilung in unterschiedliche Domänenoder innerhalb einer Domäne

Nachteile

� hohe Kosten durch mehrere MDG-Installationen und damit ver-bundene Lizenzkosten

� erhöhter Wartungsaufwand für SAP-Basis-IT

� komplexe Schnittstellen und Workflowsteuerung zur Verknüp-fung der unterschiedlichen Systeme und Pflegeprozesse

� höherer Schulungsaufwand für komplexe Datenanlage- und Datenpflegeprozesse bei den betroffenen Usern

� komplexes Berechtigungskonzept

2.2.4 Fragestellungen zur Entscheidung für eine Architektur

EntscheidendeFragen

Nach diesem Überblick über die möglichen Implementierungen wol-len wir uns nun noch den zentralen Fragestellungen widmen, die vorder finalen Entscheidung für ein Szenario unbedingt genau durch-dacht und mit allen Stakeholdern diskutiert werden sollten:



99

� Sollen nur die für das jeweilige ERP relevanten Datensätze (Mate-rialien, Kunden, Lieferanten) sichtbar sein oder immer alle Daten-sätze, auch wenn diese zu Nicht-SAP-Systemen oder -Organisati-onseinheiten gehören?

� Soll es eine Möglichkeit zur zeitgesteuerten Verteilung der Stamm-daten geben, auch wenn dies nicht im Standard der jeweiligenMDG-Domäne unterstützt wird?

� Soll es möglich sein, unterschiedliche Archivierungsanforderun-gen pro System handhaben zu können (wobei MDG weiterhin alleDaten vorhält)?

� Soll es eine getrennte Release-Fähigkeit zwischen MDG und demStandard-ERP-System geben?

� Werden unterschiedliche Service Level Agreements für das Stan-dard-SAP-ERP und das MDG-System benötigt oder gewünscht?

� Welche MDG-Domänen sollen eingesetzt werden?

� Welche Anforderungen bestehen an Governance-Level und Berech-tigungskonzept?

� Ist bereits eine Middleware wie SAP PO im Einsatz, oder soll dieStandard-ALE-Verteilung genutzt werden?

� Sollen komplexe Validierungsregeln genutzt werden, die auch Infor-mationen aus transaktionalen Daten benötigen?

� Sollen Customizing-Einstellungen des ERP auch direkt in SAPMDG verwendbar sein, ohne Einsatz eines Systems zur synchro-nen Verteilung?

Empfehlungen zum System-Setup

Hier gibt es keine pauschal gültige Empfehlung: Jedes Unternehmen hatspezielle Anforderungen, unterschiedliche Ausgangssituationen und einenanderen Anspruch an den Level der Governance. Aus unserer Erfahrunglässt sich jedoch sagen, dass das Setup als Hub-Deployment für die meistenUnternehmen und Anforderungen die ausgewogenste Variante darstellt.Dies ist also ein guter Startpunkt für die Diskussion. Identifizieren Sie dannz.B. in Workshops mit IT und Business Process Ownern explizite Themen,die mit einem Hub-Deployment nicht abgedeckt werden können. Diesekönnen dann weiter vertieft betrachtet werden. In den meisten Fällenmüssten jedoch sehr gewichtige Gründe vorliegen, um deswegen die Sys-temlandschaft auf eine andere Art und Weise aufzusetzen.


15

1

Einleitung

Als langjährige Stammdaten-Praktiker besuchen wir immer wiederKonferenzen zum Thema Stammdatenmanagement. Diese werdendankenswerterweise von den Softwareherstellern stark unterstützt.Der Schwerpunkt der Vorträge auf diesen Konferenzen und in denDiskussionen der Teilnehmer untereinander liegt jedoch fast immerauf der Technologie, die verwendet wird, um dem Thema Herr zuwerden.

Eine ähnliche Fokussierung erleben wir auch während der Stammda-tenprojekte in unserem Alltag. Wir sehen dabei immer wieder, dasssich die Umfangsbeschreibung der Projekte zunächst mit den techni-schen Komponenten befasst. Nachdem alle Instrumente, die mögli-cherweise zum Einsatz kommen, benannt und beschrieben wurden,stellt sich meist die Frage, wie diese intelligent integriert werdenkönnen und warum es scheinbar Überlappungen gibt. Diese Fragensind zwar wichtig, genau wie die Technologie, verstellen allerdingsden Blick auf andere Komponenten, die ebenfalls wichtig sind, wennSie sich erfolgreich mit dem Thema Stammdatenmanagement ausei-nandersetzen möchten. Leider führt die starke Konzentration auftechnische Aspekte oft zu Konfusion und Missverständnissen, wennes um das Thema Stammdatenmanagement geht.

ZielsetzungWir haben es uns daher im vorliegenden Buch zur Aufgabe gemacht,das Thema Stammdatenmanagement umfassender darzustellen, alses oft diskutiert wird. Wir wollen gerade die Balance zwischen Tech-nik, Organisation, Prozessen, Methodik und Datenqualität beschrei-ben, die Sie aus unserer Sicht benötigen, um langfristig erfolgreichzu sein. Unserer Überzeugung nach stellt das Meistern der Stamm-datenherausforderung eine Kernvoraussetzung dar, um den unaus-weichlichen und mächtigen Wirkungen der digitalen Transformationin allen Lebensbereichen – vor allem aber in den unternehmeri-schen – Stand zu halten. Ohne nachhaltig gute Stammdaten wird derErfolg der digitalen Initiativen schwer zu erreichen sein.

Da die Begriffe Master Data Governance (MDG) und Master DataManagement (MDM) zu den zentralen Themen dieses Buches gehö-ren und in jedem Kapitel immer wieder auftauchen, möchten wirhier eine zentrale Unterscheidung der beiden Begriffe vornehmen.


Einleitung

16

Master DataManagement

Unter MDM, also Stammdatenmanagement, verstehen wir alle Akti-vitäten rund um den konzeptionellen Aufbau der Stammdaten IhresUnternehmens. Dies beinhaltet strategische, taktische und organisa-torische Aspekte, außerdem die Entscheidung für das technologischeUmfeld sowie die Auswahl geeigneter Methoden zur Verbesserungund zum Erhalt der Stammdatenqualität. Prinzipiell ist MDM zu-nächst technologieneutral zu verstehen, also nicht auf ein bestimmtesWerkzeug begrenzt. Stammdatenmanagement setzt sich aus der Defi-nition von Prozessen, Organisationen, Betriebsrichtlinien und einersystemunterstützten Benutzerführung zusammen. Das Managementkann nach Aufstellung der Konzepte mit unterschiedlichen techni-schen Ansätzen umgesetzt werden.

SAP MDG In Abgrenzung zum generischen MDM-Ansatz widmet sich diesesBuch speziell der Umsetzung des MDM-Ansatzes mit SAP MDG.Hierbei handelt es sich um ein konkretes Werkzeug von SAP, dasspeziell zur Unterstützung von MDM-Konzepten entwickelt wurde.Im Vordergrund steht hier der Governance-Aspekt. Unter dem Be-griff Governance verstehen wir einen durch das Unternehmen defi-nierten Prozess zum Anlegen neuer oder zum Pflegen von bestehendenDaten, inklusive Verfahrensanweisung, technologischer Umsetzungund organisatorischer Einbettung. Governance dient zum einen der Be-nutzerführung (z.B. durch Workflows), zum anderen stellt sie den An-wendern Werkzeuge bereit, die es ihnen ermöglichen, ihre Aufgabenmit aller notwendigen Freiheit, aber auch gleichzeitig mit dem ange-brachten Maß an Kontrolle zu erfüllen.

Aufbau

In diesem Abschnitt stellen wir nun den Inhalt der Kapitel vor, damitSie sich einen Überblick verschaffen können, welche Bandbreite anThemen im vorliegenden Buch behandelt wird. Darüber hinaus hel-fen Ihnen der Index des Buches sowie das Inhaltsverzeichnis, sichim Buch zu orientieren.

Die Kapitel In Kapitel 1 klären wir zunächst, warum Sie sich überhaupt mit demThema Stammdaten beschäftigen sollten. Wir werden darstellen,welche Bedeutung Stammdaten für die Organisation haben, und bie-ten eine erste Struktur an, in der Stammdateninitiativen konzeptio-nell gedacht werden können. Darüber hinaus stellen wir die Frage:


Aufbau

17

Wem im Unternehmen sind welche Stammdaten wichtig und auswelchem Grund?

Außerdem stellen wir Definitionen der zentralen Stammdatenob-jekte bereit und bestimmen die Kernbereiche guter Stammdaten-Governance, bevor wir typische Ausgangssituationen von Stammda-tenprogrammen darstellen. Darüber hinaus schauen wir uns auchnoch die Erfolgsfaktoren guter Stammdatenprojekte an, die über denGo-Live hinausgehen.

In Kapitel 2 widmen wir uns der Frage, was Sie beim Start der Pla-nung und Implementierung Ihrer Stammdateninitiative beachtensollten. Wir geben Ihnen wichtige Entscheidungshilfen, mit denenSie das für Sie passende Stammdatenimplementierungsszenario fin-den: Hub- oder Co-Deployment bzw. ein Hybridszenario. Darüberhinaus beschreiben wir zentrale Elemente guter Stammdaten-Gover-nance. Insbesondere schauen wir uns das Zusammenspiel zwischenStammdatenstrategie und Stammdaten-Roadmap an. Dabei betrach-ten wir auch, wie viel Governance ein Unternehmen braucht undwas gutes Datenqualitätsmanagement bedeutet. Schließlich beschrei-ben wir Datenharmonierungs- und Migrationskonzepte und dasMDM-Change- und Stakeholder-Management.

Kapitel 3 bietet Ihnen einen ausführlicheren Einblick in die Stan-dardfunktionen des zentralen Werkzeugs dieses Buches: SAP MasterData Governance. SAP MDG ist die SAP-Stammdatenplattform, mitderen Hilfe wir die meisten unserer Stammdatenprojekte absolvierthaben. Die Plattform ist standardmäßig für die Objekte Material,Kunden, Lieferant und Finanzen einsetzbar. Darüber hinaus bietetsie auch die Möglichkeit, kundeneigene Objekte zu verwalten. Wirstellen Ihnen zuerst alle Objekte im Detail vor und gehen dann aufdie zentralen Eigenschaften der MDG-Lösung ein. Dazu zählen unteranderem die Konzepte von Active und Staging Area, die Objekte desChange Requests, die Debitoren-Kreditoren-Integration, das Replica-tion & Business Rule Framework, Hierarchien und Editionen.

In Kapitel 4 widmen wir uns dem Zusammenspiel mit Komponenten,die mit MDM verwandt sind. Dabei handelt es sich um Komponenten,die komplementär mit SAP MDG eingesetzt werden. Wir beschrei-ben, welche Vorteile die Werkzeuge im Zusammenspiel mit SAPMDG haben und welche Use Cases dadurch abgedeckt werden kön-nen. Die Werkzeuge stellen aus unserer Sicht eine gute Ergänzung zu


Einleitung

18

SAP MDG in den Bereichen User Interface, Analytik, Regeldefinition,Integration und Governance-Erweiterung bereit. Wir betrachten diefolgenden Werkzeuge: SAP Fiori, SAP Data Services und SAP Infor-mation Steward, SAP Process Orchestration (PO), SAP Business Pro-cess Management (BPM), SAP Business Workflow (BWF) und SAPLumira.

Wie Sie ein Projekt mit SAP MDG aufsetzen, erfahren Sie in Kapitel 5.Hier werden Sie sehen, welche Komponenten in Stammdatenprojek-ten besonders wichtig sind. Der spezifische Charakter von Stammda-tenherausforderungen wird hier besonders beleuchtet. Neben Rollenund Verantwortlichkeiten im Projekt betrachten wir auch konkreteAusgangssituationen und stellen mögliche Herangehensweisen vor.Ebenso bekommen Sie eine Checkliste und konkrete Werkzeuge fürdie ersten 100 Tage im Projekt, die Ihnen helfen werden, Ihr Projektzu verwalten.

Die Zeit nach dem Projekt mit dem Fokus auf der Rolle des Gover-nance-Boards und der Ausweitung des Governance-Umfangs wirdebenfalls detailliert beschrieben.

In Kapitel 6 bieten wir Ihnen vier spannende Fallstudien zumThema Stammdatenmanagement an. Sie beruhen allesamt auf unse-ren Erfahrungen. Dabei bedienen wir uns der bis dahin vorgestelltenInstrumente und Konzepte und zeigen Ihnen den Einsatz im »wah-ren Leben«. Jede Fallstudie hat eine andere Stammdatendomänezum Thema, konzentriert sich auf eine bestimmte Ausgangssituationund hat bestimmte Schwerpunkte. Während an einigen Stellen kon-krete Implementierungsanleitungen gegeben werden, werden ananderen Stellen konzeptionelle Aspekte in den Vordergrund gestellt.Damit decken wir insgesamt eine starke Bandbreite an verschiede-nen Themen ab, die grundsätzlich für alle Stammdatendomänen rele-vant sind.

Die Materialstamm-Fallstudie behandelt die Herausforderung derfehlenden Steuerungs- und Messmöglichkeiten sowie Lücken in derProdukteinführungsstrategie und der Verantwortlichkeitsprofile. Beider Fallstudie zum Kundenstamm diskutieren wir im Speziellen dieKonsolidierung des Kundenstamms, die Verbesserung der laufendenOperation durch die Konsolidierungsergebnisse und durch das inte-grierte Design des Lead-to-Cash-Prozesses. Die Fallstudie zu den


Danksagung

19

Stücklisten zeigt insbesondere die Fähigkeit von SAP MDG, auch imkundeneigenen Bereich erfolgreiche Lösungen zu implementieren.Die Finanzstamm-Fallstudie stellt die finanzstammeigenen Themenin den Vordergrund und gibt praktische Implementierungshilfen.

Stammdatennetzwerke sind das Thema von Kapitel 7. Hier reißenwir an, welche Änderungen und Herausforderungen es in den nächs-ten Jahren im Stammdatenmanagement voraussichtlich geben wird.Die Kollaboration über Organisationsgrenzen hinweg stellt Unter-nehmen vor ganz neue Herausforderungen. Der zu erwartende Nut-zen ist jedoch hoch. Wir zeigen Ihnen, welche ersten Anzeichen die-ses Wandels es gibt und wie wir diese einschätzen.

IconsUm Sie auf wichtige Informationen hinzuweisen und Ihnen so dieArbeit mit diesem Buch zu erleichtern, verwenden wir im Text Käs-ten mit folgenden Icons:

Tipp Kästen mit diesem Icon geben Ihnen Empfehlungen zu Einstellungenoder Tipps aus der Berufspraxis.

Hinweis Dieses Icon weist Sie auf zusätzliche Informationen hin.

Achtung Mit diesem Icon haben wir Warnungen oder Fallen gekennzeichnet.Auf der Website zum Buch www.sap-press.de/3969 finden Sie reich-haltigen Online-Content, z.B. Checklisten und Excel-Dateien, die Siebei Ihrer Stammdateninitiative tatkräftig unterstützen sollen.

Wir hoffen, dass wir mit diesem Buch eine anregende Lektüre vorge-legt haben, mit der Sie Ihre eigene Stammdateninitiative vorantrei-ben können.

Danksagung

Oliver Lauffer: Ich danke meiner Frau Chanelle und meiner Familie,die durch den Verzicht auf private Stunden am Wochenende und amAbend die Entstehung dieses Buches ermöglicht haben. Außerdemmöchte ich mich bei allen Kunden und Kollegen bedanken, welche invielen Diskussionen und Lösungen innerhalb der unterschiedlichs-ten Projekte neue Denkansätze ausgelöst haben.


Einleitung

20

Jan Rauscher: Vielen Dank für die zahlreichen Anregungen und guteIdeen von Kollegen und Kunden zu wichtigen Aspekten und Themendie ihren Weg ins Buch gefunden haben.

René Zimmermann: Ich bedanke mich im Besonderen bei meiner FrauKristin und meiner Tochter Martha für ihre geduldige Unterstützungwährend der letzten Monate und dafür, dass ich viele Wochenendenvor dem Computer zubringen konnte, statt Zeit mit ihnen zu ver-bringen. Mein Dank gilt auch meinen Kollegen für ihre Dienste alsSparringspartner für so manche Idee, die sich im Buch wiederfindet.Nicht zuletzt möchte ich mich bei meinen Mitautoren für die gegen-seitige Unterstützung, Motivation und Zusammenarbeit bedanken.Die letzten Monate sind eine Erfahrung, die ich nicht vergessenwerde.

Ihre AutorenOliver Lauffer, Jan Rauscher und René Zimmermann


Auf einen Blick

1 Warum ist Stammdatenmanagement wichtig für Ihre Organisation? .................................................... 21

2 Einsatz und Design von SAP Master Data Governance ............................................................... 79

3 SAP Master Data Governance und seine Funktions-weise als Grundlage der Stammdatenstrategie ........ 157

4 SAP Master Data Governance im Zusammenspiel mit komplementären SAP-Werkzeugen ................... 265

5 Ein SAP-Master-Data-Governance-Projekt aufsetzen und umsetzen ........................................................... 309

6 Implementierungsbeispiele für verschiedene Stammdatentypen .................................................... 355

7 Stammdatennetzwerke: Der Game Changer ............ 453


7

Inhalt

Vorwort .................................................................................... 13Einleitung .................................................................................. 15

1 Warum ist Stammdatenmanagement wichtig für Ihre Organisation? ............................................. 21

1.1 Bedeutung von Stammdaten für die Organisation ... 231.1.1 Effiziente und sichere Prozessabläufe

gewährleisten ............................................ 241.1.2 Stammdaten-Governance und

Organisation .............................................. 301.1.3 Prozessarchitektur ..................................... 301.1.4 Datenstruktur und Datenqualität ............... 311.1.5 Technologie ............................................... 311.1.6 Informationsbasis verbessern ..................... 32

1.2 Welche Stammdaten sind wem wichtig und warum? .................................................................. 341.2.1 Vertrieb und Marketing ............................. 371.2.2 Einkauf ...................................................... 401.2.3 Produktionsplanung und Fertigungs-

steuerung .................................................. 441.2.4 Entscheidungsträger (C-Level) .................... 46

1.3 Grundlegende Konzepte des Stammdaten-managements: Definitionen und Objekte ................ 511.3.1 Definitionen .............................................. 511.3.2 Kernbereiche der Stammdaten-

Governance ............................................... 591.3.3 Ausgangssituation und Erfolgsfaktoren ...... 65

2 Einsatz und Design von SAP Master Data Governance .............................................................. 79

2.1 Zielsetzung und Tools definieren ............................. 792.1.1 Strategie und Governance .......................... 822.1.2 Technologie und System ............................ 822.1.3 Prozesse .................................................... 842.1.4 Organisation .............................................. 84


Inhalt

8

2.2 Implementierungsszenarien ..................................... 852.2.1 Hub-Deployment ....................................... 862.2.2 Co-Deployment ......................................... 942.2.3 Hybrid-Hub- und Co-Deployment .............. 972.2.4 Fragestellungen zur Entscheidung für

eine Architektur ......................................... 982.3 Die Stammdatenstrategie ........................................ 100

2.3.1 Unternehmensstrategie und Stammdatenstrategie ................................. 100

2.3.2 Stammdatenstrategie entwickeln ................ 1022.4 Bedeutung der Stammdaten-Roadmap .................... 106

2.4.1 Zusammenhang zwischen Strategie und Roadmap ................................................... 106

2.4.2 Stakeholder-Feedback und Reifegrad-analysen ..................................................... 108

2.4.3 Roadmap als Mittel der Kommunikation .... 1102.5 Wie viel Master Data Governance braucht mein

Unternehmen? ........................................................ 1112.5.1 Standard-Governance-Modelle ................... 1122.5.2 Governance-Umfang bestimmen ................ 1152.5.3 Das Hybridmodell ...................................... 119

2.6 Bedeutung eines guten Datenqualitäts-managements .......................................................... 1232.6.1 Problemorientierter Ansatz ........................ 1232.6.2 Kontrollorientierter Ansatz ......................... 1242.6.3 Zweckorientierte Datenanalyse .................. 1272.6.4 Regeldefinitionen ....................................... 1322.6.5 Datenqualitätsmetriken mithilfe agiler

Methoden .................................................. 1352.7 Datenmigration und Datenharmonisierung im

Projekt .................................................................... 1382.7.1 Datenmigration .......................................... 1382.7.2 Datenharmonisierung ................................. 142

2.8 Change- und Stakeholder-Management im Projekt .................................................................... 1462.8.1 Unterschiede zwischen Projektmanage-

ment und Change-Management ................. 1502.8.2 Warum OCM in einem Stammdaten-

projekt so wichtig ist .................................. 1512.8.3 Stakeholder-Management .......................... 153


Inhalt

9

3 SAP Master Data Governance und seine Funktions-weise als Grundlage der Stammdatenstrategie ...... 157

3.1 SAP Master Data Governance als Kern der Stamm-daten-Governance .................................................. 1573.1.1 Integration von SAP Master Data

Governance mit SAP ERP ........................... 1593.1.2 Stammdatenprozess in SAP Master Data

Governance ............................................... 1603.1.3 MDG-Datenmodell, Flex- und

Re-Use-Modus .......................................... 1613.1.4 Verteilung der Stammdaten ....................... 163

3.2 Datenmanagement in SAP Master Data Governance ............................................................ 1643.2.1 Datenmodelle in SAP Master Data

Governance ............................................... 1663.2.2 Speicher- und Verwendungstypen von

Entitäten ................................................... 1683.2.3 Beziehungstypen zwischen Entitäten im

Datenmodell ............................................. 1713.2.4 Datenmodelle anpassen ............................. 1743.2.5 SAP-MDG-Arbeitsbereich (»staging«) vs.

aktiver (»active«) Bereich ........................... 1793.2.6 MDG-Datenmanagement-Konzepte

»Flex-Modus« und »Re-Use-Modus« .......... 1803.2.7 Empfehlungen zu Flex-Modus und

Re-Use-Modus .......................................... 1833.3 Change Requests in SAP Master Data Governance 186

3.3.1 Attribute und Eigenschaften eines MDG-Change-Requests ............................. 190

3.3.2 Change Request als steuernde Komponente ............................................. 198

3.3.3 Stammdatenprozesssteuerung mit einem Workflow .................................................. 209

3.3.4 Änderungsbelege und das Löschen von Änderungsanträgen ................................... 218

3.3.5 Analyse von Änderungsanträgen, BCV, Smart Business mit SAP HANA .................. 220

3.3.6 Änderungsantragstypen im Auslieferungs-zustand von SAP MDG .............................. 225


Inhalt

10

3.4 Datenqualität in SAP Master Data Governance ........ 2273.4.1 Suchen ....................................................... 2283.4.2 Validierungen, Prüfungen und Ableitungen

in SAP Master Data Governance ................. 2313.5 Verteilungskonzepte in SAP Master Data

Governance ............................................................. 2343.5.1 SAP-GUI-Transaktionen .............................. 2443.5.2 Web-UI-Applikationen ............................... 245

3.6 Benutzerschnittstellen (UIs) in SAP Master Data Governance ............................................................. 2453.6.1 Die Frontend-Applikationen »SAP Business

Client« und »SAP Enterprise Portal« ............ 2453.6.2 UI-Technologie in SAP MDG: Web Dynpro

ABAP ......................................................... 2473.6.3 UI-Konfigurationen und der Floorplan

Manager .................................................... 2503.7 Benutzermanagement und Bearbeiterermittlung ...... 256

3.7.1 Rollen in SAP Master Data Governance ...... 2563.7.2 Bearbeiterermittlung in SAP MDG .............. 258

3.8 Domänenspezifische Eigenschaften .......................... 2603.8.1 Customer-Vendor-Integration (CVI) ........... 2603.8.2 Editionen innerhalb von MDG-Financial ..... 263

4 SAP Master Data Governance im Zusammenspiel mit komplementären SAP-Werkzeugen ................. 265

4.1 SAP Fiori ................................................................. 2654.1.1 Business-Vorteile ....................................... 2654.1.2 Aufbau von SAP Fiori ................................. 2664.1.3 Anwendungsbeispiele von SAP Fiori ........... 2674.1.4 Integration mit SAP Master Data

Governance ................................................ 2724.2 SAP Data Services und SAP Information Steward ..... 275

4.2.1 SAP Data Services (DS) ............................... 2754.2.2 SAP Information Steward (IS) ..................... 279

4.3 SAP Process Orchestration ....................................... 2834.3.1 Flexibilität .................................................. 2864.3.2 Werte-Mapping inklusive Codelisten-

Management .............................................. 2864.3.3 Schlüssel-Mapping ..................................... 2884.3.4 Filterfunktionen ......................................... 289


Inhalt

11

4.4 SAP Business Process Management (BPM) .............. 2894.5 SAP Business Workflow .......................................... 293

4.5.1 SAP Business Workflow und SAP Master Data Governance ........................... 298

4.6 SAP Lumira ............................................................. 2994.6.1 Business-Vorteile ....................................... 2994.6.2 Aufbau von SAP Lumira ............................. 3004.6.3 Anwendungsbeispiele und Integration

mit SAP Master Data Governance .............. 3024.7 Im Zusammenspiel zum Erfolg ................................ 305

5 Ein SAP-Master-Data-Governance-Projekt aufsetzen und umsetzen ......................................... 309

5.1 Kernfragen vor dem Projekt und Projektansätze ...... 3105.1.1 Rollen und Profile der Projektbeteiligten ... 3145.1.2 Ausgangslage des Projekts ......................... 3195.1.3 Übergabe und zukünftiger Alltagsbetrieb ... 326

5.2 Checkliste für die ersten 100 Tage .......................... 3305.2.1 Regelmäßiger Abgleich der Vision und des

Ist-Zustandes ............................................. 3315.2.2 Premortem-Ansatz ..................................... 3335.2.3 Weitere Tools des Projektmanagers ........... 336

5.3 Cutover-Management ............................................. 3375.4 Nach dem Projekt ................................................... 342

5.4.1 Die Rolle des Stammdaten-Governance-Boards ....................................................... 343

5.4.2 Ausweiten des Governance-Umfangs ......... 350

6 Implementierungsbeispiele für verschiedene Stammdatentypen ................................................... 355

6.1 Fallstudie: Materialstammdaten .............................. 3566.1.1 Ausgangslage ............................................. 3576.1.2 Implementierung ....................................... 359

6.2 Fallstudie: Integration und Stücklisten-synchronisation ....................................................... 3836.2.1 Ausgangslage ............................................. 3836.2.2 Architektur entwickeln .............................. 385

6.3 Fallstudie: Kundenstammdaten ............................... 404


Inhalt

12

6.3.1 Ausgangslage ............................................. 4056.3.2 Abgleich des Kundenstamms ...................... 4096.3.3 Konsolidierungsprozess .............................. 412

6.4 Fallstudie: Finanzobjekte ......................................... 4286.4.1 MDG-F-Arbeitsbereiche und -Rollen .......... 4286.4.2 Editionsmanagement und Daten-

management in MDG-F .............................. 4296.4.3 MDG-F-Szenario: Kostenstelle

ad hoc anlegen ........................................... 4366.4.4 MDG-F-Szenario: Sachkonto anlegen ......... 450

7 Stammdatennetzwerke: Der Game Changer ........... 453

7.1 Warum Stammdatennetzwerke? .............................. 4547.2 Interoperabilität im Netzwerk .................................. 457

Die Autoren ............................................................................... 465Index ......................................................................................... 467


467

Index

A

ABAP Workbench 247Ableitung 231Access-Klasse 162, 184Active Area 179Ad-hoc-Handling 445Adressbereinigung 276Adressdatenbank 227, 278Adressprüfung 227Adressvalidierung 413agile Methoden 135Akquisition 300Aktion 203aktive Phase 394aktiver Bereich 166, 179, 184, 240Aktivierung 163, 179ALE 163, 243

Technologie 285Verteilung 86

analytische App 270Änderungsantrag � Change RequestÄnderungsantragstyp 191, 199,

209, 226Änderungsbeleg 219Anwendungshierarchie 250, 251Anwendungs-Log 241Applikationsplattform 157Ausgangssituation 65Auslieferungszustand 166, 225Automatisierungsgrad 71

B

BAdI 232, 260MDG_IDM_GET_LCL_SYSTEM 238USMD_RULE_SERVICE 232USMD_RULE_SERVICE_CROSS_ET

232USMD_WF_AGENT 444

BCV � Business Context ViewerBearbeiterermittlung 83, 200, 256,

258, 260, 282, 295, 443Beeinflusser 154Benutzermanagement 256Benutzerrollen 258

Best Record Calculation 413Betriebsanweisung 82betriebswirtschaftliche

Aktivität 200, 447Beziehungstyp 168, 171Big Data 48BPM 289BRFplus 212, 231, 284BRM � SAP Business Rules Manage-

mentBrownfield-Ansatz 320Business Add-In 232Business Case 34Business Configuration Set 159, 440Business Content Package 246Business Context Viewer 222Business Function 159, 439Business Rules Framework plus �

BRFplusBusiness Workplace 297

C

Change Request 161, 186, 190, 192Change-Management 146Checkliste 330Codeliste 236, 286Co-Deployment 85, 94, 97Compliance 418CONFIGURE_APPLICATION 252CONFIGURE_COMPONENT 253Controlling 428, 436Customer-Vendor-Integration 261Cutover-Management 337Cutover-Plan 337CVI 261

D

Data Model Metadata 178Data Quality Management

für SAP 277Data Replication Framework � DRFData Services Designer 276Daten laden 141


468

Index

Datenanalyse 127, 299Datenanlage, harmonisierte 36Datenanreicherung 163Datenaustausch 43Datenbanksuche 228Datenbanktabelle 161Datenextraktion 139Datenfluss 48Datenfreigabe 152Datenharmonisierung 142Datenkonvertierung 142Datenmigration 138, 278Datenmodell 161, 164, 263Datenmodellerweiterung 175Datenpflege 82, 152Datenqualität 31, 57, 227, 275, 279

agile Methoden 135Architektur 372kontinuierliche Verbesserung 126Konzept 82Messung 123Metrik 123Regeldefinition 132Zweck 57, 75

Datenqualitätsmanagementkontrollorientierter Ansatz 124problemorientierter Ansatz 123

DatenqualitätsmetrikFunktion 125zweckorientierte Datenanalyse 127

Datenquelle 275Datensicherheit 95Datenstruktur 178Datentransformation 139Datenverantwortung 72, 422Definition

Finanzstamm 56Kundenstamm 25, 54Lieferantenstamm 55Materialstamm 53Stammdaten 51Stammdaten-Governance 56

Design Thinking 334dezentrale Organisation 84Digitalisierung 453Domäne 165DQM for SAP 277DRF 164, 234, 239, 448Dublette, Prüfung 278Duplikat 144Duplikatsmetrik 411

E

Eclipse 290Edition 263, 429Editionstyp 193, 431Einführungsphase 393Eingangskorb 297Einkauf 40Einkaufspotenzial 42Enrichment 206Enrichment Framework 206, 233Enrichment Spot 206, 233Enterprise Search 228Entität 176Entity-Relationship-Modell 167Entscheidungstabelle 213, 258Entscheidungsträger (C-Level) 46Erfolgsfaktor 65, 73ETL 275ETL-Tool 138, 280

F

F4-Hilfe 169Fallstudie

Finanzen 428Integration 383Kundenstamm 404Materialstammdaten 356Stücklistensynchronisation 383

Feldeigenschaft 207Feldmapping 87Fertigungssteuerung 44Filter 239Filterklasse 240Filterobjekt 240Filterparameter 240Finanzen, Fallstudie 428Finanzstammdaten 56Flex-Modus 161, 163, 180, 181, 186,

264, 432Floorplan Manager 200, 245, 247,

250, 252Fokusmatrix 115

Bereiche der 117Dimension Geltungsbereich 116Dimension Geschäftseinfluss 116

Folgeaktivität 387FPM � Floorplan Manager


469

Index

G

Generic User Interface Building Block 253

Geschäftsnutzen 66Geschäftsprozess 28, 67

fehlende Prozessintegration 28Geschäftsregel 284Go Live 338Golden Record 416Governance

Maß 419Scope 175Umfang 115, 122Umfang ausweiten 350von Prozessen 29

Governance-Modell 122Hybridmodell 119invasives Modell 113nicht-invasives Modell 114

Greenfield-Ansatz 319GUIBB 253Guided Activity Floorplan 250

H

Harmonisierunginhaltliche 145strukturelle 143

Hintergrundschritt 160HTML5 266Hub 163Hub-Deployment 86, 97Hybrid-Ansatz 322

I

IDE 290IDoc 91, 235Implementierungsszenario 85Inaktivierungsphase 394Infoblatt 269Infographics 301Information, harmonisierte 36Informationsbasis, verbesserte 32Informationsdefinition 24Informationslebenszyklus 421Informationsqualität 22Infrastruktur 291

Installation 159Integrated Development Environ-

ment 290Integration 80, 157Integrationsmanager 311Integrationsworkshop 315Intermediate Document � IDocInteroperabilität 457

K

Kachel 269Kardinalität 168, 173Kennzeichen USMD_ACTIVE 180Kommunikation 76Konnektor 139Konsolidierung 428Konsolidierungsszenario 425Konstruktionsmappe 385KPI 27, 31, 63, 75, 128

agile Methoden 135Beispiele 128Finanzstamm-Konsistenz-Index 129Kundendatengesundheitsindex 130Kundenstammkonsistenzindex 129Lieferantenstammkonsistenz-

index 129Materialstammkonsistenzindex 129Metrikdefinition 133Produktaktivierungsindex 128, 373Produktaktivitätsindex 129Time-to-Market-Index 128zweckorientierte 128

Kundendatengesundheitsindex 130Kundendienst 418Kundeninformations-

lebenszyklus 421Kundenstamm 25, 54

Abgleich 409Aktivitätsfilter 410anlegen 424Compliance 418Daten 54Datenverantwortung 422Duplikat 411Fallstudie 404Informationslebenszyklus 421Konsolidierungsarchitektur 409Konsolidierungsprozess 412


470

Index

Konsolidierungsszenario 425Lead-to-Cash-Zyklus 419Lebenszyklusphasen 422MDG-Konsolidierungslösung 412Prozess 26, 28Roadmap 408

L

Launchpad 267Lebenszykluskonzept 62Lieferantenbeziehung 40Lieferantenstamm 26, 55logische Aktion 201

M

Management Information System 46Mandat 71, 75Manufacturing Execution System 44Marketingaktivität 37Massenbearbeitung 186MAT01 215Matching 413Match-Profil 231Materialstamm

Automatisierung 367Daten 53Fallstudie 356fehlende Prozesssteuerung 360Operating Model 364Portfoliostrategie 376Prozessleistungsmessung 374vorgelagerte Informations-

sammlung 369Materialstatus 84, 395MDG-CO 165MDG-Datenmodell 161MDG-F 428

Datenmodell 440installieren 439

MDG-Reifegrad 70MDG-Rolle 257MDG-Workflow 361

einfach oder komplex 362MDM-Fähigkeit 100, 103, 104MDM-Team 76mediated 235Meilenstein 342

Metadaten 31, 64, 280, 283Metadatenrahmenwerk 132Metapedia 280Metrikdefinition 133Middleware 95, 163, 286Migration 275Model-View-Controller (MVC) 247Monitoring 241, 289MS Project 338

N

Notfall-User-Konzept 329NWDS � SAP NetWeaver Developer

Studio

O

Object Instance Floorplan 250Objekt, extern kontrolliertes 38Operating Model 417, 426

Portfoliostrategie 376Organisation 30, 61, 71, 84Organisationseinheit 296organisatorische Einbettung 72Outbound-Implementierung 238Overview Floorplan 250

P

Parallelisierung 83, 390Peer-to-Peer 235Phase-out-Phase 394PI � SAP Process IntegrationPO � SAP Process OrchestrationPremortem-Ansatz 333Process Mining 376Product Lifecycle

Management 84, 383Produktaktivierungsindex 373Produktionsplanung 44Produktivbetrieb 326Produktlebenszyklus 393Projektansatz 310, 326Projektbaukasten 309Projekthandbuch 337Projektmanager 311Projekttransparenz 149


471

Index

Prozess 84Architektur 30Steuerung 360Team 317Transparenz 371

Prozessgestaltung, datenanalysen-getriebene 124

Prozessleistung messen 28, 374Prüfung 207, 231Pull-Ansatz 312Push-Ansatz 312

Q

Quality Score 280

R

RBW � Workflow, regelbasierterRechnungswesen 428Referenzdaten 39, 64Regel 232Regeldefinition 132Regelsatz 232Regelwerk 89Reifegrad 68, 77, 80Remediation-Szenario 281, 282Remote-Key-Suche 229Replikation 163, 234, 436

Architektur 236Modell 238, 240Status 241Zeitpunkt 432

ReportUSMD_ADJUST_STAGING 175USMD_DELETE_CREQUEST 220

Re-Use-Modus 161, 180, 182, 186Rezepturentwicklung 383Rich-Client-Applikation 246Risk-Assessment-Liste 337Roadmap 73, 110, 310Rolle 256Rückverteilung 388

S

Sachkonto 450SAP AppBuilder 267

SAP BPM � SAP Business Process Management

SAP BRM � SAP Business Rules Management

SAP Business Client 246SAP Business Process Management

283, 289, 365, 370, 381SAP Business Rules Management

283, 291SAP Business Workflow 291, 293,

365, 381SAP Data Services 139, 275, 410SAP Enterprise Portal 246SAP Fiori 223, 246, 265SAP Gateway 271SAP Governance Risk and

Compliance 329SAP HANA 160, 222

Content 225Suche 229

SAP Information Steward 275, 279SAP Lumira 299SAP MDG

im Transformationsprozess 407Workflow Builder 363

SAP MDG Consolidation 412Activation 413Address Validation 413Best Record Calculation 413Matching 413Validation 413Vorteile 414

SAP MDG for Finance � MDG-FSAP NetWeaver Application Server

ABAP 158SAP NetWeaver Developer Studio

283, 290SAP Process Integration 285SAP Process Orchestration 86, 164,

283SAP Recipe Development 385SAP-Einführungsleitfaden 398SAPUI5 266Schlüssel-Mapping 164, 234, 239,

288Schlüsseltabelle 288Scoring-Modelle 144Self-Service-Business-Intelligence-

Lösung 299Service Level Agreement 196Service Link 200


472

Index

SLD 238, 448Smart Business 222SMT-Mapping 185SOA 163, 235, 291Software Development Kit 301Software-Architektur 157Spezifikation 386Sponsor 71, 75Staging Area 157, 166, 179Stakeholder 34

Management 61, 146Matrix 337

StammdatenDefinition 25, 51, 52Finanzstamm 56Kundenstamm 54Lieferantenstamm 55Mandat 71Materialstamm 53Prozess 77, 160Stammdaten-Governance 56

Stammdaten-Governance 29, 56, 111Daten und Standards 64Fokusmatrix 115Governance-Umfang 115Hybridmodell 119invasives Modell 113Kommunikationsstrategie 60KPIs 63Lebenszykluskonzept 62nicht-invasives Modell 114Organisation 30, 61Prozesse 62richtiges Maß 58Roadmap 59Strategie 59Technologie 63zentrale Bedeutung 33

Stammdaten-Governance-BoardMandat des operativen Governance-

Boards 343, 346operatives 343strategisches 343

Stammdatennetzwerk 453Beweggründe 454Corporate Data League 456Daten-Governance 458Datenqualität 460Interoperabilität 457Together for Sustainability 456

Stammdatenorganisation 84organisationsspezifisches Governance-

Modell 119Stammdatenpflege 26Stammdatenrisiken 23Stammdaten-Roadmap 106

Arbeitsvorrat 107Budgetzyklus 108Fit-Gap-Analyse 107Reifegradanalyse 108Ressourcenplanung 108Stakeholder-Feedback 108

Stammdatenstrategie 73, 100, 102Beispiel 103entwickeln 102Merkmale 105Syntax 103

Standard 64Standard-Stammdaten-KPI 128Statistik 220Status Change Request 192Statusreport 400Storyboard 301Strategie 82strukturelle Harmonisierung 143Stücklistensynchronisation 383Suche 227Suchkonnektoren 230Switch Framework 159, 258System Landscape Directory � SLDSystemausfall 328Systemlandschaft 69, 158

heterogene 69

T

TabelleCVI_CUST_LINK 262CVI_VEND_LINK 262USMD120C 191USMD167C 202USMD180C 201USMD230C 204

Technologie 68, 78Transaktion

DRFF 239DRFIMG 238DRFOUT 241MDG_DATA_MODEL 167MDG_GEN_HBA_CR_EXT 224


473

Index

MDGIMG 226, 282MDS_LOAD_COCKPIT 262PPOME 296SCPR20 159SE80 247SE93 244SFW5 159SLG1 243SWDD 210, 294USMD_RULE 231USMD_SSW_DYNAMIC_AGENT_

SELECT 260transaktionale App 268Transformation 300Transparenz der Prozess-

ausführung 371TREX 228

U

UIanpassen 445Applikation 200Konfiguration 200, 250, 255

Universal Worklist � UWLUnternehmensakquisition 66Unternehmensstrategie 100User Experience 265UWL 188, 218, 282, 297, 387

V

Validierung 161, 163, 188, 227, 231, 276, 318

Verbesserung, kontinuierliche 126Verhaltensmuster 330Verteilung 234, 301Verteilungsmodell 238Vertrieb und Marketing 37Verwendungs- und Speichertyp 168Vier-Augen-Prinzip 180, 187View 248

W

Wahrnehmung des MDM-Programms 76

WDA 249, 445

WDC 248, 446Web Dynpro ABAP � WDAWeb Dynpro Component � WDCWeb Dynpro Java 291Web-Dynpro-Anwendung 253Web-Dynpro-Technologie 245Webservice 92, 291Werte-Mapping 87, 239, 286Wiederverwendungsbereich 184Window 248Workaround 313Workflow

Definition 441regelbasierter 209, 212, 218, 258Template 199, 209, 212

Workflow Builder 210, 294, 363, 442Work-Item 188WS60800086 210, 212WS75700040 210

Z

Zeitabhängigkeit 263zeitgesteuerte Verteilung 90zentrale Organisation 84Zielsetzung 79Zielsystem 194, 234Zugriffsklasse 184


Wir hoffen sehr, dass Ihnen diese Leseprobe gefallen hat. Sie dürfen sie ger-ne empfehlen und weitergeben, allerdings nur vollständig mit allen Seiten. Bitte beachten Sie, dass der Funktionsumfang dieser Leseprobe sowie ihre Darstellung von der E-Book-Fassung des vorgestellten Buches abweichen können. Diese Leseprobe ist in all ihren Teilen urheberrechtlich geschützt. Alle Nutzungs- und Verwertungsrechte liegen beim Autor und beim Verlag.

Teilen Sie Ihre Leseerfahrung mit uns!

Oliver Lauffer arbeitet seit 12 Jahren bei der SAP Schweiz AG, zuerst in der Entwicklung von Daten-migrationsprogrammen, danach in der konzeptionellen Architektur von Stammdatenlösungen.

Oliver Lauffer, Jan Rauscher, René Zimmermann

Stammdatenmanagement mit SAP Master Data Governance473 Seiten, gebunden, Juni 2016 69,90 Euro, ISBN 978-3-8362-3887-8

www.sap-press.de/3969

Jan Rauscher arbeitet seit fünf Jahren bei SAP in der Beratung für den Bereich Stammdaten. Als Architekt ist er hier hauptsächlich mit Aufgaben wie der Konzept- erstellung, Projektplanung und -durchführung betraut.

René Zimmermann leitet als Head of Global Master Data Projects & Analytics bei Merck weltweite Pharma- und Chemie-Stammdatenprogramme; zuvor begleitete er die branchenführende Stammdatenimplementierung bei BP in London.

SAP-Wissen aus erster Hand.

https://www.rheinwerk-verlag.de/stammdatenmanagement-mit-sap-master-data-governance_3969/?GPP=lpn

https://www.facebook.com/rheinwerkverlag

https://plus.google.com/118435207805510651040

http://twitter.com/rheinwerkverlag

Documents

Stammdatenmanagement mit SAP Master Data … Kapitel 2 In diesem Kapitel betrachten wir die wesentlichen strategi- schen Entscheidungen, die die Grundlage für den Einsatz von SAP