Es liegt fast nie an der Software
Wenn ein CRM-Projekt im Mittelstand scheitert, lautet die Erklärung im Nachhinein meistens: Das System hat nicht gepasst. In den seltensten Fällen stimmt das.
Wir setzen seit 2011 CRM-Projekte um und haben über 200 Einführungen begleitet, quer durch Fertigung, Handel, technischen Service und Dienstleistung. Dabei fällt auf, dass gescheiterte Projekte sich sehr ähnlich sehen, während gelungene ziemlich unterschiedlich aussehen. Die Fehlerbilder wiederholen sich, und sie entstehen fast alle in den ersten zwei bis drei Wochen, lange bevor jemand ein Feld konfiguriert.
Was folgt, sind sieben Muster, die uns regelmäßig begegnen. Sie sind bewusst unangenehm formuliert, weil eine höfliche Version davon niemandem hilft. Wenn Sie zwei oder mehr davon in Ihrem laufenden Projekt wiedererkennen, ist das ein guter Zeitpunkt für eine Zwischenbilanz.
1. Das Projekt hat kein benennbares Problem
Die häufigste Ausgangslage ist nicht ein konkreter Missstand, sondern ein diffuses Gefühl: Wir brauchen mal ein CRM. Häufig ausgelöst durch einen Beitrag, einen Wettbewerber oder einen neuen Vertriebsleiter.
Das Problem daran ist nicht die Motivation, sondern die fehlende Messlatte. Ohne benanntes Problem gibt es kein Kriterium, an dem sich später entscheiden ließe, ob das Projekt erfolgreich war. Und ohne dieses Kriterium wird jede Anforderung gleich wichtig, was in der Praxis bedeutet, dass die lauteste gewinnt.
Woran man es erkennt: Auf die Frage „Woran merken Sie in sechs Monaten, dass sich das gelohnt hat?“ folgt eine Pause.
Was hilft: Drei Sätze, die das Problem beschreiben, mit einer Zahl darin. Zum Beispiel: Angebote werden im Schnitt elf Tage nach der Anfrage verschickt, wir wollen unter vier. Das ist prüfbar, und es schließt automatisch die Hälfte aller Anforderungen aus, die sonst mitgeschleppt worden wären.
2. Der Prozess wird abgebildet statt hinterfragt
Ein CRM bildet ab, was man ihm vorgibt. Wenn ein Angebot heute durch vier Freigaben läuft, von denen zwei historisch bedingt sind, dann läuft es danach digital durch vier Freigaben. Nur schneller dokumentiert.
Das ist die vertane Gelegenheit fast jedes Projekts. Eine Einführung ist der einzige Moment, in dem sich Abläufe ohne größeren Widerstand ändern lassen, weil ohnehin alles neu ist. Wer diesen Moment ungenutzt lässt, digitalisiert den Status quo einschließlich seiner Umwege.
Woran man es erkennt: In der Anforderungsaufnahme fällt häufig der Satz „Das machen wir schon immer so“, ohne dass jemand ergänzen kann, warum.
Was hilft: Bei jeder Freigabe, jedem Pflichtfeld und jeder Statusstufe einmal fragen, welche Entscheidung davon abhängt. Wenn keine, kann sie weg. Diese Übung dauert einen halben Tag und ist regelmäßig der wertvollste Teil des Projekts.
3. Die Edition wird zu groß gewählt
Der Reflex ist verständlich: Wir wollen nicht in einem Jahr an Grenzen stoßen, also nehmen wir gleich die größere Ausbaustufe. In der Praxis kehrt sich das um.
Mehr Funktionsumfang bedeutet mehr Konfigurationsmöglichkeiten, mehr Felder, mehr Optionen im Menü. Für ein Team, das gerade erst anfängt, mit einem CRM zu arbeiten, ist das kein Vorteil, sondern eine zusätzliche Hürde. Ungenutzte Funktionen verschwinden nicht, sie stehen im Weg.
Woran man es erkennt: Die Auswahl fiel auf eine Edition, deren namensgebende Funktion niemand im Erstgespräch erwähnen konnte.
Was hilft: Die kleinere Stufe nehmen und nach sechs Monaten anhand der tatsächlichen Nutzung entscheiden. Ein Upgrade ist in praktisch jedem System ein Klick, ein Downgrade selten. Wir raten aus diesem Grund regelmäßig zu weniger, als angefragt wurde.
4. Die Datenmigration wird zu klein kalkuliert
Die Migration wird im Angebot fast immer als technischer Schritt behandelt. Tatsächlich ist sie zu einem großen Teil eine inhaltliche Aufgabe, und sie entscheidet über die Akzeptanz.
Gewachsene Bestände enthalten Dubletten aus drei Quellen, Ansprechpartner, die das Unternehmen vor Jahren verlassen haben, Adressen ohne nachweisbare Einwilligung und Felder, die zweckentfremdet wurden, weil das passende Feld fehlte. Das lässt sich übernehmen, aber nicht ungeprüft.
Woran man es erkennt: Auf die Frage, wie viele Datensätze übernommen werden sollen, kommt eine gerundete Zahl und kein Kriterium.
Was hilft: Eine Testmigration mit Abgleich, bevor produktiv übernommen wird, und eine bewusste Entscheidung darüber, was nicht mitkommt. Ein CRM mit erkennbar falschen Daten wird in den ersten zwei Wochen abgelehnt und danach umgangen. Diese Wahrnehmung lässt sich später kaum korrigieren.
5. Der Vertrieb erfährt vom Projekt, als es fertig ist
Dieses Muster ist das teuerste, weil es sich technisch nicht reparieren lässt.
Ein CRM verändert für Vertriebsmitarbeitende vor allem eines: Ihre Arbeit wird sichtbar. Das ist der eigentliche Kern des Widerstands, und er wird selten offen ausgesprochen. Stattdessen heißt es, das System sei umständlich oder die Felder passten nicht. Wer diesen Punkt erst beim Go-live adressiert, verhandelt aus einer schlechten Position, weil das System dann schon steht.
Woran man es erkennt: Im Projektteam sitzt niemand, der das System täglich benutzen wird.
Was hilft: Zwei bis drei Personen aus dem Vertrieb ab der Anforderungsaufnahme einbinden, nicht als Feigenblatt, sondern mit Entscheidungsrecht über Pflichtfelder. Und ehrlich benennen, dass Transparenz Teil des Zwecks ist. Der Vertrieb weiß das ohnehin, und ein ausgesprochener Zielkonflikt ist leichter zu bearbeiten als ein unausgesprochener.
6. Betriebsrat und Datenschutz kommen zuletzt
Im deutschsprachigen Raum ist dieses Muster besonders folgenreich, weil es ein fertiges System blockieren kann.
Auswertungen mit Personenbezug, etwa Aktivitätsübersichten je Mitarbeitendem oder Bearbeitungszeiten, berühren die Mitbestimmung. Wo ein Betriebsrat besteht, gehört die Ausgestaltung früh abgestimmt. Wir haben Projekte gesehen, in denen die Technik stand und die Nutzung monatelang wartete, weil diese Abstimmung erst nach der Umsetzung begann.
Dasselbe gilt für die Datenschutzfreigabe. Verarbeitungszwecke, Aufbewahrungsfristen, Rollenkonzept und die Frage, wohin Support-Zugriffe erfolgen: Das sind keine Formalien, die sich nachreichen lassen, sondern Vorgaben, die die Konfiguration beeinflussen.
Woran man es erkennt: Im Projektplan taucht „DSGVO-Prüfung“ als Punkt kurz vor dem Go-live auf.
Was hilft: Beide Themen in Woche eins ansprechen. Sie kosten dann Zeit im Zeitplan und nicht das Projekt.
7. Nach dem Go-live kümmert sich niemand mehr
Der Go-live wird als Ziellinie behandelt. Tatsächlich ist er der Punkt, an dem sich entscheidet, ob das System benutzt wird.
In den ersten Wochen zeigt sich, welche Felder niemand ausfüllt, welche Automatisierung an einem Sonderfall scheitert und welcher Bericht die Zahl anders rechnet als die Geschäftsführung erwartet. Wer diese Phase nicht einplant, hat ein System, das formal läuft und an dem das Team vorbeiarbeitet: Angebote weiterhin in Excel, Notizen weiterhin im Kopf.
Woran man es erkennt: Das Budget endet mit dem Go-live-Termin.
Was hilft: Vier bis sechs Wochen Nacharbeit fest einplanen, mit einem festen Ansprechpartner und dem ausdrücklichen Auftrag, Dinge wieder zu entfernen. Streichen ist in dieser Phase wertvoller als Ergänzen.
Das Muster hinter den Mustern
Sechs der sieben Punkte haben eines gemeinsam: Sie entstehen vor der ersten Konfiguration und werden erst am Ende sichtbar. Deshalb wirkt ein gescheitertes CRM-Projekt im Rückblick wie ein Softwareproblem, obwohl die Weichen längst vorher gestellt wurden.
Daraus folgt eine unbequeme Konsequenz für die Auswahl eines Partners: Wer Ihnen im Erstgespräch sofort eine Demo zeigt, arbeitet an der falschen Stelle. Die relevanten Fragen zu Beginn sind, welches Problem gelöst werden soll, wer das System täglich benutzen wird und wie die Datenlage aussieht. Erst danach ist die Frage nach dem System sinnvoll zu beantworten.
Wir sind Zoho Premium Partner, und wir sagen das offen, damit Sie unsere Empfehlung einordnen können. In der Analysephase arbeiten wir dennoch anforderungsgetrieben: Die Anforderungsliste, die dabei entsteht, gehört Ihnen und lässt sich auch für eine Ausschreibung bei anderen Anbietern verwenden.
