Salesforce-Implementierungspartner auswählen
Einen Salesforce-Implementierungspartner wählen Sie besser nach Punkten aus, die in Angeboten oft fehlen, als nach der Aufmachung der Präsentation und den Referenzen, die der Partner aussucht: wie gründlich der Partner Ihre Prozesse untersucht hat, bevor er einen Preis nennt, wer die Schlüsselrollen ab Tag 1 besetzt, wie er Qualität an Meilensteine bindet und ob Sie ohne ihn weitermachen könnten. Als Architekt auf Kundenseite habe ich schon öfter erlebt, dass ein Partner gewechselt werden musste. Viele Gründe dafür waren schon im Angebot erkennbar.
Warum Referenzen wenig über einen Implementierungspartner verraten
Referenzen werden vom Partner gebrieft. Kein Partner nennt Ihnen das Projekt, in dem es richtig schiefging. Das ist kein Vorwurf: Jeder Implementierungspartner hat Leichen im Keller, und wer etwas anderes behauptet, hat entweder wenige Projekte gemacht oder sagt nicht alles.
Die Zahlen auf AppExchange helfen bei der Vorauswahl (Trailhead1). Die Zufriedenheitsumfrage nach Projektende geht an den Kontakt, den der Partner selbst einträgt, und abgebrochene Projekte zählen nicht in den Durchschnitt (Salesforce Partner Community2).
Was die Angaben auf AppExchange zeigen
Die bessere Frage lautet: Welches Projekt ist bei Ihnen schiefgegangen, was haben Sie daraus gelernt, und woran sehe ich, dass es nicht wieder passiert? Wer darauf eine konkrete Antwort hat, mit einer geänderten Regel oder einem neuen Prüfschritt, hat aus seinen Fehlern etwas gemacht. Wenn Sie können, sprechen Sie zusätzlich mit einem früheren Kunden, der nicht auf der Referenzliste steht.
Welche Warnsignale stehen im Angebot?
Die folgenden Punkte habe ich in Angeboten gesehen, und jeder davon hat sich später im Projekt bemerkbar gemacht.
Warnsignale im Angebot eines Salesforce-Partners
Der erste Punkt wird oft unterschätzt. In meinen Fällen war der Festpreis zu optimistisch, und der Kunde wusste gar nicht, welche Funktionen in den einzelnen Arbeitspaketen enthalten waren und ob sie seinen Bedarf decken. Fehlt dann ein Prozess, deckt der Preis den tatsächlichen Umfang nicht mehr, und mit jedem Change Request schwindet der Schutz des Festpreises. Wie sich Festpreis und Aufwand verschieben, seit Partner mit KI bauen, steht in Festpreis statt Aufwand.
Die Discovery entscheidet, wie belastbar die Schätzung ist
Eine Schätzung ganz ohne Discovery ist selten geworden. Häufiger ist eine Discovery, die zu oberflächlich bleibt: Ich habe Schätzungen gesehen, für die nur der Happy Path besprochen wurde, der Standardfall nach Schema F. Bei Herstellern liegt der Aufwand aber oft in den Randfällen.
Discovery nur für den Happy Path
- Nur der Standardfall nach Schema F ist besprochen.
- Geräte ohne Seriennummer, Aufträge über zwei Werke oder eigene Rahmenverträge fehlen.
- Regeln, Datenmodell und Schnittstellen dafür stehen in keiner Schätzung.
- Die Randfälle kommen später als Change Request.
Discovery mit Randfällen
- Die Liste der Sonderfälle liegt dem Angebot bei.
- Annahmen hinter der Schätzung und offene Entscheidungen sind aufgeschrieben.
- Sie sehen vor der Vergabe, was im Preis steckt und was nicht.
Fragen Sie deshalb nicht, ob eine Discovery stattfand, sondern lassen Sie sich diese Belege zeigen. Kann der Partner nichts davon vorlegen, haben Sie keinen Beleg, dass Randfälle besprochen wurden.
Ein Teil der Verantwortung liegt beim Kunden. In jedem meiner Projekte dauerte der Abnahmetest länger als geplant, weil Mitarbeitende des Kunden nicht verfügbar waren, und es kamen Change Requests, weil der Fachbereich vorher zu wenig auf die eigene Lösung und den Ist-Zustand geschaut hatte. Fragen Sie den Partner deshalb auch, was er von Ihnen erwartet: welche Prozessverantwortlichen er wie viele Tage braucht, wann Sie welche Entscheidungen treffen müssen und wer Testfälle vorbereitet, Testdaten liefert und testet.
Das Team aus dem Pitch ist nicht automatisch das Team im Projekt
Im Pitch sitzen die erfahrenen Leute. Im Projekt war das Team dann in meinen Fällen sehr durchmischt, mit vielen Junioren. Das muss nicht schlecht sein, Junioren brauchen Projekte. Es wird schlecht, wenn niemand Erfahrenes ihre Arbeit prüft und der Kunde das erst an der Qualität merkt.
Daraus ergeben sich die Fragen für den Pitch. Wer besetzt ab Tag 1 die Schlüsselrollen, mit Namen und Zeitanteil, und welche Seniorität hat der Rest des Teams? Wer hat genau dieses Produkt und die Szenarien schon eingeführt, die Sie brauchen, bei Herstellern oft Installed Base und Anlagenhierarchien, Ersatzteile aus dem ERP oder Einsatzplanung für Servicetechniker? Und wer übernimmt, wenn eine Schlüsselperson geht, und wer bezahlt die Einarbeitung?
Wie fragen Sie nach Qualität, ohne die Antwort vorzugeben?
Auf „Arbeiten Sie in unserem Repository nach unseren Standards?“ antwortet jeder Partner mit Ja. Ich stelle diese Fragen deshalb über Umwege: Ich beschreibe ein Problem und lasse den Partner erzählen, wie er es lösen würde. Ein Partner mit gutem Vorgehen beschreibt es dann als seine Lösung, ohne dass ich es vorgegeben habe. Code-Review und Testregeln stehen selten im Angebot, und gerade seit Partner mit KI-Werkzeugen programmieren, sollte er von sich aus erklären, wie er jede Änderung prüft, egal wer oder was sie geschrieben hat.
- Meilensteine und Qualität. „Wie hängen Ihre Projektmeilensteine mit der Lieferung und den Quality Gates zusammen?“ Gute Antworten nennen konkrete Prüfungen: Code-Review, Testabdeckung und automatische Prüfungen in der Pipeline, aber auch Datenmigration, Integrationstests und Abnahmereife. Ein Meilenstein gilt erst als technisch fertig, wenn alle bestanden sind; die fachliche Abnahme kommt mit eigenen Kriterien hinzu. Mehr dazu in Quality Gates für KI-Code und Partner codet mit KI.
- Ein zweiter Partner. „In zwei Jahren kommt für Field Service ein weiterer Partner dazu. Wie verhindern wir, dass sich beide gegenseitig überschreiben?“ Gute Antworten erwähnen Pull Requests, eine Object Ownership Matrix und eine gemeinsame Sandbox-Strategie.
- Übernahme nach dem Go-live. „Wir wollen den Betrieb später selbst führen. Was bekommen wir dann von Ihnen?“ Hier zeigt sich, ob Code, Konfiguration und Dokumentation bei Ihnen liegen sollen oder beim Partner bleiben.
Was in den Vertrag mit dem Partner gehört
Was im Pitch gut klingt, muss in den Vertrag, sonst gilt es nicht. Diese Punkte gehören mindestens hinein:
- Benannte Schlüsselrollen, Austausch nur mit Ihrer Zustimmung, gleichwertiger Ersatz und eine Übergabezeit auf Kosten des Partners.
- Eigentum und Zugriff: Code, Metadaten, Dokumentation und Pipeline-Konfiguration, die für Sie erstellt werden, gehören Ihnen von Anfang an, mit Administratorzugriff auf Repository und Pipeline. Für Accelerators und Vorlagen des Partners regelt der Vertrag Ihr Nutzungsrecht.
- Quality Gates mit festgelegten Prüfungen für die technische Fertigstellung jedes Meilensteins, mit den Nachweisen, die der Partner liefert.
- Annahmen und Ausschlüsse der Schätzung und eine Regel für Randfälle, die die Discovery nicht abgedeckt hat: Wer bewertet sie, und unter welchen Bedingungen werden sie zum Change Request?
Arbeiten mehrere Partner an einer Org, kommt die Frage dazu, wer die Regeln für alle festlegt. In meinem größten Programm bauten fünf Partner mit über 30 Entwicklern an einer Org, und die Standards kamen von der Kundenseite, wie auf der Seite zur Partnersteuerung beschrieben. Wann dafür ein unabhängiger Architekt sinnvoll ist, steht in Salesforce-Freelancer oder Agentur.
Erster Schritt: drei Problemfälle für alle Partner aufschreiben
Bevor Sie Partner einladen, legen Sie fest, woran Sie sie messen, und geben allen dieselben Fälle aus Ihrem eigenen Programm.
- 01
Fälle aufschreiben
Ein Randfall aus Ihrem Prozess, ein zweiter Partner kommt dazu, eine Schlüsselperson des Partners geht.
- 02
Kriterien festlegen
Für alle Partner dieselben Kriterien, damit nicht die beste Präsentation gewinnt.
- 03
Fälle im Pitch durchspielen
Jeder Partner erzählt, wie er bei denselben drei Fällen vorgehen würde.
- 04
Belege verlangen
Schlüsselrollen mit Namen, Liste der Sonderfälle aus der Discovery, Annahmen hinter dem Preis.
Quellen2
- 1Trailhead (öffnet in einem neuen Tab)trailhead.salesforce.com
- 2Salesforce Partner Community (öffnet in einem neuen Tab)partners.salesforce.com
Häufig gestellte Fragen
Wie finde ich einen Salesforce-Implementierungspartner in Deutschland?
Für die Vorauswahl eignet sich der Consultant-Bereich auf AppExchange, gefiltert nach Produkt, Branche und Standort. Die Entscheidung sollte aber auf der Discovery, dem benannten Team und den Antworten zur Qualitätssicherung beruhen, nicht auf Sternen und Partnerstufe.
Sagt die Partnerstufe (Summit, Crest, Ridge) etwas über die Qualität aus?
Nur begrenzt. Die Stufe folgt aus einem Punktwert mit mehreren Bestandteilen, darunter die durchschnittliche Kundenzufriedenheit abgeschlossener Projekte, Zertifizierungen und Navigator-Status. Wie das Team arbeitet, das Sie bekommen, sagt sie kaum.
Festpreis oder Aufwand: was ist bei einem Salesforce-Partner besser?
Ein Festpreis schützt Sie, wenn die Discovery die Randfälle Ihrer Prozesse kennt und das Angebot Annahmen, Ausschlüsse und Abnahmekriterien nennt. Sonst wandert das Risiko über Change Requests zurück zu Ihnen.
Was tun, wenn der Partner nach dem Projektstart Schlüsselpersonen austauscht?
Regeln Sie das vorher im Vertrag: benannte Schlüsselrollen, Austausch nur mit Ihrer Zustimmung, gleichwertiger Ersatz und eine Übergabezeit, die der Partner trägt. Ohne diese Regel merken Sie den Wechsel meist erst an der Qualität.