Salesforce Einführung: Checkliste für ein erfolgreiches Projekt

Die meisten Salesforce Projekte scheitern nicht an der Technik. Häufiger sind unklare Ziele, fehlende Entscheidungen, mangelnde Beteiligung der Fachbereiche, schlechte Datenqualität oder ein Go-live ohne ausreichende Schulung die Ursache. Salesforce ist eine leistungsfähige Plattform, aber sie bildet nur ab, was zuvor sauber definiert wurde. Eine strukturierte Vorbereitung ist daher der wichtigste Erfolgsfaktor einer Salesforce Einführung. Wer diese Grundlagen früh klärt, spart später Zeit, Budget und Nerven.

Diese Checkliste gliedert das Vorhaben in fünf Phasen: Vorbereitung und Zieldefinition, Konzeption und Architektur, Umsetzung, Datenmigration und Tests sowie Go-live und Betrieb. Die Phasen überlappen in der Praxis, besonders bei agilem Vorgehen, in dem Konzeption und Umsetzung in Sprints ineinandergreifen. Dennoch hilft die Gliederung, nichts Wesentliches zu übersehen und Verantwortlichkeiten frühzeitig zu klären. Jede Phase endet mit klaren Ergebnissen, die als Grundlage für die nächste dienen.

Ob Sie Salesforce erstmals einführen, ein Altsystem ablösen oder eine bestehende Org grundlegend neu aufsetzen: Die Punkte gelten sinngemäß für alle Vorhaben. Für kleine Projekte reicht eine schlanke Variante, große Programme brauchen zusätzliche Governance. Viele Unternehmen holen sich für die Salesforce Implementierung erfahrene Salesforce Experten ins Projektteam, um typische Fehler zu vermeiden und schneller produktiv zu werden. Nutzen Sie die Punkte als Prüfliste für Ihre eigene Planung.

Phase 1: Vorbereitung und Zieldefinition

Am Anfang steht die Frage nach dem Warum. Welche konkreten Probleme soll Salesforce lösen, und woran messen Sie den Erfolg? Formulieren Sie Ziele möglichst messbar, etwa eine verlässlichere Forecast-Genauigkeit, kürzere Reaktionszeiten im Service oder eine höhere Konversionsrate von Leads. Diese Ziele dienen später als Kompass für Priorisierungen und als Grundlage für die Erfolgsmessung nach dem Go-live.

Ebenso wichtig sind Rollen und Ressourcen. Ein Sponsor aus der Geschäftsleitung sichert Rückhalt und trifft Grundsatzentscheidungen. Ein fachlicher Product Owner verantwortet Anforderungen und Prioritäten. Key User aus den betroffenen Abteilungen bringen Praxiswissen ein und werden später zu Multiplikatoren. Planen Sie realistisch ein, wie viel Zeit diese Personen neben dem Tagesgeschäft für das Projekt aufbringen können.

• Messbare Ziele und Erfolgskennzahlen definiert
• Projektumfang für den ersten Release abgegrenzt
• Sponsor, Product Owner und Key User benannt
• Budget für Lizenzen, Projekt und Betrieb geplant
• Entscheidung über interne Ressourcen und externe Unterstützung

Phase 2: Konzeption und Architektur

In der Konzeption werden die Soll-Prozesse beschrieben und auf Salesforce übertragen. Orientieren Sie sich dabei möglichst am Standard der Plattform und hinterfragen Sie Sonderwege kritisch. Jede Abweichung vom Standard erhöht Projekt- und Wartungsaufwand. Parallel entsteht das Datenmodell: Welche Objekte, Felder und Beziehungen werden benötigt, welche Daten sind Pflicht, und welches System ist für welche Daten führend?

Eine tragfähige Lösungsarchitektur betrachtet zudem Berechtigungen, Integrationen, Datenschutz und Skalierung. Wer darf welche Daten sehen? Welche Systeme werden wie angebunden? Welche Edition und welche Zusatzprodukte sind erforderlich? Wie werden Entwicklungen über Sandboxes bis in die Produktion gebracht? Diese Fragen früh zu klären, verhindert teure Umbauten und schafft die Basis für eine Org, die über Jahre gesund bleibt.

• Soll-Prozesse mit Fokus auf Salesforce Standard beschrieben
• Datenmodell und Systemführerschaft festgelegt
• Rollen- und Berechtigungskonzept erstellt
• Integrationsarchitektur und Schnittstellen definiert
• DSGVO-Anforderungen und Löschkonzept berücksichtigt
• Entwicklungs- und Deployment-Prozess über Sandboxes geplant

Phase 3: Umsetzung in Iterationen

Die Umsetzung erfolgt idealerweise iterativ in Sprints von zwei bis vier Wochen. Am Ende jedes Sprints steht eine Demo im echten System, in der Key User die Ergebnisse prüfen und Feedback geben. So werden Missverständnisse früh sichtbar, und die Fachbereiche erleben das neue System bereits während des Projekts. Das erhöht die Akzeptanz erheblich und reduziert Überraschungen kurz vor dem Go-live.

Achten Sie in dieser Phase auf saubere Arbeitsweisen: Konfigurationen werden dokumentiert, Automatisierungen konsistent mit Flow umgesetzt, Code nach Standards entwickelt und versioniert. Ein Backlog mit klaren Prioritäten hilft, den Umfang im Griff zu behalten. Neue Wünsche sind willkommen, sollten aber bewusst priorisiert und gegebenenfalls auf einen späteren Release verschoben werden, statt den Zeitplan zu gefährden.

• Sprints mit Demos und Feedback der Key User
• Priorisiertes Backlog und bewusstes Scope-Management
• Dokumentation von Konfigurationen und Automatisierungen
• Versionierung und DevOps-Prozess für Deployments

Phase 4: Datenmigration und Tests

Die Datenmigration wird häufig unterschätzt. Altdaten enthalten Dubletten, veraltete Einträge und uneinheitliche Formate. Beginnen Sie früh mit einer Analyse der Datenqualität und entscheiden Sie bewusst, welche Daten überhaupt übernommen werden. Ein sauberes Mapping auf das neue Datenmodell, mehrere Testmigrationen und eine fachliche Prüfung der Ergebnisse sind unverzichtbar. Ein CRM mit schlechten Daten verliert schnell das Vertrauen der Nutzer.

Parallel laufen die Tests. Neben technischen Tests der Entwickler sind fachliche Abnahmetests entscheidend, in denen Key User reale Szenarien durchspielen: einen Lead qualifizieren, ein Angebot erstellen, einen Service-Fall eskalieren. Testen Sie auch Berechtigungen aus Sicht unterschiedlicher Rollen und Integrationen mit realistischen Datenmengen. Fehler, die hier gefunden werden, sind deutlich günstiger zu beheben als nach dem Go-live.

• Datenqualität analysiert und Altdaten bereinigt
• Mapping und Migrationsregeln dokumentiert
• Mindestens zwei Testmigrationen durchgeführt
• Fachliche Abnahmetests mit realen Szenarien
• Berechtigungen und Integrationen unter Last getestet

Phase 5: Go-live, Adoption und Betrieb

Ein erfolgreicher Go-live braucht einen detaillierten Cut-over-Plan: Wann wird das Altsystem eingefroren, wann erfolgt die finale Migration, wer prüft die Daten, und wann wird freigegeben? Schulungen sollten kurz vor dem Start stattfinden, rollenbezogen sein und mit echten Anwendungsfällen arbeiten. In den ersten Wochen nach dem Go-live, der Hypercare-Phase, stehen Projektteam und Key User für Fragen und schnelle Korrekturen bereit.

Nach dem Go-live beginnt der eigentliche Wertbeitrag. Messen Sie Nutzung und Zielkennzahlen, sammeln Sie Feedback und entwickeln Sie das System in regelmäßigen Releases weiter. Planen Sie Ressourcen für Administration und Weiterentwicklung ein und testen Sie die drei jährlichen Salesforce Releases. SALESFOUR stellt Ihnen in jeder Phase erfahrene Salesforce Berater bereit, flexibel vom einzelnen Experten bis zum kompletten Projektteam.

• Cut-over-Plan mit Verantwortlichkeiten und Rückfalloption
• Rollenbezogene Schulungen kurz vor dem Start
• Hypercare-Phase mit schneller Reaktionszeit
• Adoption- und Zielkennzahlen regelmäßig messen
• Roadmap für weitere Releases und Ausbaustufen

Praxisbeispiele

1. Ein Mittelständler löst ein veraltetes CRM ab und startet mit einem klar abgegrenzten Vertriebsprozess als erstem Release.
2. Ein Serviceunternehmen führt die Service Cloud in drei Releases ein, beginnend mit Case-Management und Service Console.
3. Ein Konzern setzt eine historisch gewachsene Org neu auf und nutzt die Checkliste als Leitfaden für Governance und Architektur.
4. Ein Projektteam reduziert Risiken, indem es zwei vollständige Testmigrationen vor dem Go-live durchführt.
5. Ein Unternehmen misst nach dem Go-live Nutzung und Zielkennzahlen und priorisiert danach die nächsten Ausbaustufen.

Häufige Fragen