Jede zweite Salesforce-Implementierung wird teurer als geplant. Nicht wegen der Technik, sondern wegen fehlendem Prozess. Kein klares Discovery, kein sauberes Gate vor der Konfiguration, kein definierter Punkt, an dem alle sagen: Ja, das ist bereit für Go-Live.
Ich setze bei meinen Salesforce-Projekten auf ein Stage-Gate-Modell. Nicht als theoretisches Framework, sondern als konkreten Fahrplan mit sechs Phasen und klaren Entscheidungspunkten dazwischen. Das Ergebnis: weniger Nacharbeit, weniger Scope Creep und Kunden, die genau wissen, wo ihr Projekt steht.
In diesem Artikel zeige ich Ihnen, wie dieses Template aussieht und warum es Ihre Salesforce-Implementierung vorhersehbarer macht.
Sechs Stages, sechs Gates: Der Fahrplan
Das Stage-Gate-Modell teilt Ihr Salesforce-Projekt in klar definierte Phasen auf. Nach jeder Phase gibt es ein Gate: einen Entscheidungspunkt, an dem geprüft wird, ob alle Voraussetzungen für den nächsten Schritt erfüllt sind. Kein Gate bestanden? Kein Weitermachen.
Die sechs Stages:
- Discovery - Anforderungen und Ist-Zustand verstehen
- Solution Design - Architektur und Datenmodell definieren
- Configuration & Build - Salesforce konfigurieren und entwickeln
- Data Migration - Daten bereinigen, mappen und migrieren
- UAT & Training - Testen und Anwender schulen
- Go-Live & Hypercare - Live-Schaltung und Nachbetreuung
Jede Stage hat definierte Deliverables. Jedes Gate hat Kriterien, die erfüllt sein müssen. Das klingt formell, spart aber in der Praxis enorm viel Reibung.
Stage 1: Discovery
Die Discovery-Phase ist die wichtigste und wird trotzdem am häufigsten abgekürzt. Hier entscheidet sich, ob der Rest des Projekts auf einem soliden Fundament steht oder auf Annahmen.
Was in der Discovery passiert:
- Stakeholder-Interviews: Wer arbeitet mit Salesforce? Was sind die echten Pain Points? Nicht die, die im Anforderungsdokument stehen, sondern die, die im Arbeitsalltag nerven.
- Prozessaufnahme: Bestehende Geschäftsprozesse dokumentieren. Lead-to-Cash, Service-Prozesse, Reporting-Anforderungen. Am besten visuell.
- Datenlandschaft: Welche Systeme gibt es? Wo liegen die Daten? Welche Datenqualität erwartet Sie bei der Migration?
- Scope-Definition: Was ist in Scope, was ist explizit out of Scope? Schriftlich. Unterschrieben.
Gate 1: Discovery Sign-Off
Kriterien für das Bestehen:
- Anforderungsdokument vom Kunden abgenommen
- Datenquellen identifiziert und Zugänge geklärt
- Scope-Dokument unterschrieben
- Projektteam und Rollen definiert
- Realistischer Zeitplan abgestimmt
Erst wenn alle Punkte abgehakt sind, geht es weiter. Kein "Ach, das klären wir dann in der nächsten Phase". Das ist der häufigste Fehler.
Stage 2: Solution Design
Jetzt wird aus den Anforderungen eine technische Lösung. Das Solution Design ist die Brücke zwischen dem, was der Kunde will, und dem, was Salesforce kann.
- Datenmodell: Custom Objects, Felder, Beziehungen. Welche Standard-Objekte nutzen Sie, wo brauchen Sie Custom Objects?
- Automatisierungen: Welche Prozesse lassen sich mit Flows abbilden? Wo brauchen Sie Apex?
- Integrationen: Welche Drittsysteme müssen angebunden werden? API-Limits? Echtzeit oder Batch?
- Security-Konzept: Profiles, Permission Sets, Sharing Rules. Wer darf was sehen und bearbeiten?
- UI/UX: Page Layouts, Lightning App Builder, Record Types. Die Oberfläche muss zum Prozess passen, nicht umgekehrt.
Gate 2: Design-Freigabe
Kriterien:
- Solution-Design-Dokument vom Kunden reviewt und freigegeben
- Datenmodell dokumentiert
- Integrations-Architektur definiert
- Security-Konzept verabschiedet
- Keine offenen Fragen mehr im Anforderungskatalog
Stage 3: Configuration & Build
Hier wird gebaut. Aber nicht einfach drauflos, sondern nach dem freigegebenen Design. Diese Phase ist bei Salesforce-Projekten oft die längste und die, in der Scope Creep am gefährlichsten ist.
- Deklarative Konfiguration: Alles, was ohne Code geht: Flows, Validation Rules, Formula Fields, Page Layouts, Reports & Dashboards.
- Apex-Entwicklung: Nur wo Clicks nicht reichen. Trigger, Batch Jobs, Custom APIs. Immer mit Unit Tests.
- Sandbox-Strategie: Dev Sandbox für die Entwicklung, Partial Copy oder Full Sandbox für Tests. Niemals direkt in Production bauen.
- Wöchentliche Demos: Zeigen Sie dem Kunden regelmäßig, was gebaut wurde. Kein Big-Bang nach sechs Wochen.
Gate 3: Build-Abnahme
Kriterien:
- Alle Anforderungen aus dem Solution Design umgesetzt
- Unit Tests bestanden (mindestens 75% Code Coverage bei Apex)
- Konfiguration in der Sandbox vom Kunden gesichtet
- Deployment-Plan für die Migration in die nächste Sandbox erstellt
- Keine kritischen Bugs offen
Stage 4: Data Migration
Datenmigration ist der Teil, der in Salesforce-Projekten am häufigsten unterschätzt wird. Datenqualität im Altsystem ist fast immer schlechter als angenommen. Duplikate, fehlende Pflichtfelder, inkonsistente Formate.
- Daten-Audit: Analysieren Sie die Quelldaten. Wie viele Datensätze? Wie viele Duplikate? Welche Felder sind leer?
- Mapping: Jedes Feld im Altsystem muss einem Feld in Salesforce zugeordnet werden. Dokumentieren Sie Transformationsregeln.
- Bereinigung: Duplikate entfernen, Formate standardisieren, fehlende Daten ergänzen. Das ist Arbeit des Kunden, nicht des Beraters.
- Testmigration: Mindestens zwei Testläufe in der Sandbox, bevor Sie an Production denken. Prüfen Sie Beziehungen, Lookups und Record Counts.
- Tools: Data Loader für einfache Migrationen. Für komplexe Szenarien: Informatica, Talend oder Custom Scripts.
Gate 4: Migrationsfreigabe
Kriterien:
- Testmigration erfolgreich abgeschlossen
- Datenqualität vom Kunden geprüft und akzeptiert
- Rollback-Plan vorhanden
- Migrationsreihenfolge definiert (Accounts vor Contacts vor Opportunities)
- Zeitfenster für die Live-Migration abgestimmt
Stage 5: UAT & Training
User Acceptance Testing ist der Moment der Wahrheit. Hier testen nicht die Entwickler, sondern die zukünftigen Anwender. Wenn UAT sauber läuft, ist Go-Live kein Risiko mehr.
- Testfälle: Basierend auf den Anforderungen aus der Discovery. Jeder Geschäftsprozess muss mindestens einmal durchgespielt werden.
- Testdaten: Realistische Daten in der Sandbox, nicht fünf Dummy-Accounts.
- Bug-Tracking: Jeder Fehler wird dokumentiert, priorisiert und vor Go-Live behoben oder bewusst zurückgestellt.
- Training: Endanwender-Schulungen, Admin-Schulungen, Power-User-Schulungen. Unterschiedliche Zielgruppen brauchen unterschiedliche Inhalte.
- Dokumentation: Prozessdokumentation und Quick-Reference-Guides für die wichtigsten Workflows.
CRM-Checkliste für den Mittelstand Kostenlos
7 Punkte, die Sie vor jeder CRM-Entscheidung prüfen sollten. Kompakt, praxisnah, sofort anwendbar.
Gate 5: Go-Live-Freigabe
Das wichtigste Gate im gesamten Projekt:
- Alle kritischen und hohen Bugs behoben
- UAT-Protokoll vom Kunden unterschrieben
- Schulungen durchgeführt und bestätigt
- Produktions-Deployment getestet (via Change Set oder Metadata API)
- Kommunikationsplan für den Go-Live an alle Stakeholder versendet
- Support-Prozess für die Hypercare-Phase definiert
Stage 6: Go-Live & Hypercare
Go-Live ist kein Projektende. Es ist der Beginn der kritischsten zwei bis vier Wochen. Die Hypercare-Phase entscheidet, ob die Anwender Salesforce annehmen oder innerlich ablehnen.
- Go-Live-Tag: Datenmigration in Production, Feature-Aktivierung, DNS-Änderungen falls nötig. Am besten an einem Freitag oder Wochenende, wenn wenig Benutzeraktivität herrscht.
- Hypercare (2-4 Wochen): Tägliche Check-ins mit Key Usern. Schnelle Reaktion auf Probleme. Kleine Anpassungen, die den Alltag erleichtern.
- Monitoring: Login-Raten, Adoption-Metriken, Error Logs. Wenn niemand das System nutzt, ist das ein Problem, kein Feature.
- Feedback-Sammlung: Strukturiert Feedback einholen und priorisieren. Was davon ist Phase 2?
Gate 6: Projektabschluss
Kriterien:
- Hypercare-Phase ohne kritische Incidents abgeschlossen
- Übergabe an internen Admin oder Support-Team
- Lessons Learned dokumentiert
- Phase-2-Backlog priorisiert und übergeben
- Projektabschlussbericht erstellt
Warum dieses Template funktioniert
Ich habe genug Salesforce-Projekte gesehen, die ohne klare Struktur gestartet sind. Das Muster ist immer gleich: Am Anfang herrscht Euphorie, in der Mitte Chaos, und am Ende wird unter Zeitdruck ein System live geschaltet, das niemand richtig getestet hat.
Das Stage-Gate-Modell verhindert das, weil:
- Kein Überspringen möglich: Ohne Discovery-Freigabe keine Konfiguration. Ohne UAT-Abnahme kein Go-Live. Das klingt streng, schützt aber beide Seiten.
- Transparenz für den Kunden: Ihr Kunde weiß jederzeit, in welcher Phase das Projekt steckt und was als Nächstes passiert.
- Scope-Kontrolle: Neue Anforderungen werden dokumentiert und bewertet, statt stillschweigend in den Scope zu rutschen.
- Messbare Fortschritte: Jedes bestandene Gate ist ein konkreter Meilenstein, nicht ein vages "Wir sind zu 60% fertig".
Häufige Fragen
Wie lange dauert eine typische Salesforce-Implementierung mit diesem Modell?
Abhängig vom Scope: Eine Sales Cloud-Implementierung für ein mittelständisches Unternehmen dauert typischerweise 8-16 Wochen. Komplexere Projekte mit Service Cloud, Integrationen und Datenmigration können 4-6 Monate beanspruchen. Das Template skaliert mit der Projektgröße.
Ist das Stage-Gate-Modell nicht zu starr für agile Projekte?
Nein, wenn Sie es richtig einsetzen. Die Gates sind nicht-verhandelbar, aber innerhalb der Stages können Sie agil arbeiten. Sprints in der Build-Phase, iteratives Feedback im Solution Design. Das Modell gibt den Rahmen, nicht die Arbeitsweise innerhalb der Phasen.
Was kostet ein Salesforce-Projekt nach diesem Template?
Die ehrliche Antwort: Es hängt vom Scope ab. Aber das Template macht Kosten vorhersehbarer, weil jede Phase klar definierte Deliverables hat. Sie zahlen nicht für Stunden, sondern für Ergebnisse an jedem Gate.
Brauche ich als Kunde eigene Ressourcen für das Projekt?
Ja, zwingend. Sie brauchen mindestens einen internen Projektleiter, der Entscheidungen treffen kann, und Key User, die in Discovery, UAT und Training aktiv mitarbeiten. Ohne Kundenbeteiligung scheitert jedes CRM-Projekt.
Ihr nächstes Salesforce-Projekt mit Struktur
Ob Sie Salesforce neu einführen, eine bestehende Org optimieren oder von einem anderen CRM migrieren: Ein strukturierter Prozess macht den Unterschied zwischen einem Projekt, das im Budget bleibt, und einem, das eskaliert.
Ich nutze dieses Stage-Gate-Template in jedem meiner Salesforce-Projekte. Es gibt meinen Kunden Sicherheit, weil sie jederzeit wissen, wo wir stehen. Und es gibt mir die Kontrolle, Risiken früh zu erkennen und gegenzusteuern.
Wenn Sie eine Salesforce-Implementierung planen oder ein laufendes Projekt wieder auf Kurs bringen wollen, lassen Sie uns sprechen. Ich schaue mir Ihre Situation an und sage Ihnen ehrlich, was realistisch ist und was nicht.
