Migration zu SAP Service Cloud V2: Ein praktischer Leitfaden

SAP Service Cloud V2 ist kein Upgrade. Es ist eine Neu-Architektur. Komplett. V2 wurde nativ auf SAP BTP und SAP HANA Cloud aufgebaut und ersetzt die C4C-Plattform vollständig durch eine grundlegend andere technische Basis.

Wer das als «V1 plus ein paar neue Features» versteht, wird in der Migration Probleme bekommen. Also ehrlich: Behandeln Sie es als das, was es ist. Ein neues Produkt.

Für Organisationen, die derzeit Service Cloud V1 (C4C) einsetzen, erfordert der Migrationspfad sorgfältige Planung. Dieser Leitfaden erklärt, was Sie konkret erwarten können.

Was sich in V2 ändert

Technische Plattform. V2 läuft auf SAP BTP (Business Technology Platform) statt auf dem C4C-Cloud-Stack. Das ermöglicht bessere Integration mit anderen BTP-Diensten. Aber Konfiguration, Erweiterbarkeit und APIs funktionieren anders. Komplett anders.

Datenmodell. Das zugrundeliegende Datenmodell wurde neu gestaltet. Benutzerdefinierte Felder, Erweiterungen und Integrationen, die auf C4C-APIs aufgebaut wurden, werden nicht automatisch migriert. Sie müssen im V2-Modell neu aufgebaut werden. Kein Copy-Paste. Kein Lift-and-Shift. Neuaufbau.

Benutzeroberfläche. Die Endbenutzeroberfläche ist völlig neu. V2 verwendet eine moderne, rollenbasierte UI, in die SAP weiter investieren wird. Die Fiori-ähnliche Oberfläche von C4C wird eingestellt. Prima vista sieht V2 anders aus, fühlt sich anders an, navigiert sich anders.

Erweiterbarkeit. C4C verwendete Key-User-Tools und SDK-basierte Erweiterungen. Die Erweiterbarkeit von V2 läuft über SAP BTP-Dienste. Leistungsstärker, ja. Erfordert aber andere Kenntnisse. Ihr Team braucht BTP-Know-how, nicht C4C-Know-how.

Was gleich bleibt

Die grundlegenden Service-Konzepte. Tickets, Accounts, Kontakte, Service-Level, Wissensdatenbank. Das alles bleibt erhalten. Wenn Ihr Team das Service-Management versteht, wird es sich an V2 gewöhnen. Die Konzepte sind die gleichen, die Werkzeuge sind neu.

Das Integrationsparadigma ist ebenfalls ähnlich: V2 stellt REST/OData-APIs für die Integration mit ERP, Commerce und externen Systemen bereit. Die spezifischen Endpunkte ändern sich, aber die Architekturprinzipien bleiben.

Migrationsansatz

Schritt 1: Bewertung. Erfassen Sie alle aktiven Konfigurationen, Integrationen, benutzerdefinierten Erweiterungen und Berichte in C4C. Bestimmen Sie für jedes Element, ob es in V2 benötigt wird und wie es gegebenenfalls implementiert werden soll. Klingt trivial. Ist es nicht. Diese Phase entscheidet über den Projekterfolg.

Schritt 2: Neu-Design der Integration. Die meisten C4C-Integrationen müssen neu aufgebaut werden. Nutzen Sie das als Gelegenheit, wo möglich zu vereinfachen. Die nativen Konnektoren von V2 zu S/4HANA und SAP Commerce Cloud sind deutlich besser als ihre C4C-Entsprechungen. Wer hier adäquat aufräumt, spart sich später Wochen.

Schritt 3: Konfiguration in V2. Bauen Sie die V2-Umgebung parallel zum laufenden C4C-System auf. Versuchen Sie keine direkte Migration von Konfigurationsdaten. Das funktioniert nicht und erzeugt nur Frustration.

Schritt 4: Datenmigration. Migrieren Sie historische Ticket- und Kundendaten mit den Migrationswerkzeugen von SAP. Definieren Sie eine klare Cutover-Strategie. Delta-Migration ist Pflicht, nicht Kür.

Schritt 5: Training und Change Management. Die Änderung der Benutzeroberfläche allein erfordert ein Schulungsprogramm. Planen Sie es ein. De facto ist die Benutzerakzeptanz konsistent die am meisten unterschätzte Herausforderung bei V2-Migrationen. Technik können Sie immer fixen. Die Leute müssen Sie mitnehmen.

Zeitplanung

Eine typische Service Cloud V2-Migration für eine mittelgrosse Organisation (50-200 Service-Agenten, moderate Integrationskomplexität) dauert von der Projektinitiierung bis zum Go-live 6-10 Monate. Einen umfassenden Überblick über SAP Service Cloud V2 finden Sie auf unserer SAP Service Cloud V2 Lösungsseite.

Organisationen, die V2 als «Lift and Shift» behandeln, stossen in den Abschlussphasen konsistent auf Probleme. Behandeln Sie es als neue Implementierung, bei der die Migration ein Workstream ist. Nicht umgekehrt.

Spadoom hat mehrere Service Cloud V2-Migrationen durchgeführt. Kontaktieren Sie uns, um Ihre Situation zu besprechen.