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 halten die Menschen den Informationsfluss zwischen dem Webshop, dem ERP, dem Lagersystem, der Rechnungsstellung und dem Kurierdienst am Leben. Wenn eine Bestellung stecken 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. Der Weg kann unterschiedlich sein für Bestellungen auf Lager, Vorbestellungen, Nachnahme, Firmenrechnungen oder persönliche Abholung. Promotionspakete, Teillieferungen, Rückerstattungen und Adressfehler erhöhen die Anzahl der Varianten weiter.

Daher ist der erste Fehler oft, dass das Unternehmen versucht, alle Bestellungen auf die gleiche Weise zu behandeln. In Wirklichkeit ist das Ziel nicht, dass ein System blind alle Daten weiterleitet, sondern dass häufige, eindeutige Fälle automatisch weiterlaufen 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 reserviert werden kann? Wann wird die Rechnung erstellt? Was passiert, wenn der Kurierdienst die Adresse nicht akzeptiert? Wenn die Antworten auf diese Fragen aus mündlicher Überlieferung 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, daher fragt der Kundenservice auch telefonisch im Lager nach.

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 Bestelldatensatz im ERP erstellt oder aktualisiert. Das ERP bleibt weiterhin das zentrale Register für die Geschäftserfüllung: Von hier kommen die Daten für Lagerbestand, Rechnungsstellung und Versandentscheidung.

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

Die Logik des Prozesses lässt sich kurz um fünf Zustände organisieren:

• 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, die erforderlichen finanziellen und kundenkommunikativen 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 beispielsweise 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 bedeutet nicht, Ausnahmen zu beseitigen

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 zusammenfassen. Diese sollten nicht hinter einem automatischen Prozess versteckt werden.

Die gute Lösung erkennt, dass eine bestimmte Bestellung nicht sicher weitergehen 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 die Ausnahmebehandlung zu einer E-Mail-Suche wird, erzeugt die Automatisierung nur schneller Unsicherheit.

Besondere Aufmerksamkeit verdienen die teilweisen 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 Sendungsverfolgungsnummer nicht erhalten. In solchen Fällen darf das System keine doppelten Bestellungen, Rechnungen oder Etiketten immer wieder generieren.

Daher 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 dadurch, dass dieselben Daten an mehreren Stellen bearbeitet werden. Die Adresse wird im Webshop geändert, im ERP bleibt sie jedoch die alte. Das Lager arbeitet mit einer Tabelle, während sich der Bestand bereits geändert hat. Die Rechnungsstellung verwendet andere Kundendaten als der Kundenservice sieht.

Bei allen wesentlichen Daten sollte das führende System festgelegt werden. Bei Produktstamm, Preis, Kundendaten, Bestand, 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 verkäufliche Bestand. Es muss die bereits reservierte Menge, die unter Qualitätskontrolle stehenden Produkte, die in der Überführung befindliche Ware und gegebenenfalls der aus der Beschaffung 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 die Abläufe sichtbar macht. Es reicht nicht aus zu wissen, wie viele Bestellungen eingegangen sind. Es lohnt sich zu beobachten, wie viel Zeit zwischen Bestellung und Lagerausgabe vergeht, wie viele Bestellungen auf Ausnahmebehandlung warten, welcher Fehler sich wiederholt und wo sich die Arbeit ansammelt.

Diese Daten bringen oft unangenehme Fragen ans Licht. Es könnte sein, dass nicht die Integration langsam ist, sondern die tägliche einmalige Rechnungsfreigabe die Bestellungen aufhält. Es könnte auch sein, dass das Lager nicht früh genug Informationen über Kampagnen erhält. Das Ziel der Messung ist nicht die Kontrolle der Kollegen, sondern das Verständnis, wo der Prozess geändert werden sollte.

Bei der Einführung ist es ratsam, mit einem gut abgegrenzten Bestelltyp zu beginnen. Zum Beispiel mit Bestellungen auf Lager, im Voraus bezahlt und mit Inlandsversand. Diese sind in der Regel gut regelbar, und basierend auf den Erfahrungen können die Status, Datenfelder und Fehlerbehandlungsregeln präzisiert werden. Danach können die komplexeren 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 eingebaut wird. Im CGAT-Ansatz ist die Integration und Automatisierung dann wertvoll, wenn die dahinterliegende Arbeitsweise klarer, messbarer und nachhaltiger wird.

Die gute 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 man zuerst Ordnung schaffen.