Das führende System festlegen

Das führende System ist das eine System, das ein bestimmtes Feld ändern darf. Überall sonst ist dieses Feld eine Kopie. Das klingt nach einem technischen Detail und ist in Wahrheit die eine Entscheidung, die bestimmt, ob Ihre Integrationen langweilig sind oder dauerhaft brennen.

Das Symptom

Sie werden das Symptom erkennen, bevor Sie die Ursache erkennen. Jemand im Produktteam schreibt eine ordentliche Beschreibung für Artikel 4711-A: 600 Wörter, Anwendungshinweise, der Vergleich, der einem Käufer bei der Wahl hilft. Zwei Tage später steht dort wieder FITTING 3/4 V4A 10BAR, die 40-Zeichen-Zeile, die das ERP auf einer Rechnung verwendet.

Niemand hat sie gelöscht. Der nächtliche ERP-Feed hat sie überschrieben, weil der Feed eine Spalte description mitführt und der Import so konfiguriert war, dass er jede Spalte schreibt, die er findet. Das Produktteam schreibt die Beschreibung noch einmal. Sie verschwindet wieder. Nach dem dritten Mal hören sie auf, und der Katalog fällt still auf das zurück, was das ERP für eine Beschreibung hält.

Derselbe Kampf läuft um Mengeneinheiten, um Steuerklassen, um Kundenadressen. In jedem Fall ist die Ursache dieselbe: Zwei Systeme glauben, dasselbe Feld zu besitzen, und der letzte Schreiber gewinnt.

Die Regel

Für jedes Feld darf genau ein System schreiben. Alle anderen lesen es.

Daraus folgen zwei Konsequenzen, und beide sind in der Praxis unbequem:

• Eine Lesekopie muss sichtbar eine Lesekopie sein. Gehört ein Feld dem ERP, dürfen Menschen es im Cockpit nicht bearbeiten können. Sonst tun sie es, ihre Arbeit verschwindet über Nacht, und sie verlieren das Vertrauen in die Plattform statt in den Prozess.
• Die Hoheit gilt je Feld, nicht je Entität. „Das ERP besitzt die Produkte“ ist zu grob, und genau daran scheitern die meisten Projekte. Das ERP besitzt SKU, Gewicht, Steuerklasse und Einkaufspreis eines Produkts. Es besitzt nicht die Marketingbeschreibung, die Zubehörbeziehungen oder die Bilder.

Die Tabelle der Feldhoheit

Das ist das Artefakt, das sich zu erstellen lohnt. Auf einer Seite, mit Namen darauf, bevor Sie irgendetwas bauen. Ein realistischer Ausgangspunkt für einen B2B-Großhändler mit ERP, der die Revenue Cloud als Shop und PIM nutzt:

Kopieren Sie das in Ihr Projekt und ändern Sie es. Der Wert liegt in der Diskussion, die Ihr ERP-Team und Ihr Produktteam beim Ausfüllen führen, und die ist jetzt viel billiger als nach dem Go-Live.

Übergabe: der Fall Bestellung

Bestellungen sind die eine Entität, bei der die Hoheit bewusst wandert.

Während ein Käufer einen Warenkorb füllt und bis zur Übertragung besitzt die Revenue Cloud die Bestellung. Im ERP weiß noch nichts davon. Bei der Übertragung wechselt die Hoheit: Von diesem Moment an besitzt das ERP die Bestellung (ihren Status, ihre Lieferungen, ihre Rechnungen), und die Cloud zeigt eine Kopie.

Wer das in eine der beiden Richtungen falsch macht, spürt es. Bearbeiten beide Seiten weiter, haben Sie eine Shop-Bestellung, die „versandt“ sagt, und eine ERP-Bestellung, die „in Klärung“ sagt. Besitzt keine Seite den Status nach der Übertragung, rufen Käufer an, um zu fragen, wo ihre Lieferung bleibt, und genau das sollte der Shop ja abschaffen. Siehe Der Lebenszyklus einer Bestellung.

Wenn das ERP doch nicht die Antwort ist

„Das ERP ist führend“ ist der Reflex im deutschen Mittelstand, und für Transaktionsdaten stimmt er. Zwei Fälle sollten Sie trotzdem prüfen:

Sie betreiben bereits ein PIM. Akeneo, Contentserv, inRiver. Dann besitzt das PIM die Produktinformationen, das ERP die kaufmännischen Felder, und die Revenue Cloud konsumiert beides. Der Fehler hier ist, an zwei Stellen anzureichern; siehe So funktioniert Product Information Management.

Das ERP-Feld existiert, wird aber nicht gepflegt. Viele ERPs haben ein Feld Langtext, das bei 80 % der Artikel leer ist, oder eine Warengruppe, über die zuletzt 2009 nachgedacht wurde. Ein Feld, das formal existiert, aber nicht gepflegt wird, ist kein führendes System. Jemand muss dafür verantwortlich sein, es aktuell zu halten, oder die Hoheit gehört woanders hin.

Die Entscheidung verankern

Eine Tabelle auf einer Wiki-Seite hält keinen Nachtjob davon ab, eine Spalte zu schreiben. Machen Sie sie wirksam:

• Nur die Felder mappen, die die Quelle besitzt. Die stärkste Durchsetzung ist mechanisch: Steht description nicht im Mapping, kann kein Import es überschreiben. Siehe Feld-Mapping.
• Bei unsicheren Feldern „nur anlegen“ statt „immer aktualisieren“. Lassen Sie das ERP bei einem neuen Artikel einen Namen vorbelegen, und fassen Sie ihn danach nie wieder an.
• Den Eigentümer in die Attributbeschreibung schreiben. Wer bearbeitet, muss in dem Moment, in dem er zu tippen beginnt, lesen: „wird im ERP gepflegt; Änderungen hier werden überschrieben“.
• Nach dem ersten Monat prüfen. Die Felder, die Menschen immer wieder bearbeiten, sind die Felder, die Sie dem falschen Eigentümer zugewiesen haben.

Weiter

• Feld-Mapping: wo aus der Entscheidung Konfiguration wird.
• Datenqualität in der Praxis: falsche Werte erwischen, nicht nur fehlende.