Einige von Ihnen haben möglicherweise klassische SAP-Systeme im Einsatz, die auf Servern im eigenen Rechenzentrum oder dem des Basis-Dienstleisters laufen. In den meisten Fällen sind sie vermutlich auf Ihre Bedürfnisse, zum Beispiel aufgrund von Besonderheiten Ihrer Branche oder spezieller Prozesse, angepasst. Das heißt, das System wurde durch Customizing entsprechend konfiguriert oder der zugrunde liegende Code wurde modifiziert und erweitert, die Logik der Programme entsprechend angepasst.
Durch den vollen Zugriff der Entwickler auf das Backend stellt das bei diesen On-Premises-Systemen kein Problem dar.
Anders verhält es sich jedoch im wachsenden Bereich der Cloud-Anwendungen.
Hier werden die Systeme in Rechenzentren großer Dienstleister wie SAP gehostet. Der Lizenznehmer kann auf die Anwendung selbst zwar über das Internet zugreifen, hat jedoch keine Möglichkeit, in das Backend zu gelangen, um dort grundlegende Modifizierungen vorzunehmen.
Gegebene Prozesse individualisieren
Im Cloud-Umfeld wird auch von SAP stets darauf hingewiesen, dass die Vorteile einer Cloud-Lösung, wie zum Beispiel der schnelle „Time-to-Value“, insbesondere dadurch erreicht werden können, dass man bei der Implementierung neuer Software-Lösungen auf Szenarien setzt, die sich möglichst nahe am Standard bewegen (Best Practices).
Das heißt, die Prozesse sollten bestenfalls so verwendet werden, wie es die Software vorgibt. Damit wäre es zum Beispiel möglich, innerhalb weniger Wochen nach Projektstart die SAP Marketing Cloud produktiv zu nutzen.
Doch um realistisch zu bleiben – in den allermeisten Fällen gibt es im Unternehmen zum einen bereits fest definierte Prozesse, die schwer aufzubrechen sind. Zum anderen haben sich die User an bestehende Altsysteme gewöhnt, in die möglicherweise eigene Funktionalitäten programmiert wurden. In diesen Fällen wird es nur schwer möglich sein, eine neue Cloud-Lösung im Standard zu verwenden.
Welche Möglichkeiten bleiben also, wenn man nicht an den Quellcode herankommt, wie es bei eigens entwickelten oder On-Premises-Lösungen der Fall ist und Modifizierungen der Standard-Logik daher unmöglich sind?
In dieser zweiteiligen Blog-Serie möchte ich die verschiedenen Möglichkeiten aufzeigen, die SAP Marketing Cloud an Ihre Bedürfnisse anzupassen.
Die 3 Säulen der Individualisierung
Im Hinblick auf die Implementierung der SAP Marketing Cloud kann zwischen drei Leveln differenziert werden, die sich in der Tiefe, in der die Lösung adaptiert wird, unterscheiden:
1. UI-Anpassung
Hierzu zählt zum Beispiel die Anpassung des Fiori Launchpads, um eine personalisierte Oberfläche zu erhalten. Der User hat die Möglichkeit, sich die Gruppen der Anwendungen, zum Beispiel alle Apps zum Kampagnenmanagement, im Rahmen seiner Berechtigungen so anzuordnen, dass es ihn in seiner täglichen Arbeit unterstützt.
Per Drag & Drop kann er häufig genutzte Anwendungen an den Anfang der Startseite schieben. Solche Anpassungen beeinflussen niemals die persönlichen Einstellungen anderer User.
2. Konfiguration
Über die zentrale App „Lösung verwalten“ haben Administratoren des Systems die Möglichkeit, Anpassungen entsprechend der Anforderungen vorzunehmen. Die meisten dieser Einstellungen werden einmalig konfiguriert.
Die Anwendung ist vergleichbar mit dem Customizing über die Transaktion „SPRO“, die möglicherweise aus On-Premises-Systemen von SAP bekannt sein dürfte. Dort können in der SAP Marketing Cloud zum Beispiel die benötigten Kommunikationsmedien („Auf welchem Weg kommunizieren wir mit den Kunden?“, zum Beispiel E-Mail) oder Interaktionsarten („Welche Aktion ist erfolgt?“, zum Beispiel Download Whitepaper) konfiguriert werden.
Einige der Konfigurationsaktivitäten wurden zusätzlich in eigene Applikationen ausgelagert, zum Beispiel die Segmentierungskonfiguration. Getätigte Konfigurationen, die in diesen Apps vorgenommen wurden, werden nach Fertigstellung und Tests in das Produktivsystem transportiert.
Für spätere Anpassungen muss ein „Change Project“ angelegt werden, ehe diese Änderungen wiederholt auf das Produktivsystem übertragen werden können. Kommunikationssysteme, die für Integrationen in andere SAP- und Drittanbieter-Systeme benötigt werden, müssen im Produktivsystem erneut erstellt und angepasst werden.
3. Erweiterbarkeit
Die SAP Marketing Cloud bietet darüber hinaus noch weitere Möglichkeiten, das System zu erweitern. Diese umfassen etwa benutzerdefinierte Felder (Z-Felder) und Business-Objekte (zur Abbildung von Z-Tabellen), UI-Extensions (zum Beispiel zum Einbetten der Webshop-Seite bei den Produkten), CDS-Views (zum Erstellen eigener Berichte), HANA-Views und eigene Logiken.
Zudem besteht die Option, auf der SAP Business Technology Platform eigene Anwendungen zu entwickeln und diese zu integrieren.
Des Weiteren stellt SAP das sogenannte Customer Influence Portal zur Verfügung, auf dem Kunden und Partner über sogenannte „Improvement Requests“ dringend gewünschte oder benötigte Funktionen vorschlagen können. Die Vergangenheit hat gezeigt, dass bei entsprechend großer Resonanz bereits eine Vielzahl dieser Vorschläge in die Weiterentwicklung der SAP Marketing Cloud eingeflossen sind.
Fazit
Die Möglichkeiten zur Erweiterung variieren je nach Ausprägung der Software. Bei On-Premises-Systemen kann die Logik insgesamt etwas einfacher verändert werden als bei Cloud-Anwendungen. Sofern die Cloud-Lösung nicht im Standard genutzt werden kann, bestehen dennoch zahlreiche Optionen, individuelle Szenarien abzubilden. In Teil 2 dieser Serie lesen Sie, wie Sie sich dies zunutze machen können.
