The Program Managers Guide to the MDM galaxy

Andere Unternehmen bleiben mehr oder weniger untätig, weil sie nicht wissen wo sie beginnen sollen. Zu meinem Artikel „Why is everyone suddenly talking about PIM?“ haben mich zahlreiche Kommentare erreicht. Immer wieder ging es um die Frage, wie man MDM-Programme erfolgreich initialisieren und führen könne. Auch in meiner Tätigkeit als Berater von europäischen Enterprise-Kunden werde ich von Kunden gefragt, wie der Beginn eines Master Data Management Projekts idealerweise aussehen sollte. „Was ist zu beachten und wie gehe ich vor? Bitte ganz pragmatisch und so als Best Practices. Ihre Kollegen und Sie sind doch die Spezialisten...“ Aus diesen Gründen möchte ich in dem vorliegenden Artikel einmal einen Einblick in die Grundlagen unseres Vorgehensmodells geben.

Die größten Fehler werden zu Beginn gemacht. Oder anders gesagt: Eine große Chance, eine Sache richtig gut zu machen, liegt in der Schaffung der Grundlagen.

Voraussetzung 1: Qualifizierte Mitarbeiter
Darf ich vorstellen – Die Data Ninjas

Wer sind die Datenmenschen in den Unternehmen von heute? Früher war da die saubere Trennung zwischen IT und Business. Es gab Leute in den Fachbereichen, die Anforderungen hatten und andererseits IT-Leute, die diese Anforderungen in IT-Projekten umsetzten. Das Problem war jedoch, dass diese beiden Seiten sich oft nicht richtig verstanden und darüber hinaus der Kunde vergessen wurde.

In den vergangenen Jahren sind neue Rollen entstanden, um eine Brücke zwischen den Unternehmensbereichen und auch zu externen Partnern, wie Lieferanten und Kunden, zu bilden. Sogenannte „Data Stewards“, „Business Analysten“, „Data Architects“ oder auch „Data Owner“ sind oftmals nicht exakt einzelnen Abteilungen zuordenbar – eben, weil sie übergreifende und interdisziplinäre Aufgaben übernehmen. Die Analysten von Gartner sagen voraus, dass diese Rollen zunehmen werden, weil die Datenprojekte in Zukunft zunehmen. Der Rolle des „Data Stewards“ entsprechen z.B. Mitarbeitern, deren Hauptaufgabe es ist, die Informationsqualität und die Einhaltung von Informationsprozessen im Unternehmen zu überwachen und Optimierungsprojekte in diesem Umfeld durchzuführen. Gartner sagt, dass heute 32% der Unternehmen „Data Stewards“ beschäftigen. Bereits im Jahr 2020 werden es 71% sein.

Unternehmen investieren in Datenprojekte und Mitarbeiter, die Daten als echtes Asset verstehen. Die Data Ninjas sind meist nicht klar einem Unternehmensbereich zuordenbar. Sie haben den Anspruch, die Datenthemen prozess- und organisationsübergreifend anzugehen.

Voraussetzung 2: Qualifizierte Daten

Unternehmen leiden jeden Tag unter fehlenden, unvollständigen und falschen Daten. Die Mitarbeiter verbringen oftmals mehr Zeit damit, die Datengrundlage für eine Aufgabe herzustellen als für die Auswertung der Daten selbst. Es ist nicht so, dass Unternehmen die Daten nicht sammeln würden. Vielmehr geht es darum, dass Daten sich oftmals als ungeeignet für die konkrete Aufgabe herausstellen, sobald es um die Nutzung der gesammelten Daten geht.

Stellen wir uns ein Produkt vor. Es ist einfach zu diesem Produkt einzelne Stammdaten aufzuzählen. Natürlich hat ein Produkt eine Nummer und auch andere Identifikationscodes; außerdem Mengeneinheiten und sicherlich auch eine Warengruppe.

Wenn wir uns das Produkt nun in einem größeren Kontext vorstellen, dann bekommen wir eine Vielzahl weiterer Felder in unsere Liste.

Gerade vom Markt, vom Kunden oder auch vom Verarbeitungsprozess hergedacht, erweitert sich unser Beispieldatenmodell massiv: Welche Informationen benötigen die Vertriebs- und Marketingkollegen, um das Produkt zu verkaufen? Welche für spätere Auswertungen wertvollen Daten werden während des Vertriebsprozesses erzeugt?

Eine weitere Dimension erhalten wir, wenn wir unser Produkt aus der Sicht der beteiligten Systeme betrachten: Die Stammdaten werden nicht in einem, sondern in zahlreichen verschiedenen Systemen gehalten. Sind diese Informationen konsistent über die Systeme und Prozesse hinweg? Wer ist verantwortlich dafür, Änderungen und Erweiterungen in den Datenmodellen an andere Kollegen zu kommunizieren?

In unserem Beispiel haben wir lediglich ein Produkt betrachtet. Wenn wir dieses Produkt nun in den Kontext anderer Stammdatendomänen stellen, erhalten wir ein vollständiges Bild der Abhängigkeiten:  Wenn ein Mitarbeiter im Marketing auswerten möchte, welcher Kunde über welchen Vertriebskanal welches Produkt gekauft hat, dann sind hier schon drei Entitäten in Beziehung zu setzen. In vielen Unternehmen wären diese Daten nur schwer aufzutreiben und wenn, dann ohne Garantie für ihre Konsistenz, Aktualität und Vollständigkeit. Und genau darum geht es bei MDM-Programmen. Sie entstehen meist aus dem Bedarf an guten und auswertbaren Daten. Diese werden für zahlreiche interne und externe Anwendungsfälle benötigt.

Voraussetzung 3: Etablierte Standards

Wir bei parsionate beschäftigen uns vor allem mit mittleren und großen Unternehmen, die gewohnt sind, mit den führenden Analysten Forrester und Gartner zusammen zu arbeiten. Deshalb haben wir uns früh dafür entschieden, eben nicht alles selbst zu erfinden und unsere Kunden mit unzähligen neuen Begriffen und Methodiken einzulullen – wie das viele andere Berater tun. Wir haben uns angesehen, was die etablierten Standards sind und haben diese als Grundlage für unser Vorgehensmodell in der MDM-Beratung weiterentwickelt. Wir kooperieren mit Gartner, weil uns die Logik der Fachexperten gefällt. Von den Gartner-Kollegen wurde bereits vor Jahren ein Modell entwickelt, das „The Seven Building Blocks of MDM“ heißt.

Unsere Projekte richten wir an diesem Modell aus, weshalb ich es im Folgenden kurz vorstellen möchte.

1. Vision

Bevor wir mit einem Kunden seine Strategie für MDM entwickeln, benötigen wir eine klare gemeinsame Vision. Zunächst sprechen wir mit dem Executive Management. Welche Businessziele existieren? Gibt es hier Prioritäten, aus denen wir Anforderungen an die Daten ableiten können? Gerade diese erste Phase schafft den strategischen Raum für unsere MDM-Programme. So kann zum Beispiel eine geplante Internationalisierung der Vertriebsorganisation die Basis für die benötigte Bereitstellung harmonisierter Kundendaten sein. In sensitiven Branchen könnten aber auch regulatorische Anforderungen dominieren.
Neben den faktischen Businessanforderungen erarbeiten wir in der Vision ein umfassendes Bild der Stakeholder und deren Erwartungen. Auch die Unternehmenskultur in Bezug auf Daten ist relevant: Werden Entscheidungen bereits datengetrieben getroffen? Wie arbeiten Business und IT zusammen? Wie fortgeschritten sind die einzelnen Bereiche?
Alle Ergebnisse werden in ein möglichst einfaches Manifest überführt, für das wir die Unterstützung des Top-Managements einholen.

2. Strategy

Für das MDM-Programm benötigen wir klare Ziele, die in dieser Phase definiert werden. Daten- und IT-Ziele, die aus den Business-Zielen abgeleitet werden. Wie zahlt das MDM-Programm auf die Business-Ziele ein? Welchen Wertbeitrag leisten die einzelnen Teilphasen auf die Strategie?
Nach der Definition der Ziele, legen wir den Scope der einzelnen Phasen fest. Welche Applikationen, welche Prozesse, welche Teams und welche Qualitätsvorgaben werden tangiert? Diese Punkte sind übrigens nicht nur einmal initial zu definieren. Besonders wichtig ist es, hier auch festzulegen, in welchen Zyklen welche Teams bzw. Personen die Erreichung der strategischen Ziele überprüfen werden.

Aus den Zielen und der Scope-Festlegung entwickeln wir das eigentliche MDM-Programm. Für jede Phase des Programms sollte definiert und mit dem Management abgestimmt werden, was die Workstreams, Meilensteine, Ergebnisse, Ressourcen und Kosten sind.
 

3. Metrics

Messbarkeit ist gefordert! Metrics bedeutet, dass wir für die relevanten Bereiche unseres MDM-Programms definieren, wie wir die Maßnahmen und deren Erfolg messen. Die Geschäftsprozesse werden mit KPIs unterlegt. Ein Beispiel: Während wir in der Vision vielleicht festgelegt haben, dass wir Produktvarianten agiler entwickeln möchten und in der Strategie definiert wurde, dass hierzu ein neuer, unternehmensübergreifender Produktentstehungsprozess aufgesetzt werden soll, nutzen wir die Metriken hingegen dazu, eindeutige Messgrößen festzuhalten. Hier also z.B. die Zeit bis eine Produktvariante von der Produktidee bis zur Bestellfähigkeit im Webshop benötigt. Wir nehmen die heutige Durchlaufzeit auf und definieren, was wir als Zielgrößen erreichen möchten.
Messgrößen können aus verschiedenen Bereichen kommen. Übliche Beispiele sind: Performance (Dauer, Aufwand, Zeit), Finanzen (Kosten, Risiken) und die Stammdaten an sich (Qualität, Verfügbarkeit, Vollständigkeit, Korrektheit).

Mit genügend Kreativität sind hier übrigens auch „weiche“ Faktoren wie die Usability eines Systems zu messen, beispielsweise durch regelmäßige Anwenderbefragungen. Entscheidend ist, dass die Messungen regelmäßig durchgeführt werden. Während dieser Phase sollte also vor allem klar geregelt werden, welches Board bzw. welche Personen für die Prüfung und Dokumentation der KPIs in den späteren Projekten und auch in der Zeit danach verantwortlich sind.
 

4. Information Governance

Ein wichtiges Ziel jedes MDM-Programms ist es, Mitarbeitern und anderen Prozessbeteiligten Daten zur Verfügung zu stellen. Information Governance ist ein ganzheitlicher Ansatz, auf dessen Basis nun Informationen verwaltet werden. Das Ziel von Information Governance ist es, die Informationen denjenigen zur Verfügung zu stellen, die diese auch tatsächlich zur Verarbeitung benötigen. Dabei rationalisiert man das Management, reduziert die Kosten für Storage und stellt Konformität oder Compliance sicher.

Wir beginnen das Thema Information Governance, in dem wir eine unternehmensweite interdisziplinäre Arbeitsgruppe etablieren, in der die wesentlichen Datenströme im Unternehmen repräsentiert sind. In dieser Gruppe benötigen wir ein Berichtswesen und klare Entscheidungswege. Wer ist verantwortlich dafür, die Einhaltung von Normen und Gesetzen zu sichern? Wessen Aufgabe ist es, den Dialog zwischen den einzelnen Business-Bereichen herzustellen?

Compliance ist ein zunehmend wichtiges Thema. Neben allgemeinen, für alle Unternehmen verbindlichen Standards, wie die GDPR/DSGVO, sind zahlreiche Branchenstandards und Regularien ebenso einzuhalten. Es muss also klar geregelt sein, wer dafür verantwortlich ist. Und zwar nicht nur während des Projekts, sondern auch kontinuierlich danach, da sich die Standards ebenfalls weiterentwickeln.

Nicht nur die Nichteinhaltung von Informationsstandards birgt Risiken, sondern auch die Bereitstellung von Daten an sich. Hierfür benötigen wir eine Risikobetrachtung. Wer darf welche Informationen bekommen, sehen, weitergeben und verwenden? Wie kritisch sind welche Verstöße? Wer ist für die Überwachung verantwortlich? Wie wird der Datenschutzbeauftragte in das MDM-Programm involviert?

Im Rahmen der Information Governance betrachten viele Unternehmen auch die jeweiligen Investitionsvorhaben, weil spätestens in dieser Phase die Kosten (auch die Kosten der Risiken) aber auch die positiven Effekte aus bereitgestellten guten Daten ermittelt werden sollten.

5. People

Weil MDM eben nicht bedeutet, einfach eine neue Software einzuführen, beschäftigt sich diese Phase des Projekts mit der Organisation und den einzelnen Rollen. Wir beginnen mit der Arbeitsgruppe aus der Governance-Phase und entwickeln eine Rollenmatrix („RASCI“), die aufzeigt, wer welche Verantwortung trägt und welche Entscheidungen zu treffen hat. Für das eigentliche MDM-Programm definieren wir das Programm-Management. Hier sollten auch diejenigen Personen verankert werden, die das Verständnis von MDM und Daten in die einzelnen Unternehmensbereiche tragen sollen. Hier werden auch die einzelnen Projekte innerhalb des Programms gesteuert.

Als weitere Rollen werden in dieser Phase oftmals Programmverantwortliche für einzelne Datendomänen („Domain Leads“), Datenqualitätsverantwortliche („Information Stewards)“ und die Mitglieder der einzelnen Projektteams definiert.

6. Process

In dieser Phase wird der Lebenszyklus von Informationen im Unternehmen festgelegt. Für die einzelnen Datendomänen werden die Prozesse von der Entstehung bis zum Archivieren bzw. Löschen definiert. In zahlreichen MDM-Programmen kommen wir spätestens jetzt an grundlegenden Veränderungen in Bezug auf das Arbeiten im Unternehmen nicht mehr vorbei. So ist bei Produktdaten z.B. die Frage, wo diese entstehen sehr relevant für viele tägliche Arbeitsschritte im Unternehmen. Wenn ein Händler beispielsweise entscheidet, die Artikeldaten seiner Lieferanten zukünftig als Basis für sein Datenmanagement zu nehmen, müssen die Prozesse, wie Artikeldaten von den Lieferanten bereitzustellen sind, komplett verändert werden. Neben den Lieferanten haben auch die Mitarbeiter dadurch einen völlig veränderten Arbeitsablauf, der trainiert und in die Organisation überführt werden muss.

Ein weiteres Beispiel aus dem Bereich Kundendaten: GDPR/DSGVO sieht vor, dass Kunden das Löschen der über sie gespeicherten Informationen verlangen können. Diese Anforderung im Unternehmen abzubilden bedeutet zu wissen, wo Informationen zu Kunden abgelegt sind, wer diese Informationen bearbeiten kann bzw. Zugriff darauf hat, welche Systeme involviert sind, wie in diesen Systemen eine Löschung bzw. Sperrung vollzogen werden kann etc. Hierfür benötigt es klare Verantwortungsstrukturen und dokumentierte Prozesse.

Über alle Informationsprozesse hinweg sollte zudem die benötigte Datenqualität definiert werden. Je Prozessschritt sind Muss-/Kann-/Soll-Vorgaben festzulegen. Außerdem muss geklärt werden, wer für die Messung und Überprüfung dieser Definitionen verantwortlich ist.

7. Infrastructure

Jetzt – und erst jetzt! – beschäftigen wir uns mit der Implementierung von Systemen. Die gute Nachricht lautet: Wir haben bis hierher die meisten Dinge bereits festgelegt und konzipiert, die in IT-Projekten oftmals vergessen oder missachtet werden. Es sind die Dinge, bei denen es sich irgendwann rächen kann, wenn sie eben nicht berücksichtigt werden.

Grundlegende Themen im MDM-Projekt sind: Datenmodelle, Hierarchien (also z.B. Klassifikationsstandards, Warengruppenstrukturen, Vererbung, Produkt-Artikel-Relationen), Datenqualitätsregeln, Bedienoberflächen (für Mitarbeiter, aber auch für externe Partner, wie Lieferanten und Kunden), Schnittstellen zu Umsystemen, Workflows und natürlich die technische Basis (Systemarchitektur, Security, Hosting etc.).

Darüber hinaus sind der Betrieb und die Wartung der Systeme zu regeln. Einerseits technisch, im Sinne des Application Managements, andererseits aber auch organisatorisch (Wer ist verantwortlich für Updates, Prozessverbesserungen, Weiterentwicklung etc.?).

Wir haben gute Erfahrungen mit Schulungsprogrammen gemacht, die bereits parallel zum Projekt durchgeführt werden, um Mitarbeiter möglichst frühzeitig einzubinden.

Wie sie sehen können haben wir mit den „Seven Building Blocks of MDM“ von Gartner eine sehr gute Basis, um alle relevanten Themen in einem Datenprojekt zu adressieren – von der Idee und dem Dialog mit dem Top-Management bis hin zu IT-Themen und Systemen.

Die große Stunde der Data Ninjas – Strategie in der Praxis umsetzen und Resultate erzielen

Als die Welt noch einfacher war, wurden IT-Projekte von der IT durchgeführt und die Fachbereiche wurden allenfalls in der Anforderungsphase berücksichtigt. So lassen sich moderne Datenprojekte heute nicht führen. Ich kann das sicher sagen, weil meine Kollegen und ich in den vergangenen Jahren genügend gescheiterte Digitalisierungsinitiativen gesehen haben. Heute sind MDM-Programme gefragt, die Daten als Wert an sich in den Mittelpunkt stellen und ihren Nutzen aus Kundensicht betrachten. Was hat unser Endkunde davon? Welche Mehrwerte können wir ihm bieten, die sein Leben vereinfachen und ihm nutzen. Wie heben sie uns von unserem Wettbewerb ab?

Wenn wir Datenprojekte als Weichensteller für die Digitalisierung begreifen, dann sind die Data Ninjas die Analysten, Kommunikatoren, Businessleute, IT-Spezialisten und Kundenversteher. Sie denken nicht in Abteilungen und „IT vs. Business“, sondern stellen den Kundennutzen ganz nach vorne. Wir sehen großartige Initiativen für Master Data Management bei unseren Kunden und auch eine neue Generation von Mitarbeitern, die eine Grundvoraussetzung dafür sind, dass diese Initiativen langfristig zum Erfolg und Wachstum der Unternehmen beitragen werden.