Warum Multi-Org-Architekturen scheitern

Jeder Salesforce-Architekt hat den Satz schon gehört: „Wir brauchen getrennte Orgs für die einzelnen Business Units.“ Klingt logisch: saubere Grenzen, unabhängige Teams, keine gegenseitigen Störungen. Sechs Monate später fragt die Geschäftsführung, warum sie keine einheitliche Sicht auf die Pipeline bekommt.

Die Multi-Org-Strategie ist verführerisch. Sie verspricht Autonomie, Sicherheit und eine saubere Trennung der Zuständigkeiten. In der Praxis erzeugt sie Dateninseln, die eure Revenue Operations torpedieren.

Das Versprechen

Wenn Unternehmen sich auf mehrere Salesforce-Orgs aufteilen, klingt die Begründung meistens so:

• Unterschiedliche Geschäftsmodelle brauchen unterschiedliche Datenstrukturen
• Regionale Compliance verlangt Data Residency
• Zukäufe bringen ihre eigenen bestehenden Instanzen mit
• Teams wollen Kontrolle ohne IT-Bürokratie

Das sind reale Anliegen. Aber die „Lösung“ schafft oft größere Probleme, als sie löst.

Die Realität

Wir haben kürzlich mit einem PE-finanzierten Softwareunternehmen gearbeitet, das vier separate Salesforce-Orgs betrieb, eine pro Regionalteam. Jeder GM wollte Autonomie. Jedes Team baute seine eigenen Prozesse.

Der CEO konnte einfachste Fragen nicht beantworten: „Wie hoch ist unsere Gesamtpipeline über alle Regionen?“

Für die Antwort brauchte es vier separate Report-Exporte, das manuelle Zusammenführen in Excel und die Hoffnung, dass niemand doppelte Account-Namen angelegt hatte. Bis der CFO eine Zahl hatte, war sie drei Wochen alt.

„Wenn eure Geschäftsführung in Excel lebt statt in Salesforce, ist eure Architektur gescheitert.“

Der Sync-Albtraum

Manche Teams versuchen, das mit Middleware zu lösen. Sie bauen Integrationsschichten, um Daten zwischen den Orgs zu synchronisieren. Aber Syncen ist nicht simpel:

• Die Account-Matching-Logik bricht. Ist „Apple Inc.“ dasselbe wie „Apple Computer“? Euer Sync-Tool weiß es nicht.
• Ownership-Konflikte entstehen. Wem gehört der Kunde, wenn er sich über mehrere Regionen erstreckt?
• Echtzeit wird unmöglich. Bis die Daten synchronisiert sind, ist der Deal längst eine Stage weiter.

Ein Kunde zahlte 180.000 $ pro Jahr allein an Lizenzen für die Integrationsplattform, damit seine drei Orgs überhaupt miteinander reden. Der Sync fiel jede zweite Woche aus.

Der Weg zur Konsolidierung

Der Weg dorthin ist nicht einfach, aber er lohnt sich. Konsolidierungsprojekte bestehen typischerweise aus:

1. Daten-Audit und Deduplizierung

Accounts über die Orgs hinweg zusammenführen, Dubletten auflösen, eine einzige Quelle der Wahrheit etablieren.

2. Prozessharmonisierung

Gemeinsame Workflows identifizieren, org-spezifische Anpassungen abschalten, die keinen Mehrwert bringen.

3. Record-Type-Strategie

Record Types und Page Layouts nutzen, um notwendige Unterschiede abzubilden, ohne dafür getrennte Orgs zu brauchen.

4. Migration in Phasen

Eine Business Unit nach der anderen umziehen, um Störungen zu minimieren und den ROI schrittweise zu belegen.

Und das Ergebnis? Ein Kunde ging von vier Orgs auf eine und verbesserte seine Forecast-Genauigkeit innerhalb von zwei Quartalen von 62 % auf 89 %.