Die 5 Elemente einer erfolgreichen Datenstrategie

WHITE PAPER

2

InhaltDatenstrategie: Welche Probleme löst sie? .......................................................3

Daten: gestern und heute ......................................................................................4

Business ohne Datenstrategie ..............................................................................4

Definition: Was ist eine Datenstrategie überhaupt? .........................................5

Die 5 Elemente einer Datenstrategie ..................................................................6

Identifizieren ..........................................................................................................7

Speichern ...............................................................................................................7

Bereitstellen ...........................................................................................................9

Integrieren ............................................................................................................10

Regulieren ............................................................................................................12

Die Definition der Datenstrategie ist entscheidend .......................................13

Was eine Datenstrategie wirklich leisten kann ................................................13

Evan Levy, Vice President of Data Management Programs bei SAS®, ist ein anerkannter Sprecher und Autor für die Themen Enterprise Data Strategy, Datenmanagement und Systemintegration. Levy berät Kunden, wie sie mit dem exponentiellen Zuwachs an Datenvolumen, -quellen und -systemen umgehen können. Er gibt ihnen Strategien an die Hand, um diese Herausforderungen gemeinsam mit den vorhandenen Daten und Technologien sowie neuen und kreativen Methoden anzugehen.

3

Viele Unternehmen haben lange viel Geld in Datenmanagement investiert – und trotzdem wachsen ihre Datenprobleme weiter. Ein Grund dafür ist, dass Daten traditionell lediglich als ein Aspekt von Technologieprojekten angesehen worden sind – und nicht als Unternehmenswert betrachtet werden. In der Konsequenz war man bisher der Ansicht, dass herkömmliche Planungen für Anwendungen und Datenbanken ausreichend seien, um die üblichen Datenprobleme zu lösen.

Je mehr jedoch die Datenspeicher im Unternehmen wachsen – sowohl im Hinblick auf Umfang als auch im Hinblick auf Diversität –, desto klarer zeigt sich, dass eine umfassende Datenstrategie notwendig ist. Doch nicht wenige Unternehmen hadern noch mit dieser Vorstellung.

Wenn es um Strategien geht, planen viele Unternehmen munter ins Blaue hinein; für einige ist es komplettes Neuland. Tatsächlich führen die Pläne und Roadmaps oftmals zu recht wenig konkreten Ergebnissen – sind dafür aber mit umso mehr Meetings und Dokumentationen verbunden. Ein erfolgreicher Plan dagegen identifiziert realistische Ziele im Einklang mit einer Roadmap, die klare Vorgaben macht, wie diese am besten erreicht werden.

Datenstrategie: Welche Probleme löst sie? Welche Rolle eine Datenstrategie spielt, soll ein Beispiel aus der Praxis zeigen. In einer Großbank sollte ein Beratungsteam eine solche entwickeln. Der Projektleiter hatte es von Anfang an schwer, seinen Vice President (VP) von der Wichtigkeit und Notwendigkeit einer Datenstrategie zu überzeugen. Warum?

Die Bank arbeitete erfolgreich. Umsatz und Kosten waren im Einklang, die einzelnen Fachabteilungen und Technologie-Teams erreichten ihre Ziele. Was für die Bank spricht, ist, dass sie sich damit nicht zufrieden gab. Die Unternehmensleitung war stets auf der Suche nach Möglichkeiten, um die Produktivität von Mitarbeitern zu erhöhen und laufende Kosten zu senken. Es wurden alle erdenklichen Metriken und Key-Performance-Indikatoren erhoben, um IT Performance, geschäftliche Leistung und Total Cost of Ownership zu messen. Und das war der entscheidende Punkt: Der Vorschlag, noch eine weitere Roadmap zu erstellen, um ein Problem (Daten) zu lösen, für das es kein Verständnis gab, stieß nicht auf offene Ohren.

Der VP begründete dies folgendermaßen:

„Wir haben stets Dutzende von Projekten laufen. Wir sind sehr gut darin, unsere Speicheranforderungen, unsere Applikationssysteme, die analytischen Plattformen, Softwarekosten und einzelne Projektbudgets zu managen. Bei jedem Projekt werden Kosten für Mitarbeiter und Ressourcen kalkuliert – und es wird nur umge-setzt, wenn diese Kosten gedeckt werden können.

Warum brauchen wir eine Datenstrategie? Welches Problem soll damit gelöst werden?”

Da die Bank bereits so viele Dinge richtig machte, galt es, den Unternehmenslenker von den Verbesserungen zu überzeugen, die eine Datenstrategie bringen könnte. Für die Beantwortung seiner Fragen muss man sich zunächst anschauen, wie Daten früher entstanden und genutzt wurden – im Gegensatz zu heute.

4

Daten: gestern und heuteEs war einmal … Früher wurden Daten als Nebenprodukt einer Geschäftsaktivität oder eines Prozesses betrachtet. War der Prozess abgeschlossen, sank ihr Wert gegen null. Zwar gab es manchmal ein oder zwei andere Anwendungen, die in der Folge Zugriff auf diese Informationen benötigten (zum Beispiel für den Kunden-Service, spezielle Reports oder Audits), aber dabei handelte es sich in der Regel um einmalige Anfragen.

Heute sind die Geschäftsabläufe ganz anders. Der Wert von Daten ist anerkannt, die Ergebnisse aus Reporting und Analytics bilden die Grundlage für viele neue Geschäftsinitiativen. Es ist inzwischen gang und gäbe, dass Anwendungsdaten von mindestens zehn anderen Systemen genutzt werden.

Der Wert von Daten ist in den vergangenen 20 Jahren signifikant gestiegen. Dennoch gibt es bisher wenige Unternehmen, die diese Wertsteigerung beim Sammeln, Teilen und Verwalten von Unternehmensdaten berücksichtigen. Dieses Verhalten zeigt die – immer noch – zugrunde liegende überholte Auffassung, dass Daten nicht mehr sind als ein Nebenprodukt von Anwendungen.

Unternehmen sind gefordert, eine Datenstrategie zu entwickeln, die mit der Realität im Einklang steht. Für den Aufbau einer solch komplexen Strategie ist es notwendig, laufenden Geschäfts- und Technologieanforderungen gerecht zu werden und gleichzeitig neue Ziele anzugehen.

Business ohne DatenstrategieDie Bedenken des Bankmanagers sind durchaus verständlich. Er hat viel Zeit in das Prüfen von Projekten gesteckt, die ihm seine engagierten Mitarbeiter angetragen haben. Und in vielen Fällen ging es in diesen Projekten darum, perfekte Ergebnisse zu erzielen – also darum, etwas, das bereits funktioniert, noch schneller, stärker oder besser zu machen. Als Top-Führungskraft weiß er natürlich, dass Budgets und Ressourcen begrenzt sind und dass jedes zusätzlich genehmigte Projekt letztlich Geld und Ressourcen für andere Ideen reduziert. Seine Standardfrage:

„Warum sollte gerade deine Idee wichtiger sein als die anderen Punkte, die bereits auf der Prioritätenliste stehen?”

An dieser Stelle soll gar nicht die Wichtigkeit oder der Wert eines einzelnen Projektes in Frage gestellt werden. Das Problem bestand vielmehr in dem separaten Ansatz für jedes Projekt und jede Aktivität. Jede Aktivität behandelte die Datenanforde-rungen unabhängig von den anderen, Überlappungseffekte und Kosten wurden dabei nicht berücksichtigt.

Die meisten Projekte erforderten Zugang zu denselben Daten. Es gab aber keine Koordination zwischen den Projekten, um Überlappung und (unnütze) Arbeit zu vermeiden.

Es gab kein Teilen, keine Wiederverwendung von Daten und auch keine wirtschaft-lich sinnvolle Skalierung, um Datenbewegung und -entwicklung zu vereinfachen beziehungsweise die Kosten dafür zu reduzieren.

Fachanwender griffen über unterschiedliche Anwendungen auf gemeinsame Daten zu. Datenbenennung und -formate variierten je nach Anwendung.

Nutzer mussten mit inkonsistenten Berichten arbeiten, da die Quelldaten nicht dokumentiert waren und für jeden einzelnen Report andere verwendet wurden.

5

Das Ergebnis: Dubletten, Prozessüberschneidungen und ein geringes Bewusstsein dafür, dass für einzelne Projekte genau die gleichen Arbeitsschritte wiederholt wurden. Es gab keinen Ansatz, der eine Kommunikation, Kooperation oder das Teilen von Datenmethoden über Projekte und Systeme hinweg unterstützte.

Das Problem: Jedes Projekt der Bank ging Datenthemen als eine einmalige Aufgabe an, für die das Rad neu erfunden werden musste.

Case Study: die Datenherausforderungen der Bank

Das IT Team hatte 17 Projekte zu betreuen, darunter neue Anwendungen, Anwendungsverbesserungen, neue Berichte.

• Jedes Projekt erforderte Zugang zu Kundendaten und umfasste Aufgaben sowie Ressourcen, die sich mit denen anderer Projekte überlappten.

• Für jedes Projekt mussten Quelldatenverzeichnis und -analyse neu aufgesetzt werden, weil es keine Möglichkeit gab, herauszufinden, wo spezifische Daten abgelegt waren.

• Neue Datenabzüge (Teilmengen von den Applikationsdaten, die für die Ver -wendung durch andere Systeme kopiert wurden) mussten erstellt werden, da die IT keinen Überblick hatte, ob die Daten bereits vorhanden waren.

• Teams tauschten keine Abzüge aus den Quelldaten aus. Jedes Team legte seine eigenen Kopien für Datenintegrations- und Datenbankaufbauprozesse an, was zusätzlichen Speicherplatz für diesen temporären Content belegte.

• Die Integrationslogik wurde für jedes Team angepasst und individuell gepflegt, da weder die Logik noch die dazugehörigen Regeln identifiziert/dokumentiert waren, um sie teilen zu können.

Die Fachabteilungen wiederum, abhängig von ihren eigenen operativen und Reporting-Anforderungen, standen vor anderen Herausforderungen:

• Das Marketing musste sein Kampagnensystem kontinuierlich aktualisieren, um es an häufige (und nicht kommunizierte) Änderungen bei der Struktur der Datenauszüge anzupassen.

• Sales Manager stellten regelmäßig Fragen zu KPI-Berichten mit Einzelheiten zu Kunden, da Titel und Bezeichnungen über Berichte hinweg variierten – obwohl sie auf den gleichen Daten basierten.

• Anwender in den Fachbereichen erstellten oftmals ihre eigenen Reports, statt die Standardvorlagen der Finanzabteilung zu verwenden, da die Herkunft der Standard - reportdaten nicht festgestellt werden konnte.

• Das Data Warehousing Team musste sich ständig um Datenprobleme kümmern, da es dafür keine standardisierten Managementprozesse gab.

Definition: Was ist eine Datenstrategie überhaupt?Konzepte für Standards, Kooperation und Wiederverwertung sind in den meisten Unternehmen inzwischen übergreifend etabliert. Entwickler-Teams kennen sich vorwiegend mit Systemarchitektur, Entwicklungsmethoden, Anforderungskatalogen sowie Testen und Wiederverwendung von Code aus. Fachabteilungen kennen die Konzepte für Geschäftsanforderungen, Geschäftsprozessdefinitionen und Ergebnis-messung. Allerdings ist die Anwendung dieser Konzepte auf Daten, um deren Genauigkeit, den Zugriff, das Teilen und die Wiederverwendung zu verbessern, für die Mehrheit noch Neuland.

Das Problem: Jedes Projekt der Bank ging Datenthemen als eine einmalige Auf gabe an, für die das Rad neu erfunden werden musste.

6

Eine Datenstrategie hat zum Ziel, die Erhebung, die Speicherung, das Management und alle Wege des Teilens und der Verwendung von Daten zu verbessern.

Für eine effiziente Datenstrategie müssen alle Datenressourcen so aufgestellt sein, dass sie einfach und effizient genutzt, geteilt und bewegt werden können. Daten sind nicht länger ein Nebenprodukt von Geschäftsprozessen, sondern werden wie ein entscheidendes Asset behandelt, das Prozesse und Entscheidungen ermöglicht. Die Datenstrategie stellt projektübergreifende Ziele auf, um sicherzustellen, dass Daten gleichzeitig effektiv und effizient genutzt werden. Umfassende Methoden, Praktiken und Prozesse sollen dafür sorgen, dass Daten im gesamten Unternehmen wiederverwendbar verwaltet, verarbeitet und geteilt werden können.

Die meisten Unternehmen haben mehrere Datenmanagement-Initiativen gleich-zeitig (Metadaten- und Masterdatenmanagement, Data Governance, Datenmigration, Modernisierung, Datenintegration, Datenqualität etc.). Allerdings konzentrieren sie sich oft auf isolierte Einzellösungen, die auf spezifische Projekte oder Unterneh mens - anforderungen abzielen. Im Zuge einer Datenstrategie wird eine Roadmap einge-führt, die die Aktivitäten jeder Datenmanagement-Disziplin miteinander verknüpft. Das Prinzip ist dabei, dass die Disziplinen sich gegenseitig ergänzen und aufein-ander aufbauen, um so ressourcenmäßig Vorteile zu schaffen.

Die 5 Elemente einer DatenstrategieIn der Vergangenheit haben sich Strategien auf die Speicherung von Daten konzent-riert. Die IT hat umfassende Pläne für die Dimensionierung und das Management ihrer Plattformen erstellt sowie komplexe Methoden für die Datenspeicherung ent -wickelt. Dies ist zwar wichtig, jedoch werden damit längst nicht alle Möglichkeiten zur Ver besserung der Erhebung, Speicherung, Verwaltung, des Teilens und der Verwen dung von Daten ausgeschöpft.

Eine Datenstrategie muss auch Datenspeicherung mit einbeziehen, aber darüber hinaus die erwähnten Aspekte berücksichtigen. Damit sie erfolgreich ist, muss sie sämtliche Disziplinen des Datenmanagements einbeziehen, um alle möglichen

Identify

TheCore

ComponentsGovern

Integrate

Store

Provision

Abbildung 1: Die 5 Elemente einer Datenstrategie.

7

Probleme im Hinblick auf Datenverfügbarkeit und -verwendbarkeit lösen zu können. Dieser Ansatz wird der Vielfalt an Prozessen und Entscheidungen, mit denen sich Unternehmen heute beschäftigen müssen, gerecht.

Es gibt fünf Kernelemente einer Datenstrategie, die den Grundstein für eine Unter-stützung des Datenmanagements im gesamten Unternehmen legen: Identifizieren, Speichern, Bereitstellen, Integrieren und Regulieren.

Identifizieren

Daten identifizieren und ihre Bedeutung verstehen – unabhängig von ihrer Struktur, ihrer Herkunft oder ihrem Speicherort

Methoden zur Identifizierung und Darstellung des Inhalts bilden die Ausgangsbasis für die Nutzung und das Teilen von Daten innerhalb eines Unternehmens. Egal, ob es sich um strukturierten oder unstrukturierten Content handelt: Die Manipulation und Verarbeitung von Daten ist nur dann praktikabel, wenn den Daten ein Wert, ein definiertes Format und eine Bewertung ihrer Wichtigkeit zugeordnet sind (selbst unstrukturierte Daten verfügen über diese Details). Eine konsistente Benen-nung der Datenelemente und Zuordnung von Werten ist die Voraussetzung für die Verwendung und das Teilen von Daten. Diese Details sollten unabhängig von der Art der Speicherung (in einer Datenbank, Datei etc.) beziehungsweise von dem physischen System, in dem sie liegen, sein.

Es ist zudem wichtig, Möglichkeiten für die Referenzierung und den Zugriff auf die mit den Unternehmensdaten verbundenen Metadaten zu schaffen (Definition, Herkunft, Ort, Domänenwerte). Ähnlich wie ein Verzeichnis dem Besucher einer Bibliothek dabei hilft, ein bestimmtes Buch in den Regalreihen zu finden, sind Metadaten die Voraussetzung für erfolgreiche Datennutzung, insofern, als sie dazu dienen, die spezifischen Datenelemente abzurufen. Ohne diese Details zur Daten-identifizierung müsste jedes Mal ein neuer Datenbestand angelegt und analysiert werden, wenn neue Daten hinzugefügt werden. Die Konsolidierung von Geschäfts-terminologie und -bedeutung in einem Geschäftsdatenglossar ist ein häufig ein - gesetztes Mittel, um dieser Herausforderung zu begegnen.

Ohne Datenglossar und Metadaten (beispielsweise in Form eines „Data Dictionary“) laufen Unternehmen Gefahr, einige ihrer wichtigsten Daten-Assets zu übersehen. Vor dem Hintergrund, dass Daten einen echten Unternehmenswert dar stellen, muss eine Datenstrategie sicherstellen, dass sämtliche Daten identifiziert werden können.

Speichern

Daten in einer Struktur und an einem Ort vorhalten, die einfachen Zugriff und Verarbeitung durch verschiedenste Unternehmensbereiche ermöglichen

Datenspeicherung ist zwar eine der Basisfunktionalitäten im Technologieportfolio eines Unternehmens – nichtsdestotrotz handelt es sich um eine komplexe Disziplin. Viele IT-Abteilungen verfügen bereits über ausgereifte Methoden, um die Speicher-anforderungen für einzelne Applikationssysteme zu identifizieren und zu managen. Jedes System erhält ausreichend Speicherplatz, um seine eigenen Anforderungen in Sachen Verarbeitung und Ablage zu erfüllen. Für Transaktionsanwendungen, analytische Systeme oder allgemeine Datenspeicherung (beispielsweise Dateien, E-Mails, Bilder) setzen Unternehmen gleichermaßen ausgefeilte Methoden ein, um Kapazitäten zu planen und den einzelnen Systemen Speicherplatz zuzuteilen. Dieser Ansatz zielt allerdings lediglich auf die Erfassung von Daten, nicht auf das Teilen und die Verwendung.

Das Forbes Magazine1 hat über ein medizini-sches Forschungs-unternehmen berich-tet, das 100 Terabyte an Daten generierte. Diese wurden letztlich von 18 verschiedenen Teams kopiert und vor - gehalten. Das Ergebnis: mehr als 10 Petabyte belegter Speicherplatz.

1forbes.com/sites/ciocentral/2012/07/05/best-practices-for-managing-big-data

8

Die Lücke besteht darin, dass es selten einen Plan für ein effi zientes Management der Speicherkapazitäten gibt, die für das Teilen und Bewegen von Daten zwischen Systemen benötigt werden. Der Grund dafür ist einfach: Die off ensichtlichste Art des Data Sharing ist von Natur aus transaktional. Transaktionale Informationen werden zwischen Applikationen bewegt und geteilt, um einen spezifi schen Geschäftsprozess abzuschließen. Das Teilen von Massendaten wird oft noch missverstanden als ein einmaliges oder seltenes Ereignis.

Mit der Popularität von Big Data, der wachsenden Verbreitung von Business Analytics und dem steigenden Bedarf an Informationsaustausch in Unternehmen ist das Teilen von großen Mengen an Daten (oder Massendaten) zu einer Notwendigkeit geworden. Der größte Anteil dieses Shared Content fällt in eine der beiden Kategorien: intern generierte Daten (wie Informationen zu Kunden oder zum Kauf) und extern generierte Inhalte (wie Cloud-Applikationen, Third Party-Daten oder gemeinsam genutzte Informationen). Das Fehlen eines zentral verwalteten Data Sharing-Prozesses zwingt typischerweise alle Systeme, ihren Speicherplatz individuell zu managen, da jedes seine eigene Kopie der Datenquelle erstellt.

Das Forbes Magazine1 hat über ein medizinisches Forschungsunternehmen berichtet, das 100 Terabyte an Daten generierte. Diese wurden letztlich von 18 verschiedenen Teams kopiert und vorgehalten. Das Ergebnis: mehr als zehn Petabyte belegter Speicherplatz.

Die Weiterentwicklung von Unternehmen und die rasant wachsenden Daten-bestände machen das Speichern von Daten an einem einzigen Ort wenig sinnvoll. Zwar ist es möglich, ein System aufzubauen, das groß genug ist, um den gesamten Content zu fassen. Das Problem ist jedoch die Größe und dezentralisierte Struktur von Unternehmen heutzutage sowie die Vielfalt an Datenquellen: Das Laden von Daten in eine einzige Plattform ist einfach nicht mehr praktikabel. Nicht jeder Mit -arbeiter benötigt Zugriff auf alle Unternehmensdaten, sondern nur auf spezifi sche Infor ma tionen, die seine Erfordernisse unterstützen. Wichtig ist lediglich, dass die Gesamtheit der Daten für jeden einfach zugänglich ist und dass es nachvollziehbar ist, wo und wie diese Daten zu fi nden sind.

Wie wir wissen, werden Daten nach ihrer Entstehung mit zahlreichen anderen Systemen geteilt. Es ist entscheidend, effi zient an das Thema Storage heranzugehen, so dass der Zugang zu wichtigen Daten erleichtert wird. Mit einer durchgängigen Datenstrategie ist die Voraussetzung dafür geschaff en, dass Daten künftig zugäng-lich sind, ohne dass jeder seine eigene Kopie erstellen muss.

Attribute Source De�nition Type ... ... Steward

Customer ID SalesCRM Value uniquely identifying Integer ... ... Susan Craff

First Name CapBilling Customer’s �rst name Character ... ... Susan Craff

Last Name CapBilling Customer’s last name Character ... ... Susan Craff

Middle Initial CapBilling Customer’s middle initial Character ... ... Susan Craff

Home Street ServCont Home street address Character ... ... Susan Craff

Home City ServCont Home residence city Character ... ... Susan Craff

... ... ... ... ... ... ...

... ... ... ... ... ... ...

Location

Product

Customer

Abbildung 2: Ein Daten-„Karteikasten“

9

Bereitstellen

Daten bündeln, so dass sie wiederverwendet und geteilt werden können. Regeln und Richtlinien für den Zugriff auf Daten schaffen

In den ersten Tagen der IT wurden die meisten Applikationssysteme noch als einzelne, unabhängige Datenverarbeitungs-Engines gebaut, bei denen sämtliche Daten abgelegt waren, damit sie ihre definierten Aufgaben erfüllen konnten. Damals gab es noch so gut wie keine Ansätze, Daten über mehrere Applikationen hinweg zu teilen.

Kam gelegentlich die Nachfrage nach Daten aus „fremden“ Anwendungen auf, hat der Applikationsentwickler einen Auszug erstellt. Dabei hat er entweder die Daten in eine Datei gepackt oder ein einmaliges Programm zur Unterstützung der Anfrage einer anderen Applikation erstellt. Gedanken über weitere Anforderungen in Sachen Datenbereitstellung oder Datenwiederverwendung und Data Sharing machte sich kaum jemand. Das Teilen von Daten kam damals noch sehr selten vor. Heute ist es die Regel: Oft greifen bis zu zehn andere Systeme auf die einmal erhobenen Daten zu, um zusätzliche Geschäftsprozesse oder Entscheidungen zu unterstützen.

Allerdings sind die meisten herkömmlichen Applikationssysteme nicht darauf aus-gelegt, Daten zu teilen. Logik und Regeln, um Daten für den Gebrauch durch andere zu entschlüsseln, sind außerhalb des Applikationsentwicklungs-Teams selten doku-mentiert oder bekannt. In der Regel stellen IT-Abteilungen weder Budget noch Ressourcen bereit, um Daten zu teilen, wenn es sich nicht um Transaktionsdaten handelt. Stattdessen wird dies als persönlicher Gefallen unter Mitarbeitern betrachtet.

Um sie zu teilen, werden Daten gewöhnlich in Paketen gebündelt – allerdings so, wie es der Applikationsentwickler braucht, nicht der Anwender. Ein solcher Ansatz mag in der Vergangenheit akzeptabel gewesen sein, als wenige Systeme und nur einige Teams Zugang brauchten. Heute jedoch, wo die IT Dutzende von Systemen, die sich auf Daten aus einer Vielzahl an Quellen stützen, managen muss, um einzelne Ge schäfts- prozesse zu unterstützen, ist er komplett inadäquat. Packaging und Sharing von Daten

Internal

Cloud Applications Business Partners

SuppliersSupport

Purchasing Inventory

Billing

Distribution

DataVendors

SyndicatedData

External ProvidersSocial Media

SFA

Marketing Sales Finance Support

Abbildung 3: Jedes System erzeugt seine eigenen Kopien von Daten und verursacht dadurch eine Steigerung des Verbrauchs an Speicher und Prozessleistung um das Vierfache.

10

darf sich also nicht nur nach den Anforderungen eines einzelnen Applikationsent-wicklers richten. Und wenn sich erst jeder Einzelne mit den Eigenheiten einer Vielzahl an Quellanwendungssystemen vertraut machen muss, bevor er die Daten nutzen kann, ist dies ebenso wenig zielführend.

Data Sharing ist längst keine spezielle technologische Kompetenz von Applika tions-architekten und -programmierern mehr. Es ist zu einer Geschäftsanforderung im gesamten Unternehmen geworden. Geschäftserfolg hängt davon ab, dass Daten zu operativen und analytischen Zwecken gemeinsam genutzt und untereinander aus ge - tauscht werden können. Sharing ist weder eine Gefälligkeit, noch sind die Methoden zum Bündeln und Teilen von Daten eine einmalige Notwendigkeit.

Datenbereitstellung muss sich als Standardprozess etablieren, um das volle Potenzial aus dem Asset „Daten“ herausholen zu können.

Integrieren

Bewegen und Zusammenführen von Daten, die in unterschiedlichen Systemen abgelegt sind. Bereitstellen einer einheitlichen Sicht auf die Daten

Es ist kein Geheimnis, dass Datenintegration eine der kostspieligsten Aufgaben in der IT darstellt. Fast 40 Prozent der Kosten für Neuentwicklungen werden von Datenintegration verursacht. Integration bedeutet jedoch nicht nur das herkömm-liche Extrahieren, Transformieren und Laden von Daten im Zusammenhang mit Data Ware housing. Es umfasst sämtliche Daten (strukturiert, semistrukturiert oder un struk-turiert) und deren Bewegung zwischen allen Systemen (operativ und analytisch). Die Herausforderung bei der Datenintegration ist es, die Daten über die verschiedenen Quellen hinweg abzugleichen, ohne dass dafür ein expliziter Schlüssel oder eine eindeutige Kennung vorhanden ist.

Entwickler verwenden enorm viel Zeit für den Aufbau von Logik, um verschiedene Quellen miteinander zu verknüpfen. Allerdings verlangt jedes neue Entwicklungs-Team Zugang zu einzelnen Datenquellen und rekonstruiert vorhandene beziehungs-weise erstellt immer wieder neue Verknüpfungen zwischen den gleichen Daten - quellen. Und bei Datenintegration fällt diese doppelte Arbeit mit jedem neuen Projekt an, denn die Erkenntnisse der Vergangenheit werden nicht für künftige Auf -gaben herangezogen.

ClientID FName MName LName BirthDate MPhone ResAddress

1298116 William James Sosulski 04/12/39 9738723424 123 Oak St., Eves, IL 30319SFA

Sales

Acct.

Support

CustNbr FirstNm MI LastNm DOB HomePhone ContactAddress

7B983 William J. Sosulski 9736780994 437 Main St. Chicago, IL

Account FirstName Middle Last Name BDate Phone Address

1695281 Willaim James Corp. April 12 5634911234 3224 Pkwy G, Los Osos

Customer FirstName MidName LName DOB Contact Address

1298116 William James Sosulski 04/12/1939 3154789087 123 Oak St., Eves, IL 30319

Abbildung 4: Kundeninformationen, die in jeder operativen Anwendung getrennt gespeichert und referenziert werden.

11

In den meisten Unternehmen ist Datenintegration nicht zentralisiert. Jedes System- oder Applikations-Team kümmert sich ausschließlich um seine eigenen Belange. Zwar haben viele IT-Abteilungen die Aufgabe der Datenintegration für ihr Data Warehouse in einem eigenen Team konsolidiert; die Umsetzung von Dateninte gra tionsprozessen fi ndet jedoch häufi g auch außerhalb davon in anderen Applikations bereichen statt. Mit Cloud-Applika tionen und Technologie-Teams in den Fachabtei lungen ist die Ent wicklung von Datenintegrationsfunktionen nicht selten über verschiedene Abtei-lungen im Unter nehmen hinweg verteilt. Die Programmentwicklung zur Identifi zierung und Abgleichung von Datensätzen über diese einzelnen Quellen hinweg ist unter Um ständen sehr komplex, insbesondere wenn ein System Daten aus 20 oder mehr Quellen verwendet.

Was die Sache noch komplizierter macht, ist die Tatsache, dass die Mehrheit der Entwicklungs-Teams in Silos agiert und wenig darüber weiß, woran andere Teams arbeiten. Der Mangel an Tools und Methoden für Data Collaboration hat oft zur Folge, dass Teams keine Ahnung haben, welche Programme bereits vorhanden sind – und möglicherweise wiederverwendet werden könnten. Integration sollte dafür sorgen, dass einmal abgezogene Daten konsistent und wiederholbar in vorhandene Daten sätze eingefügt und für alle angeschlossenen Systeme bereitgestellt werden können.

Viele Unternehmen haben Initiativen für Programmwiederverwendung und -Collabo ration bei der Applikationsentwicklung. Nun muss Datenentwicklung als Disziplin erkannt werden, die die gleiche Stringenz und Methodologie erfordert. Entwickeln und managen die verschiedenen Teams alle ihre eigene Integrations-logik, nimmt die Wahrscheinlichkeit ab, dass Daten konsistent über verschiedene Projekte hin weg erhoben oder integriert werden – umso mehr, je stärker die Anzahl der Daten quellen und das Datenvolumen steigen.

DataSources

Application

Client Data(flat file)

Pricing Data(spreadsheet)

Sales Data(DBMS table)

Client Contacts(cloud app)

SalesForecasting

CampaignManagement

BI/DWReporting

Abbildung 5: Jede Datenquelle umfasst spezifi sche Daten (farbige Kästen). Da jede Anwendung ihre eigene Integrationslogik schaff t, können die Datenwerte für die einzelne Anwendung abweichen.

12

Regulieren

Etablieren, Managen und Kommunizieren von Informationsrichtlinien und -mecha-nismen für effektive Datennutzung

Da Daten immer noch häufig als Nebenprodukt der Applikationsverarbeitung betrachtet werden, haben bisher wenige Unternehmen Methoden und Prozesse entwickelt, um Daten außerhalb des Applikationskontextes beziehungsweise im gesamten Unternehmen zu managen. Inzwischen haben einige in Data Governance-Initiativen investiert, andere stecken diesbezüglich jedoch noch in den Kinder schuhen.

Viele Data Governance-Initiativen beschäftigen sich zunächst mit taktischen Fragen (zum Beispiel Datengenauigkeit, Definition von Geschäftsregeln oder Terminolo-giestandards) und sind auf bestimmte Abteilungen oder Projekte begrenzt. Doch inzwischen wächst das Bewusstsein für Governance, da die Probleme um Daten-Sharing und Verwendung auch für die Business-Anwender zunehmend erkennbar werden. Deshalb werden Governance-Initiativen immer häufiger ausgeweitet. In der Folge ist es naheliegend, Informationsrichtlinien, Regeln und Methoden aufzu-stellen, damit eine einheitliche Nutzung, Manipulation und Verwaltung der Daten sichergestellt ist.

Allzu häufig jedoch wird Data Governance lediglich für Anwender und die Analytics-Umgebung als verbindlich angesehen. Tatsächlich muss Data Governance auf sämt-liche Anwendungen, Systeme und Mitarbeiter angewandt werden. Die größte Herausforderung im Zusammenhang mit Data Governance ist die Akzeptanz – denn Data Governance funktioniert nur als übergreifendes Rahmenwerk mit Informations-richtlinien und Regeln, denen jeder im Unternehmen folgt.

Ein wirkungsvoller Governance-Prozess ist notwendig, damit – wenn die Daten erst einmal von der Applikation, die sie generiert hat, entkoppelt sind – die dazuge-hörigen Regeln und Details von allen Mitarbeitern und Teams, die mit diesen Daten künftig arbeiten, respektiert werden. Die Rolle von Governance in der Gesamt-datenstrategie ist es, sicherzustellen, dass das Management und die Verarbeitung von und der Zugriff auf Daten im gesamten Unternehmen konsistent sind – egal, ob es darum geht, Sicherheitsdetails, Logik für die Datenkorrektur, Standards für die Datenbezeichnung oder neue (Daten-)Berechnungsregeln aufzustellen. Entschei-dungen, wie Daten verarbeitet, aufbereitet oder geteilt werden, sind nicht von einem einzelnen Entwickler zu treffen, sondern sind durch die Data Governance vor gegeben.

Eine Data Governance sollte nicht den Zugang zu Daten oder deren Nutzung einschränken, sondern dies – im Gegenteil – vereinfachen. Zu Beginn kann sie die Produktivität von Entwicklern beeinträchtigen (aufgrund neuer Prozesse und Auf -gaben). Allerdings sollten Vorteile für die nachgelagerte Datenverwendung und dramatische Steigerung der Gesamtproduktivität diese Auswirkungen mehr als ausgleichen.

Die Einbindung von Data Governance in die Datenstrategie ist unerlässlich für die Erstellung eines Plans, der sämtliche Möglichkeiten, Informationen zu sammeln, aufzubewahren, zu verwalten oder zu nutzen, regelt. Data Governance schafft die nötige Rigorosität im Umgang mit Daten, wenn sich Änderungen in der Tech-nologie, der Verarbeitung oder der Methodologie im Umfeld der Datenstrategie ergeben.

13

Die Definition der Datenstrategie ist entscheidendFast jede neue Applikation oder jeder neue Report benötigt Zugang zu Unternehmens - informationen. In den meisten Fällen ist für Entwickler der Austausch mit anderen Mitarbeitern der einfachste Weg, um festzustellen, ob bestimmte Daten existieren und welches die bestmögliche Quelle ist. Jedoch hat die Zunahme an Open Source- und Cloud-Applikationen zu einer immensen Vielzahl an datengenerierenden Systemen geführt, die das Wissen jeder Einzelperson überschreitet. Es gibt einfach zu viele Systeme, Quellen und Daten, als dass ein Einzelner alle im Blick behalten und managen könnte. Die Nutzung der wertvollen Unternehmensdaten sollte sich daher nicht auf weitergegebenes Wissen stützen.

Unternehmen investieren zwar Millionen in die Verbesserung des Datenmanage-ments, allerdings richten sich die Aktivitäten meist auf punktuelle Lösungen, die einzelne Probleme angehen. Nur wenige haben eine Vorstellung davon, wie sich eine einzelne Investition auf andere Projekte oder Dateninitiativen auswirken könnte. Die meisten Unternehmen müssen erst noch erkennen, dass Datenzugriff und -nutzung für jede Abteilung und jeden Mitarbeiter unabhängig vom Fachwissen relevant sind.

Das Risiko bei einer Investition in eine punktuelle Lösung besteht darin, dass deren Fokussierung verhindert, auch Probleme über die einzelne Abteilung oder das einzelne Projekt hinaus zu lösen – und Datenprobleme sind von Natur aus nicht an eine einzelne Abteilung oder Anwendung gebunden. Die Bereitstellung von neuen Daten und/oder Analytics funktioniert ausschließlich dann, wenn zuvor alle anderen datenbezogenen Komponenten bearbeitet worden sind: Identifizierung, Speicherung, Bereitstellung, Integration und Regelung.

Was eine Datenstrategie wirklich leisten kannZurück zum Bankenbeispiel: Nachdem gemeinsam mit dem Leiter der Bank die verschiedenen Komponenten der Datenstrategie kritisch betrachtet worden waren, erkannte er, dass viele Projekte unter seiner Verantwortung nicht miteinander verknüpft waren, um so den strategischen Wert des Datenbestandes der Bank zu erhöhen. Zwar gab es umfassende Vorgaben für einzelne Systeme und Applika-tionen, Daten bekamen jedoch noch nicht die Aufmerksamkeit, die sie bekommen sollten. Sein Unternehmen nutzte wenig Projektmethoden oder -Tools, die das Teilen und die Wiederverwendung von Daten vorantreiben. Er wollte in Sachen Datenstra-tegie weiter gehen, benötigte dafür aber realistische Ziele und messbare Ergebnisse.

„Wir haben mit neuen strategischen Initiativen zu kämpfen. Oftmals scheitern sie, weil die Ziele zu hoch gesteckt sind und der Erfolg nicht präzise definiert ist. Oder sie werden zu Mammutprojekten, die am Ende viel zu teuer oder komplex sind. Daten sind bei uns ein großes Problem. Wie können wir weitermachen, ohne die Fehler der Vergangenheit zu wiederholen? Wie können wir neue strategische Initiativen schnell, übersichtlich und wertorientiert umsetzen?“

Die Stärke der Komponenten einer Datenstrategie ist, dass sie dabei helfen, fokus-sierte, konkrete Ziele innerhalb jeder einzelnen Disziplin zu erreichen. Jedes Unter-nehmen verfügt über ganz unterschiedliche Qualifikationen, Stärken und Schwächen. Am Anfang einer Datenstrategie steht daher die Identifizierung von Stärken und Schwächen in Bezug auf die Datenumgebung (für jede Komponente). Zudem müssen

Die meisten Unter-nehmen müssen erst noch erkennen, dass Datenzugriff und -nutzung für jede Abteilung und jeden Mitarbeiter unabhän-gig vom Fachwissen relevant sind.

14

erreichbare und messbare Ziele festgelegt werden, die zu besserem Datenzugriff und Data Sharing führen. Die Komponenten müssen nicht jede erdenkliche Daten-aktivität abdecken, sondern geben Einblick in die verschiedenen Disziplinen, aus denen sich eine Datenstrategie zusammensetzt.

Die Etablierung einer Datenstrategie ist keine einmalige Initiative, sondern ein langfristiges Erreichen von mehreren Zielen. Üblicherweise werden Ziele für die nächsten Jahre festgelegt und kurzfristigere Ergebnismeilensteine definiert (quar-talsweise oder jährlich). Auf diese Weise lässt sich die Strategie regelmäßig über-prüfen und messen, um Hürden wie die vom Bankenchef genannten zu umgehen. Die Kompo nenten dienen dazu, Aktivitäten zu kategorisieren und kurzfristige Ergebnisse zu identifizieren.

Meistens wird beim Datenmanagement in die verschiedenen Komponenten inves-tiert. Allerdings sind die einzelnen Bereiche in der Regel nicht koordiniert oder mitei-nander verknüpft. Das Beispiel der Bank zeigt, wie der Mangel einer umfassenden Datenstrategie (und miteinander verbundener Aktivitäten) immense Schwierigkeiten bei Datenzugriff und -verwendung verursachen kann. Eine Datenstrategie zeigt die Relationen zwischen den einzelnen Komponenten (und Disziplinen) auf.

Der größte praktische Nutzen einer Datenstrategie besteht darin, auch mit nicht vorhersehbaren Datenanforderungen umgehen zu können. Sie ermöglicht, immer die bestmögliche Lösung bereitzustellen, je nachdem, wie sich die Anforderungen des Unternehmens entwickeln und wachsen. Ergeben sich neue Aufgaben oder zu füllende Lücken, zeigen die Bestandteile des (Data Governance) Frameworks, welche Anpassungen im Datenmanagement notwendig sind. Mit dieser Roadmap sind Unternehmen für aktuelle und künftige Anforderungen im Datenmanagement gewappnet.

Weitere Informationen Informieren Sie sich unter www.sas.com/daten, wie SAS Data Management Ihnen bei der Entwicklung und Umsetzung einer erfolgreichen Datenstrategie helfen kann.

SAS and all other SAS Institute Inc. product or service names are registered trademarks or trademarks of SAS Institute Inc. in the USA and other countries. ® indicates USA registration. Other brand and product names are trademarks of their respective companies. Copyright © 2017, SAS Institute Inc. All rights reserved.

To contact your local SAS office: www.sas.com/germany Phone: +49 6221 415-123 www.sas.com/austria Phone: +43 1 252 42-0 www.sas.com/switzerland Phone: +41 44 805 74-74

P12

160

332