Warenwirtschaftssystem für Onlineshop-Betreiber? Worauf ist zu achten, warum ist es wichtig,...

Es gibt unzählige Berichte beim Thema Shopsoftware über Frontendfunktionen, Payment, Risiko, SEO usw. Eher seltener beschäftigt man sich aber mit den für den Shopbetreiber täglich eigentlichen Arbeiten, wenn die Bestellungen denn mal da sind. Mit vielen Prozessen, die meist erst durch ein Warenwirtschaftssystem abgedeckt werden können.

Es gibt Shopbetreiber die bekommen schon beim Aussprechen des Wortes "Wawi" graue Haare. Nur warum?

Nun zum einen ist ein Wawi-System eine enorm komplexe Software, die schon in der Bedienung meist nicht mit einer reinen Shopsoftware zu vergleichen ist. Der riesige Menübaum und die oft sehr überladenen Masken (meist um viele branchenspezifische Dinge abzubilden) sind nicht in 2 Tagen Schulung zu erlernen. Führt man bestimmte Vorgänge z.B. nur 2 mal im Jahr aus, so weiß man oft schon nicht wie man in die nötige Maske das letzte mal überhaupt gelangt ist. Schließlich soll die Software ja erleichtern und nicht Zeit kosten.

Je größer die Software, desto höher auch die laufenden Kosten. Hier unterschätzen Firmen oft die nachgelagerten Kosten für Weiterentwicklung und Instandhaltung komplexer Systeme. Jeder, der selbst die kleinste SAP Lösung in seinem Unternehmen implementiert hat wird bestätigen, dass die Softwarelizenz eher den kleinsten Teil ausgemacht hat. Besonders unangenehm spürt es der Geschäftsführer im Geldbeutel, wenn nachentwickelt werden muss, weil Sonderlösungen her müssen. Hier ist man immer gut beraten sich organisatorisch eher an die eingesetzte Software anzulehnen, anstatt mit dem Kopf durch die Wand zu versuchen seine evtl. aus der Historie gewachsenen Prozesse der Software aufzuzwingen.

Sicherheit: Vor allem bei kleineren Systemen wie man sie für ein paar Hundert Euro kaufen kann versäumt man in kleineren Firmen, ausreichend oft Sicherungen zu machen. Diese sollten täglich (bestenfalls sogar mehrfach am Tag) gemacht und vor allem an physisch getrennten Orten aufbewahrt werden. Auch heute passiert es noch oft genug, dass nach einem Einbruch der Server samt der darin enthaltenen Sicherungen abhanden kommen. Jetzt wird jeder denken, "Ach, wie kann man nur so d... sein". Aber prüft jeder Verantwortliche dieses Thema von Zeit zu Zeit genauer? Wer hat die Sicherungen im Notfall? Wie alt sind diese? Ist ein Rückspielen der Daten möglich? Besonders diese Frage sollte sich der jenige stellen, der auf wiederbeschreibbaren Medien sichert, die durchaus Ihre Datenhaltbarkeit mit der Zeit verlieren. Systeme, die ohne Datenabgleich nur Plattenpartitionen sichern sind da besonders tückisch. Ich würde meine ganze Existenz jedenfalls keiner Sicherungs-Software anvertrauen, und eine Datenrückspielung auch mal testen.
Zur Sicherheit gehört auch der Schutz der Daten. Ich kenne genügend Fälle, wo ein Mitarbeiter bei einem Onlinehändler kündigt, und 3 Wochen später selbst einen Onlineshop eröffnet und in seinem ersten Newsletter ganz zufällig alle Kunden des alten Arbeitgebers angeschrieben werden. Besonders eMail-Adressen sind für Onlinehändler ein enorm wichtiges Gut. Hier sollte die Geschäftsführung gut überlegen, wer Zugang zu so einem Bestand hat.

Schnittstellen: Auch dieser fast furchterregende Begriff sorgt mitunter dafür, dass Anwender Ihre Software verfluchen. Dabei sind allein die Programmierer dafür verantwortlich, Fehlerquellen so weit zu minimieren, dass der Begriff "Schnittstelle" möglichst das ganze Geschäftsjahr lang gar nicht genannt werden muss.

Aber wie bekommt man Schnittstellen sicher? Nun, es gibt kein Geheimrezept. Das wichtigste bleibt Disziplin bei der Entwicklung. Sprich Schnittstellen immer so flexibel zu coden, dass alle eventuellen Fehler abgefangen sind. In beiden Systemen versteht sich. Of kann man von Standards profitieren. Hat die Wawi XY einen Bestelldatenimport mit guter Doku, kann der Entwickler des Shops allein loslegen. Trotzdem ist ein guter Draht zum Entwickler beim Wawi-Systemhaus immer von Vorteil.

XML kann helfen die Datenstruktur zu vereinfachen, generell eine Schnittstelle sicherer und einfacher erweiterbar zu machen. XML bedeutet aber auch größere Datenmengen. Hat man 1.000 Artikeldaten, die stündlich von Wawi zum Shop müssen sind (sagen wir mal) 15 Megabyte Daten -> kein Problem. Hat ein größerer Shop aber 50.000 Artikel so ist das Einspielen von 0,75 Gigabyte für auch große Shopsysteme im Livebetrieb durchaus problematisch. Von der Netzauslastung durch solch eine Datenmenge mal abgesehen. Hier muss man also viel genauer planen.
Beispielsweise tagsüber nur das Delta (also neue und geänderte Artikel austauschen) und Nachts zur Sicherheit einen Komplettimport durchführen. Ich weiß nicht welche Erfahrungen da die Hersteller von anderen Shopsystemen gemacht haben, aber bei POWERGAP bekamen wir oft die Antwort "Hmmm, aber unsere Wawi XY kann nur den ganzen Bestand auf einmal exportieren". Schnell fangen dann die Diskussionen an.

Für einfache Schnittstellen wie "nur" Artikelpreise oder aktuelle Bestände überspielen reichen einfache Textdateien (CSV) völlig aus. Überträgt man Zeile für Zeile nur die Artikelnummer und den neuen Bestand, so braucht man aus meiner Sicht kein XML. Aber auch hier ist die Datenmenge nicht ganz egal. 50.000 SQL-Updates sind zwar heutzutage kein echtes Problem mehr, aber warum den Server unnötig quälen wenn sich der Bestand nur bei 200 Artikeln geändert hat? Hier fehlt den Wawis leider fast immer die Möglichkeit eben nur diese 200 Datensätze zur Verfügung zu stellen. Wenn nicht anders möglich kann auf Seiten des Shops halt eine Verzögerung eingebaut werden, die diese Updates nicht alle auf einmal schreibt. Ziel muss es immer sein den kaufenden Besucher im Shop nicht zu stören. Und eine Eieruhr im Browser, weil im Hintergrund die Shopdatenbank eine Belastungsspitze hat muss schlicht ausgeschlossen werden.

Weg des Datenaustausches: Wie die Daten zwischen Wawi und Shop ausgetauscht werden "sollten" kann man nicht pauschal aussagen. Die Anzahl der Möglichkeiten ist oft systembedingt begrenzt. Warenwirtschaftssysteme sitzen vernünftigerweise hinter Firewalls und können mit dem Netz oft nicht direkt kommunizieren. Aus Sicherheitsgründen können dann auch Shopsysteme die Wawis nicht direkt mit Daten füttern.
Hier muss man zuerst die Sicherheitssysteme entsprechend konfigurieren. Ist das Geschafft, kann der Shop aktiv z.B. eine neue Bestellung an die Wawi melden. Nicht periodisch, sondern direkt mit der Bestellung, was bedeutet dass die Bestellungen ohne Verzögerung in der Wawi weiterverarbeitet werden können. Gibt die Wawi ein "OK" zurück kann der Shop die Order als exportiert markieren. Umgekehrt genauso. Kommt kein OK zurück würde der Shop es periodisch dann so lange wieder versuchen, bis es klappt.
Eine andere Möglichkeit ist ein gemeinsames FTP-Verzeichnis zu nutzen. Hier stellt z.B. der Shop seine Bestelldaten in eine Datei und die Wawi schaut in periodischen Abständen nach, ob neue Daten vorliegen. Oft kann man über sogenannte Trigger in der Wawi sofort agieren. Sprich die Wawi merkt direkt wenn neue Daten vom Shop geschrieben worden sind.
Wichtig ist bei beiden Varianten besonders am Anfang Protokolle zu schreiben. Auch die importierten Daten nicht zu löschen, sondern in einen Korb "erledigt" zu stellen. Das hilft bei einer Fehlersuche enorm.

Letztendlich liegt es aber wirklich am Programmierer, ob er alle Eventualitäten abgefangen hat. Beispielsweise ein Schlussdatensatz, der in jeder Datei oder Übertragung bestätigt, dass es sich um eine vollständige Datei handelt. Fehlt dieser, kann das Empfängersystem reagieren und melden, dass etwas nicht stimmt.
Auch so banale Dinge wie Nummernkreise. Wawis wie Datev haben ziemlich genau eingeschränkte Ranges. Wenn man diese bereits bei der Schnittstellenentwicklung kennt sollte man das auch berücksichtigen. Bei eins der ersten eigenen Schnittstellen habe ich in der Doku eines Steuerberaters die Begrenzung bei der Bestellnummer auf 999.999 nicht beachtet. Hochgerechnet dachte ich das reicht ja für ca. 30 Jahre. Nun hat sich die Bestellmenge bei diesem Shop aber so enorm gesteigert, dass dann dieser Wert schon nach eher Monaten wie Jahren erreicht war. Heute behelfen wir uns, indem wir solche Höchstgrenzen in den Schnittstellen fest einstellen und das Script uns früh genug mit einer eMail an das Erreichen des Höchstwertes erinnert.

Solche Erfahrungen, die neuen Techniken und Datenformate sorgen dafür, dass Schnittstellen heute aus unserer Sicht gar nicht mehr so problematisch sind. Sind alle Kinderkrankheiten behoben und läuft eine Schnittstelle ein paar Wochen ohne Problem, so meldet sie sich meist für viele Jahre nicht wieder. Theoretisch :-)

Die optimale Lösung ist, wenn Shop und Wawi in einem integriertem System verschmolzen sind. Bestenfalls auf die Funktionen minimiert, die einem Onlinehändler alle Prozesse abdecken. Jemandem, der nicht zwingend ein Reisekostenmodul oder eine komplette Buchhaltung inhouse abbilden muss. Denn bei den meisten Onlinehändlern (selbst bis zu einer mittleren Größenordnung) wird die reine Buchhaltung bei einem Steuerberaterbüro abgedeckt.

Eine Kombination aus Shop + Wawi ist je nach Größenordnung und Bedarf so schon möglich. Beispiel: POWERGAP Shopsystem. Mit dieser Software, bilden auch größere Online-Händler mit z.B. 50 Mio. Jahresumsatz ihre kompletten Prozesse ab, ohne dabei auf eine zusätzliche Wawi-Software zurückgreifen zu müssen. Und das schon erfolgreich seit vielen Jahren. Das spart Nerven + Zeit und damit auch Geld.

Für einen reinen Onlinehändler der Umsätze nicht aus anderen Kanälen wie z.B. mehreren stationären Ladengeschäften usw. zusammenbringen muss, besteht im Grunde also nicht unbedingt ein Bedarf eine separate Warenwirtschafts-Software anzuschaffen.

Was an Grundprozessen nach dem Bestelleingang benötigt ein Onlinehändler eigentlich:

Zunächst eine durchdachte Bestellverwaltung die dem Mitarbeiter in jeder Lage optimale Möglichkeiten bietet und eine Bearbeitung mit möglichst wenigen Mausklicks und hochperfomant erlaubt. Integrierte Risikofeatures, die helfen Betrüger aufzuspüren wären die Kür.

Schick und für guten telefonischen Kundensupport sind auch CRM Funktionen wichtig. Der Mitarbeiter muss den Kunden im System gefunden haben, bevor dieser am Telefon "Guten Tag" ausgesprochen hat (z.B. über ein paar Zahlen der Telefonnummer im Display). Sich blitzschnell einen Überblick über den Kunden verschafft haben um ihm am Telefon bestens beraten zu können. Wären Sie nicht erstaunt, wenn Sie bei einem Onlineshop anrufen und man Sie mit "Hallo Herr Meier" anspricht? Dazu muss das System aber auch bei der Eingabe eines Teils der Telefonnummer weit unter einer Sekunde die passende Antwort liefern. Wenn (wie oft bei zu großen Systemen) zuerst die Eieruhr für viele Sekunden zu sehen ist, klappt das leider nicht. Performance ist also auch im Backend ein sehr wichtiges Kriterium.

Zahlungseingänge von Onlinezahlarten sollten natürlich direkt in der Bestellverwaltung vermerkt sein, so dass diese mit den evtl. Nachnahmesendungen direkt zum Packen gegeben werden können. Für die Vorkassen wäre ein Tool perfekt, was Bankdaten importieren kann und Zahlungseingänge für Bestellungen größtenteils automatisch erkennt und zum Packen weiterleitet.

Rechnungsdruck. Evtl. gleichzeitiger Druck von Picklisten/Lieferscheinen für das Lager, oder z.B. Versand- und Länderspezifischen Unterlagen. Wenn man größer wird sollte man aufgrund der Lieferschwellen für einzelne Länder darauf achten, dass die Software mit unterschiedlichen Steuersätzen je Land arbeiten kann. Generell sollte der Rechnungsdruck sehr flexibel sein, Freitextpositionen erlauben und im Layout frei gestaltbar sein, damit man auch auf evtl. farbigen Vordrucken auf kostengünstigen Laserdruckern printen kann.

Paketkartendruck. Entweder direkt aus dem Shopsystem angestoßen, oder in einer Sammeldatei an Software wie Easylog oder Delisprint.

Ab 30-50 Bestellungen am Tag machen Gesamtpicklisten Sinn. Damit der Picker im Lager nicht unnötige Wege läuft, sollte ein System per Gesamtpickliste die Waren für z.B. 10 Bestellungen gleichzeitig ermitteln, so dass der Picker mit dem Wagen für alle 10 (natürlich Wegeoptimiert!) nur einmal durchs Lager laufen muss.

Je nach Branche (z.B. Mode) macht ein integriertes RMA System Sinn. Bei 1-2 Retouren am Tag macht ein solches RMA-System kaum Sinn, ansonsten kann es aber helfen diese sauber zu verwalten und Kunden mit auffällig vielen Rücksendungen zu erkennen.

Ausgangsscannen. Wer die Möglichkeit schafft die eMail-Benachrichtigung an den Kunden mit dem tatsächlichen Zumachen des Pakets zu verknüpfen, der schafft auch die Sicherheit, dass der Kunde wirklich erst benachrichtigt wird, wenn das Paket auf dem Rollwagen des Versanddienstleisters liegt und nicht irgendwo im Lager verloren gegangen ist. Die Kür ist dann noch, wenn das Shopsystem zum Zeitpunkt, wo der Lagermitarbeiter die Bestellnummer einscannt auch noch das frische Bild einer Webcam einholt, die im Lager auf das Ende der Packstraße gerichtet ist. Dann kann man dem Besteller sogar sein Paket schon live zeigen und hat zudem noch den Nachweis, welcher Mitarbeiter die Schlussprüfung gemacht hat. Wenn dann noch das Paket auf der Waage steht, und das Display groß genug ist um es auf dem Bild der Webcam zu erkennen, dann hat man sogar für das Gewicht einen Beweis. Wie oft kommt es vor, dass der Kunde behauptet, dass die Hälfte der Lieferung nicht im Paket war.

Neben diesen Punkten, welche direkt die Bestellungen betreffen sind folgende Features für den Onlinehändler ein Muss:

Eine ausgezeichnete Lagerverwaltung. Diese muss zu jedem Zeitpunkt möglichst mit dem Istbestand übereinstimmen und performant und einfach zu bedienen sein.

Für ein einfachere und schnellere Inventur sollten Möglichkeiten gegeben sein die Ist-Zählung in der Lagerverwaltung zu erfassen. Optimaler weise von jedem Zähler separat. Dann könnte man per Knopfdruck ein Inventurergebnis simulieren, um einzelne Artikel bei zu großen Abweichungen nachzuzählen. Ein sauberes vom System erstelltes Inventurergebnis ersetzt die oft mühsame Bearbeitung von Excel-Dateien wie man sie in vielen Betrieben noch heute praktiziert.

Wer an der Warenannahme im Lager einen PC hinstellt könnte auch die Wareneingangsbuchung schon dort elektronisch erfassen lassen. Mit einer Verwaltung von Lagerorten ist es nicht nur möglich Laufwege der Picker zu optimieren, sondern auch Kapazitäten zu verwalten. Beim Wareneingang sollte dem Kommissionierer schon eine Warnung angezeigt werden, wenn die derzeitige Stellfläche für die Neulieferung nicht ausreicht, aber es in Gang 7 Regal 12C den nötigen freien Platz gibt.

Einkaufssystem. Schon die Lagerverwaltung sollte dem Einkäufer Prognosen für den Abverkauf anzeigen um möglichst weit im Voraus die Nachbeschaffung der Waren zu gewährleisten. Ein intelligentes System könnte sogar Bestellvorschläge für einen ganzen Kreditor von selbst vorschlagen und nach Augenprüfung die Bestellanforderung per Mail an den Kreditor senden. In der Mail aber nur einen Link auf eine Seite zeigen, wo der Verkäufer beim Kreditor die Verfügbarkeit, Lieferpreis und Menge bestätigt. Klickt der Kreditor dann auf OK, kann der Einkäufer beim Onlinehändler mit einem Klick die Ware bestellen und diese ist in der Lagerverwaltung auch schon als "bestellt" gekennzeichnet. Bestätigt die Spedition sogar die Anlieferung, könnte man z.B. einen vorzeitigen WE per Knopfdruck buchen, um die Ware schon am Wochenende zu verkaufen, die erst am Montag angeliefert wird.
Bei einem durchdachten Bestellsystem ist auch eine automatische Preisanfrage bei x Kreditoren möglich. Man stelle sich vor, der Artikel "CD-Player XY" ist bei 5 Lieferanten gleichzeitig lieferbar. Hat man dies im Bestellsystem zu diesem Artikel vermerkt, so könnte ein System die 5 Kreditoren anschreiben, die dann per Link auf eine Seite gebeten werden. Auf der müssen Sie einen möglichst niedrigen Preis eintragen, und sehen ob sie derzeit den günstigsten Preis aller 5 angefragten Lieferanten anbieten ohne dass Lieferantennamen und Preise gezeigt werden. So entsteht ein kleiner Preiskampf zwischen den Lieferanten, der dafür sorgt, dass der Onlinehändler aber den bestmöglichen Preis aushandelt. Eine Prozedur, die sonst manuell erfolgt und je nach Sortiment zuviel Arbeitskraft fordert. Es sich also aus Gründen Personalkosten nicht lohnt. Ein Solches Einkaufssystem wird übrigens genau mit diesen Eigenschaften zu Ende Januar 2008 im POWERGAP Shopsystem verfügbar sein, das damit die Prozesskette eines Onlinehändlers fast perfekt macht.

---

Einzeln aufgezählt sind es also doch schon so einige teils komplexe Punkte, die eine Wawi für einen Onlinehändler abdecken muss.

Wer eine "separate" Wawi benötigt, der kommt nicht drum herum viel zu telefonieren. Am besten möglichst viele Geschäftsfreunde abfragen, was die nutzen und wie zufrieden sie mit ihrem Systempartner sind. Denn egal bei welchen Wawi-System, es kommt am Ende auf den Faktor "Mensch" an. Also den direkten Betreuer beim Systemhaus. Im besten Fall direkt einen Programmierer und nicht den Keyaccounter, der schön reden kann, aber nicht die Lösungen hat.
Bei POWERGAP haben wir bisher z.B. beste Beziehungen zu Navision entwickelt. Bei einem Systemhaus für diese Software kennen wir direkt die Entwickler und nur dann sind Schnittstellen auch wirklich zuverlässig umgesetzt.

Die teils horrenden Investitionen, die für Warenwirtschaftssysteme nötig sind wollen gut durchdacht sein. Hier sollte man auch bei kleineren Firmen ein Projektteam bilden, dass sich umfassend mit dem Thema auseinandersetzt um die für das Unternehmen in der Zukunft beste Lösung zu finden. Diese muss auch mit all den möglichen Nebenkosten rentabel sein. Was nützt ein Rolls Royce, wenn man sich den Chauffeur nicht leisten kann.

Verfasser: Robert Zajonz