Michael Spitzner
CRM + ERP · PRAXIS & ARCHITEKTUR
Ein CRM kann technisch sauber eingeführt sein – und für die tägliche Vertriebsarbeit trotzdem wichtige Informationen vermissen lassen. Welche Entscheidungen vor der ersten Schnittstelle wichtig sind.
Systemgrenzen sind keine Prozessgrenzen.
Kundenstammdaten, Umsätze oder Aufträge liegen je nach Systemlandschaft im ERP. E-Mails und Termine entstehen in der Arbeitsumgebung der Nutzer. Weitere Informationen können in Fachanwendungen stecken.
Wenn diese Grenzen erst nach dem CRM-Design betrachtet werden, entsteht ein zusätzliches Frontend: Nutzer arbeiten im CRM – und suchen den Kontext für ihre Entscheidungen weiterhin anderswo.
Diese Frage hilft oft mehr als die anfängliche Liste aller Anwendungen, die technisch miteinander verbunden werden könnten.
KONKRETE ARBEITSSITUATION
Ein Vertriebsmitarbeiter öffnet die Opportunity für den nächsten Kundentermin. Kontakt- und Opportunity-Daten sind vorhanden. Für die nächste Entscheidung benötigt er aber möglicherweise auch Auftragsstatus, Umsatzentwicklung oder offene Vorgänge aus anderen Systemen.
Die Lösung ist nicht automatisch, diese Daten vollständig in das CRM zu kopieren. Zuerst ist zu klären, welcher Kontext für diese konkrete Arbeit notwendig ist, wie aktuell er sein muss und welches System fachlich führend bleibt.
Schematische Arbeitssituation zur Veranschaulichung – kein dokumentierter Kundenscreenshot.
ARCHITEKTUR ALS ARBEITSMODELL
Ein nutzbares CRM-Modell verbindet Entscheidungen im Arbeitsalltag mit den passenden Datenquellen und Ereignissen. Zwischen den Systemen braucht es nicht nur Datenfluss, sondern auch verlässliche Fehler- und Ausnahmewege.
DREI ENTSCHEIDUNGEN VOR DER ERSTEN SCHNITTSTELLE
01 · DATENVERANTWORTUNG
Für jedes wichtige Objekt klären: Welches System ist führend? Welche Informationen benötigt das CRM? Werden sie gespeichert, synchronisiert oder bei Bedarf gelesen? Wer löst Konflikte auf?
02 · ARBEITSKONTEXT
Von realen Aufgaben ausgehen: Lead qualifizieren, Opportunity bearbeiten, Besuch vorbereiten, Forecast aktualisieren. Nur den dafür notwendigen Kontext einplanen.
03 · EREIGNISSE
Ein Kunde wird angelegt, ein Status ändert sich, eine Anfrage trifft ein. Für jede relevante Änderung Auslöser, Empfänger, Verantwortung und Fehlerweg bestimmen.
PRAXIS · ANONYMISIERTES CRM-MVP
In einem unserer CRM-Projekte sollte die erste produktive Lösung zentrale Vertriebsarbeit abbilden – darunter Leads und Anfragen, Opportunities, Besuchs- und Kundenkontext sowie Forecasting.
Gleichzeitig blieben relevante Unternehmens- und operative Daten in einer bestehenden ERP-Landschaft. Die entscheidende Architekturfrage war deshalb nicht nur, welche CRM-Objekte benötigt werden. CRM-MVP und Integration mussten gemeinsam betrachtet werden.
Der benötigte ERP-Kontext, historische Informationen und die Verbindung zur bestehenden Arbeitsumgebung gehörten zur Nutzbarkeit des CRM. Die Integrationsschicht war somit Bestandteil des MVP-Designs – kein technisches Projekt, das erst nach der CRM-Einführung beginnt.
Einordnung: anonymisierter Architektur- und Umsetzungsansatz. Keine Aussage zu gemessener Nutzung oder Geschäftswirkung. Vor Veröffentlichung fachliche und Vertraulichkeitsprüfung erforderlich.
UMSETZUNGSREGELN
Das Zielbild folgt dem Kunden- oder Vertriebsprozess – nicht den Grenzen eines Produkts.
Der benötigte Arbeitskontext entscheidet über Lesen, Synchronisieren oder Speichern.
Benötigt der erste CRM-Use-Case Daten oder Ereignisse anderer Systeme, gehören sie zur ersten fachlichen Lieferung.
Monitoring, Wiederanlauf, Verantwortung und Ausnahmefälle sind Teil des Betriebsmodells.
WAS DER ANSATZ NICHT BEWEIST
Ein Architekturkonzept kann fachliche Zusammenhänge und Umsetzungsentscheidungen belegen. Ob das CRM tatsächlich genutzt wird und ob sich Datenqualität, Geschwindigkeit oder Forecasting verbessern, lässt sich daraus allein nicht ableiten.
SELBSTCHECK
Bevor Sie die nächste Schnittstelle spezifizieren, sollten diese Fragen beantwortbar sein:
Wenn die Antworten noch offen sind, ist eine endgültige Schnittstellenspezifikation möglicherweise zu früh.
PASSENDER NÄCHSTER SCHRITT
Im Integration & Transformation Architecture Review klären wir die kritischen System-of-Record-Entscheidungen, den benötigten Arbeitskontext, relevante Ereignisse und das Betriebsmodell – bevor daraus eine Vielzahl isolierter Schnittstellen wird.
Architecture Review ansehenWenn bereits die CRM-Zielprozesse oder der erforderliche Arbeitskontext unklar sind, kann ein Readiness Assessment der frühere Einstieg sein.
