Blog

In den vergangenen Jahren gab es immer wieder Nachrichten und Gerüchte über die Zukunft von SAP BusinessObjects.

Mittlerweile gibt es interessante Neuigkeiten!

Aktuelles zu SAP BusinessObjects BI 4.2 SP07

Am 04.03.2019 hat SAP das Support Package 07 für die „SAP BusinessObjects Business Intelligence Platform 4.2“ (SBOP BI 4.2) veröffentlicht. Dabei handelt es sich laut Aussage von SAP um das letzte Feature Pack für das Release 4.2. Ein Support Package 08 ist zwar geplant, wird aber ein reines Maintenance Release darstellen, das „nur“ Bugfixes und keine neuen Funktionserweiterungen beinhaltet.

Endlich: Der Startschuss zur Digitalisierungsstrategie ist gefallen und das Marketing soll ein wichtiger Baustein werden. Im Zuge der Strategie wurde beschlossen, eine Customer Data Platform (CDP) zur Bildung der 360 Grad Kundensicht und Automatisierung von Marketing Journeys im Realtime Umfeld zu nutzen. Eine Entscheidung, die, neben dem nicht geringen Investment wesentlich die Marketing-Prozesse und Bereiche (Online, E-Mail, E-Commerce und CRM) eines Unternehmens beeinflusst. In diesem dritten und letzten Part meiner CDP-Serie möchte ich daher auf die korrekte Auswahl und Bewertung des passenden CDP-Tools eingehen.

Anders als bei Marketing-Automation-Lösungen wird nicht nach Funktionsumfang wie Enterprise bzw. Best-of-Breed unterschieden, sondern nach dem funktionsseitigen Schwerpunkt der Customer Data Platform. Das heißt, je nachdem, wie die Anforderungen definiert sind, kann man bereits im Vorhinein eine Auswahl der richtigen CDP-Art durchführen.

Insgesamt lassen sich drei verschiedene Kategorien von Customer Data Platforms unterscheiden:

• Data CDP
• Analytics
• Engagement CDP

Diese komplette und schrittweise schnelle Demo zeigt Ihnen, wie man eine existierende Datenquelle intern mit einer modernen Cloud-Warehouse-Lösung wie Snowflake verbindet:  

• Einfach
• Schnell
• Sicher und
• ohne eine einzige Codezeile schreiben zu müssen.

Ausnahmeaggregationen waren vor HANA in SAP BW häufiger eine Herausforderung bei der Laufzeit; dazu gehörte auch die Distinct-Count-Operation. Diese wird zum Beispiel beim Zählen von Kunden aus den Aufträgen genutzt.

Früher wurden Distinct-Count-Operationen häufig folgendermaßen umgesetzt:  Es wurde eine berechnete Kennzahl mit dem Wert 1 angelegt und diese dann über eine Ausnahmeaggregation aufsummiert. Was in Umgebungen ohne HANA gut geklappt hat, führt aktuell jedoch dazu, dass der Pushdown nicht mehr funktioniert. Je nach Einstellung kann es also dazu kommen, dass die Berechnung nicht optimal durchgeführt wird.

Eine Lösung für HANA-Umgebungen muss also her: Konzentrieren wir uns daher im Weiteren auf die optimale Implementierung von Distinct Count mit BW on HANA oder BW/4HANA.

Erhalte im foglenden Beitrag einen Überblick über die verschiedenen Kategorien von Customer Data Platforms - angelehnt an die Einteilung von David Raab vom Customer Data Platform Institute und weiterentwickelt von den b.telligent-Experten zum Thema CDP.

Deutsche Unternehmen müssen einen großen Schritt in Richtung digitale Transformation und Verbesserung der Customer Experience wagen, diese Einsicht reift bei den Entscheidern zunehmend.  Die Gründe hierfür sind vielfältig:

• Wachsende Anzahl an Customer Touchpoints sowie die richtige Nutzung der Daten dahinter
• Die Erwartungshaltung der Kunden steigt immens.
• Neue Technologien halten Einzug in die Welt der Marketers.
• Gängige Kampagnenmanagementsysteme sind in Bezug auf die Implementierung sehr aufwändig.
• Die Toollandschaft wächst und wächst: Es gilt, den Überblick zu bewahren.

Da erscheinen CDP-Systeme, die es in den USA bereits seit 2013 gibt, wie gerufen. Während Kampagnenmanagementsysteme eher workflowbasiert oftmals in relationalen Datenmodellen CRM-basierte Kampagnenprozesse automatisieren, kümmern sich CDP-Systeme ganzheitlich um die Optimierung der Kundeninteraktion auf allen digitalen Kanälen wie Web, E-Mail, Mobile, Onlineshop oder Social – von der kundenzentrischen Datenhaltung in Big-Data-Technologien bis hin zum E-Mail-Versand in Realtime.

Die Europäische Zentralbank (EZB) sowie viele andere Aufsichtsbehörden erkannten in der Analyse der Ursachen der Finanzkrise 2008 unter anderem große Defizite in der IT und Datenarchitektur der Institute. Diese Defizite führten dazu, dass Risikobewertungen nicht schnell und präzise genug und nicht vollständig durchgeführt werden konnten. Kurz gesprochen: Risiken konnten weder im angemessenen Maße berichtet noch kontrolliert werden. Aus dieser Lehre heraus wurde von dem Baseler Ausschuss für Bankenaufsicht (engl. Basel Committee on Banking Supervision, kurz BCBS) der vielseits durch die Presse bekannte Standard 239 veröffentlicht, auch bekannt als „Principles for effective risk data aggregation and risk reporting“ bzw. als AT 4.3.4 der MaRisk.

Immer neue Datenquellen und Anwendungsgebiete sorgen auch weiterhin für den stetigen Ausbau von Datenhaltungssystemen, wie DWH, Data Lake oder Analytics Platform. Mit den erweiterten Anforderungen müssen auch die Datenbewirtschaftungsprozesse Schritt halten. Nicht selten wachsen kleine BI-Anwendungen zu großen Initiativen, an denen mehrere Entwicklerteams beteiligt sind. In vielen Branchen müssen Anpassungen schneller vorgenommen werden als jemals zuvor, was die Lage zusätzlich verschärft. Den Teams wird dadurch eine kurze Reaktionszeit sowie eine hohe Flexibilität abverlangt, die jedoch nicht zuletzt von der Infrastruktur getragen werden muss.

Immer noch das Problem: Ordner oder Laufwerke katalogisieren

Im letzten Eintrag haben wir in einer Lösung von weniger als zehn Zeilen mit einer rekursiven Funktion die Möglichkeit geschaffen, Ordner zu scannen und die Dateien nach Änderungsdatum und Dateigröße auswertbar zu machen.

Aufbauend auf diesem Beispiel möchte ich die Latte nochmal etwas höher legen und noch bessere Alternativen aufzeigen.

Das Problem: Ordner oder Laufwerke katalogisieren

Vor kurzem wurde mir von Kollegen im Projekt die Frage gestellt, ob man mit Python nicht den Inhalt von Laufwerken katalogisieren könne. Natürlich geht das, und der Aufwand hierfür ist so überschaubar, dass ich hier das Beispiel nutzen möchte, um die wichtigsten Best-Practice-Empfehlungen für das Arbeiten mit Laufwerkspfaden zu erläutern.

Was leistet Snowflake als Cloud-DB?

Snowflake ist eine native Cloud-DB und läuft auf AWS und inzwischen auch auf Azure. Die Internetverbindung vom Client zur Cloud und die Daten innerhalb der DB sind verschlüsselt. Dabei kann es während der Ausführung beliebig und automatisch hochskalieren und am Ende wieder herunterschalten. Da für das (Speicher-)Volumen und die Ausführungszeit gezahlt wird, können so durch die geringen Zeiten Kosten gespart werden. Eine ausführliche Online-Dokumentation ist unter folgender URL verfügbar: https://docs.snowflake.net/manuals/index.html

Man muss übrigens kein AWS-Kunde sein, um Snowflake verwenden zu können. Snowflake selbst bietet als Cloud-DB-Service keine eigenen ETL-Tools an, sondern überlässt dies den Herstellern von ETL-, Reporting- oder Self-Service-BI-Tools. Diese bieten meist native Treiber und Connections an, um ihre Tools mit Snowflake verwenden zu können. Soll im Unternehmen kein separates ETL-Tool eingesetzt werden, gibt es verschiedene Möglichkeiten, die Daten zu laden und die ETL-Strecken zu realisieren. Das Umsetzen der Logik in SQL und die Orchestrierung über Python ist dabei ein möglicher Weg.