SAP Sales Cloud V2 vs. C4C: Was sich wirklich geändert hat

Ihr C4C läuft noch. Aber es läuft auf Sparflamme. SAP hat die Richtung unmissverständlich vorgegeben: Sales Cloud V2 ist die Zukunft. C4C bekommt keine neuen Features mehr. Die Frage ist nicht ob Sie wechseln. Die Frage ist wann.

Wir haben mehrere Organisationen von C4C auf V2 migriert. Nussbaum und intelligentfood sind produktiv. Was ich Ihnen hier gebe, ist nicht Theorie. Es ist das, was wir dabei gelernt haben.

Das grosse Bild: gleicher Name, anderes Produkt

Nein, so nicht: Sales Cloud V2 ist kein Upgrade von C4C. Es ist ein komplett neu entwickeltes Produkt. Anderer Stack. Anderes Datenmodell. Anderes Erweiterungs-Framework. SAP hat den Namen behalten, um Kontinuität zu signalisieren, aber unter der Haube ist fast alles anders.

C4C war monolithisch. Eigenes UI-Framework, eigenes Datenmodell, ein proprietäres Erweiterungsmodell namens PDI. Es funktionierte. Aber jede Erweiterung hiess: SAPs eigene Tools lernen und deren Grenzen akzeptieren.

V2 ist API-first. Die Oberfläche basiert auf Fiori. Erweiterungen leben auf SAP BTP, nicht in der Anwendung. Das Datenmodell ist sauberer. Die APIs sind RESTful, gut dokumentiert, für Drittanbieter-Integration gebaut.

Das ist die gute Nachricht. Der Haken: Migration ist de facto ein Reimplementierungsprojekt.

Was in V2 besser ist

Die Fiori-Oberfläche ist schneller, konsistenter und funktioniert auf Mobilgeräten. C4Cs UI wirkte schon 2023 veraltet. V2 fühlt sich an wie ein Produkt aus diesem Jahrzehnt.

Jedes Objekt in V2 ist über REST-APIs zugänglich. In C4C brauchten manche Operationen Workarounds oder OData-Tricks. V2s API-Abdeckung ist von Anfang an umfassend.

Statt PDI nutzt V2 SAP BTP für Erweiterungen. Node.js, Java, CAP, Cloud Foundry. Echte Entwicklungswerkzeuge statt einer eingeschränkten Sandbox. Das ist eine massive Verbesserung.

KI ist nativ eingebaut: Lead Scoring, Opportunity-Einblicke, Forecasting. Bei C4C wurden diese Features spät nachgerüstet und es merkte sich.

Performance ist spürbar besser. Seitenladezeiten, Suche, Listenansichten. Für Teams, die den ganzen Tag im CRM arbeiten, zählt das.

Und die S/4HANA-Integration ist enger und vorkonfiguriert. Konto-, Kontakt-, Produktdaten. C4C brauchte für die meisten Szenarien Middleware.

Was anders ist (nicht besser, nicht schlechter, einfach anders)

Das Datenmodell ist sauberer, aber es ist ein anderes. Custom Objects, Custom Fields und Beziehungen müssen neu konzipiert werden. Nicht kopiert. Hier steckt der grösste Migrationsaufwand.

PDI-Erweiterungen lassen sich nicht übertragen. Sie werden als BTP-Anwendungen neu entwickelt. BTP ist leistungsfähiger und wartbarer. Aber es ist Neuentwicklung.

Die Admin-Oberfläche ist anders. Workflows, Zuweisungsregeln, Benachrichtigungen: alles anders konfiguriert. Ihr Admin-Team braucht Schulung.

Reporting läuft über SAP Analytics Cloud statt den eingebauten C4C-Reports. Wenn Sie auf C4Cs natives Reporting angewiesen waren, planen Sie Zeit für SAC ein.

Worauf Sie achten müssen

Prüfen Sie die SAP-Roadmap für Ihre spezifischen Features. V2 schliesst quartalsweise Lücken zu C4C, aber manche C4C-Features haben noch kein V2-Äquivalent.

Custom Objects: Planen Sie ein vollständiges Redesign. V2s Framework ist anders. Wir machen typischerweise einen eigenen Discovery-Workshop nur dafür. Es ist das grösste Einzelrisiko bei den meisten Migrationen.

Jede C4C-Integration muss überprüft werden. API-Endpunkte, Authentifizierung, Datenformate. Alles hat sich geändert.

Und die Benutzerakzeptanz: Die Oberfläche ist anders genug, dass Anwender Schulung brauchen. Gehen Sie nicht davon aus, dass die Leute es schon herausfinden, weil es «dasselbe Produkt» ist. Es ist nicht dasselbe Produkt.

Was wir in der Praxis erlebt haben

Nussbaum: 5 Monate von null auf produktiv. Pipeline-Transparenz war der Treiber. Echtzeit-Pipeline-Daten, mobiler Zugriff für den Aussendienst, KI-gestütztes Forecasting. Nichts davon funktionierte im vorherigen Setup adäquat.

intelligentfood: Fokus auf mobilem Aussendienst. Wir bauten massgeschneiderte BTP-Apps für Offline-fähige Routenplanung und Auftragserfassung, integriert mit Sales Cloud V2. Die API-first-Architektur machte das möglich, ohne gegen die Plattform zu kämpfen.

Beide Projekte bestätigten dasselbe: V2 ist das bessere Produkt. Aber der Weg dorthin erfordert, es als Neuimplementierung zu behandeln. Wer es als Versions-Upgrade angeht, scheitert.

Migrationsansatz, der funktioniert

Zuerst Discovery. Erfassen Sie Ihre C4C-Nutzung: Standardfunktionen, Custom Objects, Integrationen, Reports. Was lässt sich konzeptionell übertragen, was muss neu konzipiert werden.

Dann priorisieren. Nicht alles muss am ersten Tag live sein. Kern-Vertriebsprozesse zuerst. Komplexität in Phasen.

C4C parallel weiterlaufen lassen, bis V2 validiert ist. Datenmigration ist ein eigener Workstream, den planen Sie früh.

BTP von Anfang an. Wenn Sie Erweiterungen brauchen, bauen Sie sie von Tag eins auf BTP. PDI-Muster zu reproduzieren wäre der falsche Weg.

Key User früh in V2-Sandboxes bringen. Deren Feedback formt die Konfiguration.

Das Fazit

V2 ist objektiv die bessere Plattform. Die Architektur ist modern, die APIs sind sauber, die Erweiterbarkeit ist echt. Aber Migration ist nicht gratis. Es ist ein Projekt. Discovery, Design, Implementierung, Change Management.

Wenn Sie das einplanen, lohnt sich der Wechsel. Wenn Sie ein Push-Button-Upgrade erwarten, werden Sie enttäuscht.

Sie planen Ihre C4C-zu-V2-Migration? Wir haben es gemacht. Kontakt aufnehmen.