Wie wir einen Umsatzlebenszyklus für POS-Hardware und Abonnements aufgebaut haben

Eine Point-of-Sale-Transaktion ist nicht mehr einfach, wenn ein Vertrag Terminals, Scanner, Drucker, Zahlungsgeräte, Softwareabonnements, Installation, Schulung und Support vereint. Jede Position kann unterschiedliche Konfigurationsregeln, Vertragsbedingungen, Abwicklungsschritte und Rechnungspläne haben. Wenn die Architektur nur CRM-Datensätze mit ERP-Datensätzen verbindet, kann das Unternehmen immer noch nicht zuverlässig verfolgen, was verkauft, angenommen, geliefert, installiert, in Rechnung gestellt, geändert oder erneuert wurde.

Für einen US-amerikanischen Einzelhandelstechnologieanbieter haben wir einen POS-Hardware-Umsatzlebenszyklus für Salesforce und SAP implementiert. In diesem Artikel werden die Designentscheidungen hinter der Fallstudie zur vollständigen Implementierung erläutert: Systemverantwortung, Produktmodellierung, Konfiguration, Preisgestaltung, Auftragsorchestrierung, Auftragsabwicklung, Abrechnung und Änderungen nach dem Verkauf.

Die zentrale Designentscheidung

Wir haben das Projekt als Implementierung einer Revenue-Architektur behandelt, nicht als isolierte CPQ-Bereitstellung. Jede kommerzielle Entscheidung musste für die Teams und Systeme nutzbar bleiben, die für die Auftragsabwicklung, die Buchhaltung und die laufende Kundenbeziehung verantwortlich sind.

Welche Probleme die Implementierung lösen musste

Der Kunde hatte seine Vertriebsorganisation von HubSpot auf Salesforce Sales Cloud umgestellt, während SAP weiterhin als ERP-Plattform diente. Eine einfache Katalogintegration synchronisierte Produktinformationen, schuf jedoch keinen verlässlichen Prozess vom Abschluss einer Opportunity über Auftragsannahme, Lieferung, Installation und Rechnungsstellung bis zur Verlängerung.

Gemischte Umsatzmodelle

Ein einzelner Geschäftsabschluss musste einmalig verkaufte Hardware, laufzeitgebundene Software, wiederkehrenden Support, Dienstleistungen und unterschiedliche Abrechnungsintervalle abbilden.

Konfigurationsrisiken

Kompatible Komponenten und voneinander abhängige Mengen ließen sich nur schwer steuern, ohne Hunderte nahezu identischer Verkaufs-SKUs anzulegen.

Unverbundene Abwicklungsprozesse

Eine abgeschlossene Opportunity belegte weder die Auftragsannahme durch SAP noch den Abschluss der Lager-, Liefer- und Installationsarbeiten.

Fragmentierte Änderungen bei Kunden

Zusätzliche Standorte, Upgrades, Kündigungen und Verlängerungen wurden als neue Verkäufe behandelt statt als Änderungen an bestehenden Assets und Abonnements.

Das Projekt kombinierte daher Salesforce-Implementierung mit Integration und Betriebsmodelldesign. Das Ziel war kein universelles führendes System, sondern eine eindeutig verantwortliche Instanz für jede Datendomäne und ein geregelter Austausch von Lebenszyklusereignissen.

Architektur: Eine kaufmännische Ebene mit Anbindung an die operativen Prozesse

Wir implementierten Salesforce Agentforce Revenue Management als kaufmännische Ebene auf Basis von Salesforce Sales Cloud. SAP blieb das führende System für den physischen Produktstamm, Beschaffungskosten, Bestand, Versand und Buchhaltungsdatensätze. Die daraus entstandene Architektur verband die Cloud-Funktionen, ohne die Grenzen zwischen Vertrieb, operativer Ausführung und Buchhaltung zu verwischen.

1. Wir legten die Verantwortlichkeiten nach Datendomäne fest

Wir begannen mit einem Verantwortungsmodell auf Feldebene. Synchronisierte Kopien waren zulässig, doch für jeden Wert blieb genau eine Quelle maßgeblich. Gemeinsame Kennungen, Gültigkeitsdaten und Versionsinformationen verknüpften ein Verkaufsangebot in Salesforce mit dem zugehörigen physischen Material in SAP.

Kostendaten aus SAP wurden zur Margenberechnung mit Salesforce synchronisiert, blieben aber außerhalb von SAP nicht bearbeitbar. Das entspricht demselben Prinzip klarer Datenverantwortung, das wir bei einer geregelten SAP-Integration mit Salesforce anwenden.

2. Wir trennten Produkte von Verkaufs- und Abrechnungsmodellen

Ein POS-Terminal, ein dreijähriges Softwareabonnement und jährlicher Support können im selben Angebot stehen, ohne denselben Regeln zu folgen. Wir modellierten die Eigenschaften des Produkts getrennt davon, wie es verkauft und wie es in Rechnung gestellt wird.

Produktmodell

Physische Artikel, Software, Dienstleistungen, Attribute, Beziehungen und die für nachgelagerte Prozesse erforderlichen Kennungen.

Verkaufsmodell

Einmalige oder laufzeitgebundene Verpflichtungen einschließlich Start- und Enddatum sowie Verlängerungsverhalten.

Abrechnungsmodell

Zeitpunkt und Häufigkeit der Rechnungsstellung, getrennt von der Dauer der vertraglichen Verpflichtung.

Durch diese Trennung blieben Hardwareumsätze, wiederkehrende Umsätze, Gesamtvertragswert, Abonnementlaufzeiten und künftige Verpflichtungen sichtbar, ohne den Katalog für jede mögliche kaufmännische Variante zu vervielfachen.

3. Wir konfigurierten gültige Lösungen vor der Preisberechnung

Eine vollständige Einzelhandelslösung konnte ein Terminal, einen Scanner, einen Belegdrucker, ein Zahlungsterminal, POS-Software, ein Abonnement für die Bestandsverwaltung und Support umfassen. Wir bildeten diese Lösung mit Bundles, Produktattributen, Kompatibilitätsregeln, erforderlichen Komponenten, Ausschlüssen und Mengenabhängigkeiten ab.

Regeln im Advanced Configurator konnten eine Komponente vorschreiben, eine unmögliche Kombination ausschließen, eine irrelevante Option ausblenden, einen kontextbezogenen Hinweis anzeigen oder transaktionsübergreifend wirken. Die Prüfung erfolgte bewusst früh: Eine ungültige Lösung sollte niemals in die Preisberechnung, Vertragserstellung, Auftragserfassung oder Auftragsabwicklung gelangen.

Warum das wichtig war

Die Konfiguration war mehr als eine Funktion zur Verbesserung der Benutzererfahrung im Vertrieb. Sie verringerte die Zunahme der SKUs und schützte Lager- und Installationsteams vor vermeidbaren Ausnahmefällen in nachgelagerten Prozessen.

4. Wir zentralisierten die Preisgestaltung und regelten Ausnahmen

Wir modellierten Preisberechnungsverfahren und Anpassungen in Salesforce, damit Produkt, Konfiguration, Menge, Kundenvereinbarung, Land, Abonnementlaufzeit und Aktionsbedingungen zu einem konsistenten kaufmännischen Ergebnis beitragen konnten. SAP lieferte aktuelle Kostendaten für die Margentransparenz.

Außerdem trennten wir den berechneten Preis vom Rabatt, den eine Vertriebskraft beantragte. Genehmigungsrichtlinien konnten dadurch Rabatt, Marge, Auftragswert und weitere kaufmännische Faktoren bewerten. Standardtransaktionen liefen ohne unnötige Eingriffe weiter, während größere Abweichungen an die zuständigen Genehmigenden aus Vertrieb, kaufmännischer Leitung oder Finanzabteilung weitergeleitet wurden.

Diese Kontrollen wurden mit Salesforce Revenue Cloud als Teil des gesamten Lebenszyklus implementiert, statt als isolierte Berechnungen, die nur an ein Angebot gebunden waren.

5. Wir bewahrten den Inhalt der kaufmännischen Vereinbarung über Auftrag und Auftragsabwicklung hinweg

Das Angebot enthielt mehr als Menge und Stückpreis. Es bewahrte Termine, Abhängigkeiten, Abwicklungsanforderungen, Abrechnungspläne und Verlängerungsverpflichtungen, damit der Auftrag und die nachgelagerten Systeme die Vereinbarung umsetzen konnten, ohne sie rekonstruieren zu müssen.

1. Eine gültige Kombination aus Hardware, Software, Dienstleistungen und Support konfigurieren.
2. Preise und Margen berechnen und anschließend nur die Ausnahmen zur Genehmigung weiterleiten, die die entsprechenden Kriterien erfüllen.
3. Einen Auftrag aktivieren, der die vereinbarten Konditionen, Termine, Mengen und Abhängigkeiten beibehält.
4. Mit Dynamic Revenue Orchestrator den Abwicklungsplan, Aufgaben, Meilensteine und API-Aktionen erstellen.
5. Bestand und Versand durch SAP verwalten lassen und dabei Statusinformationen an Salesforce zurückmelden.
6. Die Installation über Salesforce Field Service zusammen mit dem übrigen Abwicklungsplan verfolgen.

Dynamic Revenue Orchestrator gab Vertrieb und operativen Teams einen gemeinsamen Überblick über die Arbeit, ohne die Lagerteams zum Wechsel aus SAP zu zwingen. Auch Lieferung und Installation blieben getrennt: Der Erhalt eines Geräts bedeutete nicht, dass der Kunde bereits die vollständige Lösung nutzen konnte.

Ein weiteres Beispiel für die Koordination operativer Arbeit in Salesforce zeigt, wie ein Kunde Sales Cloud und Field Service nutzte, um Vertriebs- und Serviceaktivitäten miteinander zu verbinden.

6. Wir erstellten Rechnungen in Salesforce und führten die Buchhaltung in SAP

Wir nutzten die Salesforce Billing Engine, um Rechnungen auf Grundlage der vereinbarten Zeitpläne und relevanten operativen Meilensteine zu erstellen. Die Rechnungsdaten wurden anschließend für die Buchhaltung an SAP übertragen. Dabei blieb die Zuständigkeit klar getrennt: Salesforce übernahm die kaufmännische Rechnungserstellung, während SAP die Buchhaltungsdatensätze führte.

Die Verknüpfung der vertraglichen Verpflichtung mit Liefer- und Abrechnungsmeilensteinen gab der Finanzabteilung außerdem eine bessere Grundlage, um festzustellen, was verkauft, geliefert und in Rechnung gestellt worden war und für ihren Umsatzrealisierungsprozess bereitstand. Die Implementierung ersetzte weder Bilanzierungsrichtlinien noch wurde behauptet, dass allein die Rechnungserstellung bereits Umsätze realisiert.

7. Wir machten Vertragsänderungen und Verlängerungen zum Bestandteil der Architektur

Die Kundenbeziehung setzte sich nach dem ersten Auftrag fort. Eine neue Filiale, zusätzliche Geräte, ein Upgrade auf Premium-Support, eine Kündigung oder eine Verlängerung veränderten einen bestehenden vertraglichen Stand.

Wir richteten Funktionen zur Transaktionsverwaltung auf Kunden-Assets und Abonnements aus. Die Teams konnten auf dem aufbauen, was der Kunde bereits besaß, die Lebenszyklushistorie bewahren und Vertragsänderungen, Upgrades, Kündigungen und Verlängerungen durchführen, ohne die ursprüngliche Konfiguration von Grund auf neu erstellen zu müssen.

Dieselbe Grundlage kann später auch gestaffelte vertragliche Verpflichtungen oder nutzungsbasierte Gebühren unterstützen. Wir behandelten diese jedoch als künftige Gestaltungsmöglichkeiten mit eigenen Anforderungen an Messung, Preisgestaltung, Abrechnung und Buchhaltung – nicht als automatische Ergebnisse der ursprünglichen Implementierung.

Erkenntnisse aus der Implementierung hybrider Umsatzmodelle

• Beginnen Sie mit dem Geschäftslebenszyklus und dem Modell der Datenverantwortung, nicht mit einzelnen Salesforce-Masken.
• Weisen Sie jedem wesentlichen Datenwert genau eine maßgebliche Verantwortungsinstanz zu und legen Sie fest, dass synchronisierte Kopien nicht maßgeblich sind.
• Trennen Sie Produkt-, Verkaufs- und Abrechnungsmodelle, damit Hardware und Abonnements nebeneinander bestehen können, ohne dass der Katalog ausufert.
• Stoppen Sie ungültige Konfigurationen, bevor sie Ausnahmefälle bei Preisberechnung, Auftrag, Lager oder Installation verursachen.
• Bewahren Sie Termine, Abhängigkeiten, Meilensteine und Verpflichtungen bei jeder Übergabe an nachgelagerte Prozesse.
• Gestalten Sie den Erstverkauf und den anschließenden Lebenszyklus gemeinsam; Vertragsänderungen und Verlängerungen sind keine Randfälle.
• Legen Sie die Verantwortlichkeiten für kaufmännische Abrechnung, operative Auftragsabwicklung und Buchhaltung ausdrücklich fest.

Eine ergänzende Fallstudie zur Datensynchronisierung zwischen Salesforce und SAP zeigt, warum aktuelle ERP-Daten und verlässliche Verantwortlichkeiten Voraussetzungen für die Automatisierung nachgelagerter Prozesse sind.

Die Implementierung funktionierte als einheitliche Umsatzarchitektur: Die Produktmodellierung bestimmte die Konfiguration, die Konfiguration bestimmte die Preisgestaltung, das Angebot bestimmte Auftrag und Auftragsabwicklung, die Abrechnung folgte den kaufmännischen Konditionen und Meilensteinen, und Kunden-Assets bildeten die Grundlage für jede spätere Änderung.