Diese Unterscheidung ist keine Wortklauberei, sondern der Ausgangspunkt jeder sinnvollen Bewertung. Eine Warenwirtschaft führt Bestände buchhalterisch und dispositiv: Sie weiß, wie viele Stück eines Artikels in welchem Lager verfügbar sind, welche davon reserviert, welche bestellt und welche gesperrt sind. Ein Lagerverwaltungssystem führt Bestände physisch: Es weiß, in welchem Regalfach welches Packstück liegt, in welcher Reihenfolge ein Kommissionierer laufen soll und wie Nachschub in die Pickzone gelangt. plentymarkets deckt die erste Aufgabe umfassend ab und die zweite in einer Tiefe, die für viele Handelsbetriebe ausreicht, aber nicht für jeden Lagertyp.
Der eigentliche Charakter der Plattform zeigt sich am Auftragsfluss. Ein Auftrag entsteht auf einem Marktplatz, in einem angebundenen Shop, per Telefon oder als Importdatei. Er wird im System als Datensatz mit Kunden-, Positions-, Zahlungs- und Versandinformationen angelegt. Von dort läuft er durch Statusstufen: Zahlung geprüft, Bestand reserviert, Kommissionierung angestoßen, Versandlabel erzeugt, Versandbestätigung gesendet, Rechnung erstellt, Buchhaltungsexport bereitgestellt. Jede dieser Stufen ist konfigurierbar und lässt sich mit Regeln automatisieren. Wer plentymarkets versteht, versteht dieses Statusmodell – alles andere ist Ausstattung.
Die Entwicklungsgeschichte prägt die Software bis heute. plentymarkets ist im Umfeld des Onlinehandels und insbesondere des Verkaufs über Marktplätze entstanden, in einer Zeit, in der Händler ihre Artikel gleichzeitig auf mehreren Plattformen anbieten wollten, ohne für jede Plattform ein eigenes Werkzeug zu pflegen. Der Kern des Produkts ist deshalb ein zentraler Artikelstamm, aus dem heraus Angebote an unterschiedliche Kanäle ausgespielt werden – mit kanalspezifischen Texten, Bildern, Preisen und Kategorien, aber mit einem gemeinsamen Bestand.
Daraus folgt eine Stärke und eine Grenze. Die Stärke liegt in der Kanalvielfalt: Wer über mehrere Marktplätze, einen eigenen Shop und gegebenenfalls einen stationären Kanal verkauft, findet eine Datenstruktur, die für genau diesen Fall gebaut ist. Die Grenze liegt in der Produktionsnähe: Klassische Fertigungsprozesse, mehrstufige Stücklisten mit Arbeitsplänen, Kapazitätsplanung an Maschinen oder Projektfertigung sind nicht das Zuhause dieser Plattform. Handelsunternehmen mit leichter Veredelung oder Set-Bildung sind gut versorgt, produzierende Unternehmen mit echter Fertigungstiefe sollten andere Systeme prüfen.
Eine Abgrenzung, die im Beratungsgespräch regelmäßig nötig wird: plentymarkets ist kein Shopsystem mit angehängter Verwaltung, auch wenn ein Shopbaukasten enthalten ist. Der Schwerpunkt liegt auf der Prozessseite, und viele Anwender betreiben ihren Verkaufsauftritt bewusst auf einem anderen Shopsystem und nutzen plentymarkets als führendes System für Artikel, Bestände und Aufträge. Diese Konstellation ist verbreitet und funktioniert – sie verlangt allerdings eine klare Entscheidung darüber, welches System die Wahrheit über Artikeldaten und Bestände hält.
Ebenso wenig ist plentymarkets eine Versandplattform. Es erzeugt Versandlabels über angebundene Dienstleister, verwaltet Versandprofile und schreibt Sendungsnummern zurück, aber es ersetzt keine Multi-Carrier-Schicht mit eigenem Regelwerk und Ausfallpfad. Und es ist keine Finanzbuchhaltung: Belege entstehen im System, die eigentliche Buchführung findet in der Steuerkanzlei oder in einem Buchhaltungssystem statt, das über Exportformate versorgt wird. Wer diese drei Abgrenzungen früh zieht, spart sich später die häufigste Enttäuschung – die Erwartung, ein System werde alles übernehmen.
Der letzte Punkt betrifft das Betriebsmodell. plentymarkets wird ausschließlich als Cloud-Dienst angeboten. Es gibt keine Variante, die im eigenen Serverraum oder bei einem selbst gewählten Hoster installiert wird. Das ist für viele Unternehmen ein Vorteil, weil Betrieb, Updates und Skalierung nicht im eigenen Haus liegen. Für Unternehmen mit einer IT-Strategie, die Eigenbetrieb vorschreibt, ist es ein Ausschlusskriterium. Diese Frage gehört deshalb nicht ans Ende, sondern an den Anfang jeder Auswahl.
Cloud-Warenwirtschaften werden üblicherweise nach mehreren Größen bemessen: Anzahl der Nutzerkonten, Anzahl der angebundenen Verkaufskanäle, Auftrags- oder Positionsvolumen je Abrechnungszeitraum, gelegentlich Speicher- oder Schnittstellenkontingente. Die Kombination dieser Größen bestimmt, welches Paket wirtschaftlich ist. Der typische Fehler bei der Auswahl besteht darin, nur die aktuelle Situation abzubilden. Wer im ersten Jahr zwei Kanäle betreibt und im dritten Jahr sechs, sollte die Kostenkurve über diese Entwicklung rechnen und nicht über den Startpunkt.
Ebenso wichtig ist die Frage, welche Funktionen an welche Ebene gebunden sind. In fast jeder gestaffelten Software gibt es Fähigkeiten, die erst in höheren Paketen verfügbar sind – häufig betrifft das Mehrlagerfunktionen, Mandantentrennung, feingranulare Rechte, erweiterte Automatisierung oder bestimmte Auswertungen. Für ein SCM-Projekt ist genau das relevant, weil Bestandsführung über mehrere Standorte kein Nice-to-have ist, sondern die Grundlage der Verfügbarkeitsrechnung. Wir empfehlen deshalb, die eigenen unverzichtbaren Funktionen als Liste zu formulieren und für jede einzelne zu klären, in welchem Paket sie enthalten ist.
Ein dritter Punkt betrifft die Zusatzbausteine. Ein Ökosystem mit Plugins und Partnerlösungen ist ein Vorteil, weil Sonderfälle ohne Eigenentwicklung abgedeckt werden. Es erzeugt aber eine zweite Kostenschicht und eine zweite Abhängigkeitsschicht. Zu klären ist: Wer entwickelt und pflegt das Plugin, wie schnell reagiert es auf Änderungen der Plattform, was passiert bei Einstellung, und wie viele solcher Bausteine sind im Zielbild vorgesehen. Eine Installation mit einer zweistelligen Zahl an Erweiterungen ist kein Standardsystem mehr, sondern eine Individuallösung mit entsprechendem Pflegebedarf.
Im Markt für mittelständische Warenwirtschaft lassen sich grob vier Ausgangspunkte unterscheiden. Erstens Systeme, die aus dem Onlinehandel und dem Marktplatzgeschäft kommen und dort ihre Stärke haben. Zweitens Systeme, die aus dem Versandhandel und der Lagerlogistik kommen und mit Kommissionierung, Packplatz und Bestandsgenauigkeit punkten. Drittens Systeme, die aus der Betriebswirtschaft kommen und Auftrag, Beschaffung, Finanzen und Controlling in den Mittelpunkt stellen. Viertens Shopsysteme, die über Module Warenwirtschaftsfunktionen ergänzen.
plentymarkets ist der ersten Gruppe zuzurechnen und hat die Prozessseite über die Jahre erheblich ausgebaut. Für Händler mit vielen Artikeln, vielen Varianten und mehreren Kanälen ist das ein Profil, das gut passt. Für einen Betrieb mit wenigen Artikeln, aber komplexer Beschaffung und intensiver Kalkulation ist der Zuschnitt weniger naheliegend. Diese Einordnung ist keine Wertung: Die beste Warenwirtschaft ist die, deren Grundannahmen zum eigenen Geschäftsmodell passen – und Grundannahmen lassen sich nicht wegkonfigurieren.
Zur Marktstellung machen wir bewusst keine Zahlenangaben. Nutzerzahlen, Marktanteile oder Wachstumsraten kursieren, sind aber unterschiedlich abgegrenzt, schnell veraltet und für eine Auswahlentscheidung ohnehin die falsche Grundlage. Aussagekräftiger sind drei andere Signale: Gibt es im eigenen Umfeld Referenzen mit vergleichbarem Geschäftsmodell, existiert ein tragfähiges Netz von Umsetzungspartnern in erreichbarer Nähe, und wie lebendig ist das Ökosystem an Erweiterungen für die eigenen Sonderfälle. Diese drei Punkte lassen sich in wenigen Gesprächen prüfen und sagen mehr aus als jede Statistik.
Dass Anbieter und Entwicklung in Deutschland sitzen, hat im Alltag konkrete Auswirkungen, die über das Datenschutzargument hinausgehen. Die Software kennt die hiesigen Gepflogenheiten: Umsatzsteuerlogiken, Rechnungsanforderungen, Belegformate für die Buchhaltung, die Anbindung an gängige Steuerberatungsschnittstellen, die im DACH-Raum relevanten Versanddienstleister und Marktplätze, die üblichen Zahlungsverfahren. Wer schon einmal ein international entwickeltes System an deutsche Anforderungen angepasst hat, kennt den Aufwand, der hier entfällt.
Hinzu kommen Support und Dokumentation in deutscher Sprache, Vertragsunterlagen nach hiesigem Recht und Ansprechpartner in derselben Zeitzone. Für mittelständische Betriebe ohne eigene IT-Abteilung ist das kein Komfortmerkmal, sondern ein Risikofaktor: Ein Problem im Auftragsfluss muss am selben Tag klärbar sein, nicht am nächsten Morgen nach einem Ticket in einer Fremdsprache. Diese Punkte gehören in die Bewertung, auch wenn sie in Funktionsvergleichen selten auftauchen.
Am Anfang steht die Datenstruktur, und sie ist bei plentymarkets bewusst tief angelegt. Ein Artikel ist der übergeordnete Container, eine Variante die konkret bestellbare, bestandsführende Einheit. Ein T-Shirt in vier Größen und drei Farben ist ein Artikel mit zwölf Varianten, jede mit eigener Artikelnummer, eigener Barcodezuordnung, eigenem Bestand, eigenem Gewicht und eigenen Maßen. Diese Trennung klingt selbstverständlich, wird in der Praxis aber häufig falsch aufgesetzt – etwa indem Varianten als eigenständige Artikel angelegt werden, was Kanalpflege und Auswertung dauerhaft erschwert.
Über die Grundstruktur hinaus stehen Merkmale und Eigenschaften zur Verfügung, mit denen sich Artikel fachlich beschreiben lassen, ohne für jede Information ein neues Feld zu erfinden. Für die Logistik sind vor allem die physischen Attribute entscheidend: Gewicht in Netto und Brutto, Länge, Breite, Höhe, Verpackungseinheit, gegebenenfalls Gefahrgutkennzeichen, Zolltarifnummer und Herkunftsland. Diese Felder sind kein Formalismus. Sie steuern die Versandkostenermittlung, die Auswahl der Versandart, die Zollpapiere im Auslandsversand und die Plausibilitätsprüfung am Packplatz. Ein Artikelstamm ohne gepflegte Maße und Gewichte macht jede Versandautomatisierung unzuverlässig.
Ein weiterer Baustein sind Set- und Stücklistenartikel. Damit lassen sich Bündel abbilden, die aus mehreren Komponenten bestehen und deren Bestand sich aus den Komponentenbeständen ergibt oder als eigener Bestand geführt wird. Für Handelsunternehmen mit Aktionsbündeln, Starterpaketen oder Ersatzteilsets ist das eine spürbare Erleichterung. Die Grenze liegt bei mehrstufigen Strukturen mit Arbeitsgängen: Wer Zwischenprodukte fertigt, Chargen verfolgt und Arbeitszeit auf Aufträge bucht, verlässt den Bereich, für den eine Handelswarenwirtschaft gebaut ist.
Schließlich die Kanalzuordnung. Aus einem Artikelstamm heraus werden Angebote an unterschiedliche Kanäle ausgespielt, jeweils mit eigenen Texten, Bildern, Kategoriezuordnungen und Preisen. Das ist der eigentliche Wertbeitrag der Plattform, und es ist gleichzeitig die Stelle mit dem größten Pflegeaufwand. Marktplätze stellen unterschiedliche Anforderungen an Attribute, Bildmaße, Kategoriebäume und Pflichtangaben. Wer diesen Aufwand unterschätzt, hat später gepflegte Stammdaten im System und abgelehnte Angebote auf den Kanälen.
Die Bestandsführung ist das Herz jeder Warenwirtschaft, und sie besteht aus mehr als einer Stückzahl. Relevant sind mindestens vier Größen: der physische Bestand, der reservierte Bestand für bestätigte Aufträge, der erwartete Bestand aus laufenden Lieferantenbestellungen und der daraus abgeleitete verfügbare Bestand, der an die Kanäle gemeldet wird. Fehler in dieser Rechnung führen unmittelbar zu Überverkäufen – und Überverkäufe auf Marktplätzen sind nicht nur ein Servicefall, sondern können die eigene Verkäuferbewertung beschädigen.
plentymarkets unterstützt mehrere Lager und innerhalb eines Lagers eine Struktur aus Lagerorten beziehungsweise Lagerplätzen. Damit lassen sich typische Konstellationen abbilden: ein Hauptlager und ein Außenlager, ein Ladengeschäft mit eigenem Bestand, ein Kommissionierbereich und ein Nachschubbereich, ein separater Bereich für Retouren und Prüfware. Für die Kanalmeldung ist entscheidend, welche Lager in den verfügbaren Bestand einfließen. Ein Ladenbestand, der versehentlich online mitverkauft wird, produziert genau die Art von Problem, die man in Bestandsprojekten vermeiden will.
Praktisch bewährt hat sich ein Vorgehen in drei Schritten. Erstens: Bestandsquellen definieren und schriftlich festhalten, welches Lager für welchen Kanal zählt. Zweitens: Puffer bewusst setzen, aber sparsam – ein zu großer Sicherheitspuffer kostet Umsatz, ein zu kleiner erzeugt Überverkäufe. Drittens: Inventurverfahren festlegen. Permanente Inventur mit rollierenden Zählungen einzelner Lagerplätze ist der ruhigere Weg als eine jährliche Vollaufnahme mit Betriebsstillstand, verlangt aber Disziplin und eine saubere Platzstruktur. Welche Verfahren die Plattform in der jeweils genutzten Ausbaustufe unterstützt, ist beim Anbieter zu prüfen.
Zur Bestandsseite gehört auch die Beschaffung. Lieferantenstammdaten, Einkaufspreise, Mindestbestände, Meldebestände und Bestellvorschläge sind vorhanden und decken den Bedarf eines Handelsbetriebs in der Regel ab. Wer aus vielen Quellen mit langen Vorlaufzeiten beschafft – etwa Containerimporte aus Übersee mit Teillieferungen und Wechselkursbezug – sollte prüfen, wie tief die Abbildung von Wareneingangsstufen, Zwischenlagern und Landed-Cost-Kalkulation reicht. Das ist erfahrungsgemäß die Stelle, an der importierende Händler nachbessern müssen.
Der operative Kern ist der Weg vom Auftrag zum Paket. plentymarkets bildet ihn über Auftragsstatus, Picklisten und Versandprofile ab. Aufträge lassen sich nach Kriterien bündeln – nach Versandart, nach Lager, nach Einzel- oder Mehrpositionsauftrag – und als Kommissionierauftrag ausgeben. Für Betriebe mit hohem Anteil an Einzelpositionsaufträgen ist die Sammelkommissionierung ein erheblicher Effizienzhebel: Ein Durchgang durchs Lager bedient viele Aufträge, die Zuordnung erfolgt anschließend am Sortier- oder Packplatz.
Am Packplatz laufen mehrere Dinge zusammen: die Kontrolle der kommissionierten Ware gegen den Auftrag, die Auswahl der Verpackung, die Erfassung von Gewicht und Maßen, die Erzeugung des Versandlabels und die Rückschreibung der Sendungsnummer in den Auftrag. Die Qualität dieses Ablaufs entscheidet über Fehlerquote und Durchsatz. Entscheidend sind dabei drei Dinge, die nichts mit Softwarefunktionen zu tun haben: eine Scanner-gestützte Verifikation statt Sichtprüfung, eine überschaubare Anzahl an Kartongrößen mit klarer Zuordnungsregel und eine geeichte Waage, deren Werte ins System zurückfließen.
Die Versandsteuerung erfolgt über Versandprofile, die Bedingungen und Dienstleister verknüpfen: Gewichtsklassen, Zielländer, Auftragswerte, Artikelmerkmale wie Sperrgut oder Gefahrgut, Kanalherkunft. Aus diesen Bedingungen leitet das System die Versandart ab und übergibt die Sendung an die passende Carrier-Anbindung. Dieses Regelwerk sauber aufzusetzen ist einer der wirksamsten Schritte in einem Einführungsprojekt, weil jede manuelle Versandentscheidung am Packplatz Zeit kostet und Fehler erzeugt. Die praktische Regel: Jede Entscheidung, die ein Mensch mehrfach täglich gleich trifft, gehört in eine Regel.
Eine ehrliche Grenzbetrachtung gehört dazu. Für Lager mit anspruchsvoller Prozessführung – Zonenkommissionierung mit Übergaben, Pick-by-Voice, Nachschubsteuerung nach Verbrauch, Chaotische Lagerhaltung mit dynamischer Wegeoptimierung, mehrstufige Packprozesse – ist eine Warenwirtschaft nicht das richtige Werkzeug. Dann ist ein eigenes Lagerverwaltungssystem sinnvoll, das über Schnittstellen mit der Warenwirtschaft zusammenarbeitet. Die Frage, ob die Lagerfunktionen der Warenwirtschaft genügen oder ein separates System nötig ist, sollte anhand der eigenen Pickleistung, Fehlerquote und Lagerkomplexität entschieden werden, nicht anhand von Funktionslisten.
Retouren sind im Onlinehandel ein eigener Prozess mit eigener Kostenstruktur, und sie sind der Bereich, in dem sich schlechte Systemgestaltung am schnellsten rächt. Der Ablauf besteht aus mehreren Schritten: Anmeldung der Rücksendung durch den Kunden oder Eintreffen einer nicht angemeldeten Sendung, Identifikation des zugehörigen Auftrags, Prüfung der Ware, Entscheidung über Wiederverkäuflichkeit, Einbuchung in den passenden Bestand, Erstellung der Gutschrift, Auslösen der Rückzahlung und Erfassung des Retourengrundes.
plentymarkets bildet diesen Ablauf über Retourenvorgänge ab, die mit dem Ursprungsauftrag verknüpft sind. Wichtig für die Praxis sind drei Details. Erstens die Bestandstrennung: Zurückgekommene Ware darf nicht automatisch als verkaufsfähig gelten, sondern gehört zunächst in einen Prüfbestand, der nicht an die Kanäle gemeldet wird. Zweitens die Gründeerfassung mit einer überschaubaren, auswertbaren Liste – zu viele Kategorien führen dazu, dass immer dieselben zwei gewählt werden. Drittens die Verknüpfung mit der Rückzahlung, damit Gutschrift und Zahlungsvorgang nicht getrennt gepflegt werden müssen.
Der Wertbeitrag entsteht dabei weniger in der Abwicklung als in der Auswertung. Eine Retourenquote je Artikel, je Variante, je Kanal und je Grund ist eine der aussagekräftigsten Kennzahlen im Onlinehandel. Sie zeigt Größenprobleme in Bekleidung, unklare Produktbeschreibungen, Verpackungsschwächen und Sortimentsteile, die trotz Umsatz keinen Beitrag leisten. Diese Auswertung ist der Grund, warum sich die disziplinierte Erfassung der Retourengründe lohnt – und der Grund, warum wir sie in Projekten von Anfang an einfordern.
Das zentrale Automatisierungswerkzeug sind Ereignisaktionen. Das Prinzip ist einfach und mächtig: Tritt ein bestimmtes Ereignis ein – ein Auftrag wird angelegt, eine Zahlung wird zugeordnet, ein Status wechselt, ein Versandlabel wird erzeugt, eine Retoure wird gebucht –, dann prüft das System hinterlegte Bedingungen und führt bei Zutreffen definierte Aktionen aus. Aktionen können Statuswechsel sein, Dokumentenerzeugung, E-Mail-Versand, Zuweisung an eine Bearbeitergruppe, Setzen von Auftragsmerkmalen oder das Auslösen einer Schnittstellenübergabe.
In der Praxis entsteht daraus eine Kette, die einen Standardauftrag ohne menschliches Zutun bis zum Versand führt. Ein typisches Muster: Auftrag aus Marktplatz eingegangen, Zahlung als vorhanden erkannt, Bestand vollständig verfügbar, Lieferland im Standardgebiet, Auftragswert unterhalb einer Prüfgrenze – dann Status auf versandbereit setzen, Lieferschein erzeugen, Auftrag in die Kommissionierliste des zuständigen Lagers geben. Alles, was diese Bedingungen nicht erfüllt, landet in einer Klärungsliste und wird von Menschen angesehen. Genau so gehört Automatisierung gebaut: Der Regelfall läuft, die Ausnahme wird sichtbar.
Die Grenzen dieses Ansatzes sind ebenfalls klar zu benennen. Erstens die Nachvollziehbarkeit: Wenn viele Regeln auf dieselben Ereignisse reagieren, ist die Reihenfolge entscheidend und Wechselwirkungen sind schwer zu überblicken. Zweitens die Dokumentation: Ein Regelwerk, das niemand außer seinem Erbauer versteht, ist ein Betriebsrisiko. Drittens die Testbarkeit: Änderungen am Regelwerk gehören in ein Testsystem, nicht in den Produktivbetrieb am Freitagnachmittag. Wir empfehlen, jede Regel mit Zweck, Auslöser und Verantwortlichem in einer schlichten Liste zu führen – diese Liste ist im dritten Betriebsjahr wertvoller als jede Schulung.
Im Multichannel-Geschäft sind zwei Größen laufend in Bewegung: der Preis und der Bestand. Beide müssen auf mehreren Kanälen gleichzeitig stimmen, und beide haben unterschiedliche Anforderungen je Kanal. Auf der Bestandsseite geht es um Geschwindigkeit und um korrekte Berechnung: Nach jedem Verkauf muss der verfügbare Bestand auf allen Kanälen aktualisiert werden, damit dieselbe Ware nicht zweimal verkauft wird. In der Praxis entsteht hier immer eine kleine Zeitlücke, und die Frage ist nicht, ob es Überverkäufe gibt, sondern wie klein die Lücke ist und wie man mit den Fällen umgeht.
Auf der Preisseite geht es um Differenzierung. Ein Artikel kann auf verschiedenen Kanälen unterschiedliche Preise haben, weil Provisionen, Versandkostenmodelle und Wettbewerbssituation unterschiedlich sind. Plattformseitig lassen sich Verkaufspreise je Kanal, Staffelpreise, Kundengruppenpreise und Aktionspreise abbilden. Für automatische Anpassungen an den Wettbewerb – im Handel als Repricing bekannt – setzen die meisten Anwender zusätzliche Werkzeuge ein, die über Schnittstellen angebunden werden. Wer diesen Weg geht, sollte Preisuntergrenzen als harte Regel im System hinterlegen: Eine Automatik ohne Untergrenze verkauft irgendwann unter Deckungsbeitrag.
Ein unterschätzter Bereich ist die Automatisierung der Beschaffung. Meldebestände, Mindestbestände und Bestellvorschläge sind Standard, aber ihre Parameter werden selten gepflegt. Ein Meldebestand, der bei der Einführung einmal gesetzt wurde und drei Jahre später noch gilt, passt mit hoher Wahrscheinlichkeit nicht mehr zum Absatz. Hier liegt ein einfacher, wirksamer Hebel: die regelmäßige Überprüfung der Dispositionsparameter anhand der tatsächlichen Absatz- und Lieferzeitentwicklung. Das ist keine Softwarefunktion, sondern eine Routine, die im Kalender stehen muss.
Der Begriff künstliche Intelligenz wird im ERP-Umfeld inzwischen für sehr unterschiedliche Dinge verwendet, und für eine Entscheidungsgrundlage lohnt sich die Trennung. Vieles, was so bezeichnet wird, ist Statistik oder Regelautomatik: Absatzprognose auf Basis historischer Verläufe mit Saison- und Trendkomponente, ABC-Analysen, Klassifizierung von Artikeln nach Umschlagshäufigkeit, Ausreißererkennung in Beständen. Diese Verfahren sind bewährt und nützlich, aber nicht neu. Sie brauchen vor allem eine ausreichend lange, saubere Datenhistorie – und genau daran scheitert es in Projekten häufiger als an der Methode.
Darüber hinaus finden sich in modernen Handelsplattformen sprachbasierte Assistenzfunktionen: Erzeugung oder Verbesserung von Artikeltexten für unterschiedliche Kanäle, Übersetzung von Beschreibungen, Kategorisierungsvorschläge, Unterstützung im Kundenservice bei Standardanfragen. Für Händler mit großen Sortimenten und Pflichtangaben je Marktplatz kann das erheblichen Aufwand sparen. Welche dieser Funktionen in der eigenen Ausbaustufe verfügbar sind, wie sie abgerechnet werden und welche Daten dabei verarbeitet werden, ist ausdrücklich beim Anbieter zu prüfen – hier verändert sich das Angebot schnell.
Unsere Haltung dazu ist zurückhaltend und lässt sich in vier Punkten zusammenfassen. Erstens: Fragen Sie bei jeder Funktion, welche Entscheidung sie trifft und ob ein Mensch sie überschreiben kann. Eine Prognose, die den Bestellvorschlag beeinflusst, ist unkritisch; eine Automatik, die eigenständig bestellt, braucht Grenzen. Zweitens: Klären Sie, welche Daten verarbeitet werden, wo das geschieht und ob sie zur Modellverbesserung genutzt werden – Kunden-, Adress- und Bestelldaten sind personenbezogen. Drittens: Bewerten Sie den Nutzen am eigenen Volumen. Prognoseverfahren brauchen Datenmengen; bei wenigen Artikeln mit sporadischem Absatz liefern sie keine belastbare Grundlage. Und viertens: Der weitaus größte Teil der Effizienzgewinne im Handel entsteht nach unserer Erfahrung durch saubere Stammdaten und ein gut gebautes Regelwerk, nicht durch Modellintelligenz. Automatisierung ist Fundament, KI ist Feinschliff.
Ein letzter praktischer Hinweis zur Prognose. Wer Absatzprognosen für die Disposition nutzt, sollte die Prognosegüte messen, statt ihr zu vertrauen. Der Vergleich von prognostizierter und tatsächlicher Nachfrage über einige Monate zeigt schnell, für welche Artikelgruppen die Prognose taugt und für welche nicht. Für schnelldrehende Standardartikel funktioniert sie meist gut, für Aktionsware, Neueinführungen und sporadische Ersatzteile deutlich schlechter. Diese Differenzierung ist der Unterschied zwischen einem hilfreichen Werkzeug und einer teuren Fehldisposition.
Die Multichannel-Anbindung ist der Bereich, in dem plentymarkets seine Herkunft am deutlichsten ausspielt. Funktional geht es um drei Richtungen. Erstens die Ausspielung von Artikeldaten an den Kanal: Titel, Beschreibung, Bilder, Attribute, Kategoriezuordnung, Preis, Versandinformationen. Zweitens den Import von Aufträgen inklusive Kundendaten, Zahlungsinformationen und kanalspezifischen Vorgaben. Drittens die kontinuierliche Rückmeldung von Bestand, Preis und Versandstatus, damit der Kanal den aktuellen Stand kennt.
Der Aufwand liegt in der ersten Richtung. Jeder Marktplatz hat ein eigenes Datenmodell mit eigenen Pflichtfeldern, eigenen Kategoriebäumen und eigenen Regeln für Bildmaße und Textlängen. Ein Artikel, der im eigenen Shop vollständig beschrieben ist, kann auf einem Marktplatz abgelehnt werden, weil ein Attribut fehlt, das dort verpflichtend ist. Für Sortimente mit vielen Varianten ist das ein erheblicher Pflegeaufwand, der planbar wird, wenn man ihn als eigene Aufgabe mit eigener Zuständigkeit einrichtet – und der eskaliert, wenn man ihn nebenbei erledigen will.
Zwei Punkte gehören in jede Prüfung. Der erste betrifft die Fulfillment-Programme der Marktplätze, bei denen der Bestand physisch beim Plattformbetreiber liegt und von dort versandt wird. Das ist ein eigener Bestandsort mit eigener Logik, eigenen Gebühren und eigenen Rückführungsregeln, und es muss im System sauber getrennt vom eigenen Lager geführt werden. Der zweite betrifft die Kundendaten: Marktplätze übermitteln teils anonymisierte oder weitergeleitete Kontaktdaten. Für die Versandbenachrichtigung und für die Empfängersteuerung beim Carrier hat das unmittelbare Folgen, die man kennen muss, bevor man auf automatische Benachrichtigung setzt.
Auf der Versandseite bietet die Plattform Anbindungen an die im DACH-Raum gängigen Paketdienstleister – direkt oder über Erweiterungen. Der Ablauf ist überall ähnlich: Das System übergibt Empfängeradresse, Gewicht, Maße und gewählte Serviceoptionen, erhält ein Label zurück, druckt es am Packplatz und schreibt die Sendungsnummer in den Auftrag. Für Betriebe mit einem oder zwei Dienstleistern und Standardversand ist die direkte Anbindung der einfachste und schnellste Weg.
Sobald mehrere Carrier parallel laufen, sich Sonderfälle häufen oder ein Ausfallpfad gebraucht wird, kommt eine Zwischenschicht ins Spiel. Multi-Carrier-Plattformen wie shipcloud oder Sendcloud sprechen mehrere Dienstleister über ein einheitliches Datenmodell an, bieten ein gemeinsames Statusvokabular, Regelwerke für die Carrier-Auswahl und häufig Retourenportale. Der Nutzen ist real, der Preis ist eine zusätzliche Komponente im kritischen Versandpfad. Unsere Erfahrung: Bei einem Carrier lohnt sich die Zwischenschicht kaum, bei drei oder mehr fast immer, und dazwischen entscheidet die Frage, wie oft die Auswahl zwischen Dienstleistern tatsächlich variiert.
Unabhängig vom Weg gehören vier Punkte auf die Prüfliste. Erstens die Labelformate und die Druckerkette – falsche Skalierung ist eine notorische Ursache für Lesefehler in der Sortierung. Zweitens die Behandlung von Stornos und Neuerzeugungen, wenn am Packplatz etwas schiefgeht. Dritten die Unterstützung der eigenen Sonderoptionen: Sperrgut, Nachnahme, Zustellnachweis, Zollinhaltserklärung. Viertens die Statusrückschreibung an alle Stellen, an denen Menschen arbeiten – in den Auftrag, in die Kundenkommunikation, in den Servicefall. Der letzte Punkt ist der, der in Angeboten am seltensten steht und im Betrieb am meisten Arbeit spart.
Auf der Zahlungsseite sind Anbindungen an die verbreiteten Zahlungsanbieter vorhanden. Der praktische Nutzen liegt in der automatischen Zuordnung von Zahlungseingängen zu Aufträgen, weil erst diese Zuordnung die weitere Automatisierung erlaubt: Ohne erkannte Zahlung darf kein Versand ausgelöst werden, mit erkannter Zahlung kann der Auftrag ohne Zutun weiterlaufen. Für Rückzahlungen im Retourenfall gilt dasselbe in umgekehrter Richtung. Wichtig ist die Prüfung, welche Zahlarten und welche Anbieter im eigenen Kanalmix vorkommen und wie Teilzahlungen, Gutscheine und Zahlungen auf Rechnung behandelt werden.
Auf der Buchhaltungsseite geht es um Exportformate. Der im DACH-Raum verbreitete Weg führt über DATEV-kompatible Formate an die Steuerkanzlei, alternativ über Schnittstellen zu Buchhaltungssystemen. Diese Verbindung ist im Handel anspruchsvoller als sie klingt, weil Umsatzsteuersachverhalte im grenzüberschreitenden Onlinehandel komplex sind: Lieferschwellen und One-Stop-Shop-Meldungen, Marktplatzhaftung, unterschiedliche Steuersätze je Zielland, Rechnungsstellung durch Plattformbetreiber. Die Systemkonfiguration ist hier nur eine Seite; die andere ist die Abstimmung mit der Steuerberatung. Wir empfehlen dringend, die Kanzlei in das Einführungsprojekt einzubeziehen, statt Exportformate nachträglich zu reparieren.
Fulfillment-Partner bilden eine eigene Kategorie. Wer die Lagerhaltung ganz oder teilweise an einen Dienstleister abgibt, braucht eine Verbindung, die Aufträge an den Dienstleister übergibt, Bestände zurückmeldet und Versandstatus einspielt. Solche Anbindungen existieren für verschiedene Dienstleister, teils als Plugin, teils über die API. Entscheidend sind dabei drei Fragen: Wie aktuell ist die Bestandsrückmeldung, wie werden Teillieferungen und Fehlmengen behandelt, und wer ist für Bestandsdifferenzen verantwortlich. Der Wechsel zu einem Fulfillment-Dienstleister ist prozessual ein größerer Eingriff als ein Systemwechsel und gehört entsprechend geplant.
Für alles, was die Standardanbindungen nicht abdecken, steht eine REST-Schnittstelle bereit. Sie erlaubt den Zugriff auf Artikel, Varianten, Bestände, Aufträge, Kunden, Retouren und weitere Objekte und ist damit die Grundlage für Eigenentwicklungen, für Anbindungen an Spezialsysteme und für Datenauswertungen außerhalb der Plattform. Für die Bewertung einer solchen Schnittstelle sind aus Projekterfahrung fünf Punkte wichtiger als die Objektliste: Qualität der Dokumentation, Verfügbarkeit einer Testumgebung, Aussagekraft der Fehlermeldungen, Umgang mit Aufruflimits und die Ankündigungspraxis bei Versionswechseln.
Der Plugin-Marktplatz ist die zweite Erweiterungsebene. Er enthält Erweiterungen des Anbieters und von Partnern: Kanalanbindungen, Zahlungsintegrationen, Layoutbausteine, Auswertungen, Werkzeuge für Preis- und Bestandsmanagement. Der Vorteil liegt auf der Hand – Sonderfälle ohne Eigenentwicklung. Die Kehrseite verdient eine klare Ansprache: Jedes Plugin ist Software eines Dritten in einem produktiv genutzten System. Es kann Fehler enthalten, es kann bei Plattform-Updates brechen, es kann eingestellt werden, und es kann bei schlechter Umsetzung die Leistung des Gesamtsystems beeinträchtigen.
Daraus folgt eine Governance-Regel, die wir in Projekten konsequent empfehlen. Führen Sie eine Liste aller installierten Erweiterungen mit Zweck, Anbieter, Version, Kosten und einem benannten Verantwortlichen. Installieren Sie nichts im Produktivsystem, was nicht vorher im Testsystem gelaufen ist. Entfernen Sie regelmäßig, was nicht mehr genutzt wird. Und prüfen Sie vor jeder Neuinstallation, ob die Anforderung nicht auch mit Konfiguration und Ereignisaktionen lösbar ist. Ein System mit wenigen, gut gepflegten Erweiterungen ist auf Dauer deutlich billiger als eines mit vielen halb genutzten.
Das häufigste Vergleichspaar im DACH-Mittelstand ist plentymarkets und JTL, und der wesentliche Unterschied liegt nicht in Funktionslisten, sondern im Betriebsmodell. plentymarkets ist reine Cloud: Der Anbieter betreibt, aktualisiert und skaliert, der Kunde konfiguriert. JTL basiert auf einer Datenbank und Client-Anwendungen, die im eigenen Verantwortungsbereich betrieben werden, ergänzt um Cloud-Bausteine. Daraus folgen unterschiedliche Verantwortlichkeiten: Wer Cloud wählt, gibt Kontrolle über Versionsstände und Wartungsfenster ab und gewinnt Freiheit von Serverbetrieb. Wer Eigenbetrieb wählt, behält Kontrolle und trägt die Betriebslast.
Fachlich gilt vereinfacht: JTL kommt aus der Lager- und Versandwelt und hat dort traditionell ausgeprägte Prozesse, insbesondere bei mobiler Kommissionierung und Packplatzabläufen. plentymarkets kommt aus der Kanalwelt und hat dort seine Tiefe. Beide Systeme haben in den letzten Jahren in Richtung des jeweils anderen ausgebaut, sodass der Unterschied kleiner geworden ist. Für die Entscheidung sind deshalb zwei Fragen zielführender als jeder Funktionsvergleich: Wo liegt der Engpass im eigenen Betrieb – im Lager oder in der Kanalpflege? Und passt Cloud-Betrieb zur eigenen IT-Strategie?
Xentral ist ebenfalls eine Cloud-Lösung und deckt die kaufmännische Breite eines Handelsbetriebs ab, mit Stärken in Automatisierung und Anbindungsvielfalt und einer gewissen Nähe zu leichter Fertigung. Wer neben Handel auch Konfektionierung, Montage oder Auftragsproduktion betreibt, findet dort eher passende Strukturen. Wer dagegen sehr viele Varianten über sehr viele Marktplätze pflegt, findet in einer marktplatzgeborenen Plattform meist die feinere Kanalsteuerung. Die Systeme überlappen deutlich, und der Unterschied zeigt sich erst an den eigenen Sonderfällen.
Billbee ist bewusst schlank und für kleinere Multichannel-Händler gebaut, die Aufträge aus mehreren Kanälen einsammeln, Rechnungen erzeugen und Versandlabels drucken wollen, ohne ein umfassendes ERP einzuführen. Für diesen Zweck ist es effizient und schnell startklar. Sobald Beschaffung, Mehrlagerlogik, Bestandsplanung oder tiefe Auswertungen wichtig werden, stößt der Zuschnitt an Grenzen – nicht als Mangel, sondern als Konsequenz der Positionierung. Der Übergang von einem solchen System zu einer vollen Warenwirtschaft ist ein typischer Wachstumsschritt im Onlinehandel.
pixi kommt aus dem Versandhandel und dem Fulfillment-Umfeld und ist entsprechend auf Lager- und Versandprozesse mit hohem Sendungsvolumen ausgerichtet. Für Betriebe, deren Engpass eindeutig im Lager liegt und die dort Prozessdisziplin brauchen, ist das ein passendes Profil. Der Unterschied zu einer marktplatzgeborenen Plattform liegt im Baukastencharakter: Wo das eine System Wege vorgibt, bietet das andere Konfigurationsfreiheit – mit dem entsprechenden Aufwand, sie zu nutzen. Beide Ansätze haben ihre Berechtigung, und die Wahl hängt davon ab, ob man eher Führung oder eher Gestaltungsraum braucht.
Eine grundsätzlich andere Architektur entsteht, wenn ein Shopsystem wie Shopware die Vertriebsseite übernimmt und eine separate Warenwirtschaft die Prozessseite. Der Vorteil liegt in der Wahlfreiheit: Man kombiniert die stärkste Shopseite mit dem passenden ERP. Der Preis ist eine Schnittstelle im kritischen Pfad und die Notwendigkeit, für jedes Datenobjekt zu klären, welches System die Wahrheit hält. Artikeldaten im Shop oder im ERP? Bestände im ERP, gemeldet an den Shop? Kunden in beiden Systemen mit welchem Abgleich? Diese Fragen müssen vor der ersten Zeile Konfiguration beantwortet sein.
Eine Zwischenform sind Warenwirtschaftserweiterungen, die direkt im Shopsystem arbeiten – Pickware ist dafür das bekannteste Beispiel im Shopware-Umfeld. Der Reiz liegt in der Einheitlichkeit: ein Datenbestand, keine Synchronisation, ein Bedienkonzept. Die Grenze liegt in der Bindung an das Shopsystem und darin, wie weit die Marktplatzbreite und die kaufmännische Tiefe reichen. Für Händler mit starkem eigenen Shop und begrenzter Marktplatzaktivität ist das oft der ruhigste Weg; für ausgeprägte Multichannel-Modelle eher nicht.
Die zentrale Einsicht dieses Kapitels lautet deshalb: Die Frage ist selten, welches System das beste ist, sondern welche Architektur zum eigenen Geschäftsmodell passt. Ein Betrieb mit vielen Kanälen und vielen Varianten braucht eine andere Antwort als ein Betrieb mit einem starken Shop und komplexem Lager. Und in beiden Fällen ist die Entscheidung über das führende System für Artikel, Bestände und Aufträge wichtiger als die Entscheidung über den Hersteller. Wer diese Reihenfolge einhält, kommt zu belastbaren Ergebnissen; wer mit Herstellernamen beginnt, diskutiert Geschmacksfragen.
Das reine Cloud-Modell hat Konsequenzen, die im Auswahlgespräch offen benannt werden sollten – in beide Richtungen. Auf der Habenseite steht, dass Serverbetrieb, Datenbankpflege, Sicherungen, Skalierung bei Lastspitzen und das Einspielen von Aktualisierungen nicht im eigenen Haus liegen. Für mittelständische Betriebe ohne eigene IT-Abteilung ist das ein echter Vorteil, weil der größte Teil des Betriebsrisikos beim Anbieter liegt und nicht bei einer einzelnen Person im Unternehmen, die nebenbei die Serverpflege übernimmt.
Auf der Sollseite stehen drei Punkte, die wir offen aussprechen. Erstens: Es gibt keine Möglichkeit, das System im eigenen Rechenzentrum oder bei einem selbst gewählten Hoster zu betreiben. Unternehmen mit einer IT-Richtlinie, die Eigenbetrieb kritischer Systeme vorschreibt, oder mit Kunden, die das verlangen, können die Plattform nicht einsetzen. Zweitens: Versionsstände und Wartungsfenster bestimmt der Anbieter. Man kann eine Aktualisierung nicht beliebig aufschieben, um ein eigenes Projekt abzuwarten. Drittens: Die Verfügbarkeit des Systems ist gleichbedeutend mit der Verfügbarkeit des Internetzugangs am Standort. Ein Lager ohne Internet ist ein Lager ohne Warenwirtschaft.
Aus dem dritten Punkt folgt eine konkrete Empfehlung, die wir in Projekten regelmäßig geben: eine zweite, technisch unabhängige Internetverbindung am Lagerstandort, idealerweise über einen anderen Zugangsweg, mit automatischer Umschaltung. Das ist im Verhältnis zu den Kosten eines Versandstillstands eine kleine Investition. Ergänzend gehört ein Notfallverfahren definiert: Was passiert, wenn das System für zwei Stunden nicht erreichbar ist – wird weiter gepackt und später gebucht, oder wird gewartet? Diese Frage sollte vor dem ersten Ausfall beantwortet sein.
Die Migration ist in fast jedem Warenwirtschaftsprojekt der Teil mit den meisten unangenehmen Überraschungen. Der Grund ist selten technisch. Er liegt darin, dass Altsysteme über Jahre gewachsene Datenbestände enthalten, deren Qualität niemand kennt, bis sie in ein neues System gehoben werden sollen. Typische Befunde: Artikel, die nie verkauft wurden, aber Pflege verursachen; Varianten ohne Maße und Gewichte; doppelte Kunden mit unterschiedlichen Schreibweisen; Barcodes, die mehrfach vergeben sind; Bestände, die nicht mit der physischen Realität übereinstimmen.
Praktisch bewährt hat sich ein Vorgehen in vier Schritten. Erstens eine Bestandsaufnahme mit Zählungen: Wie viele Artikel, Varianten, Kunden, offene Aufträge gibt es tatsächlich, und wie viele davon sind aktiv? Zweitens eine Bereinigungsphase im Altsystem, bevor migriert wird – es ist billiger, dort zu löschen als hier zu importieren. Drittens Probemigrationen in ein Testsystem mit Abgleich der Zählungen und stichprobenhafter Prüfung einzelner Datensätze. Viertens eine klare Regel, welche Historie mitgenommen und welche nur archiviert wird. Vollständige Auftragshistorien zu migrieren ist verlockend und selten nötig; ein revisionssicherer Export des Altsystems erfüllt den Zweck meist besser.
Ein eigener Punkt sind die Bestände. Sie sollten möglichst spät und möglichst nah an einer Zählung übernommen werden, weil ein migrierter Bestand, der schon beim Start falsch ist, alle folgenden Bewegungen unbrauchbar macht. In der Praxis heißt das: Umstellung an einem Tag mit geringem Betrieb, körperliche Zählung der wichtigsten Artikelgruppen, Einbuchung als Anfangsbestand. Das kostet einen Tag und spart Monate an Fehlersuche.
Ein offenes Ökosystem ist ein Vorteil, verlangt aber Regeln. Wir empfehlen eine schriftlich festgehaltene Governance mit fünf Punkten. Erstens: Ein Verzeichnis aller Erweiterungen mit Zweck, Anbieter, Kosten und Verantwortlichem. Zweitens: Keine Installation im Produktivsystem ohne vorherigen Test. Drittens: Vor jeder Neuinstallation die Frage, ob Konfiguration und Ereignisaktionen ausreichen. Viertens: Regelmäßige Bereinigung nicht genutzter Erweiterungen. Fünftens: Bewertung der Abhängigkeit – welche Erweiterungen sind so kritisch, dass ihr Ausfall den Versand stoppt, und gibt es dafür einen Ersatzweg?
Das Testsystem verdient eigene Aufmerksamkeit. In einem Cloud-Modell ist eine separate Umgebung nicht selbstverständlich, sondern eine Frage von Verfügbarkeit und Kosten – ob und in welcher Form eine Test- oder Sandbox-Umgebung zur Verfügung steht, ist beim Anbieter zu prüfen. Wo sie existiert, gehört sie konsequent genutzt: für Regelwerksänderungen, für Plugin-Tests, für Schnittstellenanpassungen und für die Einarbeitung neuer Mitarbeitender. Ein Unternehmen, das jede Änderung produktiv erprobt, arbeitet dauerhaft mit erhöhtem Risiko – und merkt es erst, wenn ein Regelwerksfehler hundert Aufträge falsch behandelt.
Für den laufenden Betrieb hat sich ein schlankes Routineset bewährt. Täglich: Klärungslisten leeren, also alle Aufträge ansehen, die die Automatik nicht durchlaufen haben. Wöchentlich: Bestandsdifferenzen und Retoureneingänge prüfen. Monatlich: Kennzahlen betrachten – Anteil automatisch abgewickelter Aufträge, Überverkäufe, Retourenquote nach Grund, Durchlaufzeit von Auftragseingang bis Versand, Anteil der Aufträge, die den Tagesabschluss erreichen. Vierteljährlich: Regelwerk, Erweiterungen, Dispositionsparameter und Berechtigungen durchsehen. Diese Routine kostet wenige Stunden im Monat und ist der Unterschied zwischen einem System, das trägt, und einem, das langsam verwildert.
Zur Frage, ab welcher Größe sich eine Cloud-Warenwirtschaft lohnt, kursieren gern runde Zahlen. Wir halten sie für irreführend, weil sie den entscheidenden Faktor ausblenden: Nicht das Auftragsvolumen allein bestimmt den Nutzen, sondern das Verhältnis von Komplexität zu verfügbarer Arbeitszeit. Ein Betrieb mit wenigen hundert Aufträgen im Monat, aber fünf Kanälen und tausenden Varianten hat einen höheren Systembedarf als ein Betrieb mit dem zehnfachen Volumen aus einem einzigen Shop und fünfzig Artikeln.
Sinnvoller ist eine qualitative Einordnung in vier Stufen. Auf der ersten Stufe wird über einen Kanal verkauft, die Auftragsmenge ist überschaubar, und eine schlanke Lösung oder das Shopsystem selbst genügt. Auf der zweiten Stufe kommen weitere Kanäle hinzu, die Mehrfachpflege wird zum Ärgernis, und ein System zur Bündelung von Aufträgen und Beständen lohnt sich. Auf der dritten Stufe wird der Handel zum Prozess mit Kennzahlen, Mehrlagerlogik, Beschaffungsplanung und Automatisierung – hier liegt der Kernbereich einer vollen Warenwirtschaft. Auf der vierten Stufe kommen eigene Anforderungen hinzu, die über Standardfunktionen hinausgehen: Fulfillment-Verbund, mehrere Firmen, eigene Schnittstellen, Lagerverwaltung als separates System.
Die praktikable Prüffrage lautet deshalb nicht, ab wie vielen Aufträgen sich ein System rechnet, sondern: Wie viele Stunden pro Woche gehen heute für Datenpflege in mehreren Systemen, für die Suche nach Auftragsständen und für die Korrektur von Bestandsfehlern verloren – und welcher Anteil davon ist strukturell vermeidbar? Diese Zahl lässt sich in einer Woche grob erheben und ist eine belastbarere Grundlage als jede Faustformel.
In der Praxis wiederholen sich einige Muster. Das erste ist der wachsende Marktplatzhändler, der aus einer schlanken Lösung herauswächst: Die Auftragsabwicklung funktioniert, aber Beschaffung, Bestandsplanung und Auswertung fehlen. Für ihn ist der Schritt zu einer vollen Warenwirtschaft ein Gewinn, sofern er die Konfigurationsarbeit einplant. Das zweite Muster ist der stationäre Händler mit neuem Onlinegeschäft: Hier liegt die Herausforderung in der Bestandstrennung zwischen Laden und Online und in der Artikeldatenqualität, die im Ladengeschäft nie gebraucht wurde.
Das dritte Muster ist der Hersteller oder Importeur, der zunehmend direkt verkauft. Er hat gute Artikeldaten, aber keine Erfahrung mit Kanalpflege, Retouren und Endkundenkommunikation. Für ihn ist die Kanalstärke der Plattform der wesentliche Nutzen, während er bei Fertigungs- und Kalkulationsanforderungen genau prüfen muss, ob eine Handelswarenwirtschaft ausreicht. Das vierte Muster ist der Betrieb mit ausgelagertem Fulfillment: Hier steht nicht die Lagerfunktion im Mittelpunkt, sondern die Qualität der Schnittstelle zum Dienstleister und die Verlässlichkeit der Bestandsrückmeldung.
Allen vier Mustern ist eines gemeinsam: Der Erfolg hängt weniger am System als an zwei Rollen im Unternehmen. Die erste ist eine Person, die die Prozesse versteht und die Konfiguration verantwortet – nicht in Vollzeit, aber benannt und mit Zeitbudget. Die zweite ist eine Person, die Stammdatenqualität verantwortet. Fehlen diese Rollen, kann die beste Plattform ihren Nutzen nicht entfalten, weil Regelwerke veralten und Stammdaten verfallen. Diese Erkenntnis ist unspektakulär und in unserer Erfahrung der zuverlässigste Unterschied zwischen erfolgreichen und mühsamen Projekten.
Die Gesamtkosten einer Cloud-Warenwirtschaft entstehen aus vier Blöcken, die nur gemeinsam ein Bild ergeben. Der erste ist das Grundabonnement, gestaffelt nach Paketebene und den darin enthaltenen Kontingenten. Der zweite ist der volumenabhängige Anteil, der mit Aufträgen, Positionen oder zusätzlichen Kanälen wächst. Der dritte sind die Erweiterungen: Plugins, Kanalanbindungen, Partnerlösungen und Zusatzmodule, die einzeln überschaubar und in Summe erheblich sind. Der vierte ist der Einführungs- und Betriebsaufwand: externe Beratung, Migration, Konfiguration, Schulung – und vor allem interne Arbeitszeit.
Der vierte Block ist der, der in Angeboten fehlt und in Projekten dominiert. Stammdaten bereinigen, Kanalattribute pflegen, Regelwerke bauen und testen, Mitarbeitende einarbeiten, Klärungslisten abarbeiten – das ist Arbeit, die im eigenen Haus anfällt und die man einplanen muss. Unsere Empfehlung: Schätzen Sie diesen Aufwand in Personentagen und bewerten Sie ihn mit einem realistischen internen Satz. Erst dann ist ein Vergleich zwischen Systemen oder zwischen Systemwechsel und Weiterbetrieb belastbar.
Zur Gegenrechnung gehört ebenfalls Disziplin. Der Nutzen einer Warenwirtschaft ist im Handel ungewöhnlich gut greifbar: eingesparte Doppelpflege in mehreren Backends, vermiedene Überverkäufe mit ihren Folgekosten, kürzere Durchlaufzeit von Auftrag bis Versand, geringere Fehlerquote am Packplatz, gezielte Sortimentsentscheidungen durch Retourenauswertung, weniger Kapitalbindung durch bessere Disposition. Diese Effekte lassen sich mit einfachen Annahmen beziffern, und sie sind es, die eine Investition rechtfertigen – nicht das Gefühl, dass ein neues System übersichtlicher aussieht.
Ein Hinweis zur Vorsicht bei Angebotsvergleichen: Preismodelle unterschiedlicher Anbieter sind selten direkt vergleichbar, weil sie an unterschiedlichen Größen ansetzen – Nutzer, Aufträge, Kanäle, Umsatz, Module. Wir empfehlen deshalb, das eigene Mengengerüst aufzuschreiben und jeden Anbieter zu bitten, genau dieses Gerüst zu bepreisen, einschließlich der Entwicklung über drei Jahre. Und klären Sie, was bei Überschreitung einer Grenze passiert, denn ein Saisonhoch überschreitet Grenzen zuverlässig.
Dass Entwicklung und Betrieb bei einem deutschen Unternehmen liegen und die Verarbeitung im europäischen Rechtsrahmen stattfindet, ist im aktuellen Umfeld ein realer Vorteil. Es entfällt die Grundsatzdiskussion über Datentransfers in Drittländer, die Vertragsunterlagen sind auf hiesige Verhältnisse zugeschnitten, Ansprechpartner sind erreichbar und sprechen die Sprache der eigenen Dokumentation. Für Unternehmen, die aus Compliance-Vorgaben oder aus Kundenanforderungen heraus auf europäische Verarbeitung achten müssen, ist das ein Argument, das über Funktions- und Preisvergleiche hinausgeht.
Gleichzeitig ersetzt die Herkunft keine Prüfung. Der konkrete Verarbeitungs- und Speicherort, die eingesetzte Infrastruktur und die Frage, welche Unterauftragnehmer beteiligt sind, gehören ausdrücklich beim Anbieter erfragt und dokumentiert. Das gilt besonders für Zusatzdienste: Ein Sprachmodell für Artikeltexte, ein Zahlungsdienstleister, ein Versanddienstleister oder ein Marktplatzbetreiber sind eigene Beteiligte mit eigener Verarbeitung. Die Kette ist nur so souverän wie ihr schwächstes Glied, und die Kette endet nicht beim Warenwirtschaftsanbieter.
Ebenso offen gehört der Cloud-Only-Charakter benannt. Es gibt keine Variante für den Betrieb im eigenen Rechenzentrum. Wer eine IT-Richtlinie hat, die den Eigenbetrieb kritischer Systeme vorschreibt, oder Kunden, die eine solche Anforderung stellen, muss diese Frage vor allen anderen klären. Sie lässt sich nicht durch Konfiguration lösen. Umgekehrt gilt: Für die überwiegende Zahl mittelständischer Handelsbetriebe ist der professionell betriebene Cloud-Dienst eines europäischen Anbieters sicherheitstechnisch besser als ein selbst betriebener Server im Nebenraum – diese ehrliche Gegenrechnung gehört zur Diskussion.
Anders als ein Transportdienstleister, der für die eigene Leistung regelmäßig als eigener Verantwortlicher handelt, verarbeitet ein Softwareanbieter die Daten seiner Kunden typischerweise nach deren Weisung – es liegt also eine Auftragsverarbeitung vor, für die ein entsprechender Vertrag erforderlich ist. Verantwortlich für die Verarbeitung bleibt das einsetzende Unternehmen. In diesem Vertrag gehören die üblichen Punkte geregelt: Gegenstand und Dauer, Art der Daten und Kategorien betroffener Personen, technische und organisatorische Maßnahmen, Umgang mit Unterauftragnehmern, Unterstützung bei Betroffenenanfragen, Löschung und Rückgabe bei Vertragsende.
Praktisch folgen daraus vier Aufgaben im eigenen Haus. Erstens die Aufnahme der Verarbeitung in das Verarbeitungsverzeichnis, einschließlich der angebundenen Kanäle, Zahlungs- und Versanddienstleister. Zweitens die Anpassung der Datenschutzinformation für Kunden, damit erkennbar ist, an wen Daten zur Vertragserfüllung weitergegeben werden. Drittens ein Berechtigungskonzept, das dem Prinzip der geringsten Rechte folgt – eine Lagerkraft braucht keinen Zugriff auf Umsatzauswertungen, der Kundenservice keinen auf Einkaufspreise. Viertens ein Löschkonzept, das mit den Aufbewahrungspflichten für Handels- und Steuerbelege abgestimmt ist; im Handel ist das der häufigste Konflikt, weil Bestelldaten gleichzeitig Belege sind.
Zum Abschluss die Betroffenenrechte. Wenn ein Kunde Auskunft über die zu ihm gespeicherten Daten verlangt oder eine Löschung fordert, muss klar sein, welche Daten im System liegen, welche in angebundenen Kanälen und Diensten, wie eine Auskunft erzeugt wird und welche Daten aus Aufbewahrungsgründen bestehen bleiben. Wer diesen Ablauf einmal geübt hat, beantwortet die nächste Anfrage in Minuten statt in Tagen. Und wer den strukturierten Export der eigenen Daten vertraglich gesichert hat, hat gleichzeitig die wichtigste Vorsorge gegen Abhängigkeit getroffen – Datenhoheit zeigt sich am Ende immer daran, ob man seine Daten vollständig und verwertbar wieder herausbekommt.
