Was beim Umstieg von SAP Sales & Service Cloud V1 auf V2 nicht mitkommt

Wer heute mit SAP Sales & Service Cloud V1 arbeitet, hat meist Jahre in das System gesteckt: eigene Felder, Workflows, Formulare, Erweiterungen, Schnittstellen. Die Frage vor dem Umstieg auf V2 ist deshalb selten „Lohnt sich V2?“, sondern: Was von dem, was wir gebaut haben, kommt mit?

Aus meinen Readiness Checks – der Bestandsaufnahme aller genutzten Objekte in V1, dem Abgleich mit dem Umfang von V2 und dem Delta dazwischen – sind es immer wieder dieselben sieben Punkte.

1. Eigene Entwicklungen aus SDK und PDI müssen neu entstehen – daneben, nicht darin

Alles, was in V1 mit dem SDK oder in der Partner-Entwicklungsumgebung (PDI) gebaut wurde, lässt sich nicht nach V2 übertragen; PDI gibt es in V2 nicht mehr. Kleine Anpassungen – eigene Felder, Regeln, Oberflächen – bleiben im System möglich. Eigene Programmierung dagegen entsteht side-by-side: als eigene Anwendung auf der SAP Business Technology Platform, neben dem System, über Schnittstellen angebunden.

Das ist der Punkt, der am häufigsten unterschätzt wird, weil er unsichtbar ist. In der Oberfläche sieht eine PDI-Lösung aus wie ein Teil des Systems; im Readiness Check zählt sie zu den Objekten, die komplett neu gedacht werden müssen. Die erste Frage lautet deshalb nicht „Wie bauen wir das nach?“, sondern „Brauchen wir das noch?“ – und erstaunlich oft lautet die Antwort nein.

2. Die Integrationen werden neu aufgebaut

Die Schnittstellen aus V1 kommen nicht mit. V2 spricht andere Schnittstellen als V1 (OData statt der alten SOAP-Dienste), und die Integrationsflüsse müssen in der SAP Integration Suite neu aufgebaut werden. Für die Standardanbindung an S/4HANA liefert SAP fertige Pakete; alles, was darüber hinausgeht – eigene Flüsse zu ECC, Emarsys oder Drittsystemen – ist Neubau. Das ist kein Grund zur Panik, aber einer für den Kalender: Integrationen sind der Teil des Umstiegs, der am ehesten die Zeitplanung sprengt, weil auf beiden Seiten Menschen gebraucht werden, die oft genug anderes zu tun haben.

Im Readiness Check gehört deshalb jede Schnittstelle einzeln auf die Liste: was sie überträgt, in welche Richtung, wer sie kennt, und ob sie in V2 überhaupt noch nötig ist.

3. Das Übergangswerkzeug überträgt Daten, nicht das System

SAP stellt mit dem Data Transition Tool ein Werkzeug für den Übergang bereit, und es nimmt echte Arbeit ab: Es überträgt Daten – Kunden, Kontakte, Leads, Opportunities und andere Geschäftsobjekte. Was es nicht überträgt, sind Konfiguration, eigene Objekte, Logik und Integrationen; und selbst bei den Daten gibt es Lücken, etwa bei Anhängen. Alles davon muss geplant, gebaut oder bewusst weggelassen werden. Wer den Umstieg mit „das Tool macht das“ beginnt, entdeckt die Lücken im Projekt statt davor.

Die ehrliche Reihenfolge ist umgekehrt: erst die Bestandsaufnahme, dann die Frage, was das Werkzeug davon abdeckt, dann der Plan für den Rest.

4. Die Migration ist der beste Zeitpunkt für die Datenqualität

Jedes CRM, das einige Jahre läuft, hat Dubletten: dieselbe Firma dreimal angelegt, Ansprechpartner, die längst woanders arbeiten, Adressen in drei Schreibweisen. Wer das 1:1 nach V2 mitnimmt, nimmt auch das Misstrauen der Anwender mit – „die Daten stimmen eh nicht“ ist einer der häufigsten Gründe, warum ein CRM nicht genutzt wird.

Der Umstieg ist die Gelegenheit, die sonst nie kommt: Dubletten prüfen, bevor sie wandern, und Firmen über eine eindeutige Kennung wie die D-U-N-S-Nummer sauber zusammenführen. Das kostet Zeit vor der Migration und spart sie danach – und es ist das Erste, was die Anwender im neuen System bemerken.

5. Berichte und Dashboards entstehen neu – in der eingebetteten SAP Analytics Cloud

V1 hat eine eigene Auswertung mit Berichten, Datenquellen und Dashboards, die über Jahre gewachsen sind. V2 hat keine eigene Analytik mehr: Berichte und Dashboards laufen in der eingebetteten Ausgabe der SAP Analytics Cloud (eSAC), die im System mitgeliefert wird. Die Berichte aus V1 kommen nicht mit; sie werden dort neu gebaut, auf den Datenquellen von V2.

Zwei Dinge sind dabei zu wissen. Erstens kann die eingebettete Ausgabe weniger als die vollständige SAP Analytics Cloud; wer in V1 aufwendige Berichte hatte, sollte früh prüfen, ob sie in eSAC abbildbar sind oder eine eigene SAC-Lizenz brauchen. Zweitens ist auch das eine Gelegenheit: Von den Berichten, die in V1 angelegt wurden, wird erfahrungsgemäß nur ein Bruchteil regelmäßig geöffnet. Die Bestandsaufnahme fragt deshalb nicht „Welche Berichte gibt es?“, sondern „Welche schaut jemand an?“ – und nur die werden nachgebaut.

6. Unterwegs ohne Netz: Offline heißt in V2 nur Lesen

Die App zu V1 hatte einen echten Offline-Modus: Der Außendienst konnte ohne Netz Besuche anlegen, Kontakte ändern, Notizen schreiben, und die App glich später ab. Die App zu V2 kann das nicht. Laut SAP gibt es keine Offline-Unterstützung; heruntergeladene Daten lassen sich ohne Verbindung lesen, aber nicht ändern.

Für Vertriebsteams, die in Werkshallen, auf Baustellen oder in Regionen mit schlechtem Netz unterwegs sind, ist das eine Prozessänderung, keine Fußnote. Im Readiness Check gehört deshalb die Frage dazu: Wer arbeitet wo ohne Netz, und was macht er dort heute im CRM? SAP schließt Lücken quartalsweise; welche Funktion wann kommt, steht in der Roadmap, und die sollte man vor dem Zeitplan lesen, nicht danach.

7. V2 ist näher am Standard – und das ist die Chance

V1 ließ viel zu. Das war angenehm und hat über die Jahre Systeme entstehen lassen, die niemand mehr ganz überblickt. V2 ist keine neue Version desselben Systems, sondern eine neue Plattform – und deutlich näher am Standard. Was auf den ersten Blick wie Verlust aussieht, ist bei den meisten Unternehmen ein Gewinn: Weniger Sonderlocken heißt weniger Pflege, weniger Abhängigkeit von Einzelnen und weniger Erklärungsbedarf bei neuen Mitarbeitenden.

Die Voraussetzung ist, den Umstieg nicht als technische Kopie zu planen, sondern als Entscheidung: Welche Prozesse übernehmen wir im Standard, welche Abweichungen sind wirklich nötig? Das ist eine Frage an Vertrieb und Service, nicht an die IT – und genau hier wird aus einer Migration ein Change-Projekt.

Was das für die Planung heißt

• Bestandsaufnahme zuerst. Alle genutzten Objekte in V1: Felder, Workflows, Ausgabevorlagen (in V2 weiterhin mit dem Adobe LiveCycle Designer gepflegt, aber auf der Datenbasis von V2 neu anzulegen), Oberflächenanpassungen und Mashups, Berichte, Erweiterungen, Schnittstellen. Nicht alle angelegten – alle genutzten.
• Das Delta benennen. Was deckt V2 ab, was überträgt das Data Transition Tool, was muss neu entstehen, was fällt weg.
• Datenqualität einplanen. Duplikatprüfung und eindeutige Kennungen vor der Migration, nicht danach.
• Den Außendienst fragen. Wer arbeitet wo ohne Netz, und was muss dort weiter möglich sein?
• Die Fachbereiche an den Tisch. Standardnähe ist eine Entscheidung der Anwender, keine Einstellung im System.

Genau das ist der Umfang meines V2 Readiness Checks: Bestandsaufnahme, Abgleich, Delta, Lösungsstrukturen und ein grober Migrationsplan – zum Festpreis, bevor Sie sich auf einen Umstieg festlegen.

Zum Nachlesen bei SAP: Extensibility Overview SAP Sales and Service Cloud V2 · Data Transition Tool und Lead-Anhänge · Integration Transition V1 to V2 · Standard-Integrationspakete für V2 · Embedded SAC in V2 · SAP Sales Cloud Mobile App (Dokumentation) · SAP-Hinweis 3696616 zum Offline-Modus · Druckformulare in V2 mit Adobe LiveCycle Designer