Welches System führt welche Daten? ERP, Shop und CRM abgrenzen
Kurz gesagt
Führen Sie jede Datenart in genau einem System und synchronisieren Sie die anderen von dort. Für die Konstellation ERP, Shop und CRM ist ein Vorschlag: Artikel, Basispreise und Bestände führt das ERP, Kundenbeziehungen das CRM, den Bestellstatus das ERP. Die Entscheidungstabelle zeigt je Datenobjekt das führende System, die Sync-Richtung und die vermiedenen Konflikte.
Das Wichtigste
- Jede Datenart gehört in genau ein führendes System; die anderen Systeme lesen von dort.
- Vorschlag für ERP, Shop und CRM: Artikel, Basispreis und Bestand führt das ERP, Sync einseitig ins Shop- und CRM-System.
- Vorschlag: Kontaktdaten des Kunden führt das CRM, Rechnungsdaten das ERP; Sync bidirektional mit Merge-Regel.
- Vorschlag: das ERP führt den Bestellstatus, der Shop legt den Auftrag an; Sync in beide Richtungen.
- Zwei Systeme, die dieselbe Datenart schreiben, erzeugen Konflikte; die Tabelle vermeidet sie je Datenobjekt.
Wenn ERP, Shop und CRM dieselben Artikel, Preise, Kunden und Bestände kennen, entsteht die Frage, wo Sie die Daten pflegen. Die Antwort ist eine klare Zuordnung: Jede Datenart hat genau ein führendes System, und die anderen Systeme übernehmen die Daten per Synchronisation.
Worauf es ankommt
Stammdaten (Master Data) sind Daten, die für alle Geschäftsvorfälle gelten und sich kaum ändern: der Artikel, der vorab bekannte Basispreis, der Kunde als Geschäftspartner. GS1 grenzt sie von Transaktions- und Ereignisdaten ab: Der aktuelle Bestand und der Bestellstatus ändern sich mit jedem Vorgang und sind Transaktions- bzw. Ereignisdaten, keine Stammdaten. Die DAMA-DMBOK, das von DAMA International herausgegebene Referenzwerk für Datenmanagement, gibt die Prinzipien und Funktionen vor, mit denen solche Stammdaten systematisch verwaltet werden.
Das Problem entsteht, wenn zwei Systeme dieselbe Datenart schreiben. Jede Änderung in einem System ist im anderen veraltet, und ohne eine Regel, welches System gewinnt, driften die Werte auseinander. Der Artikel hat im ERP einen anderen Preis als im Shop, der Kunde im CRM eine andere Adresse als im ERP, der Bestand im Shop einen höheren Wert als im Lager.
Das führende System ist die einzige Quelle, in der die Daten gepflegt werden; die anderen übernehmen sie per Synchronisation und schreiben sie nicht selbst. Die Entscheidungstabelle unten zeigt je Datenobjekt das führende System, die Sync-Richtung und den Konflikt, den diese Zuordnung vermeidet.
Die Entscheidungstabelle
Die Tabelle ordnet die fünf Datenobjekte dem führenden System zu. Die Zuordnung ist eine redaktionelle Einschätzung für den typischen Fall eines Handels- oder Dienstleistungsunternehmens mit ERP, Shop und CRM; Ihre Prozesse können eine andere Zuordnung erfordern.
| Datenobjekt | Führendes System | Sync-Richtung | Vermeideter Konflikt |
|---|---|---|---|
| Artikel | ERP (Warenwirtschaft) | ERP → Shop, ERP → CRM | doppelte Artikelstämme, abweichende Artikeltexte und -nummern |
| Preis (Basispreis) | ERP (Warenwirtschaft) | ERP → Shop | Preisabweichung zwischen ERP und Shop |
| Kunde (Kontaktdaten) | CRM | CRM → ERP | doppelte Kundendatensätze, veraltete Kontaktdaten |
| Kunde (Rechnungsdaten) | ERP | ERP → CRM | abweichende Rechnungs- und Adressdaten |
| Bestand | ERP (Lager) | ERP → Shop | veraltete Bestandsanzeige im Shop, erhöhtes Überverkaufsrisiko |
| Bestellstatus | ERP (Auftragsabwicklung) | Shop → ERP (Anlage), ERP → Shop (Status) | Statusabweichung, Kunde erfährt nichts vom Versand |
Zur Preiszeile: Der Basispreis kommt aus dem ERP. Aktions- und Rabatte im Shop führt der Shop selbst; sie fließen nicht ins ERP zurück. Der Basispreis-Sync überschreibt laufende Aktionen nicht, wenn der Shop Basis- und Aktionspreis in getrennten Feldern führt und der Sync nur das Basispreisfeld aktualisiert.
Zur Kundenzeile: Kontaktdaten und Rechnungsdaten sind zwei Seiten desselben Kunden. Das CRM führt die Kontaktdaten, das ERP die Rechnungsdaten. Beide Systeme tauschen die Daten aus; eine Merge-Regel entscheidet, welches System bei einem Widerspruch gewinnt.
Zur Bestellstatuszeile: Der Auftrag entsteht im Shop, der Status wird im ERP geführt. Der Shop meldet den Auftrag ans ERP, und das ERP meldet den Status (bestätigt, versandt, geliefert) zurück in den Shop. So sieht der Kunde im Shop den aktuellen Status.
So sieht das im Alltag aus
Beispielrechnung mit erfundenen Zahlen:
Ein Händler ändert den Basispreis eines Artikels im ERP von 19,90 Euro auf 24,90 Euro. Der Sync überträgt den neuen Preis in das Basispreisfeld des Shops. Der Shop zeigt ab sofort 24,90 Euro an. Ein laufender Aktionspreis im Shop, etwa 17,90 Euro, bleibt bestehen, wenn der Shop den Aktionspreis in einem eigenen Feld führt und der Sync nur das Basispreisfeld aktualisiert.
Gleichzeitig ändert sich der Lagerbestand: Das ERP meldet 12 Stück. Der Shop zeigt 12 Stück als verfügbar an. Wird ein Stück verkauft, meldet das ERP 11 Stück, und der Shop aktualisiert den Bestand. Verkauft der Shop auf den synchronisierten Bestand, reduziert das das Risiko veralteter Bestandsanzeigen; konkurrierende Bestellungen in kurzer Folge kann der Sync allein nicht verhindern.
Ein Kunde ändert seine Adresse im CRM. Der Sync überträgt die neue Adresse ins ERP. Die nächste Rechnung geht an die neue Adresse. Der Kunde wird nicht doppelt angeschrieben, wenn es nur einen Kundendatensatz gibt.
Typische Fehler
- Zwei Systeme schreiben dieselbe Datenart: Jede Änderung in einem System ist im anderen veraltet, und ohne Merge-Regel driften die Werte auseinander.
- Kein führendes System: Die Datenart wird in mehreren Systemen gepflegt, und niemand weiß, welcher Wert aktuell ist.
- Sync in beide Richtungen ohne Konfliktregel: Die Systeme überschreiben sich gegenseitig, und der Sync läuft in einer Schleife.
- Bestand wird nicht in den Shop gespiegelt: Der Shop verkauft Artikel, die das Lager nicht mehr hat.
- Kundendaten liegen ohne Merge-Regel in CRM und ERP: Es entstehen doppelte Datensätze, und der Kunde wird doppelt angeschrieben.
So gehen Sie vor
- Listen Sie alle Datenarten auf und notieren Sie, in welchen Systemen sie vorkommen.
- Weisen Sie jeder Datenart genau ein führendes System zu; die Zuordnung folgt der Entscheidungstabelle.
- Definieren Sie je Datenart die Sync-Richtung: einseitig vom führenden System oder bidirektional.
- Legen Sie für bidirektionale Datenarten eine Merge-Regel fest, die bei einem Widerspruch das gewinnende System benennt.
- Dokumentieren Sie die Zuordnung und testen Sie den Sync mit einem Beispielartikel, einem Beispielkunden und einer Beispielbestellung.