Business Intelligence – Das Konstrukt eines Core Datawarehouse ist überalterten Paradigmen geschuldet

Ich habe des öfteren in meinem Logbuch das Phänomen formuliert, dass wir Menschen uns in der Vergangenheit im Rahmen von Problemlösungen ein Paradigma geschaffen haben, was in der Gegenwart zu einer Denkblockade in neuen Lösungsprozessen führt. Ich möchte dies am Beispiel von Business Intelligence erhärten.

Ich bin in der Vergangenheit sehr oft mit Fagestellungen zu einem Core Datawarehouse, ab jetzt mit CDWH abgekürzt, konfrontiert worden. Ein CDWH soll in vielen Unternehmen die Schnittstelle zwischen der operativen und der dispositiven Welt bilden. Die operative Welt ist geprägt von vielen heterogenen IT-Systemen. Die Daten liegen in diesen Systemen in unterschiedlichen Strukturen und Formaten vor, die es nicht unmittelbar erlauben, auf dieser Basis Auswertungen und Analysen ganzheitlich zu fahren. Das muss dann also gesondert passieren, auf Basis eben erwähnter CDWHs, die damit als “single point of truth” dienen. Damit werden lange Datenextraktionswege von der operativen Schicht in das CDWH erkauft, die viel Tranformations- und Harmonisierungslogik enthalten. Um die Herausforderungen an Daten, wie beispielsweise schnelle Verfügbarkeit und hohe Qualität, zu erfüllen, muss man bereits an den operativen Systemen ansetzen und nicht mittendrin, beim CDWH. Warum fällt das so schwer?

Man hängt dabei noch immer dem Paradigma der IT von vor 40 Jahren an. SAP hat dieses Paradigma, ich möchte es einmal Modularisierung und Separierung nennen, teilweise durch SAP R/2 und SAP R/3 aufgebrochen, in dem betriebswirtschaftliche Prozesse und Vorgänge durch integrierte Software auf einer gemeinsamen Datenbank technisch und in real-time unterstützt wurden. Dieses Konzept wurde aber auch auf der operativen Ebene nicht ganzheitlich durchgezogen. Es wurde beispielsweise im Bereich des Opportunity Managements ein separates System mit einem zu R/3 unterschiedlichen Konzept und Modell der Geschäftsobjekte zzgl. einer separaten Datenbank konzipiert und entwickelt, das SAP CRM (Customer Relationship Management). Zum damaligen Zeitpunkt war diese Separierung vielleicht aus mehreren Gesichtspunkten notwendig. Zum einen musste man sich der Komplexität des Modellierens verschiedener betriebswirtschaftlicher Vorgänge Stück für Stück nähern. Das konnte man nur auf Kosten der Integration durchführen. Der Elefant musste erst einmal zerlegt werden. Zum anderen war diese Separierung aus rein technischer Sicht notwendig, da man damals bzgl. des Speicherns großer Datenmengen noch nicht den Stand heutiger Technik erreicht hatte. Diese Notwendigkeit, die dem damaligen Fortschritt der IT geschuldet war, impliziert aber noch lange keine Sinnhaftigkeit, da Geschäftsprozesse eben nicht modular linear ablaufen. Mittlerweile hat man einen großen Fortschritt erlangt, verschiedene Geschäftsprozesse aus verschiedenen Bereichen technisch abzubilden. Zu nennen wären hier das Opportunity Management in einem CRM-System oder das Bestands- und Beschaffungsmanagement in einem SCM-System (Supply Chain Management) oder aber interne und externe Rechnungswesenprozesse in einem ECC-System. Das ist schon mal ein Meilenstein, den man verbuchen kann. Nun ist es meines Erachtens an der Zeit, die Prozesse end-to-end bzgl. der Daten zu integrieren, denn auch der technische Stand bzgl. der Speichermöglichkeiten lässt dies zu. Schauen Sie sich beispielsweise den Purchase-to-Pay Prozess an, dann erkennen Sie Geschäftsprozesse aus mehreren Prozessbereichen, zum Beispiel Bestandsmanagent, Logistik oder Finanz. Liegen diese Prozesse nun auf mehreren operativen Systemen verteilt, kann das nur suboptimal sein. Zum einen für die operativen Tätigkeiten an sich, jedoch erst recht für die Datenbereitstellung für die dispositive Welt als Basis für Entscheidungen im Rahmen dieser operativen Tätigkeiten.

Das die Trennung von operativer und dispositiver Welt längst überholt ist habe ich in meinem Post Welche Bedeutung hat die Wahrnehmungsfähigkeit der Menschen für Business Intelligence? bereits ausgeführt. Dort finden Sie auch die scheinbar wichtigen Unterscheidungsmerkmale zwischen operativen und dispositiven Tätigkeiten.

Ich stelle mir für die Zukunft das folgende Szenario vor. Es gibt aus logischer Sicht unternehmensweit genau eine Datenbasis mit genau einem Datenmodell. Auf dieser Basis gibt es verschiedene technische Anwendungen, operative als auch dispositive. Ich spreche mit Absicht in diesem Kontext nicht von Systemen, da ich mich von diesem technischen Systembegriff lösen möchte. Häufig habe ich den Eindruck, dass Projekte zu technisch angegangen und durchgeführt werden. Es scheint fast so, als würden Systeme um ihrer selbst willen eingeführt. Man muss sich aber immer wieder vor Augen führen, dass die Technik nur Mittel zum Zweck ist, um Geschäftsprozesse bestmöglich zu unterstützen, was die Bedeutung der IT aber keinesfalls schmälern soll. Es gilt ganz klar die Regel: “IT follows Business”. Man muss schon sehr gute Gründe haben, von dieser Regel abzuweichen. Die end-to-end Prozesse, wie Order-to-Cash, Opportunity-to-Order oder Purchase-to-Pay, um nur einige zu nennen, werden in den meisten Unternehmen auf vielen verteilten operativen Systemen durchgeführt. Diese Systeme speichern die Daten in heterogenen Strukturen und Semantiken ab. Damit erkaufen sich die Unternehmen lange Datenextraktionsstrecken in die Reporting- und Analyseschichten. Dann stehen die Daten aber nicht in der erforderlichen Zeit und Qualität zur Verfügung. Da helfen auch die bekannten CDWH Ansätze nicht, dieses Problem zu heilen. Die folgende Abbildung veranschaulicht dieses Szenario.

Ist dieses Szenario technisch machbar? Wenn ich bedenke, dass wir seit längerer Zeit in der Lage sind, Sonden in Richtung Mars zu schießen, stellt sich diese Frage aus meiner Sicht nicht. Sehen Sie sich die Strategie von SAP mit HANA an, dann erkennen Sie genau diese Gedanken wieder. Ich möchte hier keine Werbung für SAP machen. Das liegt mir fern. Aber die “Walldorfer” scheinen die richtigen Ideen zu haben und umzusetzen. Sie sind noch nicht angekommen, aber auf einem guten Weg.

Ist dieses Szenario sinnvoll? Selbstverständlich. Ich möchte Ihnen dafür einige Use Cases angeben, die dies belegen sollen.

Stellen Sie sich vor, Sie möchten einen Flug buchen und nicht nur das. Sie möchten das mit einem Verkaufserlebnis verbunden wissen. Was könnte das Buchen zu einem Erlebnis machen? Wenn Sie einen Hin- und Rückflug suchen, es aber nur noch einen Rückflug gibt, würden Ihnen zum Beispiel andere Optionen angeboten werden, vielleicht aufgeteilt auf verschiedene Flughäfen, gekoppelt mit Bahnverbindungen oder Mietwagenoptionen. Würden Ihnen ähnliche Optionen in der Vergangenheit bereits angeboten worden sein, Sie aber immer abgelehnt haben, weil Sie die Verteilung auf verschiedene Flughäfen nicht mögen, wären Sie sicherlich genervt, immer und immer wieder absagen zu müssen. Das würde entfallen. Auf Basis Ihrer Buchungshistorie ist beispielsweise der Callcentermitarbeiter über ihre Reiseaktivitäten informiert und fragt Sie nach diesen Reisen, ob sie Ihnen gefallen haben oder nicht. Das wird dann wiederum Ihrem Profil hinterlegt, um für zukünftige Buchungen Präferenzen parat zu haben. Wenn Sie im Internet beispielsweise einen Buchvorgang abbrechen, wird automatisch im Hintergrund über Eventsteuerung analysiert und entsprechend reagiert. Die Eventsteuerung könnte vielleicht auf Preise reagieren, weil Ihrem Profil Schwellwerte bzgl. Preise hinterlegt sind, die den Abbruch plausibilisieren. Mit jeder relevanten Aktivität, die Sie im Internet beim Buchen durchführen, werden Ihre Daten validiert und ggf. aktualisiert, um für den nächsten Vorgang aktuell zu sein. In Summe benötigten Sie also Daten in Echtzeit. Das schaffen Sie nicht, wenn die operativen Daten in verschiedenen Töpfen verteilt liegen, sondern nur dann, wenn die Analysen dort ansetzen, wo die Daten auch entstehen.

Oder. Stellen Sie sich vor, Sie sind Leiter eines großen Verkaufsmarktes. Sie bieten verderbliche Ware an. Diese Ware soll am Ende des Tages komplett verkauft sein, aber zu einem für Sie optimalen Preis. Sie benötigen dann in Echtzeit den jeweiligen Bestand der Ware und die Verkaufshistorie des Tages, damit automatisch ein optimaler Preis errechnet werden kann. Oder Sie haben eine bestimmte Angebotsaktion mit bestimmten Artikeln. Sie müssten stetig wissen, wieviel Ware noch im Regal vorhanden ist, um nachzulegen oder entsprechend Preise zu bestimmen. Tun Sie dies nicht, können Sie immer nur “after-the-fact” ermitteln, wieviel Umsatz Sie hätten machen können und sich dann ärgern. Die Preise müssten wie gesagt automtisch bestimmt werden und elektronisch an den Regalen angezeigt werden. Bei Entnahme durch Kunden gilt dann immer der jeweils aktuelle Preis. Auch hier gilt wieder. Wenn die Abverkaufsdaten der Artikel aus dem Kassensystem und die Bestandsdaten aus dem Bestandssystem erst mühsam in ein separates CDWH extrahiert werden müssen, dabei vielleicht noch der Artikelstamm konsolidiert und harmonisiert werden muss, um dann optimale Preise zu errechnen oder den Bestand zu validieren, wird zu viel Zeit benötigt, um schnell und flexibel zu reagieren. Hier lassen sich bestimmt aus ganz vielen anderen Branchen viele weitere Use Cases definieren.

Ich habe oben zwei Herausforderungen an Daten angesprochen, schnelle Verfügbarkeit und hohe Qualität. Das möchte ich nun noch ein wenig detaillieren. Ähnlich wie ich oben ausgeführt habe, dass IT Systeme nicht einfach um ihrer selbst willen eingeführt werden dürfen, müssen auch Daten nicht immer in Echtzeit vorliegen, schon gar nicht um ihrer selbst willen. Wir dürfen uns auch hier nicht von technischen Möglichkeiten treiben lassen, sondern stets von den Anforderungen aus Sicht des Business, startend mit dem Blick auf den Markt (Kunden, Lieferanten, Wettbewerber). Aus diesem Blickwinkel werden Anforderungen bestimmt und dann technisch, prozessual und organisatorisch intern im Unternehmen umgesetzt. Selbstredend müssen Daten nicht nur zur rechten Zeit am rechten Ort vorliegen, sondern dies auch noch in qualitativ hochwertiger Form, damit sie überhaupt Basis für Entscheidungen sein können. Daten müssen also duplettenfrei, semantisch und syntaktisch eineindeutig, korrekt und Vollständig im Zugriff der Entscheider und Handelnden sein. Beide Herausforderungen lassen sich schon aufgrund dessen ein Stück weit aushebeln, dass man eben die operativen Daten nicht mehr auf verschiedene Töpfe mit verschiedenen Datenmodellen verteilt. Auch ein CDWH heilt hier nicht die Schmerzen, wie wohl in vielen Unternehmen mittlerweile schon registriert. Die Notwendigkeit der Verschmelzung von operativer und dispositiver Welt ist schon lange keine Vision mehr. Sie war es aus meiner Sicht noch nie, da die Welt uns diese Trennung gar nicht vorgibt. Wir haben diese Welt nur künstlich geschaffen. Bis zu einem gewissen Zeitpunkt war diese Trennung sicherlich hilfreich, das hatte ich oben schon angemerkt. Nur jetzt sollten wir den nächsten Schritt gehen, denn nun versuchen wir Probleme zu lösen, die erst durch die Trennung von operativer und dispositiver Welt existent sind. Das Paradigma sollte jetzt gekippt werden. Die Technik ist dafür schon lange bereit, nur unsere Köpfe noch nicht. Das belegen auch die Kommentare zu der Diskussion, die ich in 2 BI Gruppen in Xing gestartet habe: Link und Link.

Das meine ich keinesfalls despektierlich. Ich nehme diese Kommentare sehr ernst, da ich dadurch auch meine Gedanken, Ideen und Argumentationsketten stetig erweitern kann. Des Weiteren ist mir auch klar, dass das Verschmelzen von operativer und dispositiver Welt nicht von heute auf morgen umgesetzt werden kann. Man sollte es aber auf der BI Roadmap auf jeden Fall vorsehen und einplanen.

Zum Schluss möchte ich noch ein kleines Analogon anführen, auch aus dem Bereich BI. Dieses soll zeigen, dass es häufig sinnvoll ist, Probleme durch “Über-Bord Werfen” von Paradigmen zu lösen. DWHs wurden quasi schon immer spaltenbasiert als Snowflake konzipiert, da man auf die Daten dann performanter zugreifen kann. Operative Systeme besitzen, oder besser besaßen, zeilenbasierte Datenspeicherkonzepte. Da man aber erkannt hat, das man auf Daten, die zeilenbasiert abgelegt sind, nicht so performant zugreifen kann, wurden in operativen Systemen Umwege gebaut, in dem beim Speichern der Daten viele verschiedene Systemtabellen beschrieben oder Indizes angelegt wurden. Erkennen Sie den Bezug zum CDWH Paradigma? Man versucht Probleme zu lösen (Leseperformance verbessern), in dem sich andere Probleme eingekauft werden (Schreibperformance verschlechtern). Das Paradigma, in operativen Systemen müssen die Daten ausschließlich zeilenbasiert gespeichert werden, stand lange als Blockade im Weg. Dieses wird nun nach und nach aufgebrochen. Ich hoffe Ähnliches passiert mit dem Paradigma das CDWH.

(Keine Bewertungen bislang. Geben Sie doch die erste ab.)

Loading...