Skip to content

Dieselben Daten dreimal eingeben? So verbinden Sie E-Mail, CRM und ERP sinnvoll

Dieselbe Adresse im CRM, im Angebot und noch einmal in der Bestätigungsmail: Wie lässt sich diese Mehrfacheingabe vermeiden? Ein Beispiel zeigt, welche Datenübergaben und Zuständigkeiten Sie dafür klären sollten.

Ein Briefumschlag, eine Kontaktkartei und eine Auftragsablage sind durch eine Bahn mit gleich markierten Datenkarten verbunden.

Eine Anfrage, mehrere Eingabemasken

Stellen Sie sich einen einfachen Ablauf vor: Eine Kundenanfrage kommt per E-Mail. Der Verkaufsinnendienst übernimmt die Firmenadresse ins CRM. Für das Angebot trägt er dieselbe Adresse als Lieferadresse ins ERP ein und kopiert sie anschließend noch einmal in eine Bestätigungsmail. Dann meldet der Kunde: Geliefert werden soll an die Baustelle. Welche Stelle wird jetzt geändert?

Das ist ein Beispiel, keine Kundenreferenz. Für die Lösung würde ich zunächst die Übergaben anschauen: Welche Angaben werden tatsächlich gebraucht, wo werden sie gepflegt und wer darf sie ändern? Erst danach lohnt sich die Entscheidung über eine technische Verbindung.

Für jedes Feld festlegen, welche Stelle zuständig ist

Ich empfehle, nicht pauschal ein Programm zum Chef aller Daten zu erklären. Legen Sie stattdessen pro Information fest, wo der verbindliche Wert gepflegt wird. Diese Stelle nennen wir das führende System. Eine Nachricht vom Kunden wäre in unserem Beispiel zunächst ein Änderungshinweis, noch keine ungeprüfte Anweisung an alle Programme.

Für den Ansprechpartner könnte die Kundenverwaltung zuständig sein. Die bestätigte Lieferadresse für einen bestimmten Auftrag würden wir dagegen in der Auftragssoftware pflegen. Das sind Vorschläge für unser Beispiel, keine allgemeine Regel für CRM und ERP. Bestehende Zuständigkeiten Ihres Betriebs haben Vorrang.

Unsere kleine Übergabetabelle hilft bei der Abstimmung. Sie beschreibt jeweils die vereinbarte Richtung, keine automatische Übertragung beliebiger Änderungen.

InformationUrsprung und ZielWer darf ändern?Was bleibt bei Unklarheit offen?
FirmenadresseIm CRM gepflegt; beim Anlegen des Angebots als Vorschlag für die Lieferadresse ins ERP übernommenZuständiger Innendienst im CRMAbweichende Lieferadresse: Vorschlag nicht ungeprüft übernehmen
AnsprechpartnerBeim Anlegen aus dem CRM ins ERP übernommen; spätere Änderungen für offene Vorgänge zur Prüfung vorschlagenZuständiger Innendienst im CRMMehrere passende Kontakte: Zuordnung prüfen
Lieferadresse des AuftragsIm ERP bestätigt; Änderungsmail zunächst nur als Hinweis behandelnZuständige AuftragsbearbeitungUnklarer Auftrag: Adresse nicht automatisch ändern
AnfragenummerIm CRM vergeben, als Referenz ins ERP übernommenVergabe im CRM; als feste Referenz unverändert übernehmenReferenz fehlt: Übergabe zur Klärung markieren

Die erste Erfassung aus der eingehenden Mail würden wir im Beispiel beim Innendienst belassen. Für die Bestätigungsmail empfehlen wir dagegen eine Vorlage, die die bestätigte Lieferadresse aus dem ERP übernimmt. Der Mitarbeiter prüft die Mail vor dem Versand. So müssen wir weder eine automatische Auswertung jeder Eingangsmail noch einen automatischen Versand voraussetzen.

So wird aus „Wir müssen CRM und ERP verbinden“ ein konkreter Auftrag: Diese Felder sollen zu diesem Zeitpunkt in diese Richtung übertragen werden. Eine Rückübertragung braucht eine eigene Regel. Sie ist kein Häkchen, das man vorsorglich überall setzt.

Den Vorgang wiedererkennen, bevor Daten übernommen werden

In unserem Beispiel bekommt die Anfrage im CRM die Kennung A-1042. Wenn daraus ein Angebot im ERP entsteht, soll dort dieselbe Kennung als Referenz stehen. Die interne Angebotsnummer des ERP darf davon abweichen; wir würden beide Nummern zusammen im ERP speichern.

Bei einer späteren Änderung soll die Verbindung damit den vorhandenen Vorgang finden, statt erneut einen anzulegen. Für unser Beispiel würden wir festlegen, wo die Zuordnung erfolgt: im CRM, im ERP oder in der Software, die beide verbindet. Anschließend testen wir den Abgleich mit einer bestehenden Anfrage.

Wie eine solche Zuordnung aussehen kann, zeigt ein Herstellerbeispiel: Microsoft beschreibt für seine Datenplattform Dataverse sogenannte alternative Schlüssel. Damit lassen sich Datensätze anhand eindeutiger Geschäftsfelder statt ausschließlich über die interne Kennung identifizieren und mit externen Daten zuordnen. Ob und wie Ihre Programme etwas Vergleichbares erlauben, gehört in die technische Prüfung.

Praxis-Kniff: Verfolgen Sie eine abgeschlossene Anfrage vom Postfach über das CRM bis ins ERP. Notieren Sie für jede Station dieselben fünf Angaben: Anfragenummer, Kunde, Ansprechpartner, Lieferadresse und Bearbeitungsstand. Markieren Sie, was jemand erneut eintippt und wo nicht klar ist, ob noch derselbe Vorgang gemeint ist. Nutzen Sie die Notiz zunächst intern, ohne Kundendaten in ein zusätzliches Online-Werkzeug zu kopieren.

Den Änderungsfall gleich mitplanen

Für die erste Übertragung mag unser Beispiel einfach aussehen. Die interessantere Probe ist die zweite E-Mail: „Bitte an die Baustelle liefern, nicht an unsere Firmenadresse.“ Ich würde vor der Umsetzung folgende Fragen klären:

  • Auf welchen Auftrag bezieht sich die Nachricht?
  • Wer bestätigt die neue Lieferadresse?
  • Wo wird sie verbindlich gespeichert?
  • Welche anderen Stellen benötigen die bestätigte Änderung?

In unserem Beispiel prüft der zuständige Mitarbeiter die Zuordnung und ändert die Auftragsadresse im ERP. Die allgemeine Firmenadresse im CRM bleibt bestehen. Falls der Vertrieb die Lieferadresse dort sehen muss, würden wir sie getrennt als auftragsbezogene Information anzeigen. Für den Kunden bereitet die Vorlage eine Bestätigung der geänderten Adresse vor, die der Mitarbeiter vor dem Versand prüft. Wir würden nicht automatisch die Stammdaten des Kunden überschreiben. Auch umgekehrt empfehlen wir eine Grenze: Eine neue Firmenadresse im CRM sollte die bestätigte Lieferadresse eines offenen Auftrags nicht ungeprüft ersetzen.

Prüfen Sie außerdem, was passieren soll, wenn derselbe Wert trotz vereinbarter Zuständigkeit in beiden Programmen geändert wurde. Für den Einstieg empfehle ich, die Abweichung zur Klärung vorzulegen und vorerst nichts zu überschreiben. Eine nötige Korrektur erfolgt dann im führenden System. Reine Kopien würden wir gegen direkte Bearbeitung sperren und Änderungswünsche an die zuständige Person weitergeben. Die Auftrags-Lieferadresse ist dagegen ein eigenes Feld und bleibt im ERP bearbeitbar.

Eine Schnittstelle ist noch keine fertige Verbindung

Eine API ist eine definierte Softwareschnittstelle, über die Programme miteinander kommunizieren und Daten austauschen können. Vor einer Umsetzung würden wir mit dem jeweiligen Anbieter oder Betreuer prüfen, welche Informationen darüber lesbar und änderbar sind. Auch Berechtigungen, Pflichtfelder und verfügbare Zugänge gehören auf diese Liste.

Mein Vorschlag: Beginnen Sie mit einer Übergabe und wenigen Feldern. Testen Sie neben dem normalen Ablauf auch einen fehlenden Wert, eine Änderung und eine unterbrochene Übertragung. Halten Sie fest, wer einen ungeklärten Fall übernimmt.

Gerade beim letzten Test ist Vorsicht sinnvoll. Microsoft weist in seiner Beschreibung des Retry-Musters – der Wiederholung fehlgeschlagener Aufrufe – auf folgenden Fall hin: Ein Dienst kann einen Auftrag schon verarbeitet haben, obwohl seine Antwort nicht ankommt. Eine Wiederholung kann dann dieselbe Aktion nochmals auslösen.

Deshalb würde ich bei unklarem Ergebnis zunächst anhand der Vorgangskennung prüfen lassen, ob der Eintrag bereits vorhanden ist. Bei einer Änderung prüfen wir zusätzlich den aktuellen Wert im Zielsystem. Eine automatische Wiederholung gehört nur in den Ablauf, wenn für diese konkrete Aktion geklärt ist, wie doppelte Einträge oder andere doppelte Auswirkungen vermieden werden. Den betrieblichen Fehlerweg legen wir dabei ebenso fest wie die Feldzuordnung.

Wo KI infrage kommt – und wo ich mit Regeln starten würde

Für die Übernahme einer bestätigten Anfragenummer aus einem festen Feld würde ich zuerst eine regelbasierte Verbindung prüfen. Dafür müssen wir keine KI einplanen.

Bei frei formulierten E-Mails wäre eine andere Frage sinnvoll: Kann eine KI für diesen Ablauf einen brauchbaren Vorschlag machen, welche Anfrage gemeint ist und welche Angaben geändert werden sollen? Das müsste ein Test mit anonymisierten oder eigens erstellten Beispielen zeigen. Vor dem Test klären wir Anbieter und Datenverarbeitung; vor einem Einsatz mit echten Kundenmails zusätzlich die dafür erforderlichen Vereinbarungen, Zugriffe und Speicherorte. Den Vorschlag würde ich zunächst prüfen lassen, bevor er Daten im Zielsystem verändert.

Diese Aufgaben würde ich getrennt behandeln: Informationen aus einer Nachricht vorschlagen lassen, die Zuordnung bestätigen und erst dann festgelegte Felder übertragen.

Fazit: Erst die Übergabe klären, dann die Programme verbinden

Meine Empfehlung: Wählen Sie eine doppelte Eingabe, die regelmäßig anfällt oder bereits Nacharbeit verursacht hat, und notieren Sie deren Häufigkeit. Legen Sie fest, wo der verbindliche Wert entsteht, wie der Vorgang wiedererkannt wird und wer Änderungen bestätigt. Damit lässt sich viel genauer besprechen, was eine Verbindung leisten soll und was bewusst beim Mitarbeiter bleibt.

Als TRIXNER digital solutions unterstützen wir bei der Analyse und Umsetzung solcher Verbindungen. Beschreiben Sie im ersten Gespräch die beteiligten Programme und eine konkrete Übergabe; lassen Sie echte Kundendaten bitte weg. Gemeinsam klären wir, welche Zugänge vorhanden sind und welcher nächste Schritt sinnvoll ist. Mehr zu unserer Entwicklung und Systemintegration.

Sources and Further Reading

Next Step

Apply the Question to Your Own Company.

In the discovery call, we assess your specific situation and define a realistic next step.

Martin Trixner
AuthorMartin Trixner

Founder and Technical Lead of TRIXNER digital solutions. Building digital processes, integrations and applications since 2002; certified AI Automations Manager (Everlast Consulting).