Beispiel für die Automatisierung des Bestellflusses in einem Webshop

Eine Bestellung im Webshop geht ein, dann leitet jemand die Daten per E-Mail oder Excel an das Lager weiter. Der Kollege überprüft die Zahlung, ändert die Rechnungsdaten, erstellt ein Etikett, ändert den Status und versucht schließlich, den Kunden zu benachrichtigen. Dies funktioniert, solange es sich um einige Bestellungen pro Tag handelt. Beispiel für die Automatisierung des Bestellflusses im Webshop wird wirklich nützlich, wenn das Wachstum mehr manuelle Schritte, mehr Ausnahmen und immer schwerer nachvollziehbare Verantwortlichkeiten bedeutet.

Das Problem ist in der Regel nicht, dass es nicht genug Anwendungen gibt. Vielmehr ist es so, dass die Menschen den Informationsfluss zwischen dem Webshop, dem ERP, dem Lagersystem, der Rechnungsstellung und dem Kurierdienst aufrechterhalten. Wenn eine Bestellung hängen bleibt, wird dies oft erst bemerkt, wenn der Kundenservice eine Beschwerde erhält. In solchen Fällen sollte man nicht mit einem Automatisierungstool beginnen, sondern mit der Frage: Was genau passiert mit einer Bestellung vom Zahlungseingang bis zur Übergabe?

Wo wird der Bestellweg unterbrochen?

Bei einem mittelgroßen Händler ist die Bestellabwicklung selten ein einziger Prozess. Bestellungen auf Lager, Vorbestellungen, Nachnahmebestellungen, Firmenrechnungen oder persönliche Abholungen können unterschiedliche Wege haben. Aktionspakete, Teillieferungen, Rückerstattungen und Adressfehler erhöhen die Anzahl der Varianten weiter.

Deshalb ist der erste Fehler oft, dass das Unternehmen versucht, alle Bestellungen auf die gleiche Weise zu behandeln. In Wirklichkeit ist es nicht das Ziel, dass ein System blind alle Daten weiterleitet, sondern dass häufige, eindeutige Fälle automatisch abgewickelt werden und unsichere oder geschäftlich sensible Fälle an die richtige Person weitergeleitet werden.

Es lohnt sich, eine konkrete Bestellung zu verfolgen, nicht nur auf den Bildschirmen der Systeme, sondern auch in der tatsächlichen Arbeit. Wer entscheidet über Zahlungsabweichungen? Woher weiß das Lager, dass ein Artikel noch reservierbar ist? Wann wird die Rechnung erstellt? Was passiert, wenn der Kurierdienst die Adresse nicht akzeptiert? Wenn die Antworten auf diese Fragen aus mündlichen Überlieferungen oder aus dem Gedächtnis eines erfahrenen Kollegen stammen, ist der Prozess noch nicht ausreichend unter Kontrolle.

Ein Beispiel für die Automatisierung des Bestellflusses im Webshop

Angenommen, die Bestellungen aus dem Webshop werden derzeit manuell im ERP erfasst. Das Lager arbeitet von dort aus, die Rechnung wird in einem dritten System erstellt, und die Versandetiketten werden auf einer separaten Oberfläche erstellt. Der Bestellstatus im Webshop wird oft verspätet aktualisiert, weshalb der Kundenservice auch telefonisch beim Lager nachfragt.

In dieser Situation ist nicht unbedingt ein neuer Webshop oder ein vollständiger ERP-Austausch der richtige erste Schritt. Eine kleinere, gut definierte Änderung könnte darin bestehen, dass die genehmigte Bestellung automatisch den entsprechenden Bestellrekord im ERP erstellt oder aktualisiert. Das ERP bleibt das zentrale Register für die Geschäftserfüllung: Von hier kommen die Daten für Bestands-, Rechnungs- und Versandentscheidungen.

Wenn die Bestellung bearbeitet werden kann, erhält das Lagersystem die Kommissionierungsaufgabe. Nach der Zusammenstellung des Pakets werden die Versanddaten an die Kurierverbindung übermittelt, das Etikett geht zurück an das Lager, und die Paketkennung sowie der entsprechende Status werden im Webshop aktualisiert. Der Kunde wird somit nicht durch eine manuell erstellte E-Mail, sondern basierend auf den tatsächlichen Erfüllungsereignissen informiert.

Die Logik des Prozesses kann kurz in fünf Zustände organisiert werden:

• Bestellung eingegangen und technisch gültig;
• Zahlung oder geschäftliche Genehmigung überprüft;
• Bestand reserviert und Erfüllungsaufgabe erstellt;
• Paket zur Übergabe bereit oder an den Spediteur übergeben;
• Erfüllung abgeschlossen, notwendige finanzielle und kundenkommunikative Daten erfasst.

Die Bezeichnungen der Status können je nach Unternehmen variieren. Wichtig ist, dass jeder Zustand eine klare geschäftliche Bedeutung, einen Verantwortlichen und eine systemseitige Quelle hat. „In Bearbeitung“ ist zum Beispiel kein guter Zustand, wenn es einmal bedeutet, dass auf die Zahlung gewartet wird, und ein anderes Mal, dass das Paket bereits im Lager ist.

Automatisierung ist nicht das Verschwindenlassen von Ausnahmen

Im Bestellfluss wird es immer Ausnahmen geben. Ein Produkt kann ausverkauft sein, die Bankbestätigung kann sich verzögern, die Adresse kann unvollständig sein, oder der Kunde möchte mehrere Bestellungen zusammenführen. Diese sollten nicht hinter einem automatischen Prozess verborgen werden.

Die gute Lösung erkennt, dass eine bestimmte Bestellung nicht sicher weitergeführt werden kann, stoppt sie an der richtigen Stelle und erstellt eine Aufgabe. Die Aufgabe muss sichtbar sein: Wer erhält sie, auf welcher Grundlage wird entschieden, wie lange wartet die Bestellung, und was passiert nach der Entscheidung. Dies ist kein administratives Detail. Wenn das Ausnahmehandling zur E-Mail-Suche wird, erzeugt die Automatisierung nur schneller Unsicherheit.

Besondere Aufmerksamkeit verdienen die partiellen Fehler. Es kann vorkommen, dass die Bestellung im ERP erstellt wurde, aber die Lageraufgabe nicht. Oder das Versandetikett wurde erstellt, aber der Webshop hat die Tracking-ID nicht erhalten. In solchen Fällen darf das System nicht immer wieder doppelte Bestellungen, Rechnungen oder Etiketten generieren.

Deshalb sind in der technischen Gestaltung eindeutige Kennungen, wiederholbare Verarbeitung und Protokollierung erforderlich. Einfach ausgedrückt: Es muss auch später nachvollziehbar sein, welches System wann welche Daten übergeben hat und warum ein Prozess gestoppt wurde. Dies ist Teil der Betriebskontrolle, nicht nur eine Frage der Entwicklung.

Welches System sagt die Wahrheit?

Viele Bestellfehler entstehen daraus, dass dieselben Daten an mehreren Stellen bearbeitet werden. Im Webshop wird die Adresse geändert, im ERP bleibt sie noch die alte. Das Lager arbeitet aus einer Tabelle, während der Bestand sich bereits geändert hat. Die Rechnungsstellung verwendet andere Kundendaten als der Kundenservice sieht.

Bei allen wesentlichen Daten sollte das führende System festgelegt werden. Für Produktstammdaten, Preise, Kundendaten, Bestände, Bestellstatus und Rechnungsdaten ist nicht unbedingt dieselbe Quelle verantwortlich. Das ist in Ordnung, wenn die Regel ausgesprochen ist und die Synchronisation dem folgt.

Der Bestand ist ein besonders sensibler Bereich. Beim Verkauf über den Webshop ist nicht immer der physische Lagerbestand der verkaufbare Bestand. Es müssen die bereits reservierten Mengen, die unter Qualitätskontrolle stehenden Produkte, die in der Überführung befindlichen Waren und gegebenenfalls der aus dem Einkauf erwartete Bestand berücksichtigt werden. Wenn dieser Unterschied nicht geklärt wird, kann die automatisierte Bestellübertragung zu Überverkäufen oder unnötigen Stopps führen.

Messung ist nicht nachträgliche Berichterstellung

Der automatisierte Bestellfluss bietet dann einen Führungswert, wenn er den Betrieb sichtbar macht. Es reicht nicht aus zu wissen, wie viele Bestellungen eingegangen sind. Es lohnt sich, die Zeit zwischen Bestellung und Lagerausgang zu beobachten, wie viele Bestellungen auf Ausnahmebehandlung warten, welcher Fehler sich wiederholt und wo sich die Arbeit staut.

Diese Daten bringen oft unangenehme Fragen ans Licht. Vielleicht ist nicht die Integration langsam, sondern die tägliche einmalige Rechnungsfreigabe hält die Bestellungen auf. Es könnte auch sein, dass das Lager nicht früh genug Informationen über die Kampagnen erhält. Ziel der Messung ist es nicht, die Kollegen zu überwachen, sondern zu verstehen, wo es sich lohnt, den Prozess zu ändern.

Bei der Einführung ist es ratsam, mit einem gut abgegrenzten Bestelltyp zu beginnen. Zum Beispiel mit Bestellungen, die auf Lager sind, im Voraus bezahlt und innerhalb des Landes geliefert werden. Diese sind in der Regel gut regelbar, und anhand der Erfahrungen können die Status, Datenfelder und Fehlerbehandlungsregeln präzisiert werden. Danach können komplexere Fälle einbezogen werden.

Der schrittweise Ansatz verlangsamt nicht notwendigerweise die Entwicklung. Vielmehr verringert er die Wahrscheinlichkeit, dass ein falsch verstandener Prozess dauerhaft in die Systeme integriert wird. Im CGAT-Ansatz ist die Integration und Automatisierung dann wertvoll, wenn die dahinterliegende Arbeitsweise klarer, messbarer und nachhaltiger wird.

Die richtige erste Frage ist also nicht, welches Tool den Webshop mit dem ERP verbindet. Vielmehr ist es die Frage, wenn morgen doppelt so viele Bestellungen eingehen würden, an welchem Schritt das Unternehmen die Kontrolle verlieren würde. Dort sollte zuerst Ordnung geschaffen werden.