Sie befinden sich hier:
Änderungen an der Preisarchitektur
Die Preisgestaltung ist einer der architektonisch signifikantesten Unterschiede zwischen Salesforce CPQ und der Umsatzverwaltung. Wenn es nicht frühzeitig erkundet wird, ist es einer der Bereiche, in denen später Komplexität auftreten kann. Es wird empfohlen, dass das Migrationsteam ein klares Verständnis der Preismodelländerungen und ihrer Auswirkungen auf die Konfiguration und Migration entwickelt, bevor Designentscheidungen abgeschlossen sind.
Preise in CPQ
Die Preisgestaltung in Salesforce CPQ basiert auf einem Regelmodul. Preisregeln werten Bedingungen aus und wenden Anpassungen in einer definierten sequenziellen Reihenfolge an. Die Ausführungsreihenfolge ist wichtig. Wenn Sie die Reihenfolge ändern, wird das Ergebnis geändert.
Allgemeine CPQ-Preiskonstrukte enthalten die folgenden Komponenten.
- Preisregeln sind bedingungsbasiert und werden nacheinander ausgeführt, um Listenpreis, Nettopreis und Sonderpreise zu berechnen.
- Rabattregelungen sind volumen- und laufzeitbasierte Rabatttabellen, die auf Angebotsbelegposten angewendet werden.
- Bei Gruppenpreisen handelt es sich um gestaffelte Preise, die auf Mengenbereichen basieren.
- Vertragspreise sind accountspezifische Preisüberschreibungen, die als benutzerdefinierte CPQ-Datensätze gespeichert werden.
- Bei Angebotsberechnungs-Plugins (QCPs) handelt es sich um benutzerdefinierten Code, den das Regelmodul nicht nativ verarbeiten kann. Diese Plugins unterstützen Randleitplanken, linienübergreifende Berechnungen, dynamische Sichtbarkeit und alle Logiken, die das Regelmodul nicht ausdrücken kann. QCPs bieten zwar Flexibilität, können jedoch im Laufe der Zeit schwierig zu verwalten sein, wenn sich Regeln ansammeln, Abhängigkeiten zwischen Regeln ausgeblendet werden und eine umfassende Dokumentation fehlt.
Preise in der Umsatzverwaltung
Die Umsatzverwaltung ersetzt das Modul für sequenzielle Regeln durch ein strukturiertes Preisgestaltungsverfahrensmodell. Ein Preisgestaltungsverfahren ist eine benannte, geordnete Sequenz von Preisgestaltungselementen. Jedes Element führt eine bestimmte Preisaktion aus, beispielsweise das Anwenden eines Preisbuchpreises, das Anwenden eines Rabatts, das Hinzufügen eines Aufschlags oder das Berechnen einer Margenuntergrenze.
- Preisgestaltungsverfahren bieten mehr Flexibilität und Möglichkeiten als CPQ-Preisregelsätze. Sie definieren den Wasserfall für die Preisberechnung für einen bestimmten Kontext wie Direktvertrieb, Partnerkanal oder E-Commerce. Sie definieren den Wasserfall für die Preisberechnung für einen bestimmten Kontext wie Direktvertrieb, Partnerkanal oder E-Commerce.
- Preiselemente sind einzelne Schritte innerhalb eines Verfahrens. Jedes Element verfügt über einen Typ wie "Manuelle Anpassung", "Rabattregelung", "Preisliste", "Attributbasierte Preise" usw. Entsprechende Informationen finden Sie unter Verwenden von Preiselementen in Preisgestaltungsverfahren.
- Verfahrenspläne definieren, welches Preisgestaltungsverfahren je nach Kontext angewendet wird. Diese Pläne ermöglichen eine unterschiedliche Preislogik für jeden Kanal, jedes Kundensegment oder jede Produktkategorie, ohne Regeln duplizieren zu müssen.
- Die attributbasierte Preisgestaltung für ein Produkt unterscheidet sich anhand seiner Konfigurationsattribute, ohne dass für jede Variante separate SKUs oder Preisregelbedingungen erforderlich sind.
- Die Nutzungs- oder Verbrauchspreisgestaltung ist ein natives Bewertungsmodul für verbrauchsbasierte und gestaffelte Nutzungsmodelle. Es ist kein benutzerdefinierter Code erforderlich.
- Die Preisgestaltung für Vertragsartikel bietet accountspezifische oder vertragsspezifische Preisüberschreibungen mithilfe von standardmäßigen Objekten der Umsatzverwaltung und ersetzt benutzerdefinierte Datensätze von CPQ vom Typ "ContractedPrices".
Die Preise in der Umsatzverwaltung sind flexibel und einfacher zu verwalten als der CPQ-Preiswasserfall. Im Folgenden finden Sie ein Beispiel für einen Preiswasserfall für einen Angebotsbelegposten in der Umsatzverwaltung.
Der Nettostückpreis von 10.260 wird berechnet, indem diese Rabatte nacheinander auf den Listenpreis von 15.000 angewendet werden.
| Schritt | Beschreibung | Rechenvorgang | Ergebnis |
|---|---|---|---|
| 1 | Listenpreis | Keine | 15000 |
| 2 | Attributbasierter Rabatt | 15,000 − 3,000 |
12000 |
| 3 | Paketbasierte Anpassung von 5 % | 12,000 − (12,000 × 5%) = 12,00 − 600 |
11,400 |
| 4 | Mengenrabatt von 10 % | 11,400 − (11,400 × 10%) = 11,400 − 1,140 |
10,260 |
Neugestaltung und Migration des Preisgestaltungsprozesses
CPQ-Preislogik wird selten ohne Änderungen migriert. Beide Systeme definieren die Preisgestaltung auf unterschiedliche Weise. Eine direkte Regel-zu-Regel-Übersetzung führt oft zu falschen Ergebnissen, da CPQ-Regeln von der Ausführungsreihenfolge abhängen, die keine direkte Entsprechung in den Preisgestaltungsverfahren der Umsatzverwaltung hat.
Der Wechsel vom sequenziellen Regelmodul von CPQ zum Preisgestaltungsverfahrensmodell der Umsatzverwaltung ist daher eine Gelegenheit, den Preisgestaltungsprozess Ihres Unternehmens zu vereinfachen. Die zentrale Frage ist nicht, wie vorhandene CPQ-Regeln repliziert werden, sondern welche Preisergebnisse das Unternehmen tatsächlich benötigt und wie sie am deutlichsten ausgedrückt werden können.
- Überprüfen Sie alle aktiven Preisregeln und die QCP-Logik, bevor Sie mit der Migration beginnen. Verwenden Sie AI-gestützte Tools wie Forsys oder IdeaHelix, um Erklärbarkeitsberichte zu allen CPQ-Preisregeln und QCP-Logik zu generieren. Machen Sie sich mit dem Intent und Geschäftszweck der einzelnen Regeln vertraut, unabhängig davon, ob es sich um Listenpreise, Rabatte, Margenschutz oder Kanalanpassungen handelt, bevor Sie eine Änderung vornehmen.
- Klassifizieren Sie jede CPQ-Regel in ihre Entsprechung "Umsatzverwaltung". Einfache Preisanpassungen werden zu Preiselementen und komplexe linienübergreifende Logik zu benutzerdefinierten Flows oder Apex innerhalb des Verfahrens.
- Rationalisieren Sie Preisregeln, die sich im Laufe der Zeit ohne eindeutige Inhaberschaft angesammelt haben. Die Migration ist der richtige Zeitpunkt, um eine Logik einzustellen, die kommerziell nicht mehr relevant ist.
- Ordnen Sie Verfahrensplänen in der Umsatzverwaltung kanalspezifische Preisanforderungen für Direkt-, Partner- und Self-Service-Kanäle zu. Diese Zuordnung ermöglicht einen einzelnen Produktkatalog mit kontextgerechter Preisgestaltung und nicht separate Preiskonstrukte für jeden Kanal.
- Wenn Ihr Unternehmen auf eine hybride Monetarisierung umstellt, konfigurieren Sie den Verbrauch und die nutzungsbasierte Preisgestaltung in der Umsatzverwaltung. Bewertungsverfahren bestimmen die endgültige Nettorate für den Verbrauch mithilfe spezifischer Regeln und Klassen, die auf Basis-, Stufen- oder Attributratenkarten definiert sind.
- Validieren Sie die umgestalteten Preise mit einem zusammengestellten Angebotspaket, bei dem es sich um einen repräsentativen Satz historischer Angebote handelt, deren Ausgabepreise bekannt sind. Wenn das Verfahren "Umsatzverwaltung" dieselben Ergebnisse liefert, ist die Neugestaltung richtig.
- Bei Organisationen mit mehreren Währungen sollten Sie jeweils eine Währung migrieren und validieren, um eine Rundungsabweichung zwischen Preisbucheintragswerten zu vermeiden.
Bevor Sie sich auf eine Migrationsstrategie festlegen, sollten Sie Zeit in eine Preislogiküberprüfung investieren. Das Volumen und die Komplexität Ihrer Preisanpassung sind einer der stärksten Prädiktoren für die Migration insgesamt.
Einheitliches Preisgestaltungsmodul über alle Kanäle hinweg
Die API-First-Architektur der Umsatzverwaltung löst die Integrationsherausforderung, die sich aus der kanalübergreifenden Zunahme von Preislogik ergibt. Viele Unternehmen behalten am Ende separate Preisregeln für Direktvertrieb, Partnerportale und Self-Service-Kanäle bei, wodurch drei Versionen derselben Wahrheit erstellt werden, die sich im Laufe der Zeit unterscheiden und bei Kunden zu Inkonsistenzen führen.
Jeder Umsatzvorgang in der Umsatzverwaltung wird als API angezeigt. Daher kann dieselbe Produkt-, Preis- und Konfigurationslogik, die die Salesforce-Benutzeroberfläche unterstützt, von einem Partnerportal, einer Self-Service-E-Commerce-Erfahrung oder einem Flow für den Kauf innerhalb des Produkts verwendet werden, ohne die Regeln zu duplizieren. Sie können über einen einzelnen Katalog und ein einzelnes Preisgestaltungsmodul verfügen, das für jeden Kanal funktioniert.
Sie können Visualisierungstools von Drittanbietern wie ThreeKit und RenderDraw zur visuellen Produktkonfiguration integrieren.
