Wie wir eine Wachstumsplattform mit der Warenwirtschaft abstimmen, bevor sie den Einkauf steuert

Bei einem wachsenden Distributor gibt es schnell zwei Wahrheiten: die Warenwirtschaft und die Dashboards und Tools, die um sie herum entstehen. Solange beide dieselben Zahlen zeigen, fallen Entscheidungen schnell.

Widersprechen sie sich, bremst das Wachstum. Eine Nachbestellung wartet, bis zwei Tabellen verglichen sind, und eine Kanalentscheidung bleibt in der Diskussion hängen, welche Zahl stimmt.

Deshalb muss jede operative Plattform, die wir auf einer Warenwirtschaft aufbauen, Monat für Monat mit ihr übereinstimmen, bevor jemand sie für eine Entscheidung nutzt. Erst dann rechnen jeden Morgen Prognosen und Nachbestelllisten damit.

Zwei Dinge, die wir einrichten, bevor die Plattform eine Nachbestellung steuert.

• Vertrauen
  Monatsprüfung gegen die Datenbank der Warenwirtschaft
  Anzahlen und Beträge je Belegart
  Abweichungen fallen auf, bevor jemand die Zahl nutzt

  Vorher

  keine

  Nachher

  eingerichtet, läuft täglich

• Vertrauen
  Produkte mit Prognose, bei mehrmaligem Neuladen
  in unserem Review gefunden und behoben
  Prognosen bleiben beim Neuladen stabil

  Vorher

  instabil

  Nachher

  stabil, stimmt mit dem Backend überein

Das Dashboard, das sich selbst widersprach

Nach einem Neuladen zeigte unsere Prognoseseite 89 Produkte mit Prognose, nach dem nächsten 210. Unser Review führte den Sprung darauf zurück, wie die Seite ihre Daten lud.

Die Ursache lag in zwei unscheinbaren Grenzen der Datenbank hinter dem Dashboard. Sie liefert höchstens 1.000 Zeilen je Abfrage, große Tabellen werden deshalb seitenweise geladen. Ohne feste Sortierung konnte jedes Neuladen eine andere Auswahl von Zeilen liefern. Daher stammten die 89 und die 210. Mit der Korrektur blieb die Zahl stabil.

Eine zweite Abfrage forderte die ganze Produkttabelle auf einmal an, bekam stillschweigend nur die ersten 1.000 Zeilen und zeigte 141.

Wir haben beides auf jeder betroffenen Seite behoben. Jede seitenweise Abfrage hat jetzt eine feste Sortierung, und große Tabellen werden grundsätzlich seitenweise gelesen. Nach jedem Neuladen zeigt die Seite nun dieselbe Zahl wie das Backend.

Ein Dashboard, das seinem eigenen Backend widerspricht, kann mehr schaden als gar keins. Es untergräbt auch das Vertrauen in die Zahlen, die stimmen. Dabei macht erst dieses Vertrauen Entscheidungen schnell.

Die geschäftliche Frage

Wer über den eigenen Shop, Amazon und Geschäftskunden verkauft, trifft jede Woche dieselben Entscheidungen. Was wird nachbestellt, was geht in Amazons Lager, wo wird der Preis gehalten, und in welchen Kanal fließt der nächste Euro?

Jede dieser Entscheidungen rechnet mit einer Zahl weiter und vergrößert damit auch deren Fehler. Ist der Umsatz je Produkt zu hoch ausgewiesen, fällt die Nachbestellung zu groß aus, und das Geld liegt im Lager. Ist er zu niedrig, ist das Produkt ausverkauft, und das Listing verliert an Boden. Zum Steuern braucht es je Produkt und Kanal eine geprüfte Zahl, und zwar am Morgen der Entscheidung.

Warum die Warenwirtschaft zum Schiedsrichter wurde

Von Hand geflickte Tabellen und Automatisierungen kosten vorab nichts. Sie binden aber jeden Monat Zeit im Team, und stille Fehler fallen nur zufällig auf. Ein Dashboard-Tool auf Basis von Exporten aus der Warenwirtschaft ist schnell eingerichtet. Seine Zahlen sind aber nur so gut wie der Export, und der kann manche Belege anders berechnen als die Datenbank selbst.

Eine schlanke eigene Ebene über der Warenwirtschaft braucht Wochen im Aufbau und danach laufende Pflege. Dafür liest sie direkt aus der Datenbank. Damit wird die Warenwirtschaft zum Schiedsrichter, die Prüfungen laufen täglich, und Prognosen und Nachbestellungen stehen auf derselben Basis.

Die Plattform greift nur lesend auf die Warenwirtschaft zu und kann keinen Datensatz ändern. Für jede Zahl bleibt die Warenwirtschaft maßgeblich. Die Synchronisierung läuft auf dem eigenen Server des Kunden, der Spiegel dagegen in einer gehosteten Datenbank, die nur angemeldete Nutzer lesen können.

Je Auftrag enthält der Spiegel nur wenige Kundenfelder: Name, E-Mail, Ort, Land und USt-IdNr. Straße und Telefonnummer bleiben in der Warenwirtschaft, und die Amazon-Berichte, die wir lesen, enthalten keine Käuferdaten.

Der Aufbau der Prüfungen

Der Umsatz in einer Warenwirtschaft beruht auf drei Belegarten: Aufträgen, Rechnungen und Gutschriften. Für jede Art und jeden Monat vergleichen wir Anzahl, Positionen und Nettobeträge mit der Datenbank der Warenwirtschaft. So entsteht eine kleine Matrix aus Monatsprüfungen, in der jede Zelle mit der Warenwirtschaft übereinstimmen muss, bevor die Zahlen eine Entscheidung tragen.

Die Grafik zeigt das Prinzip der Prüfungen, kein datiertes Protokoll. Ihre gelben Felder markieren einen auffälligen Monat, etwa die fehlende Gutschrift, von der unter „Leitplanken“ die Rede ist.

Hinter der Matrix steht ein kleines Datenmodell. Eine Monatsprüfung summiert die Belege der Warenwirtschaft und ihre Spiegeldatensätze für eine Belegart, einen Monat und eine Kennzahl. Sie speichert beide Werte, die Differenz und einen Status. Anzahlen müssen genau übereinstimmen. Betragssummen dürfen nur um Rundungsdifferenzen abweichen, und die Prüfung markiert jede Abweichung über einem Euro. Diese Grenze bleibt fest und wächst nicht mit dem Volumen. Ein umsatzstarker Monat fällt deshalb früher auf.

Die Prüfsummenzeile auf jeder Seite ist eine eigene, gröbere Ebene. Sie vergleicht die angezeigte Summe einer Seite mit der Datenbank der Plattform und markiert eine Abweichung über einem Prozent. Sie fängt Anzeigefehler wie das oben beschriebene Problem beim seitenweisen Laden ab. Die Ein-Euro-Prüfung sichert dagegen die Plattform gegen die Warenwirtschaft ab.

Als Umsatzbasis dienen Aufträge statt Rechnungen. Aufträge enthalten Verkaufsplattform, Zielland und Kundentyp, und genau das braucht eine Kanalentscheidung. Der Auftragsumsatz ist eine Steuerungsgröße, kein gebuchter Umsatz. Rechnungen und Gutschriften bleiben in derselben Prüfung, damit auch die gebuchte Seite kontrolliert ist. Jede Belegart wird nur mit ihrem eigenen Gegenstück in der Warenwirtschaft verglichen. Liegen ein Auftrag und seine Rechnung in verschiedenen Monaten, entsteht deshalb keine Lücke.

Die Prüfung belegt, dass der Spiegel mit der Warenwirtschaft übereinstimmt. Sie belegt nicht, dass die Warenwirtschaft mit dem Geld übereinstimmt. Bei Amazon stehen Gebühren und Korrekturen in Amazons Abrechnungsberichten. Der Abgleich der Warenwirtschaft mit diesen Berichten ist eine eigene Abstimmung, die diese Prüfung nicht abdeckt.

Wie Umsatz typischerweise zu hoch ausgewiesen wird

Die meisten Abweichungen gehen auf eine Handvoll Muster zurück. Keines davon verändert die Zeilenzahl, und gerade deshalb bleiben sie lange unentdeckt.

• Angebote in der Auftragstabelle. Viele Warenwirtschaften führen Angebote und Aufträge in einer Tabelle. Trennt die Synchronisierung sie nicht, bläht das den Umsatz auf, obwohl jede Zeile echt ist.
• Listenpreis statt berechnetem Preis. Wo Geschäftskunden Rabatt bekommen, treibt der gespeicherte Listenpreis gerade deren Umsatz nach oben. Wir prüfen den tatsächlich berechneten Preis.
• Erstattungen nach Präfix gefiltert. Ein Filter, der nur auf Nummernpräfixe schaut, kann eine ganze Gruppe von Erstattungen übersehen. Jede Erstattungsart braucht ihre eigene Prüfung.
• Fremdwährung als Euro gelesen. Bestellungen in anderen Währungen müssen erst über den Wechselkursfaktor der Warenwirtschaft umgerechnet werden, bevor sie zählen.
• Bestellungen ohne Produktverknüpfung. Sie landen im Topf „unbekannt“, wenn keine Regel sie zuordnet, etwa nach Verkaufsplattform.

Jedes Muster wird zu einer Prüfstufe auf dem Weg vom Beleg in der Warenwirtschaft zur Zahl im Dashboard.

Der Kreislauf

Für jede Quelle und jede Belegart durchlaufen wir denselben Kreislauf.

1. Spiegeln. Die Warenwirtschaft nur lesend in die Plattform synchronisieren.
2. Vergleichen. Anzahl und Betrag Monat für Monat gegen die Datenbank der Warenwirtschaft prüfen.
3. Erklären. Jede Differenz bis zu den Belegen zurückverfolgen, die sie verursachen.
4. Regel korrigieren. Die Synchronisierung oder die Sicht korrigieren, nie den Bericht.
5. Erneut laufen lassen. Den Vergleich wiederholen, bis nur noch Rundungsdifferenzen bleiben.
6. Verankern. Eine Prüfung ergänzen, damit die Differenz nicht unbemerkt zurückkehrt.
7. Darauf aufbauen. Erst danach die Zahl für Prognosen, Nachbestellungen oder Preise nutzen.

Tragend sind die Schritte drei und sechs. Wir erklären eine Differenz, bevor wir sie beheben, und behalten eine Korrektur nur, wenn eine Prüfung sie absichert.

Was eine falsche Zahl kostet

Eine falsche Zahl kostet Geld, bevor sie jemandem auffällt. Nachbestellungen folgen der Nachfrage. Ist die Nachfrage zu hoch ausgewiesen, kauft jede Bestellung zu viel ein.

In dieser Skizze bindet ein Fehler von 2 Prozent höchstens etwa 2.000 € je 100.000 € Einkauf. Echte Nachbestelllogik zieht vorhandenen Bestand und Sicherheitsbestand ab, der tatsächliche Wert liegt also meist darunter. Werden Angebote als Verkäufe gezählt, kann das die Nachfragezahl weit stärker aufblähen. Ob sich der Aufbau lohnt, hängt vom Einkaufsvolumen ab und davon, wie groß die Lücke ist. Der erste Schritt ist deshalb, die Lücke zu messen.

Leitplanken

Ihren Wert zeigte die Prüfung später, als ein erneuter Lauf eine fehlende Gutschrift aufspürte. Weil die Prüfung den Beleg benannte, genügte ein breiteres Synchronisierungsfenster, und niemand musste suchen. Abstimmung ist für uns eine laufende Praxis und keine Zahl, die man einmal ausdruckt.

Was die abgestimmte Basis eröffnet

Eine abgestimmte Basis verdient für sich genommen kein Geld. Sie ist das Fundament für Prognosen, Nachbestellungen und Preise.

Auf ihr lassen sich jeden Morgen Prognosen, Nachbestelllisten und FBA-Versandmengen berechnen. Eine Preisüberwachung kann die eigenen Listingpreise des Unternehmens als Referenz nutzen, neben dem Buy-Box-Anteil aus Amazons eigenem Verkaufs- und Traffic-Bericht.

Als Nächstes kommen die Margen. Bevor sie Entscheidungen steuern, müssen Einstandspreise, Referenzpreise und Lieferzeiten vollständig vorliegen. Dann prüfen wir jede Margensicht mit demselben Kreislauf nach. Der Lauf am Morgen kann danach zeigen, was Geld verdient, und nicht nur, was sich verkauft.

Vor Ihrem nächsten Dashboard

1. Erst abstimmen, dann optimieren. Eine Wachstumsentscheidung ist nur so gut wie die Zahl, auf der sie beruht.
2. Die Datenbank der Warenwirtschaft entscheiden lassen. Exporte und Berichte können manche Belege anders berechnen.
3. Eine laufende Prüfung ist mehr wert als eine einmal perfekte Zahl. Lücken entstehen auch nach dem Go-live.
4. Die Datenabdeckung neben jeder Zahl zeigen. Eine Marge auf den Cent genau sagt wenig, wenn das Kostenfeld darunter leer ist.
5. Die kleinste eigene Ebene bauen, die die Frage beantwortet. Die Warenwirtschaft behält das letzte Wort.

Nehmen Sie sich einen Monat vor und vergleichen Sie den Umsatz in Ihrer Warenwirtschaft mit dem Umsatz in Ihren Berichten. Weichen beide voneinander ab, ist diese Differenz das Erste, dem wir gemeinsam mit Ihnen nachgehen würden.

Danksagung

Aufgebaut vom Capcelerate-Team. Danke an das Team des Kunden für Zugang und Zeit.