Salesforce Implementierung: Kosten, Zeitplan, Risiken

Eine Salesforce Implementierung wird als Lizenzposten genehmigt und als Programm geliefert. Der Lizenzposten ist öffentlich, pro Nutzer, pro Monat, und in einer Vorstandsvorlage leicht zu verteidigen. Alles, was aus diesen Lizenzen ein System macht, das jemand tatsächlich benutzt, steht außerhalb davon, und genau dieser Teil entscheidet, ob die Zahl im Business Case das erste Quartal überlebt.

Salesforce veröffentlicht die britischen Preise in Pfund. Sales Cloud Enterprise kostet £140 pro Nutzer und Monat bei jährlicher Abrechnung, Unlimited kostet £280. Fünfzig Enterprise Nutzer sind £84.000 im Jahr, bevor auch nur ein einziges Feld konfiguriert wurde. Unsere Hausschätzung für die Dienstleistungen, die diese Org in Produktion bringen, liegt beim Ein- bis Dreifachen der Lizenzausgaben des ersten Jahres, und die Position innerhalb dieser Spanne ist nicht zufällig. Vier Dinge bewegen sie, und nur eines davon ist technisch.

Das wichtigste Wort im Folgenden ist Adoption, denn ein technisch korrektes System, das niemand benutzt, ist kein Teilerfolg. Es ist ein Totalverlust mit angehängter Wartungsrechnung.

Was kostet eine Salesforce Implementierung? Die Lizenz ist meist die kleinere Hälfte. Salesforce führt Sales Cloud Enterprise in Großbritannien mit £140 pro Nutzer und Monat, fünfzig Nutzer ergeben also £84.000 im Jahr, und unsere Hausschätzung für die Implementierungsleistungen obendrauf liegt beim Ein- bis Dreifachen dieser Lizenzausgaben des ersten Jahres. Der Multiplikator hängt an der Zahl der angebundenen Systeme, am Zustand der Quelldaten, am Grad der Prozessanpassung und daran, ob die Organisation ihren Prozess an das Produkt anpasst.

Was eine Salesforce Implementierung tatsächlich umfasst

Ein Salesforce Programm hat sechs Kostenpositionen, und nur eine davon steht auf einer Preisseite.

Die erste ist die Lizenz, pro Nutzer und pro Monat, veröffentlicht. Die zweite sind die Implementierungsleistungen: die Beraterinnen und Entwickler, die die Org konfigurieren, bauen, was Konfiguration nicht kann, und das Projekt führen. Die dritte ist die Datenmigration, im Angebot als Aufgabe innerhalb der Implementierung geschnitten und im Verlauf ein eigenes Projekt. Die vierte ist die Integration, also die Anbindung von Salesforce an die Systeme, die Ihre Daten bereits halten. Die fünfte sind Schulung und Change Management. Die sechste ist der laufende Betrieb der Org, der in keinem Business Case auftaucht, weil er beginnt, wenn jede andere Rechnung bezahlt ist.

Ein Business Case, der nur die Lizenz nennt, liegt nicht knapp daneben. Er liegt üblicherweise um den Faktor zwei bis vier daneben, und die Lücke steckt fast vollständig in den Positionen drei, fünf und sechs.

Die Lizenz ist die kleine Zahl

Die britische Sales Cloud Preisliste von Salesforce ist öffentlich und in Pfund ausgewiesen.

Die Starter Suite kostet £20 pro Nutzer und Monat. Pro Suite kostet £80 bei jährlicher Abrechnung. Enterprise, die Edition, bei der die meisten britischen Mittelstandskunden landen, weil sie die erste Stufe mit Web-API ist, kostet £140. Unlimited kostet £280 und enthält eine Full Sandbox sowie den Premier Success Plan. Agentforce 1 Sales liegt bei £440. Einzeln gekauft wird der Premier Success Plan mit 30% der Netto-Lizenzgebühren berechnet.

Daraus folgen zwei Dinge. Der Sprung von Pro Suite auf Enterprise beträgt £60 pro Nutzer und Monat, bei 50 Nutzern also £36.000 im Jahr, und er wird häufig von einer einzigen Integrationsanforderung erzwungen und nicht von einer Funktion, die der Vertrieb verlangt hat. Und der Supportplan ist ein Prozentsatz, skaliert also mit der Lizenzrechnung und nicht mit dem Support, den Sie verbrauchen.

Das Verhältnis von Dienstleistungen zu Lizenzen, und was es bewegt

Die brauchbare Planungszahl ist nicht der Tagessatz. Es ist das Verhältnis der Dienstleistungen des ersten Jahres zu den Lizenzausgaben des ersten Jahres, weil dieses Verhältnis stabil genug ist, um darüber zu streiten.

Unsere Hausbänder aus dem britischen Mittelstandsgeschäft sehen so aus. Ein nahezu unveränderter Rollout einer einzelnen Cloud mit sauberen Daten und ohne Integrationen landet ungefähr beim 0,5- bis 1-Fachen der Lizenzausgaben des ersten Jahres. Eine typische Implementierung mit zwei oder drei Integrationen und einem moderaten Anteil an eigenen Objekten und Automatisierung landet beim 1- bis 3-Fachen. Ein Multi-Cloud-Programm mit Altdaten, fünf oder mehr Integrationen und starker Prozessanpassung läuft beim 3- bis 5-Fachen und manchmal darüber. Das sind unsere Schätzungen, keine veröffentlichten Zahlen, und einen Partner, der ein festes Branchenverhältnis nennt, sollten Sie fragen, woher es stammt.

Am Beispiel von £84.000 sind das £42.000 am unteren Ende, £84.000 bis £252.000 in der Mitte und £252.000 aufwärts am oberen Ende. Die Spanne ist die ganze Geschichte. Wer nur gehört hat, es sei ungefähr so viel wie die Lizenz, hat sich auf die Mitte einer Bandbreite verankert, die an den Rändern zehnmal so weit auseinanderliegt.

Die vier Variablen, die das Verhältnis bewegen

Nur vier Dinge bewegen ein Salesforce Projekt zuverlässig von einem Band in das nächste, und jedes Scoping-Gespräch sollte alle vier klären, bevor jemand eine Zahl produziert.

Das erste ist die Zahl der angebundenen Systeme. Jedes ist ein eigener Entwurf, ein eigener Satz Zugangsdaten, ein eigener Fehlerpfad und eine eigene Sache, die kaputtgeht, wenn der andere Anbieter ein Release ausliefert. Integrationen sind in den Kosten nicht additiv, sie sind etwas schlechter als additiv, weil sich die Fehlerfälle multiplizieren.

Das zweite ist die Datenqualität in der Quelle. Nicht das Volumen. Die Qualität. Sie wird weiter unten ausführlich behandelt, weil sie die am beständigsten unterschätzte Position im Programm ist.

Das dritte ist der Grad der Prozessanpassung, also wie weit das Zielbild von dem abweicht, was das Produkt nach der Installation ohnehin tut.

Das vierte ist die Frage, ob die Organisation ihren Prozess an das Produkt anpassen wird. Das ist der größte einzelne Prädiktor für Kosten und Erfolg, und fast niemand nimmt ihn in den Scope, weil es eine Frage über Menschen ist, die während einer technischen Bewertung gestellt wird.

Veränderungsbereitschaft ist eine Scoping-Frage

Eine Organisation, die ihren Vertriebsprozess an das Opportunity-Modell von Salesforce anpasst, bekommt ein günstiges, upgradefähiges, gut unterstütztes System. Eine, die darauf besteht, dass Salesforce ihre bestehende Tabellenkalkulation nachbildet, bekommt ein teures System, das sich mit jedem Release schlägt.

Das Erkennungszeichen im Discovery ist die Sprache. Wenn eine Stakeholderin sagt, das System müsse so arbeiten, wie wir arbeiten, ist das Anpassungsbudget im Begriff, sich zu verdoppeln. Wenn jemand sagt, zeigen Sie mir, wie es gedacht ist, und erklären Sie mir warum, ist es im Begriff, sich zu halbieren. Beide Sätze sind vernünftig. Nur einer davon ist günstig.

Der ehrliche Umgang damit ist, es zu bepreisen. Schreiben Sie zwei Zahlen ins Angebot, eine für das Standardmodell und eine für die maßgeschneiderte Variante, und lassen Sie die Differenz argumentieren. Wer sieht, dass eine Namenskonvention für Phasen £18.000 an eigener Automatisierung und ein dauerhaftes Upgrade-Risiko kostet, ändert die Konvention meistens. Wer hört, dass sich das machen lässt, ändert sie nicht.

Discovery, und was ein gutes Discovery produziert

Discovery ist die Phase, die am häufigsten gekürzt wird, um einen Auftrag zu gewinnen, und die hinterher am häufigsten beschuldigt wird. Ein Discovery, das eine Präsentation produziert, war eine Vertriebsübung. Eines, das vier Artefakte produziert, war eine Ingenieursübung.

Das erste ist eine Prozesslandkarte: die tatsächliche Abfolge der Schritte, mit denen aus einem Lead Umsatz wird, mit den Entscheidungspunkten und den Personen, die sie verantworten, aus der Beobachtung der Arbeit gewonnen und nicht daraus, Führungskräfte um eine Beschreibung zu bitten.

Das zweite ist ein Datenmodell: Objekte, Felder, Beziehungen, Picklist-Werte und für jedes Feld eine benannte Person, die es pflegt. Felder ohne Eigentümer werden zu den Feldern, die niemand ausfüllt.

Das dritte ist ein Integrationsinventar: jedes System, das Daten an Salesforce sendet oder von dort empfängt, mit Richtung, Volumen, Frequenz, dem Identifikator, der die Datensätze verbindet, und dem Verhalten bei Ausfall der Verbindung.

Das vierte ist eine messbare Definition of Done. Nicht, dass der Vertrieb Salesforce nutzt, sondern etwa, dass 90% der im Quartal geschlossenen Opportunities ein Abschlussdatum, einen Betrag und eine vom Eigentümer gesetzte Phase haben und das wöchentliche Pipeline-Meeting aus dem Salesforce-Dashboard läuft, ohne dass eine Tabellenkalkulation im Raum ist.

In einem Wettbewerbsverfahren gilt der Leitfaden für Software-Ausschreibungen unmittelbar: Fragen Sie jeden Bieter, was sein Discovery produziert, und sortieren Sie die aus, die die Artefakte nicht benennen können.

Die Datenmigration ist die Phase, in der der Zeitplan verschwindet

Die Migration wird als Prozentsatz des Baus angeboten und als Vielfaches davon verbraucht, wegen eines einzigen Missverständnisses: Teams schätzen gegen die Datensatzzahl, und der Migrationsaufwand skaliert mit der Qualität der Quelle.

Zwei Millionen saubere Zeilen aus einem gut gepflegten System mit verlässlichem Primärschlüssel sind eine Woche sorgfältiger Arbeit. Vierzigtausend Zeilen, verteilt auf ein Alt-CRM, drei regionale Tabellen und ein Buchhaltungspaket, ohne gemeinsamen Identifikator und mit elf Jahren Freitext im Notizfeld, sind zwei Monate und werden beim Go-live immer noch falsch sein. Der zweite Auftrag hat ein Fünfzigstel der Datensätze und den achtfachen Aufwand.

Profilieren Sie die Quelle, bevor Sie etwas zusagen

Profilierung heißt, Dinge zu zählen, bevor Sie einen Termin zusagen. Führen Sie sie für jede Quelle durch, und zwar bevor die Migrationsposition im Angebot unterschrieben ist.

Zählen Sie die Nullwerte pro Feld. Zählen Sie die verschiedenen Werte in jedem Feld, aus dem eine Picklist werden soll, denn eine Spalte für das Land mit 340 verschiedenen Werten ist keine Picklist, sondern ein Bereinigungsprojekt. Zählen Sie, wie viele Datensätze sich einen Schlüsselkandidaten teilen. Messen Sie die Formatkonsistenz bei Datumsangaben, Telefonnummern und Postleitzahlen. Zählen Sie die Datensätze ohne Eigentümer, ohne E-Mail-Adresse und ohne Aktivität in drei Jahren, denn die wird niemand verteidigen, wenn Sie vorschlagen, sie zurückzulassen.

Die Profilierung kostet auf einem mittelgroßen Bestand zwei bis fünf Tage. Sie ist die billigste Risikoreduktion im Programm, und ihr Auslassen ist der Grund, warum Migrationsschätzungen nur in eine Richtung falsch sind.

Deduplizierung, und die Regeln, die die Plattform mitbringt

Salesforce bringt ein eigenes Dublettenmanagement mit, und dessen Grenzen prägen den Entwurf. Sie können bis zu fünf aktive Duplicate Rules pro Objekt und eine aktive Matching Rule pro Objekt haben, bei mehreren Duplicate Rules steigt das auf fünf aktive Matching Rules pro Objekt, und jede Duplicate Rule kann bis zu drei Matching Rules referenzieren.

Zwei Verhaltensweisen wiegen schwerer als die Zahlen. Match Keys verengen den Vergleich auf die 100 wahrscheinlichsten Dubletten, bevor die Matching-Gleichung angewendet wird, ein Datensatz mit mehr als 100 echten Beinahe-Treffern wird also nicht vollständig bewertet. Und die Regeln laufen in mehreren verbreiteten Pfaden schlicht nicht, darunter Quick Create und die Lead-Konvertierung ohne aktiviertes Apex Lead Convert, und genau so entstehen Dubletten in einer Org, in der Duplicate Rules eingeschaltet sind.

Deduplizierung ist deshalb eine Migrationsaktivität, die in den Staging-Daten vor dem Laden erledigt wird, und kein Laufzeitfeature, das man einschaltet und vergisst. Die nativen Regeln sind die zweite Verteidigungslinie.

External IDs, und warum Upsert besser ist als Insert

Jedes migrierte Objekt braucht eine External ID: ein indiziertes eigenes Feld, das den Primärschlüssel aus dem Quellsystem hält. Das ist die wertvollste einzelne Entscheidung im Migrationsentwurf, und sie kostet nichts.

Mit einer External ID können Sie Upsert nutzen, das anhand dieses Feldes entscheidet, ob ein Datensatz angelegt oder aktualisiert wird. Wird der Wert nicht gefunden, entsteht ein Datensatz, wird er einmal gefunden, wird der Datensatz aktualisiert, und wird er mehrfach gefunden, kommt ein Fehler zurück statt einer Dublette. Damit ist jeder Ladelauf idempotent, was bedeutet, dass Sie ihn zweimal laufen lassen können, ohne Ihre Daten zu verdoppeln, was bedeutet, dass Sie proben können.

Zwei Details beißen. Der Abgleich über die External ID ist nur dann unabhängig von der Groß- und Kleinschreibung, wenn das Feld das Attribut Unique trägt und die entsprechende Option gesetzt ist, sonst sind ABC123 und abc123 zwei verschiedene Datensätze. Und wenn das Feld eine External ID ohne eindeutigen Index ist, braucht das ladende Konto die Berechtigung View All Data.

Historie migrieren oder das Nützliche migrieren

Die Standardanforderung lautet, alles herüberzubringen. Sie ist fast immer falsch, und sie ist auf drei getrennten Wegen teuer.

Sie kostet Migrationsaufwand, weil die ältesten Daten die schmutzigsten sind und Bereinigungszeit unverhältnismäßig zu ihrem Wert verbrauchen. Sie kostet Speicher, und Speicher ist eine echte Position: Enterprise-, Professional- und Unlimited-Orgs sind mit 10 GB Datenspeicher plus 20 MB je Nutzerlizenz ausgestattet, 50 Enterprise Nutzer sind also 11 GB insgesamt und nicht 11 GB pro Nutzer. Und sie kostet Adoption, weil ein System voller toter Datensätze den Nutzern beibringt, Suchergebnissen nicht zu trauen.

Die vertretbare Haltung ist, offene und aktuelle Datensätze vollständig zu migrieren, abgeschlossene Datensätze für den Zeitraum zu migrieren, über den das Geschäft tatsächlich berichtet, und den Rest an einem lesbaren Ort zu archivieren. Personenbezogene Daten aufzubewahren, für die Sie keine Verwendung haben, ist eher eine Haftung als ein Wert, das Speicherargument und das Compliance-Argument zeigen hier also ausnahmsweise in dieselbe Richtung.

Konfiguration gegen Code

Jede Anforderung in Salesforce lässt sich deklarativ, mit Code oder in einer Mischung erfüllen, und die Wahl bestimmt, was das System für das nächste Jahrzehnt im Unterhalt kostet. Die Unterscheidung lohnt sich auch dann, wenn Sie nie einen Editor öffnen.

Was deklarativ sein sollte

Deklarativ heißt: mit Konfiguration gebaut, also Objekte, Felder, Page Layouts, Validierungsregeln und Flow, der visuelle Automatisierungsbaukasten von Salesforce. Es wird von einer Administratorin geändert, es überlebt Plattform-Upgrades, weil Salesforce die Laufzeit besitzt, und es ist für jeden mit der passenden Berechtigung sichtbar.

Der eigene Entscheidungsleitfaden für datensatzgesteuerte Automatisierung von Salesforce liefert eine brauchbare Schwelle. Er misst die Automatisierungsdichte über drei Dimensionen: die Zahl der Automatisierungen, die bei einer Datenänderung feuern, das Datensatzvolumen pro Transaktion und wie weit nachgelagerte Aktualisierungen in verwandte Objekte kaskadieren. Geringe Dichte, also weniger als fünfzehn Automatisierungen, Stapel von 1 bis 200 Datensätzen und höchstens ein nachgelagerter Schreibvorgang, gehört in datensatzgesteuerten Flow.

Derselbe Leitfaden gibt eine Regel, die mehr Geld spart als jede andere auf dieser Liste: Nutzen Sie einen einzigen Einstiegspunkt pro Objekt. Flow und Apex-Trigger auf demselben Objekt zu mischen, ist der Weg, auf dem Reihenfolgefehler dauerhaft werden.

Wann eigener Code richtig ist

Mittlere Dichte gehört in eine Mischform, in der Flow orchestriert und invocable Apex die schwere Arbeit erledigt, damit die Abfolge sichtbar bleibt und die Rechenlast in etwas Testbarem sitzt. Hohe Dichte gehört ganz in Apex-Trigger, weil deklarative Werkzeuge an diesem Punkt für ein System eingesetzt werden, für das sie nicht gebaut wurden.

Code ist auch dann richtig, wenn die Logik wirklich komplex ist, wenn sie ordentlich per Unit-Test geprüft werden muss und wenn dieselbe Operation aus mehreren Einstiegspunkten gerufen wird und nur einmal existieren sollte. Wenn Sie diese Arbeit beauftragen statt sie zu besetzen, existieren unsere Dienstleistungen in der Softwareentwicklung genau für diese Grenze, an der die Plattform aufhört und maßgeschneiderte Entwicklung beginnt.

Begriffe verschieben sich, und alte Begriffe sind ein Warnzeichen

Salesforce mottet Werkzeuge ein, und ein Angebot, das gegen eingemottete Werkzeuge geschrieben ist, verrät, wann es tatsächlich verfasst wurde. Salesforce hat den Support für Workflow Rules und Process Builder am 31. Dezember 2025 eingestellt. Bestehende Regeln laufen weiter, aber es gibt keinen Kundensupport und keine Fehlerbehebungen, und der empfohlene Weg ist die Migration zum Flow Builder mit dem Werkzeug Migrate to Flow.

Die langfristigen Kosten jeder Wahl

Deklarative Arbeit ist billiger zu bauen und billiger zu ändern, und ihr Preis ist Verwässerung: Aus hundert undokumentierten Flows wird ein System, in dem niemand vorhersagen kann, was das Speichern eines Datensatzes auslöst.

Code ist teurer zu bauen und im Maßstab weit billiger zu durchdenken, weil er gelesen, versioniert und getestet werden kann. Sein Preis ist, dass er Entwickler braucht, und eine Organisation ohne Salesforce-Entwickler und ohne Retainer wird ihr eigenes System irgendwann nicht mehr ändern können.

Der teuerste Fehlschlag ist keiner von beiden. Es ist ein vollständig deklarativ gebautes System von einem Partner, der danach geht, in einer Org ohne Dokumentation und ohne benannten Eigentümer. Alles funktioniert und nichts lässt sich gefahrlos ändern, was dieselbe Lage ist wie bei ungepflegter Individualsoftware, ausführlich beschrieben in unserem Beitrag dazu, was Softwarewartung wirklich kostet.

Integration, und warum Limits die Architektur ändern

Die Integration hat ihre eigene Behandlung in unserem Beitrag über Salesforce-Integrationslimits und die realen Kosten. Hierher gehört der Punkt, dass Plattformlimits ein Architektur-Input sind und kein Betriebsdetail, das man in Woche neun entdeckt.

Zwei Limits prägen das meiste. Die Gesamtkontingente für API-Anfragen einer Org der Enterprise Edition betragen 100.000 Aufrufe je 24 Stunden plus die Zahl der Lizenzen multipliziert mit den Aufrufen, die der jeweilige Lizenztyp mitbringt, also 1.000 für eine Salesforce-Lizenz, zuzüglich gekaufter Add-ons. Das eigene Rechenbeispiel von Salesforce ist eine Enterprise-Org mit 15 Salesforce-Lizenzen, die 115.000 Anfragen erhält. Das Kontingent gilt org-weit und nicht pro Nutzer, und gleichzeitige eingehende Anfragen, die 20 Sekunden oder länger laufen, sind in der Produktion auf 25 gedeckelt.

Das zweite sind die Apex Governor Limits, die pro Transaktion durchgesetzt werden: 100 SOQL-Abfragen synchron und 200 asynchron, 50.000 per SOQL geholte Datensätze, 150 DML-Anweisungen, 10.000 per DML verarbeitete Datensätze, 6 MB Heap synchron und 12 MB asynchron sowie 10.000 Millisekunden CPU-Zeit synchron gegen 60.000 asynchron.

Ein Entwurf, der das ignoriert, besteht den Abnahmetest mit zwanzig Datensätzen und scheitert am ersten echten Nachtlauf. Das ist kein Fehler. Das ist eine Architekturentscheidung, die per Voreinstellung getroffen wurde.

Umgebungen, und was ein Sandbox-Refresh zerstört

Salesforce gibt Ihnen vier Sandbox-Typen mit unterschiedlichem Speicher und unterschiedlichen Refresh-Intervallen, und die falsche Auswahl ist ein Planungsfehler, der spät auffällt.

Developer-Sandboxen fassen 200 MB und lassen sich einmal täglich aktualisieren. Developer Pro fasst 1 GB und ebenfalls täglich. Partial Copy fasst 5 GB, kopiert eine über ein Template definierte Stichprobe der Produktionsdaten und lässt sich alle fünf Tage aktualisieren. Full ist eine Kopie der Produktion und lässt sich alle 29 Tage aktualisieren. Die Enterprise Edition enthält 25 Developer-Sandboxen und eine Partial Copy; Full-Sandboxen kommen mit Unlimited und Performance oder werden als Add-on gekauft.

Das Intervall von 29 Tagen bei Full-Sandboxen ist die Einschränkung, um die herum zu spät geplant wird. Ihre einzige realistische Probeumgebung für die Migration lässt sich einmal im Monat aktualisieren, eine Probe, die ein Problem zeigt, kostet also einen Monat, bevor Sie sauber erneut proben können. Zwei Proben in einer Full-Sandbox sind ein Fenster von neun Wochen, nicht von zwei.

Developer- und Developer-Pro-Sandboxen kopieren nur Metadaten, alles, was eine Entwicklerin zum Testen hineingeladen hat, ist nach einem Refresh also weg. Testdaten müssen ein wiederholbar ausführbares Skript in der Versionsverwaltung sein, sonst verliert das Team pro Refresh einen Tag mit dem Wiederherstellen von Hand.

Release-Management: Change Sets gegen eine Pipeline

Sie können Apex nicht in einer Produktions-Org entwickeln, jede Änderung beginnt also woanders und muss bewegt werden. Wie sie bewegt wird, ist eine Entscheidung mit langem Nachlauf.

Change Sets sind der eingebaute Mechanismus. Sie tragen nur, was Sie über Setup ändern können, niemals Datensätze, sie brauchen eine Deployment-Verbindung zwischen Orgs, die derselben Produktions-Org zugeordnet sind, und ein eingehendes Change Set wird als Ganzes ausgeliefert und nicht Komponente für Komponente. Sie werden durch Klicken zusammengestellt, sind also nicht diffbar, nicht reviewbar und nicht wiederholbar, und dasselbe Change Set, von zwei Personen zusammengestellt, wird sich unterscheiden.

Das funktioniert für eine kleine Org mit einer Administratorin und monatlichen Releases. Es funktioniert in dem Moment nicht mehr, in dem zwei Personen dieselbe Org ändern, weil es kein Merge und keine Historie gibt und der Nachweis über das Ausgelieferte in jemandes Gedächtnis liegt.

Die Alternative ist eine quellgesteuerte Pipeline: Metadaten in Git, Änderungen als Diffs reviewt, Deployments aus einem Branch gefahren. Sie kostet ein paar Tage Einrichtung und macht aus dem Release-Management statt einer Gedächtnisübung eine wiederholbare Übung. Bei mehr als einer bauenden Person behandeln Sie das als Teil des Baus und nicht als spätere Verbesserung.

Die Regel mit 75% Abdeckung ist keine Qualitätsschwelle

Für das Deployment von Apex in die Produktion ist erforderlich, dass Unit-Tests mindestens 75% Ihres Apex-Codes abdecken und dass diese Tests bestehen. Salesforce sagt ausdrücklich, dass die Abdeckung auf Testwirksamkeit hinweist, ohne sie zu garantieren, und dass Tests Verhalten prüfen sollen.

Lesen Sie, was das kommerziell bedeutet. 75% ist ein Tor, und Tore werden ausgetrickst. Testklassen, die geschrieben wurden, um die Zahl zu treffen statt etwas zu prüfen, bestehen, gehen live und fangen nichts. Wenn Sie die Arbeit eines Partners prüfen, fragen Sie nicht nach dem Abdeckungsprozentsatz. Lassen Sie sich drei Testmethoden zeigen und zählen Sie die Assertions.

Eine Salesforce Implementierung scheitert an der Adoption, nicht am Go-live

Das System geht live, das Projekt schließt, die Rechnung ist bezahlt, und acht Monate später fährt die Vertriebsleitung den Forecast immer noch aus einer Tabellenkalkulation. Nichts ist kaputtgegangen. Das ist der häufigste Ausgang eines gescheiterten Salesforce Programms, und für jedes technische Maß ist er unsichtbar.

Die Ökonomie ist brutal, weil die Lizenzkosten unabhängig davon weiterlaufen. Fünfzig Enterprise Nutzer zu £140 im Monat sind £84.000 im Jahr, ob das System benutzt wird oder nicht, eine Adoptionsquote von 40% ist also grob £50.000 im Jahr reine Verschwendung allein bei der Lizenz, bevor die Implementierungskosten über irgendetwas amortisiert sind.

Adoption ist außerdem der einzige Fehlermodus, den das technische Team nicht beheben kann. Ein Partner kann exakt das bauen, was spezifiziert wurde, jedes Abnahmekriterium erfüllen und etwas hinterlassen, das niemand öffnet. Deshalb muss die Definition of Done im Discovery von Nutzung handeln, und deshalb sollte das Projekt beim Go-live nicht als geschlossen gelten.

Die Praktiken, die Adoption bewegen

Vier Dinge verschieben die Adoption zuverlässig, und keines davon ist ein Schulungsvideo.

Rollenbasierte Schulung, getrennt gehalten. Eine Vertriebsmitarbeiterin und eine Vertriebsleiterin nutzen unterschiedliche Teile des Systems aus unterschiedlichen Gründen, und eine gemeinsame Sitzung schult beide schlecht. Schulen Sie jede Rolle auf ihrem eigenen Ablauf und auf nichts sonst.

Ein kleiner Satz Pflichtfelder. Nehmen Sie die wenigsten Felder, mit denen das Reporting funktioniert, machen Sie die zur Pflicht und lassen Sie alles andere optional. Jedes zusätzliche Pflichtfeld ist ein Grund, einen Datensatz auf halbem Weg abzubrechen, und ein System, das Dateneingabe bestraft, bekommt weniger davon.

Reporting für Führungskräfte, das von den Daten abhängt. Das ist das, was wirkt. Wenn das wöchentliche Pipeline-Meeting aus einem Salesforce-Dashboard läuft und keine Tabellenkalkulation im Raum ist, werden die Daten eingegeben, weil die Alternative darin besteht, im Gespräch nicht vorzukommen. Führt die Leitung eine eigene Tabelle, ist das CRM optional und alle wissen es.

Eine benannte Eigentümerin mit Zeit in der Woche. Kein Gremium. Eine Person, die die Org verantwortet, die Administratorrechte hält, an der Adoption gemessen wird und Stunden dafür zugeteilt bekommt. Orgs ohne das verfallen vom ersten Monat an.

Die Fehlermodi und ihre Frühwarnzeichen

Sechs Fehlermodi machen den größten Teil des Scheiterns von Salesforce Implementierungen aus, das wir reparieren sollen, und jeder zeigt ein Zeichen deutlich vor dem Schaden.

Einen kaputten Prozess nachbauen. Das Warnzeichen ist ein Anforderungsdokument, das das bestehende System beschreibt statt das gewünschte Ergebnis, in den Feldnamen des alten Systems. Einen schlechten Prozess zu automatisieren macht ihn schneller und schwerer änderbar.

Unbegrenzte Anpassung. Das Warnzeichen ist ein Änderungsprotokoll ohne eine einzige Ablehnung. Die Enterprise Edition erlaubt 500 eigene Felder pro Objekt und 200 eigene Objekte, genug Spielraum, um lange vor einem Plattformlimit etwas zu bauen, das niemand pflegen kann.

Kein einzelner Eigentümer. Das Warnzeichen ist, dass die Antwort auf die Frage, wem Salesforce gehört, das Wort und enthält.

Alles migrieren. Das Warnzeichen ist ein Migrationsumfang, der über die Datensatzzahl definiert ist statt über eine Aufbewahrungsentscheidung.

Keine Disziplin bei den Testumgebungen. Das Warnzeichen ist, wenn jemand sagt, man solle die Änderung einfach in der Produktion machen, es sei nur ein Picklist-Wert.

Das Go-live messen statt die Nutzung. Das Warnzeichen ist ein Projektplan, dessen letzter Meilenstein ein Datum ist und keine Zahl.

Zeitpläne für kleine, mittlere und komplexe Implementierungen

Dauer und Aufwand sind verschiedene Fragen, und Käufer werfen sie zusammen. Das sind unsere Hausbänder aus dem britischen Mittelstandsgeschäft, keine veröffentlichten Zahlen.

Eine kleine Implementierung, bis etwa 25 Nutzer auf einer Cloud mit höchstens einer Integration und einer einzigen sauberen Datenquelle, läuft 6 bis 10 Wochen bei 20 bis 45 Beratertagen. Eine mittelgroße, 25 bis 150 Nutzer über eine oder zwei Clouds mit zwei bis vier Integrationen und einer echten Migration, läuft 4 bis 7 Monate bei 90 bis 220 Tagen. Ein komplexes Programm, ab 150 Nutzern, mehrere Clouds, fünf oder mehr Integrationen und mehr als ein Land, läuft 9 bis 18 Monate bei 400 Tagen aufwärts.

Innerhalb dieser Summen sind Discovery 10 bis 15% des Aufwands, Konfiguration und Bau 30 bis 40%, Datenmigration 20 bis 30% und bei schlechter Quellqualität stark steigend, Integration 10 bis 20% und Test, Schulung und Hypercare 15 bis 20%. Die Position, die sich ausdehnt, ist jedes Mal die Migration.

Die Dauer übersteigt den Aufwand geteilt durch die Teamgröße aus Gründen, die nicht am Team liegen: Refresh-Intervalle der Sandboxen, Verfügbarkeit der Stakeholder für die Abnahme und das Warten auf den Dritten, dessen API Sie brauchen. Wer dieses Risiko trägt, entscheidet der Vertrag, weshalb die Frage Festpreis gegen Aufwand bei CRM-Arbeit mehr zählt als anderswo.

Britischer Datenschutz in einem CRM-Programm

Ein CRM ist eine Datenbank über Menschen, die UK-DSGVO gilt also im Grunde für alles darin, und drei Fragen kommen bei jeder Implementierung auf.

Braucht das eine DPIA?

Der Leitfaden des ICO dazu, wann eine DPIA erforderlich ist, nennt die allgemeine Regel aus Artikel 35 Absatz 1, wonach eine DPIA nötig ist, wenn die Verarbeitung voraussichtlich ein hohes Risiko für die Rechte und Freiheiten von Personen zur Folge hat, und listet den eigenen Katalog des ICO nach Artikel 35 Absatz 4 auf.

Zwei davon treffen eine typische CRM-Migration direkt. Data Matching, definiert als Zusammenführen, Vergleichen oder Abgleichen personenbezogener Daten aus mehreren Quellen, ist genau das, was eine Konsolidierungsmigration tut. Profiling in großem Maßstab deckt Lead- und Account-Scoring ab. Das ICO merkt außerdem an, dass in den meisten Fällen eine Kombination aus zwei der europäischen Kriterien auf eine erforderliche DPIA hindeutet, ohne dass dies eine strikte Regel wäre. Beachten Sie, dass dieser Leitfaden derzeit wegen der Änderungen durch den Data (Use and Access) Act überarbeitet wird, prüfen Sie ihn also, statt sich auf eine Zusammenfassung zu verlassen.

Wo liegen die Daten tatsächlich?

Salesforce ist eine globale Plattform, und auf welcher Instanz Ihre Org läuft, ist eine vertragliche Frage und keine Annahme. Der Kurzleitfaden des ICO zu internationalen Übermittlungen, zuletzt am 15. Januar 2026 aktualisiert, gibt einen dreistufigen Test: Gilt die UK-DSGVO für die Verarbeitung, initiieren Sie die Übermittlung an eine Organisation außerhalb des Vereinigten Königreichs, und ist der Empfänger eine eigene juristische Person. Dreimal ja macht daraus eine eingeschränkte Übermittlung.

Eingeschränkte Übermittlungen brauchen britische Angemessenheitsregelungen, geeignete Garantien wie das International Data Transfer Agreement, das Addendum oder verbindliche interne Datenschutzvorschriften, oder eine Ausnahme. Wo Sie sich auf Garantien stützen, erwartet das ICO eine Risikobewertung der Übermittlung. Das ist eine Vertragsprüfung und keine technische Aufgabe, und sie sollte vor der Migration stattfinden statt danach.

Ihr Implementierungspartner ist ein Auftragsverarbeiter

Wenn ein Partner Ihre Org konfiguriert, Ihre Daten lädt und Zugangsdaten dazu hält, verarbeitet er personenbezogene Daten in Ihrem Auftrag. Der Leitfaden des ICO zu Verantwortlichen und Auftragsverarbeitern legt dar, was daraus folgt, und die praktischen Folgen sind vertraglich.

Sie brauchen eine schriftliche Vereinbarung über dokumentierte Weisungen, Vertraulichkeit, Sicherheit, Unterauftragsverarbeiter, Prüfrechte sowie Löschung oder Rückgabe der Daten am Ende der Zusammenarbeit. Die letzte ist die Klausel, die am häufigsten fehlt. Ein Partner, der elf Monate lang eine vollständige Kopie Ihrer Kundendatenbank in einer Full-Sandbox gehalten hat und dessen Vertrag nichts über deren Löschung sagt, ist eine offene Haftung auf Ihrer Seite der Linie, nicht auf seiner.

Was Sie einen möglichen Partner fragen sollten

Sechs Fragen, und die Antworten, die das Gespräch beenden sollten.

Fragen Sie, was das Discovery produziert. Ist die Antwort ein Angebot statt einer Prozesslandkarte, eines Datenmodells, eines Integrationsinventars und einer messbaren Definition of Done, wird verkauft und nicht geschnitten.

Fragen Sie, wie und wann sie die Quelldaten profilieren. Findet die Profilierung nach der vereinbarten Migrationsschätzung statt, ist die Schätzung geraten.

Fragen Sie nach ihrer Voreinstellung für Automatisierung und hören Sie auf das Dichte-Argument. Wer immer Flow oder immer Apex sagt, hat ein Werkzeug. Wer 2026 Process Builder vorsieht, hat drei Jahre lang keine Einstellungsmitteilung gelesen.

Fragen Sie, wie Änderungen aus der Sandbox in die Produktion gelangen. Change Sets sind für eine Org mit einer Administratorin akzeptabel und bei allem Größeren eine Warnung.

Fragen Sie, wem die Org nach dem Go-live gehört und wie viele Stunden pro Woche das ist. Wenn sie das nicht beantworten können, ist Adoption niemandes Problem.

Fragen Sie, was am Ende der Zusammenarbeit mit Ihren Daten in ihren Sandboxen passiert, und holen Sie sich die Antwort in den Vertrag statt in eine E-Mail. Dieselbe Disziplin, die unser Leitfaden zur technischen Due Diligence beschreibt, gilt auch hier: Prüfen Sie die Behauptung, statt die Zusicherung anzunehmen.

Wann die Antwort nicht Salesforce ist

Wenn Sie weniger als etwa zehn Nutzer haben, keine Integrationsanforderung und einen Prozess, der in eine Pipeline mit fünf Phasen passt, sind die Enterprise-Lizenz und ihre Implementierung beide größer als das Problem. Ein günstigeres CRM, oder die Starter Suite zu £20 pro Nutzer, erledigt die Aufgabe und lässt sich später zu Kosten ersetzen, die Sie verkraften.

Wenn Ihre eigentliche Anforderung ein Ablauf ist, den kein Produkt unterstützt, und alles andere bereits abgedeckt ist, kaufen Sie eine Plattform, um eine einzige Anwendung darauf zu betreiben. Das spricht meistens für ein eigens gebautes System, und unsere Arbeit an Individualsoftware geht von dieser Prämisse aus. Die Entscheidung zwischen Bauen und Kaufen hängt daran, ob der unterscheidende Prozess der Kern des Geschäfts ist oder ein Detail daneben.

Wenn niemand das System verantworten wird, kaufen Sie es nicht. Das ist das Schwerste, was sich in einem Vertriebsprozess sagen lässt, und der verlässlichste Prädiktor für Verschwendung. Ein CRM ohne Eigentümer scheitert nicht laut. Es wird still zur Kopie der Tabellenkalkulation, die es ersetzen sollte, zu £140 pro Nutzer und Monat.

Und wenn das Ziel eine Ebene aus KI-Agenten ist statt ein CRM, sitzt sie auf einer funktionierenden Implementierung und ersetzt keine. Die Ökonomie behandelt unser Beitrag dazu, was Agentforce wirklich kostet.

Die Arbeit in die richtige Reihenfolge bringen

Die Reihenfolge, die funktioniert, lautet: die Daten profilieren, ein Discovery auf vier Artefakte fahren, das Standardmodell vereinbaren und jede Abweichung davon bepreisen, auf einen Automatisierungs-Einstiegspunkt pro Objekt bauen, die Migration zweimal in einer Full-Sandbox proben, nach Rollen schulen und das Projekt offen halten, bis eine Nutzungszahl erreicht ist und nicht ein Datum.

Die Reihenfolge, die scheitert, lautet: unterschreiben, konfigurieren, spät migrieren, einmal schulen, am Stichtag live gehen, Projekt schließen.

Mecanik arbeitet an den Teilen davon, die Ingenieursarbeit sind und keine Lizenzverwaltung: Integrationsentwurf gegen echte Plattformlimits, Profilierung und Werkzeuge für die Migration, Individualentwicklung dort, wo Konfiguration endet, und die Frontend-Arbeit, die CRM-Daten vor Kunden bringt. Unsere Seiten zu Dienstleistungen in der Softwareentwicklung und zum Engagement von Webentwicklern beschreiben, wie wir zusammenarbeiten. Wenn Sie vor der Unterschrift eine zweite Meinung zur Schätzung eines Partners wollen, können Sie einen Entwickler beauftragen, allein für die Prüfung.

Häufig gestellte Fragen

Was kostet eine Salesforce Implementierung in Großbritannien? Salesforce führt Sales Cloud Enterprise in Großbritannien mit £140 pro Nutzer und Monat bei jährlicher Abrechnung, 50 Nutzer sind also £84.000 im Jahr allein an Lizenzen. Unsere Hausschätzung für die Implementierungsleistungen obendrauf liegt beim 0,5- bis 1-Fachen der Lizenzausgaben des ersten Jahres für einen nahezu unveränderten Rollout, beim 1- bis 3-Fachen für ein typisches Mittelstandsprojekt und beim 3- bis 5-Fachen für ein Multi-Cloud-Programm mit Altdaten und starker Anpassung.

Wie lange dauert eine Salesforce Implementierung? Unsere Hausbänder sind 6 bis 10 Wochen und 20 bis 45 Beratertage für bis zu 25 Nutzer auf einer Cloud mit sauberen Daten, 4 bis 7 Monate und 90 bis 220 Tage für 25 bis 150 Nutzer mit zwei bis vier Integrationen und 9 bis 18 Monate und 400 Tage aufwärts für ein Multi-Cloud-Programm mit Altdatenmigration. Die Datenmigration ist die Phase, die sich ausdehnt, weil ihr Aufwand mit der Qualität der Quelldaten skaliert und nicht mit der Datensatzzahl.

Warum scheitern Salesforce Implementierungen? Fast immer an der Adoption und nicht am Go-live. Ein technisch korrektes System, das niemand benutzt, ist ein Totalverlust mit laufender Lizenzrechnung. Die häufigen Ursachen sind das Nachbauen eines kaputten Prozesses, unbegrenzte Anpassung, kein einzelner benannter Eigentümer, das Migrieren aller historischen Daten, fehlende Disziplin bei den Testumgebungen und das Messen des Go-live statt der Nutzung.

Sollte Salesforce mit Konfiguration oder mit eigenem Code gebaut werden? Der eigene Entscheidungsleitfaden von Salesforce setzt die Schwelle über die Automatisierungsdichte. Weniger als fünfzehn Automatisierungen auf einem Objekt, Stapel von 1 bis 200 Datensätzen und höchstens ein nachgelagerter Schreibvorgang gehören in datensatzgesteuerten Flow. Mittlere Dichte passt zu Flow, der invocable Apex orchestriert. Hohe Dichte passt zu Apex-Triggern. Nutzen Sie einen Einstiegspunkt pro Objekt, statt Flow und Apex-Trigger auf demselben zu mischen.

Brauchen wir für eine Salesforce Implementierung eine DPIA? Oft ja. Das ICO führt Data Matching, also das Zusammenführen oder Vergleichen personenbezogener Daten aus mehreren Quellen, und Profiling in großem Maßstab unter den Verarbeitungen, die auf eine erforderliche DPIA hindeuten, und eine Konsolidierungsmigration mit Lead-Scoring tut beides. Der Leitfaden wird derzeit im Anschluss an den Data (Use and Access) Act überarbeitet, prüfen Sie also die aktuelle Position des ICO statt einer Zusammenfassung.