Für Händler, die aus einem gewachsenen Setup kommen, ist das eine ungewohnte Perspektive. Der übliche Aufbau im E-Commerce-Mittelstand besteht aus einem Shop, einem separaten Warenwirtschaftssystem und einer Verbindung dazwischen – einer Schnittstelle, einem Konnektor, einem nächtlichen Abgleich. Diese Verbindung ist der Ort, an dem die meisten Störungen entstehen: Bestände laufen auseinander, Bestellungen kommen doppelt an, Artikelmerkmale werden in einem System gepflegt und im anderen überschrieben. Wer diese Fehlerklasse aus eigener Erfahrung kennt, versteht sofort, worin der Reiz einer eingebetteten Lösung liegt.
Der Preis dieser Architektur ist Abhängigkeit. Pickware ist keine Lösung, die man frei wählt und dann an ein Shopsystem anschließt, sondern eine Lösung, die eine bestimmte Shop-Entscheidung voraussetzt. Wer Shopware betreibt oder ernsthaft plant, hat mit Pickware eine sehr direkte Option. Wer auf einem anderen Shopsystem arbeitet oder mittelfristig wechseln könnte, muss die Bindung als strategische Frage behandeln und nicht als technisches Detail. Diese Ehrlichkeit gehört an den Anfang jeder Bewertung, weil sie über die Hälfte aller Auswahlprozesse bereits entscheidet.
Ursprünglich sind Lösungen dieser Art als Ergänzung gedacht: ein Modul, das im Shop-Backend eine Bestandsanzeige und einen Lieferschein ergänzt. Der Anspruch ist inzwischen deutlich größer. Abgedeckt werden heute die vollständige Auftragsabwicklung von der Bestellung bis zur Rechnung, mehrstufige Lagerstrukturen mit Lagerplätzen und Zonen, mobile Kommissionierung über Handscanner, Einkauf mit Lieferantenverwaltung und Wareneingang, Retourenbearbeitung, Versandabwicklung mit Etikettendruck sowie ein stationärer Kassenplatz für Filialen und Werksverkäufe.
Damit verschiebt sich die Rolle: Aus einem Zusatzmodul wird das führende System für alle warenwirtschaftlichen Vorgänge. Das ist eine wichtige Einsicht für die Projektplanung. Eine Einführung von Pickware ist kein Plugin-Klick, sondern ein Warenwirtschaftsprojekt mit allem, was dazugehört – Stammdatenaufbau, Lagerstruktur, Prozessdefinition, Schulung, Datenmigration, Parallelbetrieb. Projekte scheitern selten an der Software und häufig an der Annahme, es handle sich um eine Installation.
Gleichzeitig ist der Umfang bewusst begrenzt. Pickware ist kein Produktionsplanungssystem, keine Finanzbuchhaltung und kein Konzern-ERP. Fertigung im Sinne von Stücklistenauflösung über mehrere Ebenen, Kapazitätsplanung an Maschinen, Anlagenbuchhaltung oder Konsolidierung mehrerer Gesellschaften gehören nicht zum Kern. Für Handelsunternehmen ist das kein Mangel, sondern Fokus. Für Hersteller mit echter Produktionstiefe ist es ein Ausschlusskriterium, das früh geprüft werden muss.
Das typische Profil, das wir in Projekten sehen, ist ein Handelsunternehmen mit einem oder wenigen Lagerstandorten, einem Onlineshop als Hauptkanal, ergänzenden Marktplätzen und gelegentlich einer Ladenfläche. Die Mitarbeiterzahl in Lager und Kundenservice liegt im einstelligen bis mittleren zweistelligen Bereich. Die Artikelzahl reicht von einigen Hundert bis in den fünfstelligen Bereich. Die Prozesse sind gewachsen, teilweise noch in Tabellen dokumentiert, und der Engpass liegt weniger in fehlender Software als in fehlender Durchgängigkeit.
Weniger passend ist die Lösung dort, wo mehrere Shopsysteme parallel betrieben werden, wo der Marktplatzhandel den Shop dominiert, wo Fertigung eine tragende Rolle spielt oder wo internationale Gesellschaften mit eigener Buchführung abgebildet werden müssen. Auch bei sehr hohem Sendungsdurchsatz mit stark spezialisierten Lagerprozessen – Zonenpicking mit Wellensteuerung, automatisierte Fördertechnik, Pick-by-Voice – stößt eine shopnahe Lösung an Grenzen, die ein dediziertes Lagerverwaltungssystem nicht hat. Diese Abgrenzung ist keine Wertung, sondern eine Frage der Passung.
Der architektonische Kern lässt sich in einem Satz beschreiben: Die Warenwirtschaft benutzt die Datenhaltung des Shops. Artikel sind Shop-Artikel, Bestellungen sind Shop-Bestellungen, Bestände sind die Bestände, die der Shop im Frontend anzeigt. Es gibt keinen Zeitpunkt, an dem zwei Systeme dasselbe unterschiedlich wissen könnten. Wer in früheren Projekten Nächte mit Bestandsabweichungen verbracht hat, erkennt hier den eigentlichen Wert – und er liegt nicht in einer Funktionsliste, sondern in einer nicht existierenden Fehlerquelle.
Diese Enge hat drei Konsequenzen, die man kennen sollte. Erstens folgt der Lebenszyklus der Warenwirtschaft dem Lebenszyklus des Shops: Ein Generationswechsel im Shopsystem ist auch ein Projekt für die Warenwirtschaft. Zweitens teilen sich Shop und Warenwirtschaft Ressourcen, also Rechenleistung, Datenbanklast und Wartungsfenster – ein Kommissionierlauf im Lager und eine Rabattaktion im Shop treffen auf dieselbe Infrastruktur. Drittens wird ein Shop-Wechsel zu einem Warenwirtschafts-Wechsel. Wer diese drei Punkte akzeptiert, bekommt eine Durchgängigkeit, die konventionelle Kombinationen aus Shop plus separatem System nur mit deutlich mehr Aufwand erreichen.
In Auswahlgesprächen empfehlen wir, diese Frage zuerst zu klären und nicht zuletzt. Die Reihenfolge lautet: Bleiben wir strategisch bei diesem Shopsystem? Wenn ja, ist eine eingebettete Warenwirtschaft ein starker Kandidat. Wenn nein oder unklar, ist eine Lösung mit eigener Datenhaltung und austauschbaren Kanalanbindungen die risikoärmere Wahl. Diese Entscheidung lässt sich nicht durch Funktionsvergleiche ersetzen, weil sie auf einer anderen Ebene liegt.
Im DACH-Markt für Handelssoftware gibt es grob drei Ebenen. Die erste besteht aus Auftrags- und Versandwerkzeugen, die Bestellungen aus mehreren Kanälen einsammeln, Etiketten erzeugen und Status zurückmelden – schnell startbar, aber ohne echte Lager- und Einkaufstiefe. Die zweite Ebene bilden Warenwirtschafts- und Handels-ERP-Systeme mit Beständen, Belegen, Einkauf, Lager und Auswertungen. Die dritte Ebene sind branchenneutrale ERP-Suiten mit Produktion, Finanzbuchhaltung und Konzernfunktionen.
Pickware liegt klar auf der zweiten Ebene, mit einer Besonderheit: Der Einstieg ist niedriger als bei vielen Systemen dieser Klasse, weil kein zweites System aufgesetzt werden muss, und die Obergrenze ist niedriger, weil Produktion und Finanzbuchhaltung nicht abgedeckt sind. Für viele Handelsunternehmen ist genau dieser Zuschnitt richtig. Für Unternehmen mit Fertigungsanteil oder mit dem Wunsch, die Buchhaltung im gleichen System zu führen, ist er zu knapp – hier bleibt die Kombination aus Warenwirtschaft und angebundener Buchhaltung der Weg.
Ein weiteres Positionierungsmerkmal ist die Herkunft. Es handelt sich um einen deutschen Anbieter mit deutschsprachigem Support, deutschsprachiger Dokumentation und einem Produktverständnis, das an hiesigen Handelsprozessen ausgerichtet ist – von der Rechnungsstellung über Umsatzsteuerlogik bis zu Kassenanforderungen. Das ist im Mittelstand ein realer Vorteil, der in Funktionstabellen nicht auftaucht, im Projektalltag aber täglich wirkt.
Der Unterschied zwischen einer einfachen und einer belastbaren Bestandsführung liegt in der Granularität. Eine einfache Führung kennt eine Zahl je Artikel. Eine belastbare Führung kennt Bestände je Lager, je Lagerplatz und je Bestandsart – verfügbar, reserviert, in Kommissionierung, im Wareneingang, in Retourenprüfung, gesperrt. Diese Unterscheidung entscheidet darüber, ob der Shop verkaufen darf, was physisch noch da ist, und ob eine Zählabweichung eine Ursache hat oder nur ein Ärgernis ist.
Pickware bildet mehrstufige Lagerstrukturen ab: mehrere Lagerorte, innerhalb dieser Zonen und Plätze, dazu Umlagerungen zwischen Plätzen und Standorten. Jede Bewegung erzeugt einen Datensatz mit Zeitpunkt, Menge, Platz und auslösendem Vorgang. Diese Bewegungshistorie ist im Alltag das wichtigste Werkzeug, weil sie aus einer Abweichung eine nachvollziehbare Kette macht. Ohne Bewegungshistorie bleibt jede Inventurdifferenz eine Diskussion; mit ihr wird sie eine Recherche mit Ergebnis.
Praktisch relevant ist außerdem die Reservierungslogik. Sobald eine Bestellung eingeht, muss die Ware für diese Bestellung gebunden werden, damit sie nicht ein zweites Mal verkauft wird. Wie früh, wie lange und unter welchen Bedingungen reserviert wird – etwa bei unbezahlten Vorkassebestellungen –, ist eine Konfigurationsentscheidung mit unmittelbarer Wirkung auf Überverkäufe und auf gebundenen Bestand. Wir empfehlen, diese Regeln im Projekt explizit zu definieren und nicht auf Voreinstellungen zu vertrauen.
Im Versandhandel entscheidet der Packplatz über Kosten und Kundenzufriedenheit. Die mobile Kommissionierung über Scanner ist deshalb der Baustein, dessen Wirkung am schnellsten messbar wird. Das Prinzip: Der Mitarbeiter erhält auf dem Gerät eine geführte Reihenfolge, scannt den Lagerplatz, scannt den Artikel, bestätigt die Menge. Falscher Platz, falscher Artikel oder falsche Menge werden abgewiesen, nicht kommentiert. Aus einer Aufgabe, die Aufmerksamkeit verlangte, wird eine Aufgabe, die Aufmerksamkeit nicht mehr voraussetzt.
Darauf setzen die Optimierungen auf. Sammelkommissionierung fasst mehrere Aufträge zu einem Lauf zusammen, wenn Artikel sich überschneiden. Wegeoptimierung sortiert die Positionen nach Lagerstruktur statt nach Auftragsreihenfolge. Die Trennung von Kommissionierung und Packen entkoppelt zwei Tätigkeiten mit unterschiedlichem Rhythmus. Welche dieser Ausbaustufen sinnvoll ist, hängt an Auftragsstruktur und Lagerlayout – bei überwiegend Einzelpositionsaufträgen bringt Sammelkommissionierung wenig, bei Warenkörben mit mehreren Positionen sehr viel.
Ein Punkt, den wir regelmäßig ansprechen müssen: Die Software kann nur so gut führen, wie das Lager strukturiert ist. Ohne beschriftete, eindeutig identifizierbare Plätze gibt es keine Wegeoptimierung, weil die Reihenfolge kein Ziel hat. Die Vorarbeit im Regal – Plätze definieren, beschriften, Schnelldreher nach vorne – ist deshalb kein Nebenaspekt der Einführung, sondern deren Voraussetzung. Wer diesen Schritt überspringt, kauft Funktionen, die er nicht nutzen kann.
Retouren sind im Onlinehandel kein Sonderfall, sondern ein Regelprozess mit eigener Kette: Anmeldung, Wareneingang, Zuordnung zur Bestellung, Prüfung des Zustands, Entscheidung über Wiedereinlagerung oder Aussortierung, Erstattung, Buchung. Jeder dieser Schritte hat eine Datenanforderung. Entscheidend für den betriebswirtschaftlichen Nutzen ist die strukturierte Erfassung des Retourengrundes: Erst wenn Gründe auswertbar sind, lassen sie sich in Produktbeschreibungen, Größenangaben, Verpackung oder Sortimentsentscheidungen zurückführen. Eine Retourenquote ohne Gründe ist eine Zahl ohne Handlungsanleitung.
Multichannel bedeutet in der Praxis, dass derselbe Bestand mehrere Nachfragequellen bedient: den eigenen Shop, Marktplätze, die Ladenfläche, gelegentlich telefonische Aufträge. Der Anspruch ist einfach zu formulieren und schwer umzusetzen: Eine Einheit darf nur einmal verkauft werden. Ein gemeinsam geführter Bestand mit klaren Reservierungsregeln ist dafür die Grundlage; wo Kanäle über Konnektoren angebunden sind, kommt es zusätzlich auf die Aktualisierungsfrequenz und auf Sicherheitspuffer an. Für knappe Artikel empfehlen wir bewusste Reservierungen je Kanal statt vollständiger Freigabe des Gesamtbestands.
Ergänzend gehören Einkauf und Lieferantenseite zum Kern: Bestellvorschläge, Lieferantenpreise, Bestellungen, Wareneingang mit Mengen- und Preisprüfung, Rückstände. Für Handelsunternehmen ist dieser Bereich häufig der mit dem größten ungenutzten Potenzial, weil er in gewachsenen Setups oft noch in Tabellen und E-Mail-Verläufen lebt. Sobald Einkauf und Bestandsdaten im gleichen System liegen, wird aus Bauchgefühl eine nachvollziehbare Entscheidung.
Ein Bestellvorschlag ist im Kern eine Rechnung: erwarteter Bedarf im Wiederbeschaffungszeitraum, abzüglich verfügbarer Bestand, abzüglich bereits bestellter Mengen, plus Sicherheitsbestand, gerundet auf Verpackungseinheiten und Mindestbestellmengen. Jede dieser Größen muss gepflegt sein. Fehlt die Wiederbeschaffungszeit, rechnet das System mit einer Annahme. Fehlen Mindestbestellmengen, entstehen Vorschläge, die der Lieferant nicht bedienen kann. Fehlen Verpackungseinheiten, kommen Bruchteile heraus.
Der praktische Nutzen ist trotzdem hoch, weil der Vorschlag den Einkauf von der Frage entlastet, welche Artikel überhaupt betrachtet werden müssen. Statt eine Artikelliste durchzusehen, prüft der Einkauf eine Vorschlagsliste – und trifft die Entscheidung mit Kontext. Wichtig ist die Rollenklärung: Der Vorschlag ersetzt keine Entscheidung, er strukturiert sie. Systeme, die automatisch bestellen, sind technisch möglich und in den meisten Handelsunternehmen der falsche Weg, weil sie Sondersituationen nicht kennen: den Lieferantenengpass, die auslaufende Kollektion, die geplante Aktion.
Wir empfehlen ein gestuftes Vorgehen. Zuerst die Datenbasis herstellen: Wiederbeschaffungszeiten, Mindestmengen, Verpackungseinheiten, Lieferantenzuordnung. Dann Vorschläge für eine Warengruppe aktivieren und über einige Wochen gegen die manuelle Praxis vergleichen. Dann ausrollen. Diese Reihenfolge klingt langsam und ist der schnellste Weg zu einem Vorschlag, dem der Einkauf glaubt. Ein Vorschlagssystem, das zweimal deutlich falschlag, wird nicht mehr benutzt – und lässt sich nur schwer rehabilitieren.
Bedarfsprognosen in Handelssystemen arbeiten überwiegend mit statistischen Verfahren auf Basis der eigenen Verkaufshistorie: Mittelwerte mit Gewichtung, Trendkomponente, Saisonfaktoren, Ausreißerbehandlung. Das ist kein Nachteil, sondern angemessen. Diese Verfahren sind nachvollziehbar, brauchen wenig Daten und liefern für stetig laufende Artikel gute Ergebnisse. Ihre Grenze liegt dort, wo Geschichte keine Aussage über die Zukunft erlaubt: bei neuen Artikeln, bei Aktionsware, bei Sortimentswechseln, bei externen Effekten wie Wetter oder Reichweite in sozialen Netzwerken.
Für die Bewertung heißt das: Fragen Sie nicht, ob ein System eine Prognose hat, sondern welche Artikel es damit sinnvoll abdeckt und wie es mit den übrigen umgeht. Ein gutes Setup teilt das Sortiment: Für den stetigen Teil arbeitet die Automatik, für den unstetigen Teil bleibt die menschliche Planung mit Kontextwissen. Diese Aufteilung ist ehrlicher als eine flächendeckende Prognose, die im schwierigen Teil des Sortiments Zahlen produziert, denen niemand traut. Genauigkeitsangaben zu Prognosen nennen wir bewusst nicht – sie hängen vollständig von Sortiment und Datenhistorie ab und sind ohne die eigenen Daten bedeutungslos.
In den Projekten, die wir begleiten, kommt der messbare Effizienzgewinn fast immer aus dem unspektakulären Teil. Beispiele: Zahlungseingänge werden automatisch der Bestellung zugeordnet. Der Status wechselt ohne Klick, sobald Bezahlung und Bestand stimmen. Die Versandart wird nach Gewicht, Zielland und Wert per Regel gesetzt statt am Packplatz entschieden. Belege entstehen automatisch beim jeweiligen Prozessschritt. Benachrichtigungen an Kunden werden aus Ereignissen erzeugt, nicht aus einem Vorgang, an den jemand denken muss.
Der Grundsatz dahinter ist einfach und wirkt in jedem Handelsbetrieb: Jede Entscheidung, die ein Mensch mehrfach täglich nach demselben Muster trifft, gehört in eine Regel. Der Mensch bleibt für die Ausnahme zuständig – und wird dafür freigespielt. Dieser Hebel braucht keine KI, sondern Prozessklarheit und eine Software, in der sich Regeln ohne Programmierung hinterlegen lassen. Genau danach sollte man in einer Demonstration fragen: nicht nach dem Vorhandensein von Automatisierung, sondern nach der Frage, wer sie im laufenden Betrieb anpassen kann und wie lange das dauert.
Wo Sprachmodelle in Handelssoftware Einzug halten, betrifft es vor allem Text: Produktbeschreibungen, Merkmalsvorschläge, Übersetzungen, Entwürfe für Serviceantworten. Der Nutzen ist real, die Anforderung klar – es braucht einen Freigabeschritt, bevor Inhalte im Shop erscheinen oder an Kunden gehen. Und es braucht Transparenz darüber, welche Daten dabei wohin übertragen werden. Diese Frage gehört in dieselbe Prüfung wie jede andere Datenverarbeitung und ist beim Anbieter konkret zu klären.
Für Händler, die neben dem eigenen Shop auf Marktplätzen verkaufen, ist die Anbindung dieser Kanäle die entscheidende Integrationsfrage. Anders als beim Shop gibt es hier keine gemeinsame Datenhaltung, sondern eine Verbindung mit allen typischen Themen: Wie schnell werden Bestände zurückgemeldet? Wie werden Marktplatz-Artikelnummern auf eigene Artikel abgebildet? Was passiert mit Varianten, mit kanalspezifischen Preisen, mit Versandvorgaben des Marktplatzes? Wie werden Marktplatz-Gebühren in der Belegkette abgebildet?
Unsere Empfehlung ist, diesen Bereich in der Auswahl mit echten Beispielen zu prüfen und nicht mit einer Häkchenliste. Nehmen Sie drei konkrete Artikel aus dem Marktplatzgeschäft, einen einfachen, einen mit Varianten und einen mit kanalspezifischen Besonderheiten, und lassen Sie den kompletten Weg zeigen: Anlage, Bestandsführung, Bestellung, Versand, Retoure, Buchung. Wenn der Marktplatzhandel den größeren Umsatzanteil trägt, sollte zusätzlich geprüft werden, ob eine shopzentrierte Architektur überhaupt die richtige Grundform ist – oder ob ein System mit kanalneutraler Datenhaltung besser passt.
Die Warenwirtschaft erzeugt die Belege, die Buchhaltung verarbeitet sie. Diese Grenze ist bewusst gezogen: Eine Handelssoftware führt in der Regel keine Finanzbuchhaltung, sondern liefert Ausgangsrechnungen, Gutschriften, Zahlungsinformationen und Warenbestandsdaten in einer Form, die sich buchen lässt. Die Praxis läuft überwiegend über strukturierte Exporte, die in der Buchhaltungslösung eingelesen werden, ergänzt um Anbindungen aus dem Partnerumfeld.
Drei Punkte gehören im Projekt früh geklärt, und zwar mit der Steuerberatung am Tisch. Erstens die Kontenzuordnung: Welche Erlöskonten, welche Steuerschlüssel, welche Behandlung von Versandkosten, Gutscheinen und Rundungsdifferenzen. Zweitens der grenzüberschreitende Verkauf: Lieferungen in andere EU-Länder und an Geschäftskunden folgen eigenen Regeln, die sich in der Belegerzeugung abbilden müssen. Drittens die Abstimmbarkeit: Zahlungseingänge über Zahlungsdienstleister erreichen das Konto gesammelt und mit Gebührenabzug – die Zuordnung auf Einzelbelege muss nachvollziehbar bleiben. Wer diese drei Punkte vor dem Start klärt, spart sich einen unerfreulichen ersten Jahresabschluss.
Auf der Versandseite ist die Anforderung klar umrissen: Aus dem kommissionierten Auftrag entsteht ohne Umweg ein Etikett, eine Sendungsnummer geht an den Kunden, der Status fließt zurück, und für Rücksendungen lässt sich ein Retourenlabel erzeugen. Wichtig ist die Rückrichtung, weil sie den Kundenservice entlastet: Wenn Sendungsstatus im System sichtbar sind, muss niemand die Portalseite des Dienstleisters öffnen, um eine Kundenfrage zu beantworten.
Für Unternehmen mit mehreren Versanddienstleistern kommt die Frage der Auswahlregeln hinzu. Gewicht, Maße, Zielland, Warenwert, Zustellart und Kundenwunsch bestimmen, welcher Dienstleister zum Einsatz kommt. Diese Entscheidung gehört in eine Regel und nicht an den Packplatz. Wo die Anzahl der Carrier oder die Komplexität der Regeln über das hinausgeht, was die Warenwirtschaft abbildet, ist eine Multi-Carrier-Zwischenschicht der übliche Weg – mit dem Preis einer weiteren Komponente in der Kette.
Bei Zahlungsdienstleistern liegt der Nutzen im automatischen Abgleich. Eine Bestellung ist bezahlt, teilbezahlt, storniert oder erstattet – und dieser Zustand sollte ohne manuelle Pflege im Beleg stehen. Praktisch relevant sind dabei die unangenehmen Fälle: Teilrückerstattungen bei Teilretouren, Zahlungsabbrüche, Rückbelastungen. Diese Fälle gehören in jede Demonstration, weil sie im Alltag mehr Zeit kosten als der Standardvorgang und weil sich Systeme genau hier unterscheiden.
Der wichtigste Unterschied in dieser Gruppe ist nicht der Funktionsumfang, sondern die Grundform. Auf der einen Seite steht die eingebettete Lösung, bei der Shop und Warenwirtschaft eine Datenhaltung teilen. Auf der anderen Seite stehen eigenständige Systeme, die Kanäle über Konnektoren anbinden. Beide Formen haben ein klares Profil. Die eingebettete Form gewinnt bei Konsistenz und Einfachheit und verliert bei Kanalvielfalt und Wechselfähigkeit. Die eigenständige Form gewinnt bei Kanalneutralität und verliert an den Abgleichstellen.
Aus dieser Gegenüberstellung ergibt sich eine praktikable Auswahlheuristik. Wer einen dominierenden eigenen Shop hat und diesen strategisch behalten will, findet in der eingebetteten Form den kürzesten Weg. Wer viele Kanäle mit ähnlichem Gewicht bedient oder mit einem Shopwechsel rechnet, ist mit einem kanalneutralen System besser aufgestellt. Diese Frage ist in einem Gespräch zu klären und ersetzt eine mehrwöchige Funktionsmatrix nahezu vollständig.
Jenseits der Architektur lohnt der Blick auf vier Dimensionen, in denen sich die Systeme praktisch unterscheiden. Erstens die Lagertiefe: Wie fein lassen sich Plätze, Zonen, Chargen und Seriennummern abbilden, und wie gut führt die mobile Anwendung? Zweitens die Einkaufstiefe: Gibt es echte Lieferantenverwaltung, Bestellvorschläge, Rückstandsverwaltung, Preis- und Konditionspflege? Drittens die Kanalbreite: Wie viele Marktplätze und Shopsysteme sind angebunden, und in welcher Tiefe? Viertens die Anpassbarkeit: Lassen sich Regeln, Belege und Abläufe ohne Programmierung verändern?
Eine fünfte, oft unterschätzte Dimension ist das Umfeld. Wie viele Dienstleister kennen das System? Wie gut ist die Dokumentation? Gibt es aktive Anwendergemeinschaften, in denen praktische Fragen beantwortet werden? Wie kalkulierbar ist Support? Für ein mittelständisches Unternehmen ohne eigene IT-Abteilung ist dieses Umfeld häufig wichtiger als ein Funktionsvorteil, weil es die Verfügbarkeit von Hilfe bestimmt, wenn im Tagesgeschäft etwas klemmt.
Was wir in Auswahlprozessen konsequent nicht empfehlen: die Entscheidung über eine Funktionsmatrix mit mehreren Hundert Zeilen. Solche Matrizen erzeugen den Eindruck von Objektivität und belohnen den Anbieter mit der längsten Liste, nicht den mit der besten Passung. Wirksamer sind fünf bis acht durchgespielte Prozesse aus dem eigenen Alltag – der komplizierteste Auftrag, die häufigste Retoure, die schwierigste Inventursituation, der Monatsabschluss. Wer diese Szenarien in jeder Demonstration identisch durchspielt, sieht Unterschiede, die keine Tabelle zeigt.
Weil die Warenwirtschaft im Shopsystem läuft, ist die Betriebsfrage keine eigene Entscheidung, sondern die Betriebsfrage des Shops. Wird der Shop als Dienst betrieben, läuft die Warenwirtschaft dort mit. Wird der Shop auf eigener oder gemieteter Infrastruktur betrieben, gilt dasselbe für die Warenwirtschaft. Diese Kopplung ist ein Vorteil in der Einfachheit und eine Anforderung an die Kapazitätsplanung, weil zwei Lasten auf einer Umgebung liegen. Welche Betriebsvarianten in welcher Ausbaustufe unterstützt werden, ist beim Anbieter zu prüfen.
Praktisch bedeutet das drei Prüfpunkte. Erstens Leistung: Lagerprozesse erzeugen viele kleine Schreibvorgänge, die parallel zum Frontend-Verkehr laufen. Bei wachsendem Volumen muss die Umgebung mitwachsen. Zweitens Verfügbarkeit: Ein Wartungsfenster betrifft nicht nur den Shop, sondern auch den Packplatz und die Kasse – Zeitfenster gehören abgestimmt. Drittens Sicherung: Datensicherung, Wiederherstellungszeit und ein getesteter Wiederherstellungsvorgang sind bei einer Warenwirtschaft keine Formalität. Wir empfehlen, die Wiederherstellung mindestens einmal tatsächlich zu üben.
Für Unternehmen mit Anforderungen an Datenhoheit ist die Möglichkeit, die gesamte Umgebung selbst oder bei einem gewählten Betreiber in Deutschland zu hosten, ein realer Vorteil. Man behält Kontrolle über Speicherort, Zugriffswege und Sicherungsstrategie. Der Gegenwert ist Verantwortung: Aktualisierungen, Sicherheitspflege und Überwachung liegen dann im eigenen Haus oder beim Dienstleister und müssen verlässlich stattfinden. Ein selbst betriebenes System ohne gepflegte Aktualisierungen ist unsicherer als ein gut betreuter Dienst.
Migration bedeutet nicht, Daten zu kopieren, sondern zu entscheiden, welche Daten überhaupt mitkommen. Unser Vorgehen unterscheidet drei Klassen. Stammdaten müssen vollständig und bereinigt übernommen werden: Artikel, Varianten, Einheiten, Gewichte, Maße, Lieferanten, Kunden, Preise. Bewegungsdaten kommen selektiv mit: offene Aufträge, offene Bestellungen, aktuelle Bestände, offene Posten. Historische Daten bleiben in der Regel im Altsystem oder werden als Export archiviert – eine vollständige Historienübernahme ist teuer und bringt selten den erwarteten Nutzen.
Der aufwendigste Teil ist fast immer der Bestand. Ein Bestand, der im Altsystem nicht stimmt, stimmt nach der Migration auch nicht – er ist nur schwerer zu erklären. Deshalb gehört eine vollständige Inventur zum Stichtag in jedes Projekt, mit anschließender Einlagerung auf definierte Plätze. Das ist unbequem, insbesondere für Betriebe, die keinen Stillstandstag einplanen wollen. Es ist aber der einzige Weg zu einer belastbaren Ausgangslage. Alle Alternativen verschieben das Problem in den Betrieb, wo es teurer wird.
Anders als bei rein kaufmännischer Software gehört zur Einführung eine Hardwareentscheidung. Für die mobile Kommissionierung braucht es Geräte, die eine Acht-Stunden-Schicht durchhalten, im Lagerklima funktionieren, einen Sturz aus Brusthöhe überstehen und eine Scanleistung bieten, die auch bei schlecht gedruckten Etiketten und aus Entfernung liest. Die Bandbreite reicht von Consumer-Geräten mit Kamerascan über Geräte mit Scan-Aufsatz bis zu Industriegeräten mit Laserscanner. Für gelegentliche Nutzung reicht die einfache Variante, für Dauerbetrieb im Mehrschichtbetrieb nicht.
Auf der Druckerseite geht es um Etiketten- und Belegdruck. Thermodrucker für Versandetiketten und Lagerplatzkennzeichnung sind Standard; entscheidend ist die zuverlässige Zuordnung von Arbeitsplatz zu Drucker, damit das Etikett dort erscheint, wo die Sendung steht. Für den Kassenplatz kommen Kassendrucker, Kartenterminal, Kassenschublade und ein Bediengerät hinzu – hier sind die Anforderungen an Zertifizierung, technische Sicherheitseinrichtung und Belegausgabe zu beachten, die im Kassenrecht geregelt sind. Diese Punkte gehören mit dem Steuerberater geklärt, bevor die erste Kasse in Betrieb geht.
Für die Netzabdeckung im Lager gilt eine einfache Regel: Ein Funkloch im Regalgang wird zum Prozessproblem. Wir empfehlen, die Abdeckung vor der Einführung an den tatsächlichen Arbeitspunkten zu messen und nicht anzunehmen. Metallregale und volle Lager verändern die Ausbreitung erheblich; eine Messung im leeren Lager ist wertlos. Ebenso gehört ein Verhalten bei Verbindungsverlust definiert – ob Geräte zwischenspeichern und später übertragen oder ob der Vorgang abbricht, entscheidet über die Robustheit im Alltag.
In der Rückschau auf Projekte fällt auf, dass der Erfolg weniger mit der Unternehmensgröße korreliert als mit drei anderen Faktoren. Erstens der Klarheit der Prozesse: Unternehmen, die vor der Einführung wissen, wie ihr Auftrag laufen soll, kommen schneller in den Nutzen als Unternehmen, die diese Klärung auf die Software abwälzen. Zweitens der Datenqualität: Wo Artikelstämme gepflegt sind, funktionieren Automatismen; wo sie es nicht sind, entstehen Ausnahmen, die manuell bearbeitet werden. Drittens der benannten Verantwortung: Es braucht eine Person im Haus, die das System kennt, Regeln anpasst und Ansprechpartner ist.
Der dritte Punkt wird am häufigsten unterschätzt. Eine Warenwirtschaft ohne interne Zuständigkeit verfällt: Regeln werden nicht angepasst, wenn sich das Sortiment ändert, Ausnahmen werden zur Gewohnheit, Umgehungslösungen entstehen in Tabellen. Nach zwei Jahren arbeitet man dann wieder wie vorher, nur mit teurerer Software. Diese Rolle braucht keine volle Stelle, aber eine feste Zeit im Kalender und die Befugnis, Entscheidungen über Prozesse zu treffen.
Vier Muster begegnen uns regelmäßig. Das erste ist der Big-Bang ohne Testbetrieb: Umstellung zum Monatsersten, ohne dass jemand die komplizierten Vorgänge vorher durchgespielt hat. Das zweite ist die Migration ungeprüfter Bestände, die alte Differenzen in ein neues System trägt und dort schwerer erklärbar macht. Das dritte ist die Abbildung gewachsener Sonderwege in der neuen Software, statt sie im Zuge der Einführung zu vereinfachen – jede übernommene Ausnahme erhöht dauerhaft die Komplexität. Das vierte ist die Schulung als Einmaltermin vor dem Start, ohne Begleitung in den ersten Wochen, in denen die eigentlichen Fragen entstehen.
Dem gegenüber stehen die Muster erfolgreicher Projekte, und sie sind unspektakulär: ein enger Startumfang, ein früher Testbetrieb mit echten Fällen, eine Inventur zum Stichtag, benannte Verantwortung, Begleitung in den ersten vier Wochen, und ein Ausbau in Stufen statt in einem Wurf. Der wirksamste Einzelhebel ist dabei die Entscheidung, mit weniger zu starten. Ein System, das drei Prozesse sauber abbildet, schafft mehr Nutzen als eines, das zehn Prozesse halb abbildet.
Die Gesamtkosten entstehen aus vier Blöcken, die nur zusammen ein Bild ergeben. Der erste ist die Lizenz, gestaffelt nach Modulumfang, Nutzerzahl und Ausbaustufe. Der zweite ist die Einführung: Prozessaufnahme, Konfiguration, Stammdatenarbeit, Migration, Schulung, Begleitung in den ersten Wochen. Der dritte ist die Infrastruktur inklusive Sicherung, Überwachung und Aktualisierungspflege. Der vierte ist die Hardware mit Ersatz- und Erweiterungszyklus. Hinzu kommt ein fünfter, der in keinem Angebot steht: der interne Aufwand für Betreuung, Regelpflege und Weiterentwicklung.
Wir empfehlen, alle Blöcke über drei Jahre zu rechnen und Wachstum einzupreisen – mehr Artikel, mehr Bestellungen, mehr Nutzer, weitere Kanäle, ein zusätzlicher Standort. Ebenso gehört die Gegenrechnung dazu, und sie ist im Handel gut greifbar: eingesparte Erfassungszeit, vermiedene Fehlversendungen mit Zweitversand und Erstattung, vermiedene Überverkäufe mit Absagen, reduzierte Kapitalbindung durch bessere Bestellentscheidungen, kürzere Bearbeitungszeit im Kundenservice. Diese Effekte lassen sich mit den eigenen Zahlen abschätzen und ergeben eine belastbarere Grundlage als jede Musterrechnung.
Ein Hinweis zu Angebotsvergleichen: Preisblätter verschiedener Anbieter sind selten direkt vergleichbar, weil Module unterschiedlich geschnitten sind, Nutzerbegriffe abweichen und Leistungen unterschiedlich zugeordnet werden. Lassen Sie deshalb jeden Anbieter denselben Leistungsumfang auf Basis Ihrer Prozesse kalkulieren – gleiche Nutzerzahl, gleiche Standorte, gleiche Kanäle, gleicher Migrationsumfang. Erst dann entstehen vergleichbare Zahlen. Und fragen Sie ausdrücklich nach den Kosten der zweiten Stufe: Was passiert preislich, wenn ein Lager, ein Kassenplatz oder zwanzig Nutzer hinzukommen?
Für Unternehmen, die aus eigenen Compliance-Vorgaben oder aus Kundenanforderungen heraus auf europäische Datenverarbeitung achten müssen, ist die Herkunft des Anbieters mehr als ein Marketingargument. Ein deutscher Anbieter mit Betrieb in der EU bedeutet praktisch: Vertragsunterlagen nach hiesigem Recht, Ansprechpartner in derselben Zeitzone und Sprache, keine grundsätzliche Diskussion über Drittlandtransfers, und ein Produktverständnis, das an hiesigen Anforderungen an Belege, Umsatzsteuer und Kassenführung ausgerichtet ist. Wer schon einmal versucht hat, eine Datenschutzfrage mit einem Support außerhalb Europas zu klären, kennt den Unterschied.
Besonders relevant ist die Option, die Umgebung selbst zu betreiben oder bei einem gewählten Betreiber in Deutschland zu hosten. Damit liegen Speicherort, Zugriffswege und Sicherungsstrategie vollständig im eigenen Verantwortungsbereich – ein Argument, das in regulierten Branchen und bei Ausschreibungen mit Souveränitätsanforderungen den Unterschied macht. Zu prüfen bleibt, in welchen Ausbaustufen diese Option verfügbar ist und welche Anforderungen an Aktualisierungspflege und Überwachung damit einhergehen. Diese Frage gehört ausdrücklich in das Vorgespräch mit dem Anbieter.
Gleichzeitig ersetzt die Herkunft keine Prüfung. Auch bei einem deutschen Anbieter gilt: Wird der Betrieb als Dienst erbracht, liegt eine Auftragsverarbeitung vor und es braucht eine entsprechende Vereinbarung mit Beschreibung der Verarbeitung, der technischen und organisatorischen Maßnahmen und der eingesetzten Unterauftragnehmer. Auch Support-Zugriffe auf Produktivdaten gehören geregelt, begrenzt und protokolliert. Und auch hier lohnt die Frage nach dem Umgang mit Sicherungskopien, weil Sicherungen an anderen Orten liegen können als die Produktivumgebung.
Eine Handelssoftware ist gleichzeitig Datenschutz- und Aufbewahrungsthema, und beide Anforderungen ziehen in unterschiedliche Richtungen. Kundendaten sollen gelöscht werden, wenn der Zweck entfällt; Belege müssen über die handels- und steuerrechtlichen Fristen aufbewahrt werden. Die Auflösung liegt in einem differenzierten Löschkonzept, das zwischen Belegdaten und darüber hinausgehenden Daten unterscheidet – etwa Marketingeinwilligungen, Servicekommunikation, Verhaltensdaten. Dieses Konzept gehört mit der Steuerberatung und dem Datenschutzbeauftragten abgestimmt und im System technisch umgesetzt, nicht nur beschrieben.
Für Betroffenenrechte braucht es zwei Fähigkeiten: Auskunft und Löschung. Auf Anfrage muss darstellbar sein, welche Daten zu einer Person vorliegen – Bestellungen, Adressen, Servicevorgänge, Zahlungsinformationen – und das möglichst ohne Datenbankrecherche. Bei Löschanfragen muss die Software zwischen dem löschbaren und dem aufbewahrungspflichtigen Teil trennen können, üblicherweise über Anonymisierung des personenbezogenen Anteils bei Erhalt des Belegs. Wir empfehlen, beide Vorgänge im Testbetrieb einmal durchzuspielen, damit im Ernstfall klar ist, wer was in welcher Reihenfolge tut.
Nachvollziehbarkeit ist der dritte Punkt und dient auch dem eigenen Interesse. Wer hat wann welchen Bestand verändert, wer hat einen Beleg storniert, wer hat einen Preis angepasst? Eine belastbare Protokollierung ist die Grundlage jeder Klärung – bei Inventurdifferenzen, bei Verdachtsfällen, bei Reklamationen und im Rahmen einer Prüfung. Für die verbindliche Bewertung des konkreten Einsatzes gilt jedoch: Das gehört zum eigenen Datenschutzbeauftragten, zur Steuerberatung und, wo nötig, zu fachkundiger rechtlicher Begleitung.
