SAP Sales Cloud V2 Implementierung: Spadooms Projektmethodik für den DACH-Raum

Die häufigste Frage zu Beginn eines Sales Cloud V2 Projekts gilt nicht der Software. Sie lautet: Wie führt ihr das Projekt?

Das ist die richtige Frage. Eine SAP Sales Cloud V2 Implementierung ist technisch nicht so komplex wie ein grosses S/4HANA-Rollout. Die Plattform ist cloud-nativ, die Konfigurationsoberflächen sind gut dokumentiert, und für die meisten DACH-Enterprise-Integrationsszenarien gibt es vorgefertigten Content in SAP Integration Suite. Die Herausforderung ist nicht die Technologie, sondern die Entscheidungsqualität und das Change Management.

Dieser Beitrag beschreibt, wie Spadoom SAP Sales Cloud V2 Projekte im DACH-Raum strukturiert: was in jeder Phase passiert, welche Entscheidungen vor dem Beginn der nächsten Phase getroffen sein müssen, welche Integrationsmuster wir verwenden und wie die realistischen Zeitpläne aussehen. Er ist aus der Architektur- und Delivery-Perspektive geschrieben, nicht als Verkaufspräsentation.

Warum die Methodik das Ergebnis bestimmt

Jede Sales Cloud V2 Implementierung, die wir übernommen haben, weil ein früherer Partner gescheitert war oder der Kunde gestartet und pausiert hatte, litt an einem von drei Problemen.

Das erste Problem ist Konfiguration, die den tatsächlichen Vertriebsprozess nicht abbildet. Jemand hat die Pipeline-Stufen, die Opportunity-Felder und die Genehmigungsregeln auf Basis einer Vorlage oder einer Demo-Umgebung gebaut statt nach der tatsächlichen Arbeitsweise des Vertriebsteams. Das Ergebnis ist ein System, das mehr Arbeit verursacht, als es einspart.

Das zweite Problem ist die aufgeschobene S/4HANA-Integration. Das Projekt lieferte Sales Cloud V2 ohne die ERP-Verbindung, mit dem Plan, sie später nachzuliefern. Aus später wurde nie, weil die Integrationsarbeit nach dem Go-live nicht budgetiert oder beauftragt wurde und das Vertriebsteam Aufträge und Preise weiterhin direkt im ERP nachschlug.

Das dritte Problem ist fehlende Akzeptanz. Das Training fand einmal statt, zwei Wochen vor dem Go-live, und die First-Line-Manager setzten die Nutzung des neuen Systems nicht durch. Innerhalb von drei Monaten war die Dealdaten auf Sales Cloud V2 und E-Mail verteilt, und Pipeline-Reviews verloren ihren Wert.

Eine gute Methodik verhindert alle drei. Die nachfolgenden Phasen beschreiben, was wir tun und warum.

Phase 1: Discovery und Architekturdesign (Wochen 1 bis 2)

Die ersten zwei Wochen eines Sales Cloud V2 Projekts drehen sich nicht um Sales Cloud V2. Sie drehen sich um den Vertriebsprozess und die Integrationslandschaft.

Vertriebsprozess-Mapping. Wir führen strukturierte Workshops mit dem Vertriebsmanagement und einer Stichprobe von Vertriebsmitarbeitenden durch, um die tatsächliche Pipeline zu dokumentieren: wie Deals entstehen, wie sie vorankommen, welche Informationen in jeder Stufe erfasst werden, wo der Prozess heute stockt und welche Reports das Management zur Steuerung des Geschäfts nutzt. Das Ergebnis ist ein dokumentierter Vertriebsprozess, den die Konfiguration abbildet, kein SAP-Standardprozess, an den das Vertriebsteam sich anpassen soll.

Integrationslandschaft-Assessment. Wir kartieren jedes System, mit dem Sales Cloud V2 verbunden werden muss. Im DACH-Kontext ist das typischerweise S/4HANA oder SAP ECC (Kundenstamm, Auftragshistorie, Preisfindung), manchmal ein CPQ-System, eine Marketing-Automation-Plattform (SAP Engagement Cloud oder ein Drittanbieter-Tool) und ein Telefonie-System für CTI. Wir dokumentieren den Integrationsumfang, das führende Datensystem für jeden Objekttyp und den Datenqualitätsstatus der S/4HANA-Stammdaten.

Architecture Decision Record. Bevor das Projekt Phase 1 verlässt, erstellen wir einen einseitigen Architecture Decision Record, der das Projekt auf bestimmte Entscheidungen festlegt: welches System die führende Quelle für Kundendatensätze ist, welche Objekte repliziert werden gegenüber solchen, die bei Bedarf gelesen werden, wie Konflikte zwischen CRM- und ERP-Daten aufgelöst werden und welche Integrationsmuster für jede Anbindung verwendet werden. Dieses Dokument wird vom Projektsponsor des Kunden gezeichnet. Änderungen daran nach Phase 1 werden als Umfangsänderungen behandelt.

Phase 2: Basiskonfiguration (Wochen 2 bis 6)

Die Konfigurationsphase baut das Kernsystem auf Basis des in Phase 1 erstellten Vertriebsprozessmodells auf.

Organisationsstruktur. Die Vertriebsorganisationshierarchie wird definiert: Unternehmen, Vertriebsbereiche, Teams und einzelne Nutzer. Diese entspricht der Vertriebsorganisationsstruktur in S/4HANA und bestimmt, wie Daten gefiltert und berichtet werden. Das Organisationsmodell muss stimmen, bevor irgendetwas anderes konfiguriert wird; eine Änderung mittendrin zieht sich durch Routing, Zugriffskontrolle und Reporting.

Pipeline und Opportunity-Konfiguration. Die Pipeline-Stufen werden aus dem dokumentierten Vertriebsprozess gebaut. Felder, die bei jedem Stufenwechsel erforderlich sind, Pflichtfelder für die Deal-Anlage und das Feldlayout für die mobilen und Desktop-Ansichten werden festgelegt. Zwei oder drei Vertriebsmitarbeitende sollten die Konfiguration vor dem nächsten Sprint prüfen; damit werden Usability-Probleme erkannt, bevor das Training beginnt.

Nutzerrollen und Zugriff. Das Rollenmodell wird konfiguriert: Vertriebsmitarbeitende, Vertriebsleiter, Business Development, Administratoren. Es wird definiert, was jede Rolle sehen, anlegen, bearbeiten und genehmigen kann. Bei DACH-Unternehmen sind die Genehmigungsregeln für Rabatte und Sonderkonditionen oft komplex; sie werden dokumentiert, bevor sie konfiguriert werden, und jedes Genehmigungsszenario wird getestet.

E-Mail- und Aktivitätenintegration. Die Microsoft-Outlook- oder Google-Workspace-Integration wird so konfiguriert, dass E-Mails und Kalendereinträge automatisch dem relevanten Konto, Kontakt oder der Opportunity zugeordnet werden. Diese Funktion hat den grössten Adoptionsimpakt in Sales Cloud V2: Wenn Mitarbeitende in Outlook bleiben können und ihre Kommunikation automatisch erfasst wird, löst sich das Datenvollständigkeitsproblem nahezu von selbst.

Phase 3: S/4HANA-Integration (parallel zu Phase 2)

Die Integrationsarbeit läuft parallel zur Konfiguration, nicht danach. Einen späten Integrationsstart ist die häufigste Ursache für Projektverzögerungen bei DACH-Sales-Cloud-V2-Projekten.

Business-Partner-Replikation. Die erste Integration ist die Kunden- und Kontaktreplikation von S/4HANA nach Sales Cloud V2 via SAP Integration Suite. Sie liefert die Konto- und Kontaktstammdaten, von denen jede weitere Integration abhängt. Typische Probleme: Kunden mit mehreren Geschäftspartnerrollen in S/4HANA, die vor der Replikation zusammengefasst oder gefiltert werden müssen; Ansprechpartner, die nicht einheitlich an Konten geknüpft sind; und Adressdatenqualitätsprobleme, die erst beim Start der Replikation sichtbar werden.

Auftragshistorie und Pipeline-Kontext. Vertriebliche Key Account Manager müssen offene und aktuelle Aufträge neben der Pipeline sehen. Die Standardintegration stellt Kundenauftragsdaten in der Kontound Opportunity-Ansicht als schreibgeschützten Kontext aus S/4HANA bereit. Das erfordert keine kundenspezifische Entwicklung; es verwendet den vorgefertigten Integration-Content aus SAP Integration Suite. Der Konfigurationsaufwand liegt im Feldmapping und im Datenerneuerungsintervall.

Quote-to-Order-Ablauf (wenn SAP CPQ im Scope ist). Wenn das Projekt SAP Configure, Price, Quote umfasst, löst das genehmigte Angebot in Sales Cloud die Anlage eines Kundenauftrags in S/4HANA aus. Diese Integration ist die technisch komplexeste in einem typischen Sales Cloud V2 Projekt. Wir führen sie als separaten Integrationssprint durch, testen sie mit mindestens 20 repräsentativen Angebotsszenarien und beziehen sie nicht in den Haupt-Go-live ein, solange sie nicht vollständig und stabil ist.

Preisabfragen. Vertriebsmitarbeitende in DACH-B2B-Unternehmen benötigen kundenspezifische Preise, um Opportunities zu qualifizieren und informelle Angebote vor der CPQ-Phase zu erstellen. Die Standardintegration kann Listenpreise aus dem S/4HANA-Produktstamm anzeigen. Kundenspezifische Preise aus Konditionen erfordern entweder eine Echtzeit-Integrationsabfrage oder eine regelmässig aktualisierte Preisliste in Sales Cloud V2. Beide Muster funktionieren; die Wahl hängt von der Preislistenvolatilität und der akzeptablen Datenaktualität ab.

Phase 4: User Acceptance Testing und Training (Wochen 6 bis 8)

Testing und Training finden zusammen statt, nicht nacheinander. Die Vertriebsmitarbeitenden, die das System täglich nutzen werden, sollten am Testing beteiligt sein; das ist der wirksamste Adoptionshebel.

Strukturiertes UAT. User Acceptance Testing wird mit einer benannten Gruppe von 5 bis 10 Vertriebsmitarbeitenden aus verschiedenen Teams und Rollen durchgeführt. Sie erhalten ein Testskript, das jedes wichtige Szenario abdeckt: einen Lead anlegen, eine Opportunity qualifizieren, die Pipeline durchlaufen, einen Anruf erfassen, ein Angebot erstellen und einen Auftrag in S/4HANA nachschlagen. Jedes Problem wird als Ticket erfasst; es wird gelöst, bevor das Go-live-Datum festgelegt wird.

Rollenbasiertes Training. Vertriebsmitarbeitende, Vertriebsleiter und Administratoren werden getrennt trainiert. Das Training für Mitarbeitende deckt die täglichen Workflows ab. Das Managementtraining deckt Pipeline-Reviews, Coaching-Markierungen und Reporting ab. Das Administratorentraining deckt die Nutzerverwaltung, Routing-Regeln und einfache Konfigurationsänderungen ab. Im mehrsprachigen DACH-Kontext wird das Training in jeder Sprache durchgeführt oder übersetzte Trainingsunterlagen werden bereitgestellt; deutschsprachige Unterlagen funktionieren nicht für französischsprachige Teams in Genf.

First-Line-Manager-Aktivierung. Das ist kein Trainingsthema; es ist eine Change-Management-Aufgabe. First-Line-Manager müssen sich verpflichten, Pipeline-Reviews vor dem Go-live in Sales Cloud V2 durchzuführen, nicht neben E-Mail-Threads oder Tabellen. Wenn Manager den neuen Prozess in den ersten 30 Tagen nicht durchsetzen, stagniert die Adoption. Wir adressieren dies explizit in Phase 1 und erneut in der Trainingsphase.

Phase 5: Go-live und Hypercare (Wochen 8 bis 10, dann 4 Wochen Hypercare)

Go-live Readiness Check. Vor dem Go-live wird verifiziert: Alle Nutzer sind provisioniert und können sich einloggen; die Outlook-Integration funktioniert für mindestens zwei repräsentative Konten; die S/4HANA-Integration überträgt Daten für eine Stichprobe echter Konten; alle offenen Opportunities aus dem Altsystem sind migriert oder werden neu angelegt; und die First-Line-Manager haben sich verpflichtet, ihre Pipeline-Reviews in Sales Cloud V2 am Go-live-Tag zu beginnen.

Datenmigration. Offene Opportunities aus dem bisherigen CRM oder aus Tabellen werden migriert. Geschlossene und verlorene Opportunities müssen in der Regel nicht migriert werden; historische Pipeline-Daten können im Altsystem als schreibgeschütztes Archiv verbleiben. Der Migrationsumfang sollte definiert und vereinbart sein, bevor die UAT-Phase beginnt; kurzfristige Umfangserweiterungen bei der Migration sind ein häufiges Go-live-Risiko.

Hypercare. Für die ersten vier Wochen nach dem Go-live steht eine Spadoom-Beraterin oder ein Spadoom-Berater für tägliche Check-ins und schnelle Problemlösung zur Verfügung. Die häufigsten Hypercare-Probleme bei DACH-Sales-Cloud-V2-Projekten: Routing-Regeln, die sich bei vollständiger Nutzerlast anders verhalten als beim Testen; S/4HANA-Integrationsfehler bei bestimmten Konto- oder Auftragsszenarien, die nicht im Testskript enthalten waren; und Nutzeranfragen zur Änderung von Feldbezeichnungen oder Listeneinträgen, die legitim sind und zeitnah bearbeitet werden sollten, um die Adoptionsdynamik aufrechtzuerhalten.

Der Fall Nussbaum: 5 Monate bis zur vollständigen Pipeline-Transparenz

Das Projekt Nussbaum Matzingen ist eine unserer veröffentlichten Sales Cloud V2 Referenzen für den DACH-Fertigungssektor. Das Engagement umfasste den gesamten Stack: drei Datenquellen, die auf einer einzigen Vertriebsplattform konsolidiert wurden, Spadoom Engage CTI für eingehende und ausgehende Telefonie sowie ein KI-Lead-Service für die Lead-Qualifizierung.

Das Ergebnis war ein Go-live in fünf Monaten, mit vollständiger Pipeline-Transparenz vom ersten Tag an und hoher Effizienz für das Vertriebsteam. Der Marketingleiter des Kunden bezeichnete es als Quantensprung in der Arbeitsweise des Teams.

Was das Projekt erfolgreich machte: ein einziger benannter Verantwortlicher auf Kundenseite mit Entscheidungsbefugnis, ein sauberer Datenmigrations-Plan, der in Phase 1 vereinbart wurde, und First-Line-Manager, die ihren ersten Pipeline-Review in Sales Cloud V2 am Montag nach dem Go-live durchführten. Die Technologie war nicht der Unterschied. Die Projektdisziplin war es.

Den vollständigen Case lesen Sie auf der Nussbaum Success-Story-Seite.

Was DACH-Sales-Cloud-V2-Projekte unterscheidet

Drei Dinge unterscheiden DACH-Implementierungen konsequent von generischen Sales Cloud V2 Rollouts.

Mehrsprachige Konfiguration. Ein Schweizer Unternehmen, das Kunden in deutsch-, französisch- und italienischsprachigen Regionen bedient, benötigt Feldbezeichnungen, Auswahllistenwerte, E-Mail-Vorlagen und Trainingsunterlagen in allen drei Sprachen. Das ist keine Übersetzungsaufgabe; sie erfordert sprachbewusste Konfigurationsentscheidungen in der gesamten Phase 2 und einen klaren Verantwortlichen für die Übersetzungsqualität in jeder Sprache.

Stärkere ERP-Kopplungserwartungen. DACH-B2B-Unternehmen erwarten, dass das CRM die ERP-Realität abbildet: Preise, Auftragsstatus und Kreditlimits sollten aktuell sein. Die Standardintegrationsmuster liefern das, aber die Datenqualitätsarbeit in S/4HANA, also das Bereinigen von Kundenstammsätzen, die Rationalisierung von Konditionssätzen, die Auflösung doppelter Geschäftspartner, muss vor der Aktivierung der Integration stattfinden. Diese Datenvorbereitung ist im initialen Projektumfang oft nicht budgetiert.

Change Management in einer konsensuellen Kultur. DACH-Organisationen neigen dazu, mehr Stakeholder in Toolentscheidungen einzubeziehen und mehr Abstimmung vor Änderungen zu erwarten. Das ist keine Kritik; es bedeutet, dass der Change-Management-Plan mehr Kalenderzeit und mehr sichtbar beteiligte Executive Sponsors benötigt. Das sollte in den Projektzeitplan eingeplant werden, nicht als Nice-to-have.

Mit Spadoom an Sales Cloud V2 arbeiten

Wir betreiben Sales Cloud V2 in unserem eigenen Vertrieb und tun das seit Anfang 2026. Das bedeutet, wir kennen das Produkt von innen, auch dort, wo die scharfen Kanten sind und welche Konfigurationsentscheidungen später bereut werden.

Wenn Sie eine Sales Cloud V2 Implementierung für Ihre DACH-Organisation planen, beginnt das Gespräch in der Regel mit dem Vertriebsprozess-Mapping, nicht mit einer Demo. Wir führen einen eintägigen Discovery-Workshop durch, um den Architecture Decision Record und einen realistischen Projektumfang zu erstellen. Danach folgen Projektplan und kommerzielles Angebot innerhalb einer Woche.

Die SAP Sales Cloud V2 Lösungsseite hat unsere Kontaktmöglichkeit für Vertriebsthemen vorausgefüllt.