Ursprünglich aus dem Münchner Raum stammend, hat sich pixi* über zwei Jahrzehnte im deutschsprachigen Onlinehandel etabliert – lange bevor „Fulfillment“ ein Modewort wurde. Seit der Übernahme durch die Descartes Systems Group, einen börsennotierten kanadischen Logistiksoftware-Konzern, wird das Produkt als Teil eines internationalen Portfolios geführt und häufig als „Descartes pixi*“ vermarktet. Entwicklung, Support und Vertriebsstrukturen für den DACH-Markt sind dabei in Deutschland verankert geblieben – ein Punkt, der in Auswahlprozessen regelmäßig unterschätzt wird, weil viele Interessenten den Konzernnamen nicht kennen.
Drei Eigenschaften prägen pixi* in der Praxis:
Die häufigste Verwechslung in Erstgesprächen: pixi* wird für ein Shopsystem oder ein ERP im Vollumfang gehalten. Beides trifft nicht zu. Der Onlineshop bleibt Shopware, Shopify, Adobe Commerce oder was auch immer im Einsatz ist – pixi* übernimmt die Bestellung, sobald sie entstanden ist. Und die Buchhaltung bleibt in der Regel beim etablierten Buchhaltungs- oder Steuerberatungssystem; pixi* liefert die belegrelevanten Daten dorthin, führt aber keine Bilanz.
Diese Arbeitsteilung ist kein Mangel, sondern eine Entscheidung. Systeme, die alles gleichzeitig sein wollen, sind in jeder Disziplin nur mittelmäßig. pixi* konzentriert sich auf die Schicht zwischen Verkaufskanal und Lagerrealität – und genau dort liegt bei wachsenden Onlinehändlern typischerweise der größte operative Schmerz: Bestände stimmen nicht, Aufträge bleiben liegen, Retouren stapeln sich, niemand weiß verlässlich, was tatsächlich verfügbar ist.
Aus unseren Projekten lässt sich der Eignungsbereich recht klar beschreiben. pixi* passt zu Händlern, die selbst versenden oder versenden lassen, die mehrere Verkaufskanäle bedienen, die ein physisches Lager mit Lagerplätzen und Laufwegen betreiben und die eine Auftragsmenge erreicht haben, bei der manuelle Nachsteuerung nicht mehr funktioniert. Es passt außerdem zu Fulfillment-Dienstleistern, die für mehrere Auftraggeber gleichzeitig lagern und versenden und dafür eine mandantenfähige Struktur brauchen.
Weniger passend ist pixi* für sehr kleine Händler mit einer Handvoll Bestellungen pro Tag – dort ist der Einführungs- und Betriebsaufwand betriebswirtschaftlich nicht zu rechtfertigen, und leichtere Werkzeuge leisten das Nötige. Ebenso wenig passt es für produzierende Unternehmen, deren Kernanforderung Stücklisten, Fertigungsaufträge und Kapazitätsplanung sind – hier führt der Weg zu einem klassischen ERP mit Produktionsmodul. Und für Betreiber hochautomatisierter Anlagen mit Fördertechnik, Shuttle-Lagern oder Kommissionierrobotik reicht die Lagerlogik einer Versandhandels-Warenwirtschaft irgendwann nicht mehr; dann beginnt das Terrain klassischer Lagerverwaltungssysteme.
Anders als bei vielen Cloud-Anwendungen gibt es bei pixi* keine öffentlich beworbene Stufenfolge von einer kostenlosen Einstiegsvariante bis zu einer Konzernversion. Das Produkt kommt funktional breit und wird über Konfiguration, aktivierte Bausteine und die Zahl der Arbeitsplätze auf das Unternehmen zugeschnitten. Praktisch bedeutet das: Die Frage „welche Edition brauchen wir“ ist die falsche Frage. Die richtige lautet: „welche Prozesse müssen abgebildet werden, an wie vielen Arbeitsplätzen, in wie vielen Lagern, für wie viele Mandanten und Kanäle“.
Diese Logik hat Folgen für den Auswahlprozess. Ein belastbares Angebot entsteht erst nach einer strukturierten Prozessaufnahme, nicht durch Ankreuzen einer Paketstufe. Wir empfehlen deshalb, in die Anbietergespräche mit einer geschriebenen Prozesslandkarte zu gehen: Kanäle, Auftragsarten, Lagerorte, Kommissionierstrategien, Versandarten, Retourenwege, Sonderfälle. Wer das nicht mitbringt, erhält Schätzungen statt Angeboten – und trägt das Risiko später selbst. Welche Bausteine im jeweiligen Vertrag konkret enthalten und wie sie benannt sind, ändert sich über die Zeit und ist beim Anbieter zu prüfen.
Descartes ist im Kern ein Logistiksoftware-Haus, das über Jahre durch Zukäufe gewachsen ist. Das Portfolio reicht von Zoll- und Außenhandelsanwendungen über Transportmanagement und Telematik bis zu Versand- und Lagerlösungen für den Onlinehandel. pixi* sitzt in diesem Gefüge im Bereich E-Commerce-Abwicklung – als System, das die Auftrags- und Lagerseite des Onlinehandels bedient, während andere Konzernprodukte etwa Transportvergabe, Sendungsverfolgung oder Zollabwicklung adressieren.
Für Interessenten ist die praktische Konsequenz zweigeteilt. Positiv: Ein Produkt in einem großen, profitablen Konzern hat eine belastbarere Perspektive als eine Einzellösung eines kleinen Anbieters, und benachbarte Themen lassen sich potenziell innerhalb derselben Anbieterbeziehung ergänzen. Kritisch: Konzernportfolios verschieben sich, Produkte werden neu positioniert, und Roadmaps folgen einer globalen Logik, nicht dem Wunsch eines einzelnen DACH-Kunden. Beides gehört in die Bewertung – ohne Dramatik, aber mit offenen Augen.
In der Beratungspraxis kommen drei Fragen regelmäßig auf. Erstens: Bleibt die deutschsprachige Betreuung? Hier zählt der Vertrag, nicht die Broschüre – Support-Sprache, Reaktionszeiten und Eskalationswege sollten schriftlich vereinbart sein. Zweitens: Ändert sich das Preismodell? Konzerne standardisieren gern, deshalb sind Laufzeiten, Preisanpassungsklauseln und Kündigungsfristen genau zu lesen. Drittens: Wie wirkt sich der außereuropäische Konzernsitz auf Datenschutz und Datenhoheit aus? Diese Frage behandeln wir ausführlich in Kapitel 09, weil sie im deutschen Mittelstand zu Recht ernst genommen wird.
Der wichtigste, im Vorfeld am häufigsten unterschätzte Nutzen liegt in der Bestandsführung. Ein Onlinehändler mit mehreren Kanälen hat nicht ein Bestandsproblem, sondern ein Gleichzeitigkeitsproblem: Derselbe Artikel wird im eigenen Shop, auf zwei Marktplätzen und im telefonischen Verkauf angeboten, während im Lager kommissioniert, retourniert und eingelagert wird. Ohne ein führendes System mit klarer Trennung von physischem, verfügbarem, reserviertem und erwartetem Bestand entstehen Überverkäufe – und damit Stornos, Nachlieferungen, schlechte Bewertungen und im Marktplatzgeschäft messbare Sanktionen.
pixi* setzt hier an: Bestände werden zentral geführt, Kanäle werden aus dieser einen Wahrheit versorgt, und Reservierungslogiken bestimmen, welcher Kanal wie viel sehen darf. Ergänzend lassen sich Auftragsregeln definieren, die vor der Lagerarbeit greifen – etwa Freigabeprüfungen bei Zahlungsart oder Risikobewertung, das Zusammenfassen mehrerer Bestellungen desselben Empfängers, das Aufteilen von Aufträgen über Lagerorte hinweg oder das Zurückhalten von Teilmengen. Diese Regelwerke sind der eigentliche Hebel: Jede Entscheidung, die vorne automatisch fällt, muss hinten niemand mehr manuell aufräumen.
Ebenso wichtig ist die Abbildung von Sonderbeständen. Chargen, Mindesthaltbarkeitsdaten und Seriennummern sind in Branchen wie Lebensmittel, Kosmetik, Nahrungsergänzung oder Elektronik keine Kür, sondern Pflicht – teils aus regulatorischen Gründen, teils zur Gewährleistungsabwicklung. Ob und in welcher Tiefe die eigene Anforderung abgedeckt ist, gehört in jeden Anforderungskatalog; hier lohnt eine Prüfung am konkreten Beispiel statt am Prospekt.
Im Lager entsteht der überwiegende Teil der Kosten – und dort wirkt Software am unmittelbarsten. pixi* arbeitet mit einer Lagerplatzstruktur, die reale Regale, Fächer, Zonen und Sonderbereiche abbildet. Auf dieser Grundlage steuert das System Einlagerung, Nachschub von Reserve- auf Pickplätze, Kommissionierung und Inventur. Die Kommissionierung selbst kann je nach Auftragsstruktur unterschiedlich organisiert werden: einzelauftragsweise für große Aufträge, als Sammelkommissionierung mehrerer Aufträge in einem Rundgang für viele Kleinaufträge, zonenweise bei großen Lagern oder in mehrstufigen Verfahren mit anschließender Sortierung.
Der Praxisgewinn entsteht durch drei Dinge. Erstens durch Wegeoptimierung: Die Reihenfolge der Positionen folgt dem tatsächlichen Laufweg, nicht der Reihenfolge im Auftrag. Zweitens durch Scanquittierung: Jeder Griff wird gegen Artikel und Lagerplatz geprüft, was Verwechslungen systematisch verhindert, statt sie nachträglich zu entdecken. Drittens durch Führung statt Wissen: Neue Mitarbeitende werden vom Handgerät geführt und sind schneller produktiv – ein in Zeiten knapper Lagerkräfte und hoher Saisonspitzen unterschätzter wirtschaftlicher Faktor.
Am Packplatz setzt sich das fort. Die Software schlägt Verpackungen vor, prüft Gewichte gegen Erwartungswerte, verhindert Fehlversand durch Kontrollscans und erzeugt Versandetiketten sowie Beilagen. Wichtig ist hier die Abstimmung mit der Hardware: Etikettendrucker, Waagen, Scanner und gegebenenfalls Fördertechnik müssen zuverlässig zusammenspielen. Wir sehen regelmäßig, dass Projekte nicht an der Software scheitern, sondern an einer unterschätzten Peripherie.
Retouren sind im deutschen Versandhandel kein Randthema, sondern ein eigener Produktionsprozess – bei manchen Warengruppen mit Quoten, die den Wareneingang aus Lieferungen übersteigen. pixi* behandelt Retouren entsprechend als geführten Ablauf: Ankündigung oder Erfassung, Zuordnung zum Ursprungsauftrag, Prüfung mit Zustandsbewertung, Entscheidung über Wiedereinlagerung, Aufarbeitung, B-Ware-Kanal oder Entsorgung, anschließend Gutschrift und Rückzahlung. Der Nutzen liegt weniger in einzelnen Funktionen als in der Durchgängigkeit: Wo der Retourenstatus im System steht, sinken Rückfragen im Kundenservice messbar, weil Auskunft ohne Nachforschung möglich ist.
Auf der Versandseite ist die Mehr-Carrier-Fähigkeit entscheidend. Praktisch jeder wachsende Händler arbeitet mit mehreren Dienstleistern – national, international, für Sperrgut, für Expresssendungen, für Gefahrgut. pixi* erlaubt es, die Wahl des Versandwegs regelbasiert zu treffen: nach Gewicht, Maßen, Zielland, Wunschtermin, Servicelevel oder Kostenlogik. Das ersetzt Bauchentscheidungen am Packplatz durch nachvollziehbare Regeln und ist gleichzeitig einer der direktesten Kostenhebel überhaupt, weil Versandkosten in vielen Onlinehandelsmodellen den größten variablen Kostenblock bilden.
Wenn wir in Projekten messen, wo Zeit verloren geht, ist die Antwort selten „das System ist zu langsam“. Sie lautet fast immer: Menschen entscheiden wieder und wieder denselben Standardfall. Welcher Carrier? Welcher Karton? Freigeben oder warten? Zusammenfassen oder einzeln? Jede dieser Entscheidungen kostet Sekunden, manchmal Minuten, und sie fällt hunderte oder tausende Male am Tag. Eine Warenwirtschaft wie pixi* verdient ihr Geld dadurch, dass diese Entscheidungen einmal als Regel formuliert und danach maschinell getroffen werden.
Der Aufwand liegt entsprechend nicht in der Technik, sondern in der Entscheidungsarbeit im Vorfeld: Regeln müssen ausformuliert, gegen Sonderfälle geprüft und von den Fachbereichen getragen werden. Erfahrungsgemäß gilt dabei die Faustregel, dass ein kleiner Teil der Auftragstypen den größten Teil des Volumens ausmacht. Wer diese Standardfälle vollständig automatisiert und die Ausnahmen bewusst manuell lässt, holt den überwiegenden Nutzen mit vergleichsweise geringem Aufwand. Der umgekehrte Weg – erst die exotischen Fälle automatisieren – ist einer der teuersten Projektfehler, die wir kennen.
Bestandsdisposition ist die Disziplin, in der datengetriebene Verfahren im Onlinehandel den unmittelbarsten wirtschaftlichen Effekt haben, weil sie zwei entgegengesetzte Fehler gleichzeitig reduzieren: gebundenes Kapital in unverkäuflicher Ware und entgangenen Umsatz durch Nichtverfügbarkeit. Grundlage sind Verkaufshistorie, Saisonmuster, Aktionsplanung, Wiederbeschaffungszeiten und Lieferzuverlässigkeit. Daraus entstehen Reichweiten, Meldebestände und Bestellvorschläge, die der Einkauf prüft und freigibt.
Zwei Hinweise aus der Praxis. Erstens: Prognosequalität ist eine Funktion der Datenqualität. Wer Aktionen nicht kennzeichnet, Ausverkaufsphasen nicht markiert und Sortimentswechsel nicht pflegt, erhält Vorschläge, die die Vergangenheit falsch interpretieren. Zweitens: Automatische Vorschläge ersetzen keine Einkaufsentscheidung. Sie verlagern die Diskussion von „was glauben wir“ auf „welche Annahme ist falsch“ – und das ist bereits der ganze Fortschritt. Ob und in welcher Ausbaustufe Prognoseverfahren im eigenen Vertrag enthalten sind oder über ergänzende Werkzeuge abgedeckt werden, ist beim Anbieter zu prüfen.
Der Markt für Warenwirtschaft und Lagerlogistik ist derzeit mit KI-Begriffen gut versorgt. Nüchtern betrachtet steckt in Produkten dieser Kategorie üblicherweise eine Mischung aus klassischen statistischen Verfahren, Optimierungsalgorithmen für Wege und Zuordnungen, Mustererkennung bei Anomalien sowie – in neueren Ausbaustufen – Assistenzfunktionen mit Sprachmodellen für Auswertungen, Textarbeit oder Support. Alles davon kann nützlich sein. Nichts davon ersetzt saubere Prozesse.
Unsere Empfehlung für die Bewertung: Verlangen Sie zu jeder beworbenen KI-Funktion drei Angaben – welche Entscheidung sie trifft oder vorbereitet, auf welchen Daten sie arbeitet, und wie ein Mensch das Ergebnis kontrollieren und übersteuern kann. Funktionen, die diese drei Fragen nicht beantworten, sind für eine Auswahlentscheidung wertlos, unabhängig davon, wie gut sie klingen. Und da sich Funktionsumfänge in diesem Feld schnell ändern, gilt: aktuellen Stand beim Anbieter prüfen und im Vertrag festhalten, statt sich auf Präsentationsfolien zu verlassen.
Auf der Verkaufsseite geht es um zwei Richtungen. Eingehend kommen Bestellungen, Kundendaten, Zahlungsinformationen und Stornos; ausgehend gehen Bestände, Preise, Artikeldaten, Versandstatus und Sendungsnummern zurück. Für die im DACH-Raum verbreiteten Shopsysteme – etwa Shopware, Adobe Commerce beziehungsweise Magento, Shopify, WooCommerce oder OXID – sowie für die relevanten Marktplätze existieren im Umfeld solcher Systeme üblicherweise etablierte Anbindungen. Welche Kanäle in welcher Tiefe abgedeckt sind, ist jedoch immer konkret zu prüfen, weil Kanäle ihre Schnittstellen laufend verändern.
Bei Marktplätzen liegt die Tücke nicht in der technischen Verbindung, sondern in den Sonderregeln. Marktplätze schreiben Reaktionszeiten vor, sanktionieren Storno- und Verspätungsquoten, verlangen bestimmte Rechnungs- und Retourenprozesse und stellen eigene Anforderungen an Bestandsmeldungen. Wer Marktplatzgeschäft betreibt, sollte in der Auswahl deshalb nicht fragen, ob ein Kanal angebunden werden kann, sondern ob dessen Prozessvorgaben abbildbar sind. Ein Sonderfall ist die Abwicklung über Lagerdienste der Marktplätze selbst: Hier liegt der Bestand außerhalb des eigenen Lagers, und die Warenwirtschaft muss diesen Fremdbestand als eigene Kategorie führen können, um Verfügbarkeitsversprechen korrekt zu berechnen.
Auf der Versandseite gehören Anbindungen an die im DACH-Raum üblichen Paket- und Speditionsdienstleister zum Pflichtprogramm – inklusive Etikettenerzeugung, Sendungsdatenübermittlung, Rücksendescheinen und Statusrückmeldungen für die Sendungsverfolgung. Praktisch relevant ist zusätzlich die Frage, wie leicht ein weiterer Dienstleister ergänzt oder ein bestehender ausgetauscht werden kann. Wir empfehlen, den Wechsel eines Carriers gedanklich als Testfall durchzuspielen: Wie viel Projektaufwand entsteht, wenn sich in achtzehn Monaten die Versandstrategie ändert? Systeme, in denen das ein Konfigurations- und kein Entwicklungsvorgang ist, sparen später erhebliches Geld.
Bei Zahlungen geht es um Zahlungsstatus, Zuordnung von Eingängen zu Aufträgen, Teilzahlungen, Rückzahlungen bei Retouren und die Behandlung von Zahlungsarten mit unterschiedlichem Ausfallrisiko. Der Prozess entscheidet darüber, wie viele Aufträge unnötig hängen bleiben – ein oft übersehener Hebel für Durchlaufzeit und Liquidität. Auf der Buchhaltungsseite ist im deutschen Mittelstand der Weg über die etablierten Formate der Steuerberatungs- und Buchhaltungswelt der Normalfall: Rechnungs-, Gutschrift- und Zahlungsdaten werden strukturiert übergeben, statt die Buchführung im Warenwirtschaftssystem nachzubilden. Wichtig ist, dass Belegkreise, Steuerkennzeichen und Kontenlogik von Anfang an gemeinsam mit der Steuerberatung definiert werden – nachträgliche Korrekturen sind mühsam und selten vollständig.
Über die fertigen Anbindungen hinaus braucht praktisch jedes wachsende Handelsunternehmen individuelle Verbindungen: zu einem Produktdatenmanagement, zu einem Kundenservice-Werkzeug, zu einer Auswertungsdatenbank, zu einem Rechnungsversand, zu einem Dienstleister. Hier zählt die Qualität der Programmierschnittstelle – Umfang, Dokumentation, Stabilität über Versionen, Umgang mit Massendaten und Begrenzungen bei Abfragefrequenzen. Diese Punkte klingen technisch, entscheiden aber darüber, ob Integrationsprojekte Wochen oder Monate dauern.
Zunehmend verbreitet ist der Aufbau einer Integrationsschicht zwischen den Systemen, statt jede Verbindung einzeln zu verdrahten. Der Vorteil: Änderungen an einem Kanal wirken sich nicht auf alle anderen aus, Fehler werden zentral sichtbar, und Wiederholungen bei Störungen lassen sich sauber steuern. Der Nachteil: eine weitere Komponente, die betrieben und verstanden werden muss. Für Unternehmen mit vielen Kanälen und mehreren Fachsystemen rechnet sich dieser Weg in unserer Erfahrung fast immer; für Häuser mit zwei Kanälen und wenig Sonderlogik ist er überdimensioniert.
Das ist der Vergleich, der in der Praxis am häufigsten geführt wird. JTL ist im deutschen Onlinehandel stark verbreitet, verfügt über ein großes Partner- und Dienstleisternetz und wird häufig in Eigenregie oder mit lokalen Partnern betrieben. Der Einstieg ist vergleichsweise günstig, die Verfügbarkeit von Know-how am Markt hoch, und für viele Händler ist genau das der entscheidende Punkt: Man findet leicht Menschen, die das System kennen. Im Gegenzug liegt mehr Verantwortung für Betrieb, Aktualisierung und Architektur beim Unternehmen selbst oder bei seinem Partner.
Xentral kommt aus einer anderen Richtung: als kaufmännisch breit angelegtes System für wachsende, digital geprägte Unternehmen, mit starker Betonung von Automatisierung und Anbindungsfähigkeit. Xentral gewinnt häufig, wenn neben Lager und Versand auch kaufmännische Abläufe, Angebots- und Rechnungsprozesse oder Auswertungen in einem System liegen sollen und die Lagerkomplexität moderat bleibt.
pixi* gewinnt gegen beide typischerweise dort, wo die Lager- und Versandtiefe den Ausschlag gibt: viele Aufträge, viele gleichzeitig arbeitende Lagerkräfte, mehrstufige Kommissionierung, hohe Retourenquoten, ausgeprägte Saisonspitzen, mehrere Lagerorte oder Mandanten. Es verliert, wenn Budget und Betreuungsaufwand dominieren, wenn kaufmännische Breite wichtiger ist als Lagerfeinheit, oder wenn eine hohe Anpassbarkeit durch die eigene IT gewünscht wird.
plentymarkets positioniert sich als umfassende Commerce-Plattform, die Shop, Kanäle, Warenwirtschaft und Auswertung zusammenführt. Für Händler, die bewusst eine einzige Plattform für Verkauf und Abwicklung wollen, ist das attraktiv. Der Preis dafür ist eine engere Bindung: Wer sein Frontend später wechseln möchte oder eine sehr spezielle Shop-Architektur braucht, hat es mit getrennten Systemen leichter. pixi* trifft hier die entgegengesetzte Entscheidung – es überlässt das Verkaufsfrontend anderen und konzentriert sich auf die Abwicklung.
Billbee und vergleichbare leichte Werkzeuge sind in einer anderen Liga, und das ist kein Werturteil, sondern eine Beschreibung. Sie lösen das Problem kleiner und mittlerer Händler ausgezeichnet: Bestellungen aus mehreren Kanälen bündeln, Etiketten erzeugen, Rechnungen schreiben, Standardvorgänge automatisieren – schnell, kostengünstig und ohne Projekt. Sie sind nicht dafür gebaut, ein Lager mit Zonen, Nachschubregeln und Mehrauftragspicking zu steuern. Der Wechsel von einem solchen Werkzeug zu einem System der pixi*-Klasse ist typischerweise das Zeichen dafür, dass das Lager zum Engpass geworden ist.
Nach oben grenzt pixi* an zwei Klassen. Die eine sind reine Lagerverwaltungssysteme vom Typ Körber, inconso oder PSI Logistics. Diese Systeme sind darauf ausgelegt, hochautomatisierte Anlagen zu steuern: Fördertechnik, automatische Lager, Sortieranlagen, Kommissionierstationen, Ressourcenplanung im Schichtbetrieb. Sie bringen jedoch typischerweise kein Auftrags-, Kunden- und Belegwesen mit und werden deshalb hinter einem führenden System betrieben. Der Übergang ist eine Frage von Automatisierungsgrad und Volumen: Wo Fördertechnik und Anlagensteuerung das Bild bestimmen, endet der Bereich einer Versandhandels-Warenwirtschaft.
Die andere Nachbarklasse sind klassische ERP-Plattformen. Sie decken Produktion, Finanzbuchhaltung, Anlagenwirtschaft, Konzernkonsolidierung und Branchenprozesse ab – Dinge, die pixi* nicht adressiert. Ihr Nachteil im Onlinehandel ist die Feinheit der Versandprozesse: Was eine spezialisierte Warenwirtschaft im Standard mitbringt, muss dort häufig über Zusatzmodule oder Anpassungen entstehen. In der Praxis sehen wir daher regelmäßig Kombinationen: ein ERP für Finanzen und Produktion, ein spezialisiertes System für die Versandabwicklung, verbunden über definierte Schnittstellen. Diese Zweiteilung ist kein Notbehelf, sondern oft die wirtschaftlich sinnvollste Architektur – vorausgesetzt, die Datenhoheit ist klar geregelt und nicht doppelt vergeben.
Die kritische Frage jeder Warenwirtschafts-Umstellung lautet: Wie kommen wir von System A zu System B, ohne den Versand zu unterbrechen und ohne Bestände zu verlieren? Bewährt hat sich ein klar definierter Umstellungskorridor – häufig ein Wochenende oder eine ruhige Phase im Jahresverlauf –, in dem eingehende Aufträge im Altsystem abgearbeitet, Bewegungen gestoppt, eine Bestandsaufnahme durchgeführt und die Bestände als Ausgangswerte im neuen System gesetzt werden. Ab dem Startzeitpunkt laufen alle neuen Aufträge nur noch im neuen System.
Dieses Vorgehen erfordert Disziplin, ist aber deutlich risikoärmer als ein wochenlanger Parallelbetrieb. Zwei Systeme, die gleichzeitig Bestände führen, driften unweigerlich auseinander, und niemand weiß am Ende, welche Zahl gilt. Was hingegen unbedingt in den Plan gehört: eine ehrliche Rückfallstrategie für den Fall, dass der Start nicht funktioniert, ein eingeplanter Leistungsabfall in den ersten Tagen und eine offene Kommunikation gegenüber Kunden und Marktplätzen über eventuell verlängerte Laufzeiten. Wer Perfektion ab Tag eins verspricht, erzeugt genau den Druck, unter dem Fehler passieren.
Die Qualität der Lagerabbildung entscheidet über die Leistung des Systems im Alltag. Ein Lager, das nur grob in wenige Bereiche unterteilt ist, kann nicht wegeoptimiert kommissionieren – dem System fehlt die Information, wo etwas liegt. Umgekehrt erzeugt eine übergenaue Struktur mit tausenden kaum genutzten Plätzen Pflegeaufwand ohne Nutzen. Die richtige Granularität ist eine Projektentscheidung, die man am besten gemeinsam mit den Menschen trifft, die täglich durch das Lager laufen.
Drei Punkte bewähren sich regelmäßig: eine eindeutige, sprechende Platzbenennung mit Barcodes an jedem Platz; eine bewusste Zonierung nach Umschlagshäufigkeit, damit Schnelldreher kurze Wege haben; und eine saubere Trennung von Pick- und Reserveplätzen mit definierten Nachschubregeln. Diese drei Entscheidungen wirken über Jahre und sind nachträglich nur mit erheblichem Aufwand zu korrigieren – sie gehören daher in die Einführung, nicht in die Optimierung danach.
pixi* wird typischerweise als gehostete Lösung betrieben, was den eigenen IT-Aufwand für Server, Aktualisierungen und Verfügbarkeit reduziert. Das bedeutet nicht, dass keine IT-Verantwortung bleibt: Netzanbindung im Lager, Endgeräte, Drucker, Scanner, Ausfallkonzepte und die Betreuung der Schnittstellen bleiben Aufgabe des Unternehmens. Besonders die Netzabdeckung im Lager ist ein klassischer Stolperstein – kabellose Handgeräte in Hochregalgassen mit metallischen Reflexionen sind ein eigenes Planungsthema, das man nicht dem Zufall überlassen sollte.
Zur Implementierung arbeiten Unternehmen in der Regel mit dem Anbieter selbst oder mit spezialisierten Partnern zusammen. Prüfen Sie dabei drei Dinge: Erfahrung mit vergleichbaren Mengengerüsten und Branchen, Verfügbarkeit während der eigenen Hochsaison und die Frage, wer im Störungsfall welche Verantwortung trägt. Klare Vereinbarungen zu Reaktionszeiten, Eskalationswegen und Zuständigkeit an Schnittstellen sind bei einem System, das den Versand steuert, keine Formalie – ein Ausfall bedeutet stillstehende Pakete, und die Folgekosten entstehen im Stundenrhythmus.
Das erste und häufigste Profil ist der gewachsene B2C-Versandhändler. Er hat mit einem Shop begonnen, später Marktplätze ergänzt, das Lager mehrfach umgezogen und arbeitet heute mit einem Werkzeugkasten, der aus einem Shop-Backend, mehreren Tabellen, einem Versandportal und viel Erfahrung im Kopf einzelner Personen besteht. Der Schmerz ist konkret: Überverkäufe, Fehlversand, unklare Verfügbarkeiten, Abhängigkeit von Schlüsselpersonen, Chaos in Saisonspitzen. Für dieses Profil ist eine spezialisierte Warenwirtschaft der naheliegende nächste Schritt.
Das zweite Profil ist der Fulfillment-Dienstleister. Wer für mehrere Auftraggeber lagert, kommissioniert und versendet, braucht getrennte Bestände, mandantenspezifische Versand- und Verpackungsregeln, getrennte Auswertungen und eine belastbare Grundlage für die Abrechnung nach Lagerplatz, Auftrag, Position oder Retoure. Diese Mandantenfähigkeit ist keine Zusatzfunktion, sondern die Geschäftsgrundlage – und ein Bereich, in dem viele einfachere Systeme ausscheiden.
Das dritte Profil ist der Multichannel-Händler mit mehreren Lagerorten – etwa mit einem Zentrallager, einem Ersatzteil- oder Sperrgutlager und Beständen bei Marktplatzdiensten. Hier liegt der Wert in der übergreifenden Bestandssicht und in Regeln, die entscheiden, aus welchem Lager ein Auftrag bedient wird. Das vierte, seltener genannte Profil ist der Händler mit hoher Retourenquote, etwa in Mode oder Consumer-Elektronik: Dort ist der Rücklauf ein eigener Produktionsprozess, und Systeme ohne geführten Retourenablauf werden schnell zum Engpass.
Die Frage „ab wann brauchen wir das“ lässt sich nicht an einer Paketzahl festmachen, wohl aber an Symptomen. Wir achten in Projekten auf sechs Signale: Erstens treten Überverkäufe regelmäßig auf, weil Bestände zwischen Kanälen nicht sauber synchron sind. Zweitens werden Fehlversand und Fehlkommissionierung zum wiederkehrenden Kostenfaktor, weil ohne Scanquittierung gearbeitet wird. Drittens hängt das Tagesgeschäft an Erfahrungswissen einzelner Personen, deren Urlaub zum Betriebsrisiko wird.
Viertens kippt die Leistung in Saisonspitzen, weil zusätzliche Aushilfen ohne Systemführung nicht schnell produktiv werden. Fünftens kostet die Retourenbearbeitung unverhältnismäßig viel Zeit und blockiert verkäufliche Ware. Sechstens fehlen belastbare Zahlen: Niemand kann sagen, wie viele Aufträge pro Stunde bearbeitet werden, wie hoch die Fehlerquote ist oder welche Artikel wirklich Kapital binden. Treten drei oder mehr dieser Signale gleichzeitig auf, ist die Frage nicht mehr, ob umgestellt wird, sondern nur noch wann und wohin.
Umgekehrt gilt eine Warnung: Ein Systemwechsel behebt keine organisatorischen Probleme. Wenn Verantwortlichkeiten unklar sind, Stammdaten niemandem gehören und Prozesse nicht entschieden sind, wird eine neue Software das nicht heilen – sie wird die Unklarheit nur präziser dokumentieren. Wir empfehlen deshalb, vor jedem Auswahlprojekt zu klären, wer im Unternehmen die Verantwortung für Artikeldaten, Lagerstruktur und Prozessregeln trägt. Diese Frage kostet nichts und entscheidet mehr über den Projekterfolg als die Systemwahl.
Für kleine Händler mit überschaubarem Tagesvolumen, wenigen Artikeln und einem einfachen Lager ist ein System dieser Klasse überdimensioniert. Der Einführungsaufwand, die Stammdatenarbeit und die laufenden Kosten stehen in keinem Verhältnis zum Nutzen; leichtere Werkzeuge liefern hier das Wesentliche zu einem Bruchteil des Aufwands. Ebenso sollten produzierende Unternehmen, deren zentrale Anforderung Fertigungsplanung ist, den Weg über ein ERP mit Produktionsmodul prüfen und die Versandabwicklung erst danach betrachten.
Vorsicht ist außerdem geboten, wenn ein Unternehmen viele hochspezifische Sonderprozesse als unverhandelbar betrachtet. Standardnahe Systeme leben davon, dass Prozesse sich an bewährte Muster anpassen. Wer stattdessen erwartet, dass die Software jede historische Eigenheit nachbildet, landet entweder bei teuren Anpassungen oder bei dauerhafter Unzufriedenheit. Die ehrliche Vorbereitung besteht darin, jeden Sonderprozess einmal auf die Frage zu prüfen, ob er dem Kunden nützt oder nur der Gewohnheit.
pixi* gehört zu den Systemen ohne öffentlich einsehbares Preismodell – üblich in dieser Marktklasse, für Interessenten aber unbequem. Praktisch bedeutet das: Sie erhalten ein individuelles Angebot, dessen Vergleichbarkeit Sie selbst herstellen müssen. Fragen Sie deshalb aktiv nach den Preistreibern und lassen Sie sich schriftlich geben, wie sich die Kosten entwickeln, wenn sich Arbeitsplätze, Auftragsvolumen, Kanäle, Lagerorte oder Mandanten verändern. Ein System, dessen Kosten mit dem Erfolg unkontrolliert mitwachsen, wird in drei Jahren zum Streitthema.
Für die Gesamtkostenbetrachtung gehören mindestens fünf Blöcke in die Rechnung: laufende Nutzungs- und Betriebskosten, einmaliger Einführungsaufwand, Integrationsprojekte, Hardware im Lager (Handgeräte, Etikettendrucker, Waagen, Netzwerk) und der interne Aufwand für Stammdaten, Tests, Schulung und Anlaufphase. Der letzte Block ist der am häufigsten vergessene und in unserer Erfahrung regelmäßig größer als erwartet. Wer nur die monatliche Gebühr betrachtet, unterschätzt die tatsächlichen Kosten des ersten Jahres deutlich.
Auf der Nutzenseite lässt sich die Rechnung erfreulich konkret aufstellen, weil im Versandhandel fast alles messbar ist: vermiedene Stornos und Nachlieferungen, gesunkene Fehlversandquote, Zeit pro Auftrag am Packplatz, Retourendurchlaufzeit, Versandkosten je Sendung durch bessere Carrier- und Kartonwahl, gebundenes Kapital durch bessere Disposition. Wir empfehlen, drei bis fünf dieser Größen vor dem Projekt zu messen und danach erneut. Das ist die einzige belastbare Grundlage für die Frage, ob sich die Investition gerechnet hat.
Descartes Systems Group ist ein börsennotiertes Unternehmen mit Sitz in Kanada. Diese Tatsache muss man klar benennen, weil sie datenschutzrechtliche Relevanz hat und in vielen Ausschreibungen abgefragt wird. Kanada ist dabei ein besonderer Fall: Für den kommerziellen Sektor besteht ein Angemessenheitsbeschluss der Europäischen Kommission, der Datenübermittlungen in diesem Rahmen erleichtert. Das ist eine deutlich komfortablere Ausgangslage als bei Anbietern aus Ländern ohne solchen Beschluss – nimmt aber die Prüfpflicht nicht ab, weil Konzerne international arbeiten, Support und Entwicklung an mehreren Standorten sitzen können und Unterauftragsverhältnisse bestehen.
Für die Praxis heißt das: Klären Sie schriftlich, wo die Daten verarbeitet und gespeichert werden, ob eine EU- beziehungsweise deutsche Datenregion zugesichert ist, welche Unterauftragsverarbeiter beteiligt sind, aus welchen Ländern Support und Wartung zugreifen, welche Transfermechanismen gelten und wie lange Daten aufbewahrt werden. Diese Angaben gehören in den Auftragsverarbeitungsvertrag und in das Verzeichnis der Verarbeitungstätigkeiten, nicht in eine Präsentation.
Inhaltlich sind Warenwirtschaftsdaten kein harmloser Datenbestand: Sie enthalten Namen, Liefer- und Rechnungsadressen, Kontaktdaten, Bestellhistorien und je nach Zahlart Zahlungsinformationen. Bei bestimmten Sortimenten – etwa Gesundheits- oder Arzneimittelnähe – kann die Bestellhistorie zudem Rückschlüsse mit besonderer Schutzbedürftigkeit erlauben. Das erhöht die Sorgfaltsanforderung an Berechtigungskonzepte, Löschfristen und Protokollierung. Wer diese Punkte früh klärt, hat sie später nie wieder auf dem Tisch.
Datenhoheit wird meist als Standortfrage diskutiert. Genauso wichtig ist die Frage, ob man wieder herauskommt. Eine Warenwirtschaft hält die operativen Kerndaten eines Handelsunternehmens: Artikel, Kunden, Bestellhistorie, Bestandsbewegungen, Belege. Wenn diese Daten nur eingeschränkt exportierbar sind, entsteht eine Abhängigkeit, die sich in Verhandlungen bemerkbar macht – unabhängig davon, wie gut die Zusammenarbeit heute läuft.
Wir empfehlen deshalb, den Ausstieg schon beim Einstieg zu regeln: Welche Daten können in welchem Format und in welcher Vollständigkeit exportiert werden? Wie schnell? Zu welchen Kosten? Was passiert mit Protokoll- und Bewegungsdaten? Diese vier Fragen kosten in der Verhandlung nichts und schaffen eine Verhandlungsposition, die über die gesamte Vertragslaufzeit wirkt. Ergänzend gehört dazu ein regelmäßiger eigener Datenexport als Sicherungsebene, unabhängig von den Zusagen des Anbieters.
