CRM und ERP: welche Daten wohin gehören

Die Grenze in einem Satz

Ins CRM gehört, was den Kunden beschreibt und den Weg zum Abschluss abbildet: Unternehmen, Kontakt, Deal, Aktivität, Einwilligung. Ins ERP gehört, was den Abschluss abrechnet: Rechnung, Vertrag, Umsatzrealisierung. Alles Weitere ist eine Ableitung aus diesen beiden Sätzen.

Diese Grenze ist keine technische Eigenschaft der Systeme. Sie ist eine Entscheidung, die jemand trifft und aufschreibt. Wo sie nicht aufgeschrieben ist, existiert sie nicht – und ein CRM ohne Grenze wird über zwei bis drei Jahre zu einem zweiten, schlechteren ERP.

Warum die Grenze von selbst verschwimmt

In einem gewachsenen CRM findet man regelmäßig Dinge, die dort nichts zu suchen haben: Rechnungspositionen, Anbindungen ans Finanzsystem, Workflows, die Daten in ein Backend schieben. Niemand hat das je als Architekturentscheidung getroffen. Es ist entstanden, weil jede einzelne Ergänzung für sich vernünftig aussah.

Der Mechanismus dahinter ist banal und genau deshalb wirksam: Ein modernes CRM lässt sich so weit erweitern, dass ERP-Funktionalität darin abbildbar ist. Custom Objects, berechnete Felder, Workflows – die Bausteine sind da. Kein System sagt an der Stelle „nein". Die Rechnung kommt später, und sie kommt in drei Raten: als Wartungsaufwand für Logik, die niemand mehr erklären kann, als Datenqualitätsproblem, wenn zwei Systeme dieselbe Zahl unterschiedlich ausweisen, und als Migrationskosten beim nächsten Systemwechsel.

Welches Objekt wohin gehört

Die folgende Zuordnung ist die Kurzfassung, die in ein Design-Dokument passt. Die Spalte „Was passiert bei Verstoß" ist der eigentliche Inhalt: Sie beschreibt, was die falsche Einsortierung konkret kostet.

Der strittigste Fall in dieser Liste ist das Angebot. Es entsteht im Vertrieb, es enthält Preise, und beide Systeme haben ein plausibles Argument dafür, es besitzen zu wollen. Die brauchbare Aufteilung: Das Angebot lebt im CRM, weil der Vertrieb damit arbeitet; die Preis- und Rabattlogik bleibt im führenden System und wird angebunden. Bei aumico hat die saubere Aufsetzung dieses Prozesses in HubSpot den Zeitaufwand für Angebote um 80 % gesenkt, erreicht in weniger als zwei Wochen.

Anbinden statt nachbauen

Der Reflex bei einer Migration ist, den geerbten Funktionsumfang eins zu eins mitzunehmen. Er wurde schließlich einmal gebraucht. Die Gegenfrage, die den Umfang halbiert: Muss diese Funktion im CRM leben, oder muss das CRM sie nur sehen können?

In den meisten Fällen reicht sehen. Eine Schnittstelle, die den Status aus dem Backend liest, ist billiger zu bauen und deutlich billiger zu betreiben als eine Nachbildung derselben Logik im CRM – und sie hat einen Eigentümer, nämlich das führende System.

Beide Zahlen stammen aus Projekten, in denen die Grenze vorher gezogen wurde. Das ist kein Zufall: Der Aufwand, den eine Migration einspart, ist zu einem großen Teil der Aufwand, den man vorher für Logik betrieben hat, die im falschen System lag.

„Unsere Prozesse sind anders"

Dieser Satz fällt in fast jedem Projekt, und er ist selten böswillig gemeint. Er kommt aus echter Detailkenntnis. Nur hält er der Prüfung meistens nicht stand: Legt man die Prozessmodelle mehrerer Unternehmen derselben Branche übereinander, sind sie weitgehend deckungsgleich. Was sich unterscheidet, sind Benennungen, Zuständigkeiten und ein bis zwei echte Besonderheiten – nicht die Struktur.

Daraus folgt ein Auswahlkriterium, kein Bequemlichkeitsargument: Wie weit lässt sich ein Prozess im Standard des Systems abbilden, ohne Custom Build? Je näher am Standard, desto billiger ist jedes künftige Update, desto kürzer die Einarbeitung, desto einfacher der nächste Wechsel. Die Besonderheiten kommen als Farbe obendrauf, nicht als Fundament.

Praktisch heißt das: Die Zahl der Custom Objects für Phase 1 wird festgelegt, bevor die erste Anforderung eintrifft, und sie ist an einer Hand abzählbar. Jedes weitere braucht eine Begründung und eine Unterschrift.

Die Grenze hält nur schriftlich

Es gibt einen Grund, warum die Grenze vor dem Bau stehen muss und nicht währenddessen entstehen kann: Anforderungen kommen erst gegen ein laufendes System ehrlich zurück. In der Erhebungsphase beschreiben Menschen ihre Arbeit so, wie sie sie erinnern. Steht der erste funktionierende Stand vor ihnen, fällt regelmäßig der Satz, dass es doch anders sei als beschrieben – nicht aus Nachlässigkeit, sondern weil ein laufendes System eine präzisere Frage stellt als ein Workshop.

Wer die Grenze vorher schriftlich festgehalten hat, kann diese zweite, ehrlichere Runde einbauen, ohne die Architektur neu zu verhandeln. Wer sie nicht festgehalten hat, verhandelt beides gleichzeitig, unter Termindruck.

Der Härtefall: mehrere Gesellschaften, mehrere Backends

Unter einem Dach mit mehreren Gesellschaften wird die Grenze nicht einmal gezogen, sondern je Gesellschaft geprüft. Jede bringt ihr eigenes Backend mit, oft mit eigener Historie und eigenen Zuständigkeiten. Wer hier eine Grenze für alle beschließt, ohne sie je Gesellschaft durchzusprechen, bekommt entweder Widerstand oder eine Ausnahmeregelung pro Standort – was dasselbe ist wie keine Grenze.

Was in dieser Konstellation zusätzlich zählt: Erst die gemeinsame Grenze macht einen gemeinsamen Kundenblick überhaupt möglich. Solange jede Gesellschaft Kundendaten in einer anderen Tiefe und an einer anderen Stelle führt, lässt sich die Frage „arbeiten wir bereits mit diesem Unternehmen" nicht beantworten – und das ist meist die Frage, wegen der das Projekt begonnen wurde. Wie ein gruppenweites Setup aufgesetzt wird, steht unter gruppenweites CRM.

Woran man merkt, dass keine Grenze gezogen wurde

Vier Anzeichen, alle vor dem Go-live sichtbar:

Das vierte ist das aussagekräftigste. Eine Grenze ohne benannten Genehmiger ist eine Empfehlung, und Empfehlungen halten der ersten dringenden Anforderung nicht stand.