Deutsch
Mehr aus SAP Analytics herausholen - Architekturoptionen im Überblick
Mehr aus SAP Analytics herausholen - Architekturoptionen im Überblick
In diesem Video
- Wie hat sich die SAP Analytics Architektur in den letzten Jahren entwickelt?
- Welche Rolle spielen SAP Datasphere, SAP Analytics Cloud und SAP Business Data Cloud?
- Wo liegen praktische Herausforderungen beim Data Warehousing im SAP-Umfeld?
- Welche Alternativen gibt es zur Data-Warehouse-Umsetzung in der Datasphere?
- Warum wurde in einem Kundenprojekt eine Kombination mit AnalyticsCreator gewählt?
Key takeaways
- Die SAP Analytics Architektur hat sich seit dem SAP Business Warehouse über BW/4HANA, Data Warehouse Cloud und Datasphere bis zur SAP Business Data Cloud stark verändert.
- SAP Datasphere wird im Vortrag eher als semantische und modellierende Schicht beschrieben als als vollwertige Data-Warehouse-Lösung.
- Herausforderungen werden insbesondere bei Historisierung, Integrationsfunktionalität, Mehrbenutzerunterstützung, Kostenprognose und Single Source of Truth gesehen.
- In einem Kundenprojekt wurde eine Architektur mit AnalyticsCreator, SQL-Datenbank, Datasphere Semantic Model und SAP Analytics Cloud als zukunftssicher bewertet.
- Standardisierte SAP Data Products können für Standardanforderungen hilfreich sein, stoßen bei komplexeren Integrationsanforderungen jedoch an Grenzen.
Transcript
Ich geb Ihnen dazu zur Einordnung erst mal 'n kurzen Überblick über die Historie. Äh, wo kommt das alles her? Wie hat sich das in den letzten Jahren bei der SAP entwickelt? Wie sieht die aktuelle Architektur aus? Und da ganz speziell auch: Wie hat sich das in den letzten Jahren, äh, entwickelt? Äh, da werfen wir einen genauen Blick auf die Cloud, äh, Komponenten. Ähm, wir wollen Ihnen paar Antworten geben, ähm, auf die Frage: Welche Erkenntnisse haben sich in der Praxis da gezeigt, ja? Äh, aber auch welche Her-Herausforderungen haben wir festgestellt und, äh, was für alternative Lösungsansätze haben wir daraus, ähm, erzeugt und generiert und, äh, auch schon in der Praxis, ähm, umgesetzt. Und dann gebe ich Ihnen noch ein paar Handlungsempfehlungen, die so 'n bisschen aus den gesamten Erfahrungen raus, äh, entstanden sind. Starten wir mit dem, ähm, historischen, ähm, Überblick.
Das Ganze begann, die Analytics Welt im SAP-Umfeld begann, ähm, 1998 mit, äh, der Einführung, ähm, von, ähm, dem SAP Business Warehouse in Kombination, ähm, mit der Business Explorer Suite. Äh, Business Explorer oder kurz BEX waren, äh, ein Tool, was als, äh, Excel Add-in für das SAP BW zur Verfügung stand. Äh, ist von vielen verflucht, von anderen sehr geschätzt worden. Ähm, war 'ne erst mal flexible Lösung und, äh, das ist auch 'ne relativ stabile Zeit gewesen, äh, in den Anfangsjahren, äh, dieser Analytics Welt bei der SAP, ähm, bis 2008 etwa. Im Jahr 2009 gab's dann, äh, die ersten Auswirkungen aus einem Zukauf, den die SAP, äh, ein oder zwei Jahre vorher, ich glaube im Jahr 2007, gemacht hat. Da hat man Business Objects, äh, erworben. Ein französisches Unternehmen. Da ist relativ viel Geld damals schon investiert worden, weil man da auch schon die Bedeutung gesehen hat für das Thema. Äh, ich glaube, fast sieben Milliarden Euro sind da bezahlt worden und man hat damit, äh, den damaligen, äh, Mit-Hero, sag ich mal, mit der, mit der Cognos-Lösung, äh, das waren die beiden Haupt, äh, Lösungen so, die in der Zeit, ähm, sehr, sehr präsent am Markt waren. Gab's sicherlich noch ein paar andere mit Hyperion und, und, äh, Ihnen fallen da auch noch einige ein, aber das war schon ein großer. Und man hat dann versucht, in den Folgejahren diese Lösungen zu integrieren und immer weiter, ähm, in, in die SAP Welt, äh, aufzunehmen. Ähm, im Jahr 2011 kam dann das BW und HANA, ja. Man hat ja dann bei der SAP eine neue Datenbank eingeführt, die HANA-Technologie, äh, um, äh, da wirklich, äh, auch, äh, von der Datenbank, von, von anderen, äh, abhängen, äh, anderenAnbietern, ähm, aus der Abhängigkeit rauszukommen. Ähm, das ist ja jetzt in den letzten Jahren konsequent, äh, vorangetrieben worden. Früher wurden SAP-Systeme auf Oracle oder DB2 oder auch SQL-Server-Plattformen betrieben. Heute gibt's, glaube ich, da nicht mehr viele von. Äh, die müssten, dürften heute überwiegend auf der HANA-Technologie unterwegs sein. Das hat die SAP entsprechend, äh, durchaus geschickt gemacht. Ähm, es gab dann in 2013, äh, auch 'ne, 'ne eigene Lösung namens Lumira, äh, auf Basis basierend auf, auf Busi-Business Objects Technologie. Und das war so die Zeit zwischen 2011 und 2015 und hier wurd's dann auch deutlich dynamischer. Es gab, ähm, immer kürzere Zyklen auch, ähm, und sehr viel Veränderung. Ähm, es gab dann 2016, äh, das BW/4HANA mit, äh, 'ner spezialisierten, auf die Da-Datenbank, äh, ausgerichteten Architektur. Ähm, man hat 2017 dann auch, ähm, aus dem Lumira Designer und, äh, der Lösung Discovery nannte die sich, glaube ich, äh, das Design Studio, ähm, entwickelt, zusammengeführt.
Und im Jahr 2015, jetzt machen wir einen kleinen Sprung zurück, ähm, kam dann ein ganz neues Produkt auf den Markt, nämlich die Analytics Cloud. Das heißt, das ist ein Produkt, was, ähm, ähm, extra, äh, originär nativ für die Cloud entwickelt worden ist und, äh, ja schon 'n Meilenstein in der SAP-Analytics-Architektur damit darstellt. Und in den ersten Jahren, äh, war das, äh, BW da sozusagen die Hauptbasis, was die Daten angeht. Die, die Analytics Cloud war durchaus auch in der, äh, Lage, direkt auf das SAP-4-System zuzugreifen, ähm, aber, ähm, auch CSV-Dateien, Non-SAP-Daten, äh, waren möglich anzubinden, zum Beispiel per OData. Äh, aber die meisten Kunden werden, äh, auf der HA-- BW beziehungsweise HANA-Plattform unterwegs gewesen sein.
Im Jahr 2020 kam dann noch mal wieder 'ne, äh, sehr große Veränderung. SAP hat die Data- Warehouse Cloud eingeführt. Also neben der Analytics Cloud als Frontend, mit dem Sie Ihre Berichte und, äh, Datenmodelle, äh, baut, gebaut haben, bauen konnten, ist dann auch 'ne Data-Warehouse-Lösung, ähm, platziert worden, ähm, um dann auch, äh, das Datenmanagement, die Themen, um die wir uns heute kümmern, ähm, abbilden zu können mit, ähm, mit einer neuen Cloud-Technologie. Äh, und man hat damit dann auch, äh, ein Stück weit, äh, das Ende vom SAP Business Warehouse eingeläutet. Es gibt ein Ende-Datum. Ähm, ich glaube, das, äh, aktuell ist das für 2040 noch sehr weit in die Zukunft, äh, adressiert, aber man hat ein entsprechendes Datum, äh, angekündigt und damit ist im Grunde dieses Produkt ein Stück weit tot. Ähm, die Entwicklungsschwerpunkte liegen klar in der Cloud-Technologie und das ist ja auch nicht überraschend. Das machen andere Hersteller ja auch so. Ähm, im Jahr '23 wurde das Ganze dann, ähm, mit, ähm, der Umbenennung in die SAP Datasphere weiterentwickelt. Das Frontend ist und bleibt SAP Analytics Cloud. Äh, da hat sich jetzt nicht mehr viel getan, aber die Datasphere, ähm, ist aus einer Zusammenführung quasi von, äh, SAP Data- Intelligence Cloud und, ähm, aus Kooperationen, die man mit Herstellern wie Collibra, Confluence und so weiter hatte, ähm, erwachsen.
Und 2025 gab's dann noch mal wieder 'ne Veränderung und man hat, äh, die Architektur weiter ergänzt, ähm, und hat die SAP Business Data Cloud, äh, ausgerufen und damit halt auch gewisse AI-Komponenten mit reingebracht, insbesondere weil man das selber bisher unterrepräsentiert hatte in, in den Tools, ähm, durch die Kooperation mit, äh, Databricks und man hat auch ein eigenes Produkt entwickelt namens SAP Databricks. Und das, äh, ist die Architektur, mit der wir uns heute, äh, beschäftigen. Also wie man sieht, hat sich da einiges getan die letzten Jahren und auch, äh, wenn man sich die Taktung anguckt, ähm, ist dort gerade in den letzten Jahren sehr viel passiert. Immer wieder Veränderungen, ähm, was schön ist, weil es neue Funktionalität gibt, was aber auch, äh, immer wieder 'ne Herausforderung darstellt für, äh, SAP-Kunden, weil sie immer wieder, ähm, vor neue Technologien, vor Veränderungen, äh, ge-gestellt werden. Also ausruhen ist da nicht.
So, jetzt noch mal, ich hatte es angekündigt, ein genauer Blick auf die Ar-Architektur, ähm, im Bereich, äh, der Cloud-Analytics-Tools. Ähm, ich hab's eben gesagt, 2015 kam die Analytics Cloud auf den Markt. Kern waren hier, äh, sicherlich die BW und die S4 beziehungsweise auch die, ähm, ECC- und PRAM-Systeme, die man anbinden konnte. Man konnte, wie gesagt, auch, äh, Non-SAP-Systeme anbinden. Die Modellierung, äh, hat dann in der Analytics Cloud stattgefunden, der Datenmodelle, die man dann fürs Reporting benutzt hat. Ähm, und, ähm, im Jahr 2017 gab's dann auch die erste SV Hana Cloud, äh, Version, ähm, als ERP, ähm, in der Public Cloud zunächst. Äh, Private Cloud ist dann einige Jahre später, ich glaube, '21, erst eingeführt worden. Und ja, das waren sozusagen, äh, die Quellsysteme. Äh, dazwischen, ähm, gab's erst mal in der Cloud nichts. Das heißt, man musste erst mal mit dem BW-System leben. Vielleicht, wenn die, äh, in die Cloud ge-gehoben worden sind, dann, äh, konnte man da zumindest schon von, von Cloud-Architektur sprechen. Aber, ähm, das würde ich mal als die Übergangsphase bezeichnen.
2020 kam dann, wie schon erwähnt, die Data Warehouse Cloud, ähm, und damit ein, äh, echter Meilenstein aus unserer Sicht, weil man jetzt wirklich, ähm, neben der Analytics Cloud auch im Datenmanagement und Data-Warehouse-Umfeld 'ne Cloud-Lösung angeboten hat bei der SAP. Äh, auch wir bei der xax, ähm, wir waren früher schon mal, ähm, SAP-Partner, mm, haben aber dann immer wieder auch von unseren Kunden gespiegelt bekommen, dass man nicht so richtig zufrieden war mit, mit verschiedenen Komponenten in der Vergangenheit, auch teilweise mit den Veränderungen, die sich über diese ganzen Zukäufe, äh, ergeben haben. Und deswegen haben wir das irgendwann beendet. Aber spätestens als die Data Warehouse Cloud auf den Markt kam, haben wir das Thema SAP wieder sehr intensiv, ähm, betrachtet und, äh, haben gesehen: Hier entwickelt sich vieles in die richtige Richtung, äh, auch für uns sehr, sehr spannend. Ähm, die BW-Kunden hat man natürlich nicht vergessen, sondern man hat, äh, mit der BW Bridge eine Komponente angeboten, die es ermöglichen sollte, äh, Daten aus, äh, dem vorhandenen BW-System zu überführen, äh, in die neue Cloud-Infrastruktur. Ich lasse das mal verschwinden, weil wenn man sich heutige Folien anguckt, das Produkt hat nicht wirklich funktioniert. Es gab viele Einschränkungen, gerade wenn man Non-SAP-Daten in seinem Business Warehouse hatte, äh, hat das nicht gut funktioniert. Dementsprechend hat man's wieder, ähm, aufgelöst und oder abgelöst und, ähm, heute andere Ansätze, gerade im Zusammenhang mit der Business Data Cloud, gehe ich gleich noch mal ein bisschen detaillierter drauf ein. Es gab dann, ähm, diese SAP Data Intelligence Cloud. Ähm, es gab, äh, verschiedene, äh, Anbieter wie DataRobot oder, äh, Collibra, wie schon eben erwähnt, mit denen man, ähm, Allianzen eingegangen hat, um sich breiter aufzustellen, um Datendienstleister mit ins Portfolio zu holen, ähm, für Lakehouse-Ansätze, ähm, um Daten dann irgendwo, ähm, auch frei am Markt einkaufen zu können. Ähm, das Ganze ist aber dann, ähm, aufgegangen, äh, im Jahr 23 in dem Produkt Datasphere. Also man hat Teile, äh, aufgelöst dieser ganzen Komponenten, Teile, äh, übernommen, äh, und ein neues Produkt generiert, das SAP Datasphere heißt. Ähm, damit, äh, gab's kleinere Veränderungen aus unserer Sicht. Ähm, man hatte dann, ähm, da immer noch im Kern die SAP Datasphere als Fokusprodukt, äh, für die, ähm, für die Abbildung der Warehouse-Themen, für das Datenmanagement. Ähm, allerdings ist der Name Warehouse Cloud verschwunden und das, äh, ist, glaube ich, auch nicht ganz ohne Grund passiert. Äh, das zeigt sich jetzt, wenn man schaut, wie's weitergegangen ist.
Im Jahr 2025, also im letzten Jahr, gab's nämlich eine noch mal größere Veränderung, größere Ankündigung, ähm, bei der SAP. Die Datasphere ist im Prinzip ein bisschen, ähm, ja, kleiner geworden. Man hat ihnen, man hat ihr verschiedene andere Komponenten an die Seite ge-stellt. Das hatte ich eben schon gesagt: In der Datasphere war das Thema künstliche Intelligenz und auch Machine Learning unterrepräsentiert. Ähm, SAP hat reagiert und hat das nicht selbst entwickelt, sondern hat 'ne Kooperation gemacht und das eigene, äh, SAP Databricks entwickelt. Das ist im Grunde eine abgespeckte Databricks-Version. Äh, man bekommt nicht die ganzen Data-Engineering-Komponenten, sondern im Kern sind es, ähm, die, ähm, die AI- und ML-Tools, äh, aus der Databricks-Landschaft. Äh, dann hat man auch was ganz Clevers gemacht. Man hat nämlich gesagt, wir nehmen das Business Warehouse in die Lizenzierung mit auf, in die Technologie, ähm, der Business Data Cloud.
Viele BW-Kunden waren, wie gesagt, nicht so ganz happy mit der Situation, dass sie, ähm, jetzt mit 'ner komplett neuen Plattform, äh, konfrontiert sind, die auch nicht mal eben so per BW Bridge, hat's halt schon mal nicht funktioniert, äh, in diese neue Cloud-Infrastruktur übertragen werden kann. Mm, das heißt, man hat dort in der Vergangenheit sehr große Budgets in, in den Aufbau dieser Business Warehäuser gesteckt und, äh, sieht jetzt so ein bisschen seine Felle schwimmen, weil natürlich man sich, äh, jetzt irgendwie mit, mit, äh, dieser neuen Technologie auseinandersetzen muss. Gerade durch das gesetzte Support-Ende-Datum, äh, muss man halt, ähm, sich definitiv damit auseinandersetzen: Wie geht's in der Zukunft weiter mit meiner Analytics-Architektur? Man hat, ähm, das Business Warehouse in der Private Cloud Edition, also man muss schon auf dem aktuellen BW Release 7.5 sein, ähm, und, ähm, da ist man dann in der Lage, diese Dinge in die Cloud-, äh, Infrastruktur zu übernehmen. Die werden quasi, äh, mit so 'ner Art Remote Tables in die, äh, Architektur übertragen, äh, und, äh, verbunden quasi. Ähm, es wird aber 'n Weg aufgezeigt, wie man damit weitergehen kann. Ähm, wer die offiziellen Folien gi-- kennt, da gibt's dann noch das BDC-Cockpit, äh, 'ne Administrationskomponente, 'ne Verwaltungskomponente, die diese BDC, ähm, Werkzeuge ein bisschen steuert, äh, im Wesentlichen nicht zum Beispiel auch den neuen SAP Object Store. Der Object Store ist ein Tool, ähm, was auf Basis, äh, der Databricks-Technologie basiert. Äh, Databricks basiert ja auf Spark-Technologie und, äh, dadurch kommen sogenannte Delta Tables, ähm, ein filebasiertes, ähm, Storage-Format, ähm, in die Architektur mit rein. Äh, man hat halt festgestellt, dass die, äh, auf HANA-Technologie basierenden Komponenten wie Datasphere relativ, ähm, teuer werden können, äh, wenn man das intensiv nutzt. Und man möchte den Kunden eine Alternative anbieten, äh, indem man, ähm, hier eine, ähm, filebasierte, günstigere Speichermöglichkeit anbietet. Und auch das hat die SAP damit, äh, einge-Führt und im Grunde, äh, bisherige Vorgehensweisen ein bisschen revidiert ein Stück weit. Man hat, ähm, die SAP Data Products eingeführt. Ähm, das sind fertige Produkte, die auf Basis von, ähm, SAP-Vorsystemen bestimmte Inhalte, Themen, Bereiche abdeckt, abbildet und man kann auf diese Weise, ähm, so ist zumindest das, äh, Versprechen auf den Folien, sehr leicht, ähm, Analytics-Architekturen aufbauen und standardisiert, ähm, erstellen. Äh, neben den SAP Data Products, äh, da ist halt, wie ich eben schon sagte, eine, eine Veränderung passiert in der Sicht, äh, dass man da sich eigentlich aus Content bisher, äh, rausgehalten hat seitens der SAP, äh, innerhalb dieser Analytics Cloud Archit-- oder der Analytics-Architektur in der Cloud. Ähm, tatsächlich, äh, bietet man damit jetzt wieder, ähm, Content an, ähm, was m-mir andere Dienstleister, SAP-Partner gespiegelt haben, sie nicht so gut finden, weil einige haben da eigenen Content aufgebaut. Äh, das kann man jetzt teilweise wieder in die Tonne treten, äh, sag ich mal so ein bisschen, äh, salopp und muss sich da, äh, drum kümmern, da jetzt Alternativen aufzubauen. Äh, Custom Data Products, äh, beziehungsweise Partner Data Products sind dann Komponenten, die, äh, neben den direkt von SAP verwalteten Komponenten auch eigene Lösungen, ermöglichen. Ähm, ja, und der Weg für die SAP-Kunden, äh, SAP-BW-Kunden ist, dass sie mit dem Data Product Generator, äh, Data Products erzeugen können. Ja, also das ist der Gedanke, äh, um dann langfristig, äh, vom, äh, Business Warehouse wegzukommen, ähm, ist die Idee, mit Data Product, äh, Generator, ähm, Strukturen zu ent, äh, entwickeln, die es ermöglichen, Daten aus dem Business Warehouse dann in die neue Cloud-Architektur zu überführen.
Und das alles ist dann die SAP Business Data Cloud. So hat sich das entwickelt über die letzten Jahre, da ist das hergekommen und, äh, so sieht die Architektur im Grunde heute aus. Also wir haben die Vorsysteme, äh, Non-SAP-Systeme, alle SAP-Systeme, die man so, äh, weit und breit kennt. Und, äh, wir haben dann, äh, entsprechend diese, Cloud-Komponenten, mit der man, äh, diese verschiedenen Themen, äh, abdecken kann. Wenn Sie also damit arbeiten wollen und da sehen wir gewisse Herausforderungen, werden Sie mit SAP Data Products Standardthemen abdecken können. Sie werden also Daten aus, ähm, zum Beispiel, ähm, dem S4, aus Ihrem S4 per Standard Data Product extrahieren können. Äh, man kauft Data Products über die sogenannten SAP Intelligent Apps oder SAP Intelligent Applications heißt das, glaube ich, offiziell. Ähm, die sind, äh, Teil, äh, einer Lizenzierung und damit bekommt man die und kann sie dann aktivieren. Ähm, so ähnlich wie Content früher auch im Business Warehouse. Ähm, den, den konnte man auch extrahieren samt Extraktoren. Und, äh, so ist es auch, dass die Data Products im Wesentlichen auf CDS Views aufsetzen. Das ist Kerntechnologie, ähm, auf der ERP-Seite. Äh, dann kommt hier dieser filebasierte Storage mit einigen Metadaten, Semantik, ähm, Informationen drumherum und dann bieten die die Basis, Basis für, ähm, die Weiterverarbeitung innerhalb der BDC-Architektur.
Wenn man Daten, äh, dort, äh, direkt aus dem ERP holt, dann gucken wir uns noch mal quasi den, den anderen Weg an. Äh, wo kommen Daten alternativ, äh, her? Natürlich, äh, wenn man ein BW hat, aus dem BW mit dem Product G-Generator. Äh, die Datasphere wird dann vielleicht auch irgendwann Plandaten haben, die man wieder zurückspielen möchte. Und, ähm, wenn man dann mit Databricks arbeiten möchte, dann wird man wahrscheinlich, äh, Daten aus dem Object Store in Richtung Databrick schieben, äh, und auch wieder zurück in Richtung des Object Stores, wenn man dort Ergebnisse erzeugt hat. Ähm, es gibt auch wohl direkt die Möglichkeit, ähm, diese Komponenten miteinander zu verbinden. Dann wird's aber spannend und das ist 'ne Kernfrage, die wir uns heute auf Basis dieser, ähm, Architektur stellen. Äh, in Richtung Data Management und Data Warehousing muss man fragen: Wo ist hier eigentlich die Single Source of Truth? Das ist mir faktisch nicht mehr klar und das, äh, sehe ich auch als Herausforderung. Insbesondere wenn man heute auf SAP-Folien guckt, äh, ist halt der Name Datasphere, äh, im Kern verschwunden, äh, der Name Data Warehouse Cloud und das, der Begriff Data Warehousing v-verschwunden. Man findet das auf den Folien nicht mehr, auf den Architekturfolien. Äh, man findet hier im Wesentlichen, äh, Business Semantics als Stichwort. Das heißt, äh, das Modellieren, äh, der semantischen Schicht. Und, ähm, da wächst das Tool tatsächlich auch sehr eng mit der Analytics Cloud zusammen. Ähm, es gibt, ähm, mit dem Seamless Planning, ähm, Ambitionen, dass man, ähm, jetzt, äh, auch das, äh, Datenmodell, äh, auch für Planung in der Datasphere halten kann. Bisher war das so, dass man, äh, Analytics-Modelle zunächst in der Analytics Cloud definiert hat. Dann ging das, dass man sie in der Data Warehouse Cloud Schrägstrich in der Datasphere modellieren konnte. Planungsmodelle mussten aber persistiert werden in der Analytics Cloud. Ähm, sie werden auch heute immer noch hier modelliert, können aber in der Datasphere gespeichert werden. Langfristig ist es vielleicht dann auch möglich, ähm, hier auch Planungsmodelle hier zu definieren. Das ist auch nicht günstig, weil es halt unterschiedliche Tools und Stellen und Frontends gibt, um, äh, diese verschiedenen Komponenten zu nutzen. Das haben wir in den Kundensituationen gesehen, dass das durchaus, ähm, eine Herausforderung sein kann, ähm, mit diesem, mit diesem sehr großen Mück, ähm, ja, mit diesem sehr großen Umfang an Möglichkeiten, den man so hat. Den muss man dann halt auch füllen. Gut, so weit der Blick.Auf die Architektur.
Ähm, ich hab gesagt, wir haben dann Fragen, Herausforderungen gesehen. Äh, Teil dieser Fragen hab ich schon andiskutiert. Eine zentrale Frage, die ich mir stelle, ist, wie lange diese Architektur Bestand haben wird. Da können wir ja gerne mal Wetten abschließen, wenn jemand, äh, dadrauf wetten möchte, dass das so bleibt, äh, fünf Jahre lang. Ich nehme gerne Wetten entgegen. Ähm, ist die Übernahme des BWs in die BDC-Architektur eine Perspektive für einen längeren Weiterbetrieb des ABWs? Schon aus Lizenzsicht ja, aus Wartungssicht ja. Man kann das tun. Ähm, ich glaube aber, man sollte sich davor hüten, nicht, ähm, zügig auch, äh, das BW abzulösen und in, in neue Architekturen zu gehen, in die Cloud-Architektur, äh, das Ganze weiterzuentwickeln. Ähm, am Ende ist es nur ein Weg, äh, um BW-Daten in die neue Zukunftstechnologie zu überführen. Hm, wie groß, wie teuer wird die Übernahme großer BW-Systeme? Das ist tatsächlich etwas, was, äh, ich auch, äh, in Gesprächen immer wieder gespiegelt bekomme, äh, dass da viele Bedenken haben, äh, dass es so weit geht, dass man BW-Systeme erst mal abspecken muss, Daten löschen muss, bevor man sie in diese Cloud-Architektur hebt, weil es doch relativ teu-teuer wird, die in dieser BDC HANA, ähm, Umwelt zu betreiben. Äh, dementsprechend muss man sich das sehr genau angucken, wie da der richtige Weg ist. Ähm, ist die Umbenennung der DWC, der Data Warehouse Cloud in Datasphere ein Zufall? Äh, aus heutiger Sicht, wenn ich die Folien so sehe, aus meiner Sicht nicht. Es ist, äh, durchaus wegentwickelt worden, ein ganzes Stück weit, äh, von, ähm, ein, von, von dem Data Warehouse, von der Data-Warehouse-Lösung. Ähm, und, ähm, es ist schon, äh, deutlich, äh, zu merken, dass es in Richtung eines semantischen Modellierungstools als Basis, als Modellbasis für die SAC, also für die Analytics Cloud, geht. Ähm, wenn man noch mal auf diese, ähm, ähm, auf die-- Ich springe einfach noch mal zurück, ähm, auf die Folie davor. Ähm, 'ne spannende Frage ist: Wo ist hier die Grenze zwischen, äh, Object Store und Datasphere? Und das ist etwas, was ich mir wirklich intensiv stelle, diese Frage, äh, weil diese Integration, wenn ich die hier tue, dann hätte ich die Vorteile, dass ich wirklich alle Komponenten damit, ähm, versorgen kann. Ähm, damit ist dann, ähm, das hier aber aus meiner Sicht, äh, keine Data-Warehouse-Lösung mehr, äh, sondern wir haben zwei verschiedene Technologien, zwei verschiedene Tools und Ansätze. Äh, wir haben hier 'nen hohen Grad an, an Standardisierung. Äh, wenn wir jetzt die Frage stellen: Wo integrieren wir Daten aus verschiedenen Vorsystemen? Und das haben viele unserer Kunden, als Herausforderung. Wenn ich jetzt, äh, drei, vier ERP-Systeme, wir haben, Kunden, die haben, äh, ähm, über zehn ERP-Systeme im Unternehmen. Wenn ich die irgendwo integrieren möchte, äh, dann muss ich mir die Frage stellen: Wo tue ich das? Und, ähm, 'ne Herausforderung ist halt, wenn ich hier schon Business-Logik drin hab, und das ist schon in den CDS-Views, ist häufig schon Business-Logik mit verdrahtet, äh, wenn ich hier zusätzlich noch, äh, Business-Logik drin habe, die gekapselt ist in, äh, Sub-Data-Products, äh, dann stelle ich mir die Frage: Wie bekomme ich dann meine, äh, Drittdaten integriert? Wir haben im Projekt, kann ich sagen, die, äh, die Erfahrung gemacht, äh, dass das auf Basis von vorgefertigtem Content, äh, der schon aus einer gewissen analytischen Sicht modelliert wurde, äh, und nicht mehr, wie man das im Data Warehousing eigentlich macht, von den Quellen her modelliert und gedacht wird. Das ist extrem schwer, dort noch mal, Daten, ähm, ran zu bekommen. Es hat, äh, dementsprechend auch nicht funktioniert. Also so viel zu der Frage: Wo ist die Grenze? Das ist 'ne offene Frage. Ich weiß das nicht genau. Ich kann das nicht beantworten. Und, das ist 'ne Herausforderung.
Ich stelle auch die Frage: Wird. es demnächst noch eine echte Data-Warehouse-Lösung geben? Weil auch das, äh, kann ich schon mal spoilern. Wir haben die Erfahrung gemacht, dass, äh, echte Data-Warehouse-Lösungen, echte, ähm, Profi-Enterprise-, ähm, ETL-Werkzeuge ganz andere Funktionalitäten mitbringen. Ähm, die Datasphere, äh, hat von der Funktionalität eher den Charakter einer, ähm, einer semantischen, einer, äh, Tool-unterstützenden Schicht. Ähm, echte Integrationsfunktionalitäten, äh, fehlen. Es gibt keine Ansätze für Historisierung, es gibt, äh, keine Modell-, äh, -unterstützung eines, eines speziellen Modellansatzes, sondern das, äh, ist frei zu definieren. Ähm, und, ähm, viele Funktionalitäten wie Mehrbenutzerunterstützung, das ist nicht gut gesteuert. Ähm, all solche Themen, äh, bringen, bringen größere Herausforderungen. Ähm, wo liegt die Single Source of Truth? Aus meiner Sicht ein ganz zentraler Punkt, weil es immer wieder der, das Ziel in dem Unternehmen, auch eine Single Source of Truth zu machen. Mit diesen verschiedenen Komponenten ist das schon eine, äh, Herausforderung und, äh, ich sehe hier keine, äh, klare Data-Warehouse-Strategie, äh, sondern das sind schon, schon, schon einige, ähm, Herausforderungen, die man dann beantworten muss mit diesen verteilten Informationen. Ähm, was wir auch gesehen haben, ähm, mit dieser Architektur: Wenn Sie jetzt, ähm, zum Beispiel ein neues ERP einführen wollen, ähm, HANA einführen, äh, wollen, äh, S/4HANA einführen wollen, dann ist die, äh, Sicherstellung von kontinuierlicher Reporting-Fähigkeit durchaus 'ne Herausforderung, ähm, weil man, äh, sieht, dass mit, wenn man mit der, äh, SAP Analytics Architektur, ähm, äh, starten will, man schon, äh, brauchbare, ähm, Strukturen auf der S/4HANA-Seite haben muss. Das heißt, zum Go live, äh, müssten Sie, äh, irgendwie relativ schnell dann sehen, dass plötzlich alles, äh, sehr schnell aufgebaut wird, äh, wenn das, äh, S/4HANA komplett fertig modelliert wird. Und Sie wollen ja, wahrscheinlich auch noch Daten aus dem Altsystem, ähm, reinmodellieren und das ist, ähm, 'ne Herausforderung in dieser Architektur, weil Sie im Grunde erst starten können, äh, wenn eigentlich schon alles ziemlich stabil ist. Auch das hat sich gezeigt in den Projekten. Da sind Kunden durchaus mit der Herausforderung konfrontiert, dass Veränderungen in der, äh, Datasphere durchaus ziemlich viele Herausforderungen mit sich bringen. Äh, einfach mal rauslöschen von so 'nem Modell ist nicht. Das ist schon ziemlich kompliziert und, und aufwendig. Ähm, ja, wie kann man trotz der unterschiedlichen Tools die SAP-Standard-Synergien, äh, heben? Das ist auch 'ne Frage, die ich mir stelle, äh, wo ich Schwierigkeiten sehe. Äh, was sich gezeigt hat, ist, dass alle Komponenten, auch die Datasphere, eigene Berechtigungssysteme haben. Das ist immer was, was, wo viele sagen: Na ja, wenn ich SAP-Tools durchgängig einsetze, äh, dann hab ich, ähm, dann hab ich da viele Synergien, die ich nutzen kann. Äh, hat sich tatsächlich nicht bewahrheitet, weil jedes Tool in sich 'ne eigene, ähm, eigene Welt ist. Und, äh, man hat Vorteile, ähm, schon, dass das, äh, alles aufeinander ausgerichtet ist, gerade auf die SAP-Vorsysteme. Äh, aber grade in Richtung eines offenen Data-Warehousing, äh, ist es nicht so einfach.
Worauf kommt's eigentlich bei Data-Warehousing an? Das einfach nur als kleiner Exkurs und zur Erinnerung, viele werden's wissen und viele haben sich damit sicherlich schon auseinandergesetzt: Der Kernpunkt ist die Single Source of Truth. Wir wollen eine einheitlich konsistente Datenbasis, äh, erstellen fürs ganze Unternehmen. Ähm, Basis, äh, als für datengetriebene Entscheidungen, auch das ist klar. Für alle verschiedenen Komponenten, die oben drauf sind, äh, wollen wir eine vernünftige, äh, Plattform schaffen. Äh, deswegen ist das, äh, das Schaffen einer Single Source of Truth so wichtig. Äh, Transparenz, Steuerbarkeit ist natürlich wichtig, äh, Skalierbarkeit. Äh, das-- da hab ich keine Zweifel. Also mit-- gegen Einwurf von Münzen kann man, äh, die Datasphere gut skalieren. Äh, da kann man sicherlich, ähm, nahtlos Platz, äh, Space und, und auch CPU hinzukaufen. Ähm, ja, und, äh, am Ende auch nicht zu vergessen: Compliance-Governance-Themen. Data Lineage, aber auch da die Herausforderung, über diese verschiedenen Komponenten hinaus von Vorsystem, Object Store und, äh, Datasphere und vielleicht, äh, dann noch Databricks, ähm, dazu als Komponente: schwierig. Also auch da gibt's, ähm, nach meinem Kenntnisstand keine übergreifenden Lösungen. Das heißt, man ist immer, äh, maximal innerhalb, äh, von, ähm, von den einzelnen Lösungen unterwegs. Das ist auch noch nicht optimal. Muss besser werden.
Ähm, wir zeigen jetzt, einmal, ähm, möchte ich kurz berichten von einem Projekt, was, wir hatten, äh, was, ähm, gezeigt hat, ähm, ja, ähm, wie die Herausforderungen mit der Architektur dann eigentlich auch aussehen, ähm, aufgrund eines anstehenden ERP-Wechsels. Man ist weggegangen von einem, äh, ehemaligen an, alten Anbieter, äh, der ziemlich in, die Jahre gekommen ist, und, das Unternehmen hat sich, dynamisch weiterentwickelt. Man brauchte ein, ein, eine neue ERP-Lösung und hat sich für, äh, S/4HANA entschieden und in dem Zusammenhang wurde dann auch die Analytics-Architektur hinterfragt. Ähm, das war im Jahr 22, 23. Äh, wir sollten als Sax diesen Prozess begleiten, ähm, und bewerten. Wir sollten unsere Einschätzung abgeben, haben das auch getan, haben tatsächlich damals gewisse Herausforderungen gesehen. Ähm, ja, ähm, man hat aber trotzdem, äh, dann in Q1 24 entschieden, dass man, äh, rein auf SAP-Technologie setzen möchte, um die Synergien zu heben, um, ähm, in, in einer, Tool-, äh, Familie zu bleiben. Und, äh, wir haben den Kunden dann, äh, ein Stück weit begleitet, gerade in der Betreuung des Altsystems, äh, und auch, äh, in, äh, der Bewertung des, des neuen Tools und haben, ähm, dann, äh, entsprechend ab Q2 24 dieses Projekt, äh, entsprechend mit begleiten dürfen. Ähm, wir sind dann etwa ein Jahr später aber an die Stelle gekommen in dem Projekt, dass der Kunde deutliche Zweifel geäußert hat, ähm, wie die Abbildung in, äh, der Datasphere als DWH-Lösung aussehen soll. Ich sag ganz bewusst, es geht nicht darum, die Analytics Cloud als Frontend infrage zu stellen. Auch die Datasphere als Modellierungstool, ähm, ähm, stand nur ein Stück weit infrage. Äh, aber, ähm, man hat sich schon gefragt: Ähm, wie will man diese ganzen Herausforderungen abbilden? Weil es ist relativ viel Budget, äh, in dieses Projekt geflossen und es gab relativ marginale Fortschritte nur. Und, äh, das als Herausforderung hat dazu geführt, dass man an der Stelle, äh, dann, äh, noch mal wieder, ähm, alternative Ansätze untersuchen wollte. Ähm.
Wir haben festgestellt in diesem Projekt, der Kunde hat festgestellt, dass es ein sehr flexibles Space- und Layer-Konzept, äh, gibt, was aber auch viel Spielraum lässt. Den muss man füllen, damit muss man sich auseinandersetzen. Und das war, äh, eine Herausforderung. Die Definition einer, nachvollziehbaren, durchgängigen Standardarchitektur war dann, äh, auch für den sehr großen SAP-Dienstleister, der mit in dem Projekt, äh, dabei war, der das gemacht hat, äh, die Umsetzung, äh, eine Herausforderung. Also es ist schwierig, ähm, auf Basis dieser sehr freien Plattform eine, eine nachhaltige Architektur, äh, zu entwickeln, von der man sagen kann: Wir sind sicher, dass sie, äh, alle, äh, anstehenden zukünftigen Herausforderungen abdecken, äh, wird. Und es ist halt auch vieles manuell. Wie gesagt, man kann nicht irgendwie sagen, ich möchte eine Historisierung aktivieren. Man muss das alles manuell bauen und hat halt dort relativ wenige Möglichkeiten. Man ist relativ schnell, weil es nicht so viele Standardtransformationsobjekte gibt innerhalb dieses Werkzeugs, relativ schnell an der Stelle, dass man sagt, äh, man muss, ähm, sich Dinge in SQL oder Python selber bauen. SQL ist es dann aber wieder SAP SQL. Das ist nicht Standard SQL. Das hat auch den einen oder anderen so 'n bisschen, ähm, zu Herausforderungen geführt, weil nicht alles, äh, so funktioniert, wie, wie man's dann vielleicht gewohnt ist. Ähm, und auch Python ist zum Beispiel ein- abgespeckter Python-Standard. Auch das ist nicht, ähm, nicht so richtig günstig, äh, gewesen, ähm, sodass gar nicht so einfach ist, dann da alles so abzubilden. Genau, die ungeführte Entwicklung im Tool. Es gibt keinen Modellierungsansatz, keine, keine klare Stützung, äh, in Richtung, also, der, der, des Modellierers, ähm, wie muss er bestimmte Themen abbilden? Das muss man sich selbst überlegen. Und, es hat sich gezeigt, dass viele Standardfunktionalitäten, äh, halt fehlen. Habe ich schon, angesprochen. Ähm, für das, äh, Zusammenführen von, äh, Modellstrukturen gibt's auch keine, äh, klaren Modell, ähm, Modellstrukturen. Ähm, dementsprechend ergibt sich, äh, schnell nach, nach 'nem einigen, nach 'nem erst mal eigentlich übersichtlichen Einblick, wenn man startet in das Tool an vielen Details, aber 'ne, 'ne gewisse Unübersichtlichkeit, das kommt noch dazu. Ja, und was überhaupt nicht funktioniert, das ist, äh, mehrfach angefragt worden, auch in Richtung des Dienstleisters, ähm, 'ne Abschätzung der späteren Betriebskosten ist extrem schwierig, gerade wenn man all die Funktionalitäten dann, ähm, abgebildet hat. Das kann man schn-- schlecht prognostizieren, quasi gar nicht.
Man war also in dieser Kundensituation der Meinung, dass man die, äh, vorliegenden Anforderungen durchaus mit der Datasphere, äh, hätte umsetzen können. Ähm, es war aber nicht absehbar, mit welchem personellen Aufwand und wo das, ähm, in Richtung der Betriebs- und Wartungskosten dann später, ähm, hinläuft. Und deswegen, äh, wollte der Kunde, äh, noch mal Alternativen, ähm, untersuchen. Und, ähm, hier stelle ich mal kurz dar, welche Alternativen wir untersucht haben in diesem Projekt. Äh, die Variante eins war, äh, die Datasphere. Das war die Variante für sowohl Datenintegration als BI-Modellierung, mit der man ja gestartet ist. Äh, wir haben, wir haben dann die Alternative Analytics Creator ins Spiel gebracht, ähm, auf Basis, äh, 'ner Standard-Microsoft-SQL-Datenbank. Ob das nun on premise oder irgendwie im Azure-Umfeld oder auch Fabric, das ist dem Tool Analytics Creator relativ egal. Da ist man flexibel. Ähm, und, ähm, als BI-Modellierungstool ist die Datasphere in diesem Ansatz weiter, äh, im Spiel. Ähm, in der dritten Variante haben wir den Analytics Creator genommen, ähm, mit 'ner SQL-Datenbank und wir haben dann die BI-Modellierung, äh, in der Analytics Cloud gemacht. Auch das funktioniert. Man kann mit der Analytics Cloud auf, ähm, Microsoft-Datenbanken zugreifen, ähm, und, ähm, haben die Datasphere komplett rausgenommen und haben auch noch weitere, äh, Alternativen betrachtet in diesem Ansatz. Ähm, das SAP BW, ähm, ist relativ schnell ausgeschlossen worden, weil halt ein Ende-Datum dran steht und das, äh, aus meiner Sicht heute auch nicht sinnvoll ist, auf so eine Architektur zu setzen. Äh, das HANA DWH, also auf der HANA-Technologie könnte man, äh, theoretisch natürlich auch ein eigenes DWH aufbauen. Das ist aber völlig, äh, ungeführt. Da gibt es keine vernünftigen Tools, äh, da haben wir uns auch schnell dagegen entschieden. Äh, normalisiertes Modell innerhalb der Datasphere, normalisierter Modellierungsansatz, der, äh, eher Datenintegration ermöglicht, das alles manuell zu bauen. Aufgrund der mangelnden Tool-Unterstützung ist das auch nicht weiter betrachtet worden. Ähm, genauso wie ein Data Vault Modell. Data Vault ist eine Modellierungstechnologie, die, äh, zum Beispiel der Analytics Creator auch unterstützt, mit sehr viel vorgedachten Strukturen, äh, die Antworten auf die Standard-, ähm, Alltagsherausforderungen des, äh, des Data Warehousings, äh, liefert. Äh, ist ein sehr durchdachter Ansatz, der Anfang der 2000er Jahre von Dan Linstedt entwickelt wurde. Ähm, aber auch hier ist es ganz wichtig, weil das durchaus komplexere Modelle sind, die dann entstehen, dass das toolgeführt passiert. Wenn man das manuell macht, ist das sehr aufwendig und da das, äh, die Datasphere oder andere Tools nicht direkt, äh, angeboten haben, ist auch dieser Ansatz verworfen worden. Heute würde man vielleicht mit dem Object Store da noch mal zumindest intensiver draufschauen. Ich glaube, Databricks ist mangels Funktionalität, äh, zur Erinnerung, es sind nur die KI- und ML-Funktionalitäten, die, äh, dort im Kern in der SAP Databricks, äh, beinhaltet sind, äh, nicht geeignet und der Object Store, ähm, macht auf uns auch nicht den Eindruck, als wenn es das wäre. Wir haben uns damit aber noch nicht tiefer auseinandergesetzt. Ähm, und, ähm, ja, da ist halt auch immer noch die Frage der Architektur: Äh, wo ist die Single Source of Truth?
Ähm, wenn wir jetzt auf die Ansätze dann noch mal kurz schauen, die BDC stand nicht zur Verfügung, gab's da auch noch nicht, haben wir uns die Datasphere, äh, angeschaut als, äh, Tool. Die Variante eins ist also, äh, das eben schon beschriebene, ähm, der Einsatz von Datasphere mit Analytics Cloud. Äh, wir haben dann, äh, im nächsten Schritt, äh, die Analytics Creator-Version mit einem Enterprise Data Warehouse im SQL-Umfeld, äh, betrachtet und haben, ähm, die Datasphere Semantic Model genutzt, äh, Analytics Cloud, äh, obendrauf gesetzt. Ähm, das war aus unserer Sicht ein, ähm, sehr vielversprechender Ansatz. Äh, ein weiterer Ansatz war auch, den wir untersuchen wollten: Ähm, wie ist das, wenn wir, ähm, auf die Datasphere verzichten? Und ein bisschen auf die, auf die Uhr geblickt, dass wir gleich vielleicht noch ein bisschen Zeit auf Fragen haben. Relativ schnell zusammengefasst hier, ähm, die Variante, die am zukunftssichersten von uns eingeschätzt wurde, wo man am flexibelsten ist, die die, äh, beste Funktionalität, insbesondere im Bereich der Funktionalität, äh, sehr, sehr stark ist, weil es, äh, alle, äh, Themen abdeckt und Zukunftsfähigkeit auch in Richtung, ähm, Analytics Cloud und, äh, Datasphere, weil, ähm, SAP scheint zunehmend, ähm, ähm, diese, diese Verbindung von Datasphere und Analytics Cloud zu forcieren. Viele Funktionalitäten werden demnächst nur noch gehen, wie Seamless Planning, wenn man auch die Datasphere hat. Von daher, äh, ist der Ansatz dann am besten bewertet worden. Und, äh, ist auch gewählt worden. Das heißt, äh, es ist ein Analytics Creator, ähm, Enterprise Data Warehouse im Aufbau. Ähm, die Businessmodellierung des Semantic Model passiert in der Datasphere und, äh, in der Analytics Cloud werden dann auf Basis der vorhandenen Modelle die Berichte entwickelt.
Wie gesagt, der Kunde hat sich für diese Architektur entschieden. Es, äh, im Wesentlichen war der Vorteil die Kombination der ver-- der Stärken dieser verschiedenen Architekturkomponenten, die Zukunftsfähigkeit. Und es ist am Ende, wir haben auch eine Kostenbewertung gemacht, trotz der zusätzlichen, aber überschaubaren, ähm, Kosten für, für den Analytics Creator und die SQL-Datenbank ist es schon so, dass es, äh, aufgrund, äh, dieser massiven Assistentenunterstützung, dieser beschleunigten Entwicklung des Data Warehouses durch eine Automatisierungslösung, äh, im Endeffekt zu erheblich günstigeren prognostizierten Kosten gekommen ist.
Die Realisierung läuft. Äh, wir haben aber schon durchaus das Feedback bekommen, dass, ähm, die Analytics-Creator-Umgebung sehr gut funktioniert und, ähm, das gibt uns, äh, stimmt uns sehr positiv, äh, dass, äh, hier auch langfristig ein richtig gutes System aufgebaut wird, äh, passend sukzessive parallel zur Einführung der S/4HANA, ähm, der, der EOP-Umgebung.
Jetzt hatte ich noch versprochen, Ihnen ein paar Empfehlungen zu geben. Äh, wenn man das alles so zusammenträgt, was man so an Erfahrungen, äh, irgendwo mitgenommen hat, dann muss ich sagen, dass ich, ähm, ja, ähm, für die verschiedenen, ähm, Alternativen auf jeden Fall empfiehlt, äh, das sehr individuell zu betrachten, zu untersuchen. Ähm, grundsätzlich finde ich, dass die BDC-Architektur in jedem Fall auch gut funktionieren kann, wenn man relativ wenig Integrationsanforderungen hat. Äh, wie gesagt, da sehen wir in der Architektur durchaus Herausforderungen, ähm, aufgrund dieses Vorgehens und der Tatsache, dass man relativ weit weg von DWH-Standards da ist. Ähm, und auch wenn das S/4HANA im Standard ist, kann man sicherlich gut Standard CDS Views, Standard Data Products nutzen, äh, um dort relativ schnell ein Reporting auf Basis seines S/4HANAs aufzubauen. Ähm, die SaaS-Kosten, das muss man halt akzeptieren, äh, sind nicht so leicht zu prognostizieren. Ähm, auf der letzten Analytics-Veranstaltung der SAP, äh, hat die SAP selbst gesagt, dass sie das eigentlich auch nur selber gerade können. Wir haben da irgendwelche Excel-Rechner. Selbst die Partner können das da, äh, zu dem Zeitpunkt, ich weiß nicht, ob sich in den Wochen jetzt seither was geändert hat, aber konnten es da nicht. Das heißt, das Sizing ist schon schwer. Wie viel Capacity Units braucht man? Was brauche ich irgendwie am Ende? Total schwierig zu sagen. Ähm, aber das muss man auch sagen, ist häufig in, äh, anderen, ähm, Cloud-Plattformen, Cloud-Data-Engineering-Plattformen ähnlich. Das, äh, ist ein Stück weit etwas, was man wahrscheinlich in Kauf nehmen muss. Ja, ähm, der Blick auf alternative, äh, Ansätze bietet sich in jedem Fall unbedingt an, äh, wenn man nicht nah am Standard ist mit seinem S4 und durchaus Integrationsanforderungen hat, dann ist es aus unserer Sicht wirklich lohnenswert, auch mal zumindest Alternativen zu prüfen.
So, dann möchte ich noch ein Angebot, äh, Ihnen machen. Also wenn Sie Fragen haben, äh, zu dem Thema, ähm, ich diskutiere gerne dadrüber. Das ist für, für mich natürlich auch eine Leidenschaft, beschäftige mich, äh, meine gesamte berufliche Karriere mit diesen Themen. Ich bin gerne, äh, für Sie da. Sprechen Sie mich an, kontaktieren Sie mich per Mail oder lassen Sie mir Ihre Kontaktdaten zukommen, mir beziehungsweise uns, äh, den Kollegen von Analytics Creator. Und, äh, dann können wir gerne in eine Diskussion ein, äh, steigen. Ich habe hier auch die Möglichkeit, äh, mal in Spiel gebracht. Buchen Sie über den Link. Wenn Sie die Präsentation wollen, lassen Sie uns Infos zukommen, dann haben Sie den Link. Dann können Sie dort entsprechend direkt in meinem Kalender auch einen Termin buchen und, äh, freue mich ansonsten, dass Sie dabei waren, dass es Sie interessiert hat, dass Sie dabei geblieben sind. Und ja, würde jetzt noch Fragen in den Raum stellen, beziehungsweise, ähm, ja, Raum für Diskussion. Fünf Minuten haben wir auf jeden Fall noch, denke ich. Ja, vielen Dank, Matthias. Sehr, sehr ausführlich. Hat mich sehr gut gefallen. Danke schön. Moin.