CRM-Implementierung: der Umfang, den niemand aufschreibt

Das Projekt ist abgenommen. Die Daten sind drin, die Felder stimmen, das Team hat seine Schulung bekommen. In der ersten Woche nach dem Go-Live fällt jemandem auf, dass die Anfragen aus dem Kontaktformular niemandem mehr zugewiesen werden. Sie liegen da. Niemand hat diese Regel entfernt — es hat nur nie jemand aufgeschrieben, dass es sie gab.

Das ist der häufigste Bruch in einer CRM-Implementierung, und er hat fast nie mit Daten zu tun. Daten ziehen um. Was nicht von allein umzieht, sind die Prozesse, die im Altsystem still gelaufen sind: Automatisierungen, Zuweisungsregeln, die Übergabe zwischen Marketing und Sales. Sie stehen in keinem Projektumfang, weil niemand sie je als eigenen Punkt gedacht hat.

Warum die Abnahme das nicht fängt

Eine Abnahme prüft, was im Umfang steht. Genau das ist ihr Zweck, und genau darin liegt die Lücke: die Prozesse, über die niemand geschrieben hat, sind kein Prüfpunkt. Sie erscheinen in keiner Checkliste, weil eine Checkliste aus dem Umfang entsteht.

Der Weg dorthin ist immer derselbe und wirkt in jedem einzelnen Schritt vernünftig. Im Workshop nennt der Kunde eine Regel, die ihm wichtig ist. Der Anbieter sagt zu, das abzubilden. Zwei Wochen später wird die Regel im Detail anders besprochen, weil sich eine Abhängigkeit gezeigt hat. Beide Seiten wissen, was gemeint ist, und keiner hält es fest — der Umfang stammt aus Woche eins und wird nicht nachgezogen. Am Go-Live existieren dann drei Versionen: die im Dokument, die im Kopf des Kunden und die im System.

Deshalb ist der Moment des Bruchs auch nicht der Moment des Fehlers. Der Fehler liegt Wochen früher, in einem Gespräch, in dem jemand sagte „das machen wir dann natürlich mit" — und niemand notierte, was „das" war. Die interne Aufarbeitung auf Anbieterseite kommt in solchen Fällen fast immer zum selben Befund, und es ist ein unspektakulärer: keine böse Absicht, sondern zu schwache Projekt-Governance. Umfangsänderungen wurden mündlich besprochen und nie schriftlich festgehalten, Risiken nicht formal an Entscheidungsträger auf beiden Seiten eskaliert.

Daten ziehen um, Prozesse nicht

Diese Unterscheidung trägt den ganzen Artikel. Ein Datenimport ist eine abgrenzbare technische Aufgabe: Objekte, Felder, Zuordnungen, Dublettenlogik. Sie ist in Tagen beschreibbar und in Tagen zu prüfen. Eine Prozessintegration ist etwas anderes — sie fragt, welche Abläufe das neue System nach dem Go-Live tragen muss, und sie ist der Teil, der Wochen braucht.

Bei MAIA by Prodlane ist beides belegt und auseinandergehalten. Das Unternehmen hatte vorher vier Wochen in Pipedrive investiert, war damit aber an die Grenzen der Anpassbarkeit gestossen. SalesPlaybook half dann, HubSpot innerhalb von 6-8 Wochen vollständig aufzusetzen und in die bestehenden Prozesse zu integrieren — mit dem Ergebnis klar strukturierter Abläufe, die planbar wurden.

Die Wochenzahl ist die interessante Grösse. Sie beschreibt nicht, wie lange ein Import dauert, sondern wie lange es dauert, bis ein System die Arbeit eines Teams wirklich abbildet. Wer in einem Angebot eine Migrationsdauer liest, sollte deshalb genau diese Frage stellen: bezieht sich die Zahl auf die Daten oder auf die Prozesse?

Die vier Bereiche, die regelmässig fehlen

Aus Implementierungs- und Migrationsprojekten wiederholt sich dasselbe Muster. Vier Bereiche laufen im Altsystem so unauffällig, dass sie niemand als Leistung wahrnimmt — und tauchen deshalb im Umfang nicht auf.

Die vierte Zeile ist die unangenehmste, weil sie oft ausserhalb der CRM-Zuständigkeit gesehen wird. Ein Webhook, der Aufträge ins Abrechnungssystem schiebt, gilt intern als IT-Thema — bis er nach der Umstellung nicht mehr feuert. Dann ist er ein CRM-Thema.

Die Liste dieser vier Bereiche zu erstellen, dauert weniger lang als die Diskussion darüber, wer sie erstellen müsste. Im Altsystem sind Automatisierungen und Zuweisungsregeln aufzählbar: sie stehen in einer Übersicht, haben Namen und lassen sich exportieren. Die Übergabe an den Vertrieb ist schwieriger, weil sie teilweise nicht im System steht, sondern in einer Gewohnheit — dann ist die richtige Frage nicht „welche Regel gilt", sondern „woran erkennt Sales, dass ein Lead für ihn ist". Bei den Schnittstellen hilft nur, die Systeme durchzugehen, die Daten aus dem CRM beziehen oder hineinschreiben, und pro System eine Person zu benennen.

Wer diese Liste vor der Unterschrift hat, verhandelt anschliessend über etwas Konkretes. Der Anbieter kann jede Zeile einschätzen, herausnehmen oder als Aufwand ausweisen. Was er nicht mehr kann, ist sie unausgesprochen mitzunehmen — und genau das ist der Zweck der Übung.

Der Gegenfall: wenn der Umfang vorher steht

Es geht auch anders, und der Unterschied ist nicht Glück. Workist hat den Wechsel von Salesforce zu HubSpot als Umstellung der gesamten Revenue-Journey aufgesetzt, nicht als Datenumzug: Marketing, Sales und Service in einem System, Backend-Anbindung per Webhooks, Nutzbarkeit für alle Teams ab dem ersten Tag.

Dazu kommen zwei Posten, die dieselbe Case Study ausweist: über 100.000 € jährliche Toolkosten eingespart, weil Einzeltools ersetzt wurden, und die Notwendigkeit einer Vollzeit-RevOps-Rolle entfiel — durch ein Setup, das wartbar genug ist, um ohne Spezialistin zu laufen. Beide Angaben stehen in der Case Study Workist.

Der Punkt dieser Zahlen ist nicht ihre Höhe. Er ist, dass „vollständige End-to-End-Abbildung der Revenue-Journey" bei Workist ein Umfangspunkt war und kein Nebenprodukt. Wer die Prozesse zum Gegenstand des Projekts macht, bekommt sie — und spart am Ende an einer Stelle, an der vorher niemand gerechnet hatte.

Wie eine Umfangszeile aussieht, die hält

Der Unterschied zwischen einem Umfang, der trägt, und einem, der später ausgelegt werden muss, liegt in einer einzigen Eigenschaft: die Zeile nennt ein Ergebnis, das man am Go-Live prüfen kann. Drei Beispiele aus demselben Projektteil.

Trägt nicht: „Übernahme der bestehenden Automatisierungen." Die Zeile klingt vollständig und ist es nicht — sie sagt nicht, welche, wie viele, und ob „Übernahme" heisst nachbauen oder ersetzen. Am Go-Live lässt sich nichts daran prüfen.

Trägt: „Die 14 im Export vom 12.03. gelisteten Pipedrive-Automatisierungen werden in HubSpot nachgebaut. Sieben davon eins zu eins, sieben werden vorher fachlich geprüft und gegebenenfalls zusammengefasst; die Entscheidung wird je Regel dokumentiert." Diese Zeile hat eine Zahl, eine Quelle, eine Abgrenzung und einen Prüfpunkt.

Trägt auch: „Automatisierungen sind nicht Bestandteil dieses Projekts. Der Kunde setzt sie nach dem Go-Live selbst auf; SalesPlaybook stellt eine Übersicht der Altregeln bereit." Ein ausdrückliches Nein ist ein guter Umfang. Was einen Go-Live gefährdet, ist nicht die enge Abgrenzung — es ist die fehlende.

Dieselbe Prüfung lässt sich auf jede Zeile anwenden: Steht dort etwas, dessen Fehlen am Tag nach dem Go-Live auffallen würde? Wenn ja, ist die Zeile brauchbar. Wenn die Antwort „das kommt darauf an, wie man es liest" lautet, ist sie der nächste Streitpunkt.

Wenn es doch bricht: Problem vor Zuständigkeit

Kein Projektumfang ist vollständig. Irgendwann bricht etwas, das niemand vorhergesehen hat — und dann entscheidet die Reihenfolge der ersten Reaktion über die Zusammenarbeit, nicht der Vertragstext.

Was in diesem Moment fast automatisch passiert: sobald das Problem sichtbar ist, verschiebt sich das Gespräch auf die Frage, was vereinbart war und was nicht. Für den Anbieter fühlt sich das nach nötiger Klärung an. Für den Kunden fühlt es sich nach einem Themenwechsel an — weg vom Ausfall, hin zu einer Detailfrage, die er nicht gestellt hat. Sein Prozess läuft weiter nicht.

Das ist keine Frage der Freundlichkeit, sondern der Wirkung. Wer zuerst über Zuständigkeit spricht, hat den Vertrauensschaden meist schon angerichtet — unabhängig davon, wie berechtigt der vertragliche Punkt tatsächlich ist.

Das Schriftliche ist dabei kein Formalismus, sondern das einzige Werkzeug, das in einem Projekt mit zwei Parteien und mehreren Monaten Laufzeit zuverlässig funktioniert. Eine Notiz nach jedem Workshop, in der steht, was sich am Umfang geändert hat und wer zugestimmt hat, kostet zehn Minuten. Sie ersetzt später eine Diskussion, in der beide Seiten aufrichtig etwas Verschiedenes erinnern.

Die Liste für das Angebot, das vor Dir liegt

Wenn Du gerade ein Angebot für eine CRM-Implementierung prüfst, sind das die Fragen, die den Unterschied machen. Sie sind absichtlich so gestellt, dass eine ausweichende Antwort auffällt.

1. Nennt der Umfang Prozesse oder nur Objekte? Steht dort „Kontakte, Unternehmen, Deals", ist das ein Datenumfang. Prozesse haben Namen.
2. Wer erstellt die Liste der bestehenden Automatisierungen? Wenn die Antwort offen bleibt, erstellt sie niemand.
3. Bezieht sich die genannte Dauer auf Import oder auf Integration? Beides ist eine legitime Antwort — aber nur eine davon beschreibt den Go-Live.
4. Wie werden Umfangsänderungen festgehalten? „Wir sprechen das laufend ab" ist die Antwort, die später zum Streitpunkt wird.
5. Was passiert in Woche eins nach dem Go-Live? Ein Projekt, das mit der Abnahme endet, endet zu früh.

Für den Weg aus einem bestimmten Altsystem gehen wir an anderer Stelle ins Detail — Salesforce, Marketo und Excel haben je eigene Fallstricke. Was intern an Aufwand anfällt, rechnet der Artikel zu den internen Kosten einer CRM-Einführung durch. Und wenn mehrere Gesellschaften betroffen sind, kommt die Governance-Frage dazu, die wir für konzernweite CRM-Projekte beschreiben.

Der Projektumfang ist kein juristisches Dokument. Er ist eine Liste der Prozesse, die nach dem Go-Live laufen müssen — und wer sie vorher aufschreibt, hat am Ende kein Vertragsproblem, sondern einen Projektplan.