Big Data | Data Warehouse Lösung

Data Warehouse und analytische Datenbanken

Unsere langjährige Erfahrung ist unsere Kompetenz

„Data Warehouse und analytische Datenbanken“ ist der Name einer von drei Säulen des Lösungsangebotes der pmOne. Nachfolgend finden Sie einen längeren Text, der unsere Erfahrungen und unsere Kompetenz zu diesem Thema darstellt. Je mehr Sie die Herausforderungen und Erkenntnisse in den nachfolgend gemachten Aussagen und Thesen wiedererkennen, desto erfolgversprechender ist eine Zusammenarbeit mit der pmOne bei diesem Thema. Kontaktieren Sie uns...

Ein Data Warehouse ignoriert viele Realitäten im Unternehmen

Data Warehouse
Data Warehouse

Das Data Warehouse stand und steht seit vielen Jahren im Zentrum vieler Business Intelligence Projekte und wurde propagiert als Fundament für unternehmensweite Business Intelligence Lösungen. Denn eine Data Warehouse sollte als „Single-Point-of-Truth“ dienen, in dem die „absolute Unternehmenswahrheit“ enthalten ist. Alle Mitarbeiter sollten auf die widerspruchsfreien und konsistenten im Data Warehouse zugreifen können. Gestartet wurde ein Projekt für den Aufbau eines Data Warehouse häufig im Finanz- oder Controllingbereich. Denn die hier anfallenden Daten sind im Regelfall klar definiert und ließen sich zumeist schnell in ein Data Warehouse überführen. Wegen ihrer Andersartigkeit fiel die Integration von Daten aus dem Vertrieb oder dem Marketing ins Data Warehouse schwerer.

Obwohl viel Zeit und Ressourcen dafür verwendet wurde, Unternehmensprozesse zu harmonisieren und zu strukturieren, damit die anfallenden Daten ins Data Warehouse übernommen werden konnten, haben diese Bemühungen nur in den seltensten Fällen zum Erfolg geführt. Die vermeintlichen Ursachen waren – verbunden mit entsprechenden Schuldzuweisungen - schnell gefunden: Die Unternehmensprozesse seien zu unstrukturiert bzw. wurden nicht eingehalten, die Anwender in den Fachabteilungen seien zu undiszipliniert, vom Fachbereich sei zu wenig Zeit und Aufmerksamkeit auf die Konzeption verwendet worden, etc. Kurzum: der Faktor Mensch war inkompatibel mit der Idee – besser: der Utopie - des „Single Point of Truth“.

Im Rückblick unverständlich wurde versucht, den Menschen bzw. die Anwender zu ändern, ja sogar umzuerziehen, damit sie ein strukturierbarer und disziplinierbarer Teil des „Ökosystems Data Warehouse“ werden. Spätestens die Finanzkrise 2008/2009 hat zu der Erkenntnis geführt, dass das strukturierte und integrierte Data Warehouse für die schnelle Verwirklichung vieler neuer und unternehmenskritischer Anforderungen an eine Business-Intelligence-Anwendung einfach viel zu behäbig und starr ist. Die Turbulenzen in der Finanzkrise und die wirtschaftliche Realität verlangten nach höherer, maximaler Umsetzungsgeschwindigkeit. Daran sowie an den Bedürfnissen und Verhaltensweisen der Menschen und Anwender hat sich die Technologie auszurichten. Der Versuch, Menschen bzw. deren Verhalten an eine Data Warehouse Lösung anzupassen, war ein Irrweg.

BARC-Institut befragte Anwender zum Thema Data Warehousing: Ernüchternde Ergebnisse

Fachbereiche und IT-Abteilung sind enttäuscht vom Nutzen eines Data Warehouse. Dies zeigen  sehr deutlich die Ergebnisse einer 2011 durchgeführten Anwenderbefragung des unabhängigen BARC-Instituts zum Thema „Data Warehousing“ in Deutschland, Österreich und der Schweiz. Aus über 200 Antworten von Entscheidungsträgern in IT-Abteilungen und verschiedenen Fachbereichen ergibt sich deutlich, dass der Nutzen von Data-Warehouse-Projekten unter den Erwartungen bleibt. Nachfolgend einige der zentralen Ergebnisse aus der Befragung, die zu diesem ernüchternden Fazit führen:

Nahezu alle Befragten (98 Prozent) bewerten die Bedeutung des Data Warehouses als ‚wichtig‘ oder ‚kritisch‘ für ihr Unternehmen.

„Vertrauen in Daten“ befindet sich mit deutlichem Abstand auf dem ersten Platz der wichtigsten Ziele für die Einführung eines Data Warehouse. Für 96 Prozent der Teilnehmer ist dies „wichtig“ (14 Prozent) oder „äußerst wichtig“ (82 Prozent).
Die Zielerreichung nach der Einführung eines Data Warehouses ist fast mager zu nennen: Nur 51 Prozent der Befragten sehen das Ziel ‚Vertrauen in Daten‘ erreicht. Alle übrigen Aspekte weisen eine Zielerreichung von weniger als 50 Prozent auf. Signifikante Unterschiede gibt es im Detail: Nutzer, die auf vollständig synchroni-sierte Daten zugreifen, bewerten die Zielerreichung durchschnittlich um 20 Prozent höher, als Nutzer mit nicht synchronisierten Daten im Data Warehouse. Viele Befragungsteilnehmer erkennen den größten Nutzen aus dem Data Warehouse in ihrer eigenen Abteilung.

Trotzdem ist das Konzept des Data Warehouse stark verbreitet: Bei 86 Prozent der Befragten ist die Speicherung von Daten zur Entscheidungsunterstützung in einem Data Warehouse das klar dominierende Konzept, 52 Prozent der Befragten nutzen informelle Datenbestände und 26 Prozent haben unabhängige Data Marts aufgebaut.

Im Fazit kommentiert Dr. Carsten Bange, Geschäftsführer des BARC-Instituts die Ergebnisse: „Die Zielerreichung von Data-Warehouse-Projekten kann absolut nicht als befriedigend bezeichnet werden und auch die genannten Herausforderungen hinsichtlich Datenqualität, Agilität, Integration wichtiger Fachbereiche oder übergreifender Auswertbarkeit werden Anwender weiter am Konzept hin und wieder zweifeln lassen und Betreibern große Kopfschmerzen bereiten.“ Dennoch werde insbesondere das Vertrauen in die für die Unternehmenssteuerung genutzten Daten von Data Warehouses sehr gut unterstützt. „Trotz aller Mängel und Herausforderungen von Data-Warehouse-Systemen schneiden die Alternativen, wie  informelle Organisation von Daten oder die Nutzung der operativen Systeme in vielen Aspekten schlechter ab“, schreibt Dr. Bange.

Die Ergebnisse der Anwenderbefragung können Sie hier anfordern.

Ein Data Warehouse ist Teil einer Information Architecture für Business Intelligence

Die Utopie des „Single-Point-of-Truth“
Schon seit Jahrhunderten lehrt uns die Philosophie, dass die Wahrheit im Auge des Betrachters liegt. Die moderne Quantenphysik geht einen Schritt weiter: Das Auge des Betrachters definiert sogar die Wahrheit. (http://de.wikipedia.org/wiki/Schr%C3%B6dingers_Katze) Daraus eine umfassende Analogie zum Data Warehouse zu ziehen, soll hier gar nicht versucht werden, aber eine Aussage lässt sich daraus ableiten: Einen „unternehmensweiten Single-Point-of-Truth“ kann es in der Realität sowohl praktisch als auch theoretisch nicht geben.

Deswegen ist ein Data Warehouse aber keinesfalls sinnlos. Für viele Anforderungen der Anwender gerade im Finanzbereich und im Controlling wird nach wie vor ein Data Warehouse die richtige Lösung sein. Ganz wichtig ist das Verständnis dafür, dass nicht alle Anforderungen an eine Business Intelligence Lösungen von einem Data Warehouse abgedeckt werden können und sollen. Vielmehr ist ein Data Warehouse ein Teil einer größeren „Business Intelligence Information Architecture“. Diese Erkenntnis wird insbesondere wichtig, um den Faktor Mensch bzw. das Verhalten der Anwender zu berücksichtigen.

Evolution und Komplexität
Bislang wurde immer versucht, ein Data Warehouse „am Reißbrett“ zu entwerfen. Dafür wurden die Anforderungen gesammelt zusammengeführt (Whiteboarding) und dann implementiert. In der Hoffnung, dass das Resultat den Erwartungen entsprach.

Ein solches Vorgehen ist bei stark vordefinierten Prozessen, wie sie beispielsweise in der Finanzabteilung oder im Controlling vorzufinden sind, auch erfolgreich. Wenn die Prozesse weniger vordefiniert oder gar als intransparent gelten, wie das beispielsweise im Vertrieb oder im Marketing der Fall ist, scheint ein solches Vorgehensmodell regelmäßig zu scheitern. Ein einfacher Grund dafür ist, dass sobald Systeme und Prozesse eine gewisse Komplexität erreicht haben, sich diese kaum vordefinieren lassen. Dieser Faktor bekommt durch den Einzug von Technologien, die mit großen Mengen von strukturierten Daten (Zahlen) und unstrukturierten Daten (Texten) umgehen können, noch stärkeres Gewicht. Solche Technologien werden derzeit unter dem Stichwort Big Data diskutiert. Beim Thema Big Data scheitern klassische Vorgehenskonzepte bereits vor dem Start.

Lösung hierfür ist das Lernen von der Natur, indem ein evolutionärer Ansatz gewählt wird. Anstatt zu versuchen, alles auf einmal im Vorfeld zu definieren, können komplexere bzw. schwierig definierbare Anforderungen an Business-Intelligence-Lösungen iterativ durch Erweitern und Verproben erstellt werden. Es gibt gute Beispiele aus der jüngeren Technologiegeschichte dafür, wie iterative und evolutionäre Vorgehensweisen lange gültige Prämissen aus dem Weg geräumt haben.

Beispiel Digitalfotografie

Noch vor wenigen Jahren wurde ein Foto noch länger „geplant“ und „konzipiert“. Der Ort wurde gut gewählt, die Belichtung wurde vorher geprüft, der richtige Film eingelegt, etc., bevor das Foto dann geschossen wurde. Danach wurde es beim Entwickler „implementiert“. Nach einigen Tagen konnten Interessierte das Resultat begutachten und überprüfen, ob es den ursprünglichen Erwartungen entspricht bzw. die Anforderungen erfüllt. Wer keine Zeit investierte um „Fotografie-Experte“ zu werden, wurde bei diesem Vorgehen des Öfteren vom eigentlichen Foto enttäuscht.

Mit der Digitalfotografie lässt sich das Ergebnis einer Aufnahme sofort überprüfen. Eine genaue Planung ist nicht mehr zwingend notwendig. Sollte das Foto nicht gefallen, lässt es sich einfach löschen und er Vorgang wiederholen, bis das Foto den Erwartungen entspricht. Die Technologie erlaubt dem Anwender eine so schnelle Wiederholung dieses „Probierens“, also ein iteratives Vorgehen, dass es keinen nennenswerten Mehraufwand bedeutet oder Verzögerungen verursacht, mehrere Fotos zu machen. Gutes Fachwissen zur Technik der Fotografie würde sicher helfen schneller zum perfekten Bild zu kommen, aber das nicht mehr zwingend notwendig. Auch „Fotografie-Laien“ können durch reines „Probieren“ fantastische Fotos erstellen.

Für den Aufbau eines Data Warehouse gelten die Vorteile eines evolutionären Vorgehens, oftmals despektierlich als „Rumprobieren“ bezeichnet, analog. Es gibt Anwendungsfälle, wo die traditionellen Ansätze für ein Data Warehouse nach wie vor der richtige Weg sind. Allerdings muss in einer ganzheitlichen Betrachtung das Data Warehouse um Technologien und Prozesse erweitert werden, die evolutionäre und iterative Vorgehensweisen erlauben. Die Technologien dafür sind mittlerweile vorhanden und erfüllen die Anforderungen hinsichtlich Einfachheit der Bedienung und Geschwindigkeit.

cMORE/Modelling ist eine Lösung, die evolutionäres Vorgehen beim Aufbau einer Buiness-Intelligence-Anwendung ermöglicht.

Geschwindigkeit der Umsetzung und Einfachheit

Der Begriff und das Konzept „In-Memory“ werden derzeit breit diskutiert. Es ist kein Geheimnis mehr, dass durch die neuartige In-Memory-Datenbank-Technologie eine sehr hohe Geschwindigkeit bei der Datenbankabfrage erreicht werden kann. Die Hardware für In-Memory-Technologien ist mittlerweile erschwinglich geworden. Insofern sollte nichts mehr die „In-Memory“-Revolution aufhalten. Dabei sollte ein sehr wichtiger Erfolgsfaktor beachtet werden: die Einfachheit der Bedienung. Damit sind zunächst keine Touch-enabled User-Interfaces gemeint. Vielmehr lohnt es sich zu überlegen, was derzeit die mit weitem Abstand am meisten verbreitete Business-Intelligence-Lösung der Welt ist, und warum diese so flächendeckend eingesetzt wird.

Eindeutiger Sieger in der Kategorie „am meisten verbreitete Business-Intelligence-Lösung der Welt“ ist Microsoft Excel. Excel ist auch dank seiner leicht verständlichen Bedienung der Quasi-Standard für Business Intelligence. Selbst die unzähligen Versuche der diversen Business-Intelligence-Anbieter in den letzten Jahren den Siegeszug von Excel im Unternehmen als Werkzeug für Business Intelligence zu verhindern, haben es nicht verhindert, dass das mit Abstand beliebteste Feature in jedem Business-Intelligence-Tool der "Export to Excel"-Button ist.

Offensichtlich bietet Excel insbesondere bei der Erstellung und Erweiterung von Business-Intelligence-Lösungen Funktionen, die den Anwendern in anderen Tools nur schwer zugänglich sind. Natürlich birgt natives Excel auch einige Risiken hinsichtlich Security, Auditierbarkeit und Versionierung.

Die instinktive Reaktion der Hersteller von Business-Intelligence-Werkzeugen war es, Excel als Ganzes abzulösen. Nachdem dies in den letzten 15 Jahren nicht geklappt hat, kommt nun langsam die Erkenntnis, dass Excel offensichtlich für Anwender unverzichtbar ist. Sinnvoller ist es daher, Excel so zu ändern, dass die durchaus vorhandenen Limitierungen und Risiken bei der Arbeit mit Excel wegfallen. Auch hierfür sind mittlerweile die technologischen Voraussetzungen vorhanden.

Es ist möglich, die „standardisierte Welt“ des Data Warehouse mit der „iterativen Welt“ von Excel zu verknüpfen. Es ist sogar möglich, die Entwicklung einer Business-Intelligence-Lösung in ihren Anfängen als kleine Excel-Lösung bis zur standardisierten, unternehmensweiten und ins Data Warehouse integrierten Lösungen mit einem einzigen technischen und semantischen Business-Intelligence-Framework zu begleiten.

Änderungsfähigkeit und Agilität einer Business-Intelligence-Lösung sind kritische Faktoren für deren Erfolg. Denn die Anforderungen an jede Business-Intelligence-Lösung ändern sich permanent. Veränderung ist Teil des Systembetriebs. Diese Realität findet sich aber in vielen Data-Warehouse-Architekturen nicht wieder. Die Verantwortlichen diskutieren praktisch nur über statische Architekturen bzw. Architekturen die immer nur auf „perfekte“ Endzustände abzielen. Eine ganzheitliche Business Intelligence Information Architecture muss aber auch die Dimension Zeit enthalten. Damit ist gemeint, dass die BI Information Architecture Business-Intelligence-Lösungen über ihren gesamten Lebenszyklus unterstützt; gerade wenn Anwender iterativ Lösungen erstellen können und sollen, ist das ein extrem wichtiger Erfolgsfaktor. Als Grundregel gilt: Sobald eine Lösung existiert, die Endanwendern Information liefert, muss es für diese in einer ganzheitlichen „BI Information Architecture“ ein Platz geben. Nicht erst, wenn sie in ein Data Warehouse integriert worden ist.

Eine Business-Intelligence-Applikation ist nicht statisch

Die Berücksichtigung von geänderten Anforderungen der Anwender im Zeitablauf ist ein ganz wichtiger Bestandteil einer Business Intelligence Information Architecture. Im Unternehmensalltag entstehen unzählige Fragen, deren Beantwortung eine Aufarbeitung von Daten bedarf. Oft ist im Vorfeld nicht absehbar, ob eine schnell erstellte Lösung nur einmalig verwendet wird, also ob eine Frage beantwortet und damit das Problem gelöst wurde; oder, ob diese Analyse auch einem breiteren Nutzerkreis in regelmäßigen Abständen Informationen zur Entscheidungsunterstützung bereitstellen kann. Hier gilt nun wieder das Prinzip der Evolution: Was funktioniert und sich durchsetzt, lebt weiter, der Rest stirbt aus.

Würde ein klassisches Data Warehouse versuchen, alle Anfragen, die in einem Unternehmen auftauchen zu beantworten, würde spätestens nach mehreren Jahren ein großer Teil des Data Warehouse irrelevant sein, aber im Betrieb weiter Kosten verursachen. In der Realität wird das Data-Warehouse-Team nicht annähernd alle Anforderungen erfüllen können, weshalb die Fachbereiche versuchen, ihre Probleme selbstständig zu lösen – nötigenfalls auch heimlich.

Heute gibt es die notwendigen Technologien, um die „iterative und agile Business-Intelligence-Welt der Endanwender“ mit der vordefinierten, standardisierten Welt des Data Warehouse zu integrieren, in der auch der zeitliche Wandel und Lebenszyklus einer Business-Intelligence-Lösung von Anfang bis zum Ende in einer Technologiewelt begleitet werden kann.

Reale Kontrolle versus gefühlter Kontrolle: „Managed Self-Service“

Sehr häufig ist der IT-Bereich Initiator oder zumindest Implementierer eines Data Warehouse. Dabei wird sehr oft zu viel Augenmerk auf technische „Schlankheit“ und Effizienz der Architektur gelegt anstatt auf die eigentlichen Anforderungen der Endanwender bzw. dem bereits erwähnten Wunsch der Endanwender nach schneller Umsetzung. Dabei schwingt auch immer die Sorge des Data-Warehouse-Teams mit, dass der Endanwender zu viel Freiraum erhält, und unvorhersehbare bzw. unkontrollierbare Situationen im Data Warehouse verursacht. Reflexartig  wird das Data Warehouse funktional limitiert. Es gilt, die Prämisse des Data-Warehouse-Teams: „Ich gebe vor was im Data Warehouse passiert. Ich behalte die Kontrolle und stelle sicher, dass die Endanwender nichts kaputt machen.“

Dies ist allerdings ein Trugschluss: Ohne die angefragte und erwartete Flexibilität starten Endanwender in vielen Fällen eigene „Schattenlösungen“: Bevorzugt unter Verwendung von nativen Excel und zumeist ohne Wissen des eigentlich zuständigen IT-Bereiches. Die daraus resultierenden Verluste bei Kontrolle und Steuerbarkeit fallen bei der ursprünglichen Risikoabschätzung unter den Tisch. Für das Data-Warehouse-Team gilt leider oft das Motto: „Was ich nicht weiß, macht mich nicht heiß.“

Eine Business Intelligence Information Architecture hat insbesondere die Aufgabe, die Anforderungen des IT-Bereiches nach Kontrolle und die Anforderungen der Anwender nach Flexibilität gleichermaßen zu erfüllen. Dabei gilt folgende Beobachtung: „Wenn ein Endanwender Daten oder Analysen braucht, um seinen Job zu machen, dann kommt er an diese ran bzw. erstellt er diese, ganz egal welche offiziellen Regeln, Prozesse oder Systeme vorhanden sind.“ Diese empirische Beobachtung müssen auch diejenigen akzeptieren, die für Business Intelligence insgesamt oder für ein Data Warehouse verantwortlich sind. Es ist letztlich unmöglich, dies durch starre Architekturen zu verhindern. Deswegen sollte mehr darauf geachtet werden, dass Endanwender ihre Lösungen in einer Umgebung aufbauen, in der die IT wenigstens beobachten kann, was passiert. Damit IT-Verantwortliche also nachverfolgen können, welche Daten exportiert werden, oder welche User wann auf welche Lösungen zugreifen.

Mit dem „Wissen“ was passiert, kann die IT viel eher auf dringende Probleme der Fachbereiche reagieren bzw. aktiv dort unterstützen, wo „der Schuh drückt“. Des Weiteren können Aktionen der Endanwender, die weitreichende Security-Probleme hervorrufen könnten, schnell unterbunden oder in die richtigen Bahnen gelenkt werden.

cMORE Reporting ist eine Lösung, bei deren Entwicklung darauf geachtet wird, dass sie zum einen fachanwendertauglich, zum anderen zugleich auch die Anforderungen der IT-Abteilung an Administrierbarkeit und Security erfüllt.

nach oben

Module

cMORE/Modeller

cMORE/Modeller
Schnellster Weg vom Fachkonzept zum fertigen Datenmodell

cMORE/Connect for SAP

cMORE/Connect for SAP
Vollwertige Alternative für das SAP-basierte Data Warehouse

Neuester Blog-Beitrag zu Big Data

Wir haben heute kein Data Warehouse eines Teilbereiches, sondern tatsächlich ein Data Warehouse für die gesamte Air Berlin.


Claus Glüsing, Director Controlling, Air Berlin

kostenlose Webinare

de en