CPQ zu Revenue Cloud migrieren: Phasen, Aufwand, Cutover

Eine Migration von Salesforce CPQ zu Revenue Cloud ist ein Neuaufbau auf Salesforce-Standardobjekten, mit neuer Preislogik, neuem Konfigurator und neuen Berichten. Die Salesforce-Hilfe teilt sie in drei Phasen: vorbereiten, Strategie wählen, umsetzen, jede abgeschlossen vor der nächsten. Salesforce nennt 3 bis 6 Monate von der Analyse bis zum Go-live als typisch, bei komplexen Orgs mehr. In dieser Zeit läuft CPQ in derselben Org weiter. Werkzeuge beschleunigen das Mapping von Produkten und Preisen, drei Entscheidungen bleiben aber bei Ihnen: wer den Preis führt, wann umgestellt wird und wie viel Historie mitkommt. Ohne diese Entscheidungen ist jede Partnerschätzung geraten.

Was ändert sich zwischen CPQ und Revenue Cloud wirklich?

Salesforce CPQ und Salesforce Billing stammen von SteelBrick, das Salesforce im Dezember 2015 gekauft hat1. Beide sind Managed Packages mit eigenen Objekten. Revenue Cloud, in der Salesforce-Hilfe derzeit Revenue Management genannt und ursprünglich als Revenue Lifecycle Management (RLM) gestartet, baut auf Standardobjekten auf. Die CPQ-End-of-Life-Seite von Salesforce2 fasst es knapp: CPQ nutzt eigene Objekte in einem Managed Package, Revenue Cloud ein Standarddatenmodell mit API-first-Angebotslogik, und “CPQ-specific objects, custom fields, pricing rules, and scripts don’t map directly”.

Was das für die Migration heißt, Baustein für Baustein:

Bereich	Salesforce CPQ und Billing (SteelBrick)	Revenue Cloud	Folge für die Migration
Datenmodell	Paketobjekte, etwa SBQQ__Quote__c	Standardobjekte wie Quote, Order, Asset	Jedes Feld, jeder Flow, jede Schnittstelle wird neu zugeordnet
Produkte	Produkte mit Optionen und Features	Katalog, Klassifizierungen, Attribute, Bundles	Katalog neu entwerfen, nicht kopieren
Konfigurationsregeln	Produktregeln	Konfigurationsregeln und Constraint Rules Engine mit CML	Regeln neu modellieren
Preisfindung	Price Rules, JavaScript Quote Calculator Plugin3	Pricing Procedures, Decision Tables	Logik neu bauen und mit echten Angeboten testen
Vertragsgeschäft	CPQ-Subscriptions	Assets mit Zustandsperioden	Für jedes offene Abo ein Asset anlegen
Abrechnung	Paket blng	Revenue Cloud Billing auf Standardobjekten	Eigener Cutover, siehe unten
Berichte	Berichte auf Paketobjekten	Berichte auf Standardobjekten	Alles neu bauen

Den ausführlichen Vergleich finden Sie in Salesforce CPQ und Revenue Cloud: die echten Unterschiede. Für die Planung reicht ein Punkt: Es gibt keinen Upgrade-Knopf, und jede Zeile dieser Tabelle ist ein Arbeitspaket.

Salesforce teilt die Migration in drei Phasen

Der Hilfeartikel Migrate to Revenue Management4 gibt den Rahmen vor. Die Arbeit läuft in Phasen, und Salesforce verlangt, alle Aufgaben einer Phase in der genannten Reihenfolge abzuschließen, bevor die nächste beginnt:

1. 01

   Vorbereiten

   Prüfen, welche Funktionen von Revenue Cloud Sie brauchen, und die operative Planung klären. Die Hilfe nennt hier zwei praktische Voraussetzungen, die für jede Strategie gelten: das Beibehalten der CPQ-Lizenz und die Koexistenz während des Übergangs.

2. 02

   Strategie wählen

   Migrationsstrategie, Umgang mit Bewegungsdaten sowie Rollout und Cutover festlegen. Laut Hilfe gehören diese Entscheidungen an den Anfang, weil sie Umfang, Schnittstellen, Cutover und Change Management bestimmen.

3. 03

   Umsetzen

   Produktdaten, Asset-Daten und Billing-Daten migrieren, Berichte neu bauen und Change Management von Beginn an als parallelen Strang führen.

Einen festen Zeitrahmen setzt die Hilfe nicht. Die CPQ-Seite nennt 3 bis 6 Monate als typisch und ergänzt, dass komplexe Implementierungen länger dauern können. Meine Einschätzung: 3 Monate sind für eine aufgeräumte Org mit wenigen Preisregeln realistisch, eine über Jahre gewachsene Org mit vielen eigenen Skripten gehört an das obere Ende oder dahinter. Eine Analyse der technischen Schulden vor der Schätzung zeigt, welchen Fall Sie haben.

Der Lizenzpunkt betrifft das Budget. Während des Aufbaus erstellt CPQ weiter Angebote in Produktion, Sie zahlen also für die Dauer des Projekts CPQ und Revenue Cloud parallel. Ein Grund mehr, die Migration nicht über Jahre zu strecken.

Die Daten wandern in der Reihenfolge ihrer Abhängigkeiten

Die Hilfe nennt drei Gruppen: Produktdaten, Asset-Daten und Billing-Daten. Die Reihenfolge innerhalb dieser Gruppen folgt den Abhängigkeiten, die der Revenue Cloud Developer Guide in seiner Object Deployment Reference5 aufführt. Eltern vor Kindern, Metadaten vor Datensätzen:

1. Katalogstruktur: Attributdefinitionen und Picklisten, Produktklassifizierungen, dann die Produkte selbst.
2. Verkauf und Preise: Product Selling Models, Preisbücher, Kostenbücher, Preisbucheinträge, danach Preisanpassungen.
3. Bundles und Kataloge: Komponentengruppen und zugeordnete Komponenten, Kataloge und Kategorien.
4. Assets: ein Asset für jedes offene CPQ-Abo, damit Nachträge und Verlängerungen in Revenue Cloud funktionieren. Laut Trailhead6 beginnt jeder Nachtrag an einem Asset und läuft über ein Angebot und einen Auftrag.
5. Billing-Daten: nur, wenn Sie heute Salesforce Billing nutzen. Dazu gibt es einen eigenen Beitrag: von Salesforce Billing zu Revenue Cloud Billing.

Wie Katalog und Preise danach von der Sandbox in die Produktion kommen, ist ein eigenes Thema: Revenue Cloud Deployments.

Was leisten Migrationswerkzeuge, und was nicht?

Auf der CPQ-Seite nennt Salesforce drei Partnerangebote: Forsys RevRamp für Datentransformation und Schema-Mapping, IdeaHelix mit Automatisierung über den gesamten Migrationsablauf und Prodly, das die bestehende CPQ-Einrichtung analysiert. Außerdem schreibt Salesforce, dass rund 15 Prozent der Kunden von Revenue Cloud Advanced Unternehmen sind, die von CPQ migriert haben.

Diese Werkzeuge sparen Zeit bei Produkten, Preisbucheinträgen und Abos. Die Hilfe benennt die Grenze klar: Werkzeuge ersetzen keine menschlichen Designentscheidungen, vor allem nicht bei eigener Logik und beim Umbau von Schnittstellen. Eine Preisregel, die ein altes Rundungsproblem behebt, ein Skript, das ein Feld aus SAP liest, eine Freigabekette mit Ausnahmen für ein Land: Jemand muss entscheiden, ob diese Logik noch gebraucht wird und wie sie in einer Pricing Procedure aussieht.

Beim Vergleich von Partnerangeboten würde ich jeden Partner nach denselben drei Zahlen fragen: wie viele Preisregeln, Produktregeln und Skripte er in Ihrer Org gezählt hat und was er mit jedem vorhat. Wer ohne Zählung anbietet, verkauft eine Spanne. Wie Sie solche Angebote vergleichen und welches Vertragsmodell passt, beschreiben Festpreis statt Aufwand und das Kapitel der KI-Masterclass zu AIforce und Systemintegratoren.

Rechenbeispiel: ein Komponentenhersteller mit CPQ seit 2018

Angenommen, ein Komponentenhersteller nutzt Salesforce CPQ seit 2018. Er hat 60 Nutzer, die Angebote erstellen, 1.200 Produkte, 40 Preisregeln, ein Quote Calculator Plugin mit über Jahre gewachsener Logik und 3.500 aktive Service-Abos für Fernüberwachung. Rechnungen kommen aus SAP. Alle Zahlen sind Annahmen.

Der Plan könnte so aussehen:

• Wochen 1 bis 4, vorbereiten: Regeln und Skripte zählen, entscheiden, welche Logik entfällt, SAP als Preisführer für Listenpreise und Revenue Cloud für Rabatte festlegen.
• Wochen 5 bis 8, Strategie: Umstellung je Produktlinie, zuerst Ersatzteile und Service, Maschinen zuletzt. Abos wandern in Paketen, immer vor ihrem Verlängerungsmonat.
• Monate 3 bis 5, umsetzen: Katalog und Preise in der Pipeline, Assets für das erste Abo-Paket, Berichte neu gebaut, Vertrieb je Produktlinie geschult.
• Monat 6: Die letzte Produktlinie zieht um, CPQ wird schreibgeschützt, die CPQ-Lizenz endet zum nächsten Verlängerungstermin.

Da Billing nicht im Einsatz ist, entfällt in diesem Szenario der Billing-Cutover. Mit Salesforce Billing käme ein Cutover zum Periodenende und die Freigabe durch die Finanzabteilung dazu.

Die Schulung je Produktlinie deckt nur einen Teil des Change Managements ab, das die Hilfe als parallelen Strang verlangt. 60 Nutzer, die seit Jahren in CPQ anbieten, müssen auch verstehen, warum sich ihr Werkzeug ändert. Warum Schulungen allein selten reichen, beschreibe ich in Salesforce Change Management: warum Einführungen scheitern.

Was muss der Kunde selbst entscheiden?

Diese Entscheidungen gehören Ihnen, nicht dem Partner und nicht dem Werkzeug:

• Preisführung: welche Preise aus SAP kommen und welche in Revenue Cloud berechnet werden. Zwei führende Systeme für denselben Preis funktionieren nie.
• Cutover-Modell: alles auf einmal, je Produktlinie oder je Land, und der Tag, ab dem CPQ schreibgeschützt ist.
• Historie: was migriert wird, was ins Archiv geht und was in CPQ lesbar bleibt.
• Verantwortung nach dem Go-live: wer Klassifizierungen, Constraint-Regeln und Pricing Procedures pflegt. Eine Object Ownership Matrix hilft, wenn mehrere Partner in derselben Org arbeiten.
• Lizenzende: wann der CPQ-Vertrag ausläuft. CPQ hat kein End-of-Life-Datum, dieser Termin liegt also ganz bei Ihnen.

Ob Sie überhaupt umsteigen oder vorerst bei CPQ bleiben, behandelt CPQ behalten oder zu Revenue Cloud wechseln?. Das ganze Thema finden Sie im Masterclass-Kapitel Von CPQ zu Revenue Cloud, und mehrere Partner durch einen solchen Umstieg zu steuern, gehört zu meiner Arbeit in der Partnersteuerung.

Quellen6

1. 1im Dezember 2015 gekauft hat (öffnet in einem neuen Tab)siliconangle.com
2. 2CPQ-End-of-Life-Seite von Salesforce (öffnet in einem neuen Tab)salesforce.com
3. 3JavaScript Quote Calculator Plugin (öffnet in einem neuen Tab)developer.salesforce.com
4. 4Migrate to Revenue Management (öffnet in einem neuen Tab)help.salesforce.com
5. 5Object Deployment Reference (öffnet in einem neuen Tab)developer.salesforce.com
6. 6Trailhead (öffnet in einem neuen Tab)trailhead.salesforce.com