Warum die Migration zu einem neuen CRM oder ERP schwieriger ist, als es aussieht — und was sie wirklich zum Erfolg macht

Es gibt eine Version der CRM- oder ERP-Migrationsgeschichte, die gut ausgeht. Das Unternehmen entscheidet sich für den Wechsel, exportiert seine Daten, ordnet die Felder zu, führt eine Validierung durch, löst die Probleme und geht an einem festgelegten Datum live. Das Team wird geschult. Das alte System wird abgeschaltet. Innerhalb weniger Wochen ist das neue System zur eigentlichen Arbeitsumgebung geworden, und niemand vermisst das alte.

Diese Version gibt es, aber sie ist nicht die typische. Häufiger dauert die Migration zwei- bis dreimal so lange wie geplant, bringt erhebliche Datenqualitätsprobleme mit sich und führt zu einem System, das ein nennenswerter Teil des Teams stillschweigend weiter umgeht. Um zu verstehen, warum das so ist — und was die erfolgreichen Fälle gemeinsam haben —, muss man zunächst erkennen, dass das größte Risiko nicht in der Technologie liegt.

Das Verzögerungsproblem: zu lange an dem festhalten, was gerade noch ausreicht

Unternehmen, die ihr aktuelles System bereits hinter sich gelassen haben, wechseln selten in dem Moment, in dem ihnen das bewusst wird. Sie wechseln erst nach Monaten oder Jahren, in denen sich Workarounds angehäuft haben: zusätzliche Tabellenkalkulationen, die Lücken füllen, E-Mail-Verläufe, die Informationen transportieren, die das System nicht abbilden kann, manuelle Doppelerfassung zwischen Tools, die nie dafür gedacht waren, miteinander zu kommunizieren. Die Verzögerung ist für den Einzelnen rational — ein Wechsel ist störend, und die Workarounds funktionieren gerade gut genug, um die Woche zu überstehen —, aber sie verschärft das zugrunde liegende Problem.

Mit jedem Monat, den ein Unternehmen auf einem System arbeitet, das es bereits überwachsen hat, sammeln sich mehr Daten in Formaten an, die nicht zu dem passen, wohin sie eigentlich gehören. Die Konventionen werden immer impliziter. Immer mehr Arbeitsabläufe richten sich nach den Einschränkungen des bestehenden Systems. Bis die Migrationsentscheidung endlich getroffen wird, ist das Problem erheblich größer, als es im ersten Moment des offensichtlichen Herauswachsens gewesen wäre.

Besonders deutlich zeigt sich das beim Übergang von Tabellenkalkulationen zu einem strukturierten System. Aus einer einzigen zentralen Kundenliste sind fünfzehn Versionen geworden, gepflegt von unterschiedlichen Personen in unterschiedlichen Abteilungen, mit uneinheitlichen Spaltennamen, unterschiedlichen Konventionen zur Erfassung von Beziehungen und unterschiedlichem Vollständigkeitsgrad. Der Umfang der notwendigen Migrationsarbeit hängt zum Teil davon ab, wie lange die Migration hinausgezögert wurde — und in Unternehmen, die traditionell mit Tabellenkalkulationen arbeiten, fällt diese Verzögerung fast immer länger aus, als sie sollte.

Die Falle der „sauberen Daten zuerst“

Die zuverlässigste Überzeugung, die eine Migration verzögert, ist der Glaube, die Daten müssten erst bereinigt werden, bevor die Migration beginnen kann. Die Überlegung ist nachvollziehbar: Niemand möchte ein Durcheinander in ein neues System importieren und anschließend mit den Folgen leben. In der Praxis wird „saubere Daten zuerst“ jedoch zu einem Projekt, das nie endet.

Der Aufwand für die Datenbereinigung dauert länger als erwartet. Sonderfälle häufen sich. Mitarbeitende entdecken Unstimmigkeiten, von denen sie nichts wussten. Während der Bereinigungsphase entstehen im alten System neue Datensätze, die ebenfalls bereinigt werden müssen. Entscheidungen darüber, was als Duplikat gilt, wie mit Kontakten umzugehen ist, die seit drei Jahren nicht mehr aktiv waren, und wie Datensätze zu behandeln sind, die in einem System existieren, im anderen aber nicht, werden zu umstrittenen organisatorischen Fragen statt zu technischen Aufgaben. Bis die Daten schließlich für bereit erklärt werden, sind Monate vergangen, und die Einführung des neuen Systems hat ihren Schwung verloren — und oft auch ihren Projektverantwortlichen.

Der wirksamere Ansatz besteht darin, das zu migrieren, was wirklich zählt, zu akzeptieren, dass manche Datensätze erst nach der Migration bereinigt werden müssen, und den Importprozess selbst zu nutzen, um Probleme aufzudecken und zu lösen. Ein gut konzipiertes Import-Tool — eines, das Ihre Daten auf die Zielstruktur abgebildet zeigt, Duplikate und Formatverstöße kennzeichnet und Ihnen erlaubt, diese vor der endgültigen Übernahme zu klären oder zu überschreiben — findet Datenqualitätsprobleme schneller als eine tabellenbasierte Bereinigung, weil das Tool das Zieldatenmodell kennt und genau sagen kann, wogegen ein Datensatz verstößt. Eine Datenbereinigung, die während eines strukturierten Imports stattfindet, unterscheidet sich qualitativ von einer Bereinigung, die isoliert davor stattfindet.

Wirklich sauber sein müssen vor der Migration nur die aktiven Datensätze. Historische Kontakte ohne Aktivität seit zwei Jahren, überholte Produkte, abgeschlossene Deals aus drei zurückliegenden Geschäftsjahren — diese können unverändert migriert, archiviert oder ganz zurückgelassen werden. Das Unternehmen kann problemlos mit einem neuen System arbeiten, das saubere aktive Datensätze und ein ruhendes Archiv historischer Daten enthält, in das ohnehin niemand regelmäßig hineinschaut.

Was wirklich migriert werden muss — und was nicht

Einer der kontraproduktivsten Instinkte bei einer Migration ist der Wunsch, alles mitzunehmen. Wenn Sie ohnehin die Unterbrechung einer Migration in Kauf nehmen, sollten Sie doch gleich alle Datensätze, die gesamte Historie und alle angehängten Dokumente übertragen — und im Idealfall auch jeden Report und jeden automatisierten Workflow aus dem alten System im neuen nachbauen. Das maximiert zwar den Umfang, die Kosten und die Dauer der Migration, aber nicht im gleichen Maß den gelieferten Wert.

Die meisten historischen Daten, die älter als zwei bis drei Jahre sind, werden im normalen Tagesgeschäft nicht mehr abgerufen. Der Nachbau alter Reports, die für aktuelle Geschäftsentscheidungen keine Rolle mehr spielen, kostet Zeit, ohne Wert zu schaffen. Individuelle Automatisierungen, die für einen früheren Arbeitsablauf gebaut wurden, spiegeln oft eher wider, wie das Unternehmen früher gearbeitet hat, als wie es heute arbeitet — sie originalgetreu nachzubauen, repliziert Einschränkungen, die man eigentlich hätte abschaffen können.

Die bessere Frage lautet nicht „Was existiert im alten System?“, sondern „Was braucht das Team, um vom ersten Tag an im neuen System arbeitsfähig zu sein?“ Die Antwort lautet in der Regel: aktive Kontakte und Kunden, offene Deals und Opportunities, aktuelle Preise und Produktinformationen sowie genug Historie, um mit einem anrufenden Kunden ein sinnvolles Gespräch führen zu können. Das ist meist nur ein Bruchteil dessen, was im alten System existiert — und einen Bruchteil zu migrieren ist schneller, risikoärmer und leichter zu validieren, als alles zu migrieren.

Die zwei Arten des Migrationsscheiterns: technisch und menschlich

Über technisches Scheitern wird am meisten gesprochen. Beschädigte Datensätze, Fehler beim Feld-Mapping, die eine Telefonnummer in einem Adressfeld für Unternehmen landen lassen, Beziehungen zwischen Datensätzen, die zerbrechen, weil sich die Fremdschlüsselstruktur zwischen den Systemen unterscheidet, Integrationen, die gegen die alte API funktionierten und für die es im neuen System kein Äquivalent gibt. Diese Fehler sind real und kommen vor, besonders bei Migrationen aus Systemen mit eigenwilligen Datenmodellen oder aus Tabellenkalkulationen, in denen die Struktur uneinheitlich ist und Konventionen eher stillschweigend gelten als durchgesetzt werden.

Menschliches Scheitern ist weniger sichtbar und deutlich häufiger. Es tritt auf, wenn die technische Migration vollständig gelingt — die Daten sind im neuen System, die Felder korrekt zugeordnet, die Validierungen bestanden — und die Menschen es trotzdem nicht nutzen. Sie melden sich gelegentlich an, um einer Aufforderung der Führungskraft nachzukommen. Ihre eigentlichen Datensätze pflegen sie weiterhin woanders. Sie finden Gründe, warum ihre spezielle Situation nicht ganz zum Workflow des neuen Systems passt — was etwas anderes ist als „dem neuen System fehlt die Funktion“. Es bedeutet, dass das System die Funktion zwar besitzt, sie aber anders funktioniert als erwartet, und die Reibung des neuen Workflows die Motivation zur Veränderung übersteigt.

Menschliches Scheitern lässt sich nicht durch mehr Schulung lösen — die häufigste organisatorische Reaktion. Schulungen schließen Wissenslücken. Sie schließen keine Motivationslücken und keine Reibungslücken im Workflow. Wer nach einer Migration aufhört, ein neues System zu nutzen, weiß in der Regel sehr wohl, wie man es bedient. Die Nutzung wird eingestellt, weil sie für die konkreten täglichen Aufgaben langsamer ist als der gewohnte Workaround, weil das System persönlich nichts bietet, was vorher nicht schon vorhanden war, oder weil die organisatorische Dynamik eine fortgesetzte Nichtnutzung folgenlos zulässt.

Die Falle des Parallelbetriebs

Der klassische Ratschlag lautet, altes und neues System parallel zu betreiben, bis Vertrauen in das neue System entstanden ist. Im Prinzip verringert das Risiko: Sollte das neue System ausfallen oder unzuverlässige Daten liefern, bleibt das alte verfügbar. In der Praxis ist der Parallelbetrieb jedoch einer der zuverlässigsten Indikatoren für eine gescheiterte Migration.

Wenn Mitarbeitende beide Systeme aktualisieren können, pflegen sie in der Praxis keines von beiden konsequent. Die Daten laufen innerhalb weniger Tage auseinander. Das neue System zeigt eine bestimmte Gesamtzahl offener Deals; das alte eine andere. Ein Kundendatensatz im neuen System verzeichnet den letzten Kontakt vor zwei Wochen; das alte System zeigt einen gestrigen Anruf, der dort aus Gewohnheit erfasst wurde. Eine Entscheidung auf Grundlage des neuen Systems fällt anders aus als dieselbe Entscheidung auf Grundlage des alten. Das Team verliert das Vertrauen in beide Systeme, weil keines von ihnen maßgeblich ist — das genaue Gegenteil dessen, was die Migration eigentlich bewirken sollte.

Organisationen, deren Migration gelingt, vollziehen sie in der Regel als harten Umstieg: einen festen Stichtag, ab dem das alte System nur noch lesbar oder gar nicht mehr zugänglich ist und das neue System die einzige Option darstellt. Das entfernt das Sicherheitsnetz und ersetzt es durch Dringlichkeit. Gibt es Probleme mit dem neuen System, werden sie gelöst, weil es keine Alternative gibt. Das Unbehagen der Umstellung wird vorgezogen und dann aufgelöst. Der Parallelbetrieb hingegen verteilt das Unbehagen über Monate, ohne je die zugrunde liegende Frage zu klären, welches System nun tatsächlich maßgeblich ist.

Die Excel-Ausweichlösung

Für Unternehmen, die von Tabellenkalkulationen statt von einem anderen strukturierten System wechseln, gibt es ein Fehlermuster, das bei System-zu-System-Migrationen nicht auftritt: die Excel-Ausweichlösung. Weil jeder bereits weiß, wie man eine Tabelle bedient, und weil Tabellenkalkulationen für bestimmte Aufgaben tatsächlich leistungsfähig sind — Ad-hoc-Analysen, flexibles Layout, kein Login, kein Berechtigungsmodell —, greifen Mitarbeitende, denen das neue System noch fremd ist, sofort wieder darauf zurück. Nicht weil dem neuen System die Fähigkeit fehlt. Sondern weil das mentale Modell und die eingeübte Routine bereits vorhanden sind, und die Reibungskosten, einen bereits beherrschten Arbeitsablauf neu zu lernen, real sind, selbst wenn am Ende dasselbe Ergebnis steht.

Die Excel-Ausweichlösung lässt sich besonders schwer schließen, weil Tabellenkalkulationen für manche Zwecke durchaus legitim sind. Sie wollen niemandem verbieten, Szenarien in Excel zu modellieren oder Ad-hoc-Pivot-Tabellen zu bauen. Verhindern wollen Sie, dass eine Tabelle zum primären Datensatz für aktive Kunden, offene Deals, Lagerbestände oder alles andere wird, das eigentlich im neuen System geführt werden soll. Die Grenze ist oft unklar, und ohne eine klar durchgesetzte Richtlinie darüber, was im System geführt wird und was in einer persönlichen Tabelle geführt werden darf, leert sich das System nach und nach, weil die eigene Version schneller zu pflegen ist. Das neue System wird zu einer reinen Reporting-Ebene statt zur tatsächlichen Arbeitsumgebung — dieselbe Dynamik, die auch die CRM-Einführung scheitern lässt, nur aus einer anderen Richtung erreicht.

Wie gutes Onboarding tatsächlich aussieht

Erfolgreiche Einführungen weisen tendenziell Merkmale auf, die unabhängig davon sind, welche Plattform gewählt wurde.

Das erste Merkmal ist ein namentlich benannter fachlicher Verantwortlicher für die Migration — keine IT-Leitung, deren Aufgabe es ist, das technische Projekt zu steuern, sondern eine Person aus dem Fachbereich, deren Aufgabe die Sicherstellung der Nutzung ist. Diese Person legt fest, welche Daten wichtig sind, trifft die Entscheidungen darüber, was in welchem Zustand migriert wird, setzt den Stichtag für den Umstieg fest und setzt ihn durch, und kümmert sich um Situationen, in denen eine Abteilung das alte System oder die eigenen Tabellen weiter nutzen möchte. Ohne diese Person ist die Migration ein Technologieprojekt statt eines betrieblichen Wandels — und Technologieprojekte ohne fachliche Verantwortung liefern zuverlässig zu wenig.

Das zweite Merkmal ist ein an einem festen Stichtag voll funktionsfähiges System statt eines sich hinziehenden, phasenweisen Rollouts. Startet das neue System in unvollständigem Zustand — manche Funktionen verfügbar, andere folgen später, manche Integrationen noch nicht fertig —, umgehen Mitarbeitende die Lücken mit alten Werkzeugen. Die Gewohnheit, das neue System zu umgehen, etabliert sich, bevor das System voll funktionsfähig ist, und hält an, auch nachdem die Lücken geschlossen wurden. Es ist deutlich einfacher, ein vollständiges System an einem klaren Stichtag einzuführen, als ein unvollständiges über Monate hinweg schrittweise einzuführen.

Das dritte Merkmal ist, den Importprozess selbst als Stufe der Datenqualitätssicherung zu behandeln statt als vorgelagerte Hürde. Die besten Onboarding-Tools zeigen Ihre Daten, abgebildet auf die Struktur des neuen Systems, bevor irgendetwas endgültig übernommen wird, weisen genau auf die Datensätze und Felder hin, die gegen das Zielmodell verstoßen, erlauben es, jedes Problem zu klären oder zu überschreiben, und bieten für ein angemessenes Zeitfenster nach der Übernahme eine Rollback-Option. Das Unternehmen braucht keine sauberen Daten, bevor der Prozess beginnt — es braucht einen Prozess, der die Daten am Ende sauber macht.

Die Plattformfrage im Moment der Migration

Migrationen sind Wendepunkte. Ein Unternehmen, das sich entschieden hat, von Excel oder einem CRM der ersten Generation zu wechseln, verfügt in diesem Moment über mehr Aufmerksamkeit für die eigenen Daten und mehr organisatorische Erlaubnis, die Art der Datenspeicherung und des Datenzugriffs neu zu strukturieren, als zu jedem anderen Zeitpunkt bis zur nächsten Migration. Die Frage, wohin migriert werden soll, ist nicht bloß ein Funktionsvergleich — es ist eine strukturelle Entscheidung darüber, ob die Fragmentierung gleichzeitig mit dem Plattformwechsel angegangen wird oder erneut aufgeschoben wird.

Ein Unternehmen, das seine CRM-Daten auf eine Plattform migriert, auf der dieselben Datensätze auch für Rechnungsstellung, Lagerbestand, Buchung und Kundenservice zugänglich sind, hat die Integrationsarbeit einmalig erledigt und die laufenden Kosten für die Synchronisierung getrennter Systeme eliminiert. Ein Unternehmen, das sein CRM auf eine neue eigenständige CRM-Plattform migriert und dabei separate Systeme für Buchhaltung, Lager und Kundenservice beibehält, verschiebt diese Integrationsarbeit nur und zahlt die Kosten für die Integrationspflege dauerhaft weiter — in Entwicklungszeit, in Abstimmungsaufwand und in der Qualität von Entscheidungen, die auf unvollständigen Daten beruhen.

Für die meisten Unternehmen ist der integrierte Ansatz im Moment der Migration die langfristig bessere Entscheidung, auch wenn er die Migration selbst komplexer macht. Die Komplexität, zwei oder drei Systeme zu einem einzigen Zeitpunkt in eine Plattform zu migrieren, ist begrenzt und vorübergehend. Die Komplexität, zwei oder drei über Punkt-zu-Punkt-Integrationen verbundene Systeme dauerhaft zu betreiben, ist unbegrenzt und dauerhaft. Migrationen sind der Moment, in dem diese Entscheidung getroffen wird — und sie lässt sich leichter treffen, solange sich die Organisation ohnehin schon in der Haltung befindet, ihre Arbeitsweise zu verändern, als zu jedem anderen Zeitpunkt.

---