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. Das sind Unternehmen, Kontakt, Deal, Aktivität und Einwilligung. Ins ERP gehört, was den Abschluss abrechnet: Rechnung, Vertrag, Umsatzrealisierung. Alles Weitere leitest du aus diesen beiden Sätzen ab.

Diese Grenze ist keine technische Eigenschaft der Systeme. Gezogen wird sie durch eine Entscheidung, die jemand trifft und aufschreibt. Wo sie nicht aufgeschrieben ist, existiert sie nicht. Ein CRM ohne Grenze wird innerhalb von zwei bis drei Jahren zu einem zweiten, schlechteren ERP.

Warum die Grenze von selbst verschwimmt

In einem gewachsenen CRM findest du regelmäßig Dinge, die dort nichts zu suchen haben. Etwa Rechnungspositionen und Anbindungen ans Finanzsystem oder 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 du darin ERP-Funktionen abbilden kannst. Custom Objects, berechnete Felder und Workflows: Die Bausteine sind da. Kein System sagt an dieser Stelle „nein“. Die Rechnung kommt später, und sie kommt in drei Raten. Die erste ist der Wartungsaufwand für Logik, die niemand mehr erklären kann. Die zweite ist ein Problem mit der Datenqualität, wenn zwei Systeme dieselbe Zahl unterschiedlich ausweisen. Die dritte sind die Migrationskosten beim nächsten Systemwechsel.

Welches Objekt wohin gehört

Die Zuordnung unten ist die Kurzfassung, die in ein Design-Dokument passt. Der eigentliche Inhalt steckt in der Spalte „Was passiert bei Verstoß“. Dort steht, was dich die falsche Einsortierung konkret kostet.

Der strittigste Fall in dieser Liste ist das Angebot. Es entsteht im Vertrieb und enthält Preise. Beide Systeme haben ein plausibles Argument dafür, es besitzen zu wollen. Brauchbar ist diese 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 der sauber aufgesetzte Prozess in HubSpot den Zeitaufwand für Angebote um 80 % gesenkt, und zwar in weniger als zwei Wochen.

Anbinden statt nachbauen

Bei einer Migration ist der Reflex, den geerbten Funktionsumfang eins zu eins mitzunehmen. Schließlich wurde er einmal gebraucht. Eine Gegenfrage halbiert den Umfang: Muss diese Funktion im CRM leben, oder muss das CRM sie nur sehen können?

Meistens 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. Was eine Migration einspart, ist zu einem großen Teil der Aufwand für Logik, die vorher 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. Leg die Prozessmodelle mehrerer Unternehmen derselben Branche übereinander, und sie sind weitgehend deckungsgleich. Unterschiede gibt es bei Benennungen und Zuständigkeiten, dazu kommen ein bis zwei echte Besonderheiten. Die Struktur ist dieselbe.

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

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

Die Grenze hält nur schriftlich

Die Grenze muss vor dem Bau stehen und kann nicht währenddessen entstehen. Der Grund: Ehrlich kommen Anforderungen erst gegen ein laufendes System 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. Das ist keine Nachlässigkeit. Ein laufendes System stellt einfach eine präzisere Frage als ein Workshop.

Hast du die Grenze vorher schriftlich festgehalten, kannst du diese zweite, ehrlichere Runde einbauen, ohne die Architektur neu zu verhandeln. Hast du es nicht, verhandelst du beides gleichzeitig und unter Termindruck.

Der Härtefall: mehrere Gesellschaften, mehrere Backends

Unter einem Dach mit mehreren Gesellschaften ziehst du die Grenze nicht einmal, sondern prüfst sie je Gesellschaft. Jede bringt ihr eigenes Backend mit, oft mit eigener Historie und eigenen Zuständigkeiten. Beschließt du eine Grenze für alle, ohne sie mit jeder Gesellschaft durchzusprechen, bekommst du Widerstand. Oder du bekommst eine Ausnahmeregelung pro Standort, und das ist dasselbe wie keine Grenze.

In dieser Konstellation zählt noch etwas: Erst die gemeinsame Grenze macht einen gemeinsamen Blick auf den Kunden möglich. Solange jede Gesellschaft Kundendaten in anderer Tiefe und an anderer Stelle führt, bleibt eine Frage offen: „Arbeiten wir bereits mit diesem Unternehmen?“ Meist ist das genau die Frage, wegen der das Projekt begonnen wurde. Wie du ein gruppenweites Setup aufsetzt, steht unter gruppenweites CRM.

Woran du merkst, dass keine Grenze gezogen wurde

Vier Anzeichen, und alle sind vor dem Go-live sichtbar:

Das vierte Anzeichen sagt am meisten. Eine Grenze ohne benannten Genehmiger ist nur eine Empfehlung. Und Empfehlungen halten der ersten dringenden Anforderung nicht stand.