Für Entscheider im Mittelstand ist genau diese Doppelbenennung der erste Punkt, der Klarheit braucht. Wer heute nach inconso recherchiert, findet einerseits eine gewachsene Produktgeschichte mit etablierten Modulbezeichnungen und einer großen Zahl an Referenzinstallationen im deutschsprachigen Raum, andererseits einen internationalen Anbieter mit breitem Portfolio, in dem diese Produkte unter neuen Namen und in einer übergeordneten Architektur weitergeführt werden. Beides gehört zusammen, aber es beschreibt unterschiedliche Perspektiven: die eine ist historisch und funktional, die andere organisatorisch und strategisch.
Praktisch heißt das: Sie kaufen heute keine eigenständige inconso-Firma mehr ein, sondern ein Produkt aus einem Konzernportfolio. Das hat Vorteile – größere Entwicklungsressourcen, internationale Präsenz, ein Ökosystem aus Automatisierungs- und Robotiktechnik im selben Haus. Und es hat Fragen zur Folge, die man im Auswahlprozess stellen sollte: Wie lange wird die bestehende Codebasis weiterentwickelt, welche Migrationspfade sind vorgesehen, welche Ansprechpartner bleiben regional erreichbar, und welche Roadmap gilt für das Modul, auf das man sich verlässt. Diese Fragen sind kein Misstrauen, sondern Sorgfalt – und der Anbieter beantwortet sie in einem seriösen Gespräch ohne Umschweife.
Die Entstehungsgeschichte erklärt viel über den Charakter der Software. inconso wurde von Menschen aufgebaut, die aus der Projektlogistik kamen – aus Einführungen von Lagerverwaltungssystemen in Distributionszentren, aus der Anbindung von Fördertechnik und Regalbediengeräten, aus der Zusammenarbeit mit Anlagenbauern. Daraus entstand keine Standardsoftware im Sinne eines fertigen Produkts, das man installiert und benutzt, sondern eine Plattform mit Standardkern und projektspezifischer Ausgestaltung. Dieses Modell ist im deutschen Logistikmarkt weit verbreitet und unterscheidet sich deutlich von der Denkweise reiner Cloud-Produkte.
Mit der Zugehörigkeit zu einem international aufgestellten Konzern hat sich der Rahmen verändert. Das Portfolio wurde neben andere Lösungen gestellt, die aus anderen Märkten und anderen Traditionen kommen, und die Markenführung wurde gebündelt. Für Kunden bedeutet das zweierlei: Sie profitieren von größerer Investitionskraft und einem breiteren Angebot – von Software über Robotik bis zu Beratung und Betrieb –, müssen aber im Auswahlgespräch genauer klären, welches Produkt aus dem Portfolio ihnen tatsächlich angeboten wird. Denn ein Portfolio mit mehreren Lagerverwaltungslinien ist funktional nicht identisch, und die Empfehlung hängt von Branche, Land, Automatisierungsgrad und Unternehmensgröße ab.
Eine Abgrenzung, die im Beratungsgespräch fast immer nötig ist: Ein Lagerverwaltungssystem ist kein ERP-System. Es führt keine Buchhaltung, keine Auftragsabwicklung mit Kundenpreisen, keine Beschaffung und keine Kostenrechnung. Es übernimmt einen Auftrag oder eine Lieferanweisung aus dem Vorsystem und beantwortet daraufhin die Fragen, die im Lager entstehen: Wo liegt der Artikel, in welcher Reihenfolge wird kommissioniert, welcher Mitarbeiter oder welches Gerät führt den nächsten Schritt aus, wie werden Packstücke gebildet, welche Kontrolle greift, welche Charge oder welches Mindesthaltbarkeitsdatum wird gezogen, wann wird was verladen. Diese Fragen entscheidet ein WMS – und zwar in Echtzeit, mit Bezug auf physische Zustände.
Ebenso wenig ist inconso ein Materialflussrechner allein oder eine Steuerung für Fördertechnik allein, auch wenn beides zum Portfolio gehört. Und es ist keine Planungssoftware im Sinne von Absatz- oder Bestandsplanung über längere Horizonte; solche Aufgaben liegen in ERP-Systemen oder in eigenständigen Planungslösungen. Wer diese Grenzen nicht sauber zieht, produziert im Projekt genau die Effekte, die Einführungen teuer machen: doppelte Datenhaltung, unklare Zuständigkeit für Bestände, endlose Diskussionen darüber, welches System recht hat.
Der wichtigste konzeptionelle Punkt zum Schluss dieses Kapitels: Ein Lagerverwaltungssystem ist immer nur so gut wie die Prozesse, die es abbildet. Wer ungeklärte Abläufe digitalisiert, erhält – wie wir es im Projektalltag nennen – „digitalisierte Unklarheit“ – schneller, aber nicht besser. Deshalb beginnt jedes Projekt, das wir begleiten, nicht mit einer Softwareauswahl, sondern mit einer nüchternen Aufnahme des Ist-Zustands: Artikelstruktur, Auftragsstruktur, Lagerorte, Bewegungsarten, Sonderfälle. Erst danach ist die Frage nach dem passenden System sinnvoll beantwortbar.
Der praktische Vorteil einer Suite liegt darin, dass die Module aus einer gemeinsamen Entwicklungslinie kommen und über bekannte Wege miteinander sprechen. Wenn ein Lagerverwaltungssystem, ein Transportmodul und eine Zeitfensterbuchung vom selben Hersteller stammen, entfällt ein erheblicher Teil des Integrationsaufwands, der bei einer Kombination aus drei fremden Systemen anfällt. Ebenso wichtig: Es gibt einen Verantwortlichen für die Gesamtfunktion. Wer schon einmal in einem Störungsfall zwischen drei Herstellern vermittelt hat, kennt den Wert dieses Punktes.
Der Preis dieser Bündelung ist eine gewisse Abhängigkeit. Wer alle Schichten von der Bestandsführung bis zur Anlagensteuerung bei einem Anbieter bezieht, hat einen sehr einheitlichen Betrieb – und einen sehr konzentrierten Wechselaufwand, wenn er später einen Teil ersetzen will. Unsere Empfehlung ist deshalb weder maximale Bündelung noch maximale Vielfalt, sondern eine bewusste Entscheidung pro Schicht: Wo bringt Einheitlichkeit echten Nutzen, und wo will man Freiheitsgrade behalten. Diese Entscheidung sollte dokumentiert sein, damit sie in fünf Jahren noch nachvollziehbar ist.
Ein zweiter Aspekt der Modularität betrifft den Einstieg. Nicht jedes Unternehmen braucht alle Schichten sofort. Viele Projekte beginnen mit der Lagerverwaltung, ergänzen später eine Zeitfensterbuchung, weil sich Staus vor den Toren nicht mehr anders lösen lassen, und kommen erst danach zur Transportsteuerung. Diese Reihenfolge ist meist sinnvoller als ein Gesamtwurf, weil jede Stufe Nutzen liefert und Erfahrungen für die nächste erzeugt. Wichtig ist nur, dass die Zielarchitektur von Anfang an gedacht ist – sonst entstehen Provisorien, die man später doppelt bezahlt.
Der Körber-Konzern hat über mehrere Jahre eine Reihe von Logistik-Softwarehäusern und Automatisierungsanbietern zusammengeführt und daraus einen eigenen Geschäftsbereich für Supply Chain geformt. inconso ist einer der Bausteine dieses Bereichs, neben Lösungen anderer Herkunft, neben Robotik- und Fördertechnikkompetenz und neben Dienstleistungen für Beratung, Implementierung und Betrieb. Die Marken wurden im Zuge dieser Bündelung schrittweise unter dem Konzernnamen zusammengefasst; die Produktlinien selbst bestehen weiter, teilweise unter neuen Bezeichnungen.
Für die Auswahlentscheidung ergeben sich daraus drei sehr konkrete Fragen. Erstens: Welche Produktlinie wird für den eigenen Fall vorgeschlagen, und warum genau diese – ein Portfolio mit mehreren Lagerverwaltungslinien bedeutet, dass die Empfehlung von Branche, Region, Automatisierungsgrad und Größe abhängt. Zweitens: Wie sieht die Roadmap für diese Linie aus, welche Funktionen sind angekündigt, und wie werden Bestandskunden bei Architekturwechseln begleitet. Drittens: Wer übernimmt Projekt und Betreuung – der Hersteller selbst, eine regionale Einheit oder ein Partner, und mit welcher Erfahrung in der eigenen Branche.
Positiv zu bewerten ist die Nähe zur Anlagentechnik. Ein Konzern, der Software, Fördertechnik, Robotik und Beratung im Haus hat, kann Automatisierungsprojekte aus einer Hand anbieten – und das ist bei Investitionen in Lagertechnik ein realer Vorteil, weil die klassische Bruchstelle zwischen Softwarehaus und Anlagenbauer entfällt. Gleichzeitig sollte man sich nicht in eine Paketlösung drängen lassen: Ein gutes WMS muss auch Anlagen anderer Hersteller ansteuern können, und diese Offenheit gehört ausdrücklich abgefragt.
Die Suite adressiert im Kern drei Kundentypen mit unterschiedlichen Anforderungen. Im Handel und in der Distribution zählen Kommissionierleistung, Auftragsspitzen, Retourenabwicklung und Versandvielfalt. In der Industrie stehen Produktionsversorgung, Chargen- und Seriennummernführung, Behälterkreisläufe und die Kopplung an Fertigungssteuerung im Vordergrund. Bei Logistikdienstleistern kommt eine ganz eigene Dimension hinzu: die Mandantenfähigkeit, also die Fähigkeit, mehrere Auftraggeber mit getrennten Beständen, eigenen Prozessen, eigener Abrechnung und eigenen Auswertungen in einem System zu führen.
Diese Mandantenfähigkeit ist ein Merkmal, an dem sich Lagerverwaltungssysteme deutlich unterscheiden, und sie ist deshalb ein guter Prüfstein. Wer als Kontraktlogistiker arbeitet, braucht mehr als getrennte Bestandskreise – er braucht mandantenspezifische Strategien, mandantenspezifische Belege, eine leistungsbezogene Abrechnung nach Bewegungen und Lagerplätzen sowie die Möglichkeit, neue Auftraggeber ohne Programmierung aufzuschalten. Anbieter mit Wurzeln in der Kontraktlogistik sind hier traditionell stark, und die inconso-Historie mit Projekten bei Dienstleistern spricht für Erfahrung in diesem Feld.
Jedes Lagerverwaltungssystem kann Bestände buchen. Der Unterschied zwischen einem einfachen und einem leistungsfähigen System liegt in den Strategien – also in den Regeln, nach denen das System entscheidet. Bei der Einlagerung sind das Kriterien wie Artikelumschlag, Gewicht, Volumen, Zusammenlagerungsverbote, Temperaturzonen, Gefahrstoffklassen oder Lagerplatzauslastung. Bei der Kommissionierung geht es um Wegoptimierung, Zonenbildung, Batch- und Multi-Order-Picking, Pick-and-Pass, Ware-zum-Mann-Anbindung, Chargen- und Verfallsdatumslogik sowie um die Frage, wie Teilmengen und Fehlmengen behandelt werden.
Der Reifegrad eines Systems zeigt sich in zwei Dingen. Erstens in der Breite der verfügbaren Strategien, zweitens – und wichtiger – in der Frage, ob sie über Parameter gesetzt oder programmiert werden müssen. Ein System, in dem jede Strategieänderung ein Entwicklungsticket auslöst, wird im Betrieb teuer und träge, denn Lagerprozesse ändern sich mit dem Sortiment. Wir empfehlen deshalb, im Auswahlgespräch nicht nach Funktionen, sondern nach Änderungsaufwand zu fragen: Wie ändert man die Einlagerstrategie für eine neue Artikelgruppe, wer darf das, und wie lange dauert es.
Zum WMS-Kern gehören weitere Bereiche, die im Alltag über die Akzeptanz entscheiden. Die Inventur mit permanenter oder stichtagsbezogener Aufnahme und mit Stichprobenverfahren. Der Nachschub zwischen Reserve- und Kommissionierzone, dessen Auslösung entweder verbrauchsgesteuert oder auftragsbezogen erfolgt. Die Packplatzunterstützung mit Kartonwahl, Gewichtskontrolle und Versandetikettierung. Die mobile Bedienung auf Handhelds und Staplerterminals, deren Dialogführung darüber entscheidet, wie schnell neue Mitarbeitende produktiv werden – ein in Zeiten hoher Personalfluktuation nicht zu unterschätzender Punkt. Und die Rückverfolgbarkeit über Chargen, Seriennummern und Verfallsdaten, die in Lebensmitteln, Pharma und Technik nicht verhandelbar ist.
Auf der Ausgangsseite schließt das Transportmanagement an. Funktional geht es um die Bildung von Sendungen aus Aufträgen, die Auswahl des passenden Frachtführers nach Regeln, die Tourenbildung, die Erzeugung der Transportdokumente, die Ermittlung und Prüfung von Frachtkosten sowie die Verfolgung von Sendungsstatus. Für Unternehmen mit gemischtem Versand – Pakete, Stückgut, Teil- und Komplettladungen – ist die entscheidende Frage, ob das System alle diese Verkehrsarten in einem Regelwerk führen kann oder ob für jede Art ein eigener Weg entsteht.
Auf der Eingangsseite und auf dem Betriebsgelände setzt das Yard- und Slot-Management an, das in der Praxis häufig unterschätzt wird. Wer Anlieferungen ohne Zeitfenster annimmt, produziert Wartezeiten vor dem Tor, ungleichmäßige Auslastung im Wareneingang und Konflikte mit Speditionen. Eine Zeitfensterbuchung, in der Lieferanten und Frachtführer selbst Termine wählen, verlagert Planungsarbeit dorthin, wo die Information liegt, und glättet die Last im Lager. Ergänzend steuert das Yard Management die Bewegungen auf dem Gelände: Wo steht welcher Trailer, welches Tor ist frei, welche Rangierbewegung ist als nächste fällig, wie melden sich Fahrer selbst an.
Der Nutzen dieser Module entsteht nicht durch Software allein, sondern durch die Bereitschaft, Regeln durchzusetzen. Eine Zeitfensterbuchung, die man umgehen kann, wird umgangen – und das Wort „verbindlich“ steht dann nur im Konzept. Deshalb gehört zu jedem Yard-Projekt eine Vereinbarung mit den Transportpartnern und eine klare Eskalationsregel für Verspätungen. Das ist Organisationsarbeit, nicht IT-Arbeit – und sie entscheidet über den Erfolg.
Sobald Fördertechnik, Regalbediengeräte, Sorter, Shuttlesysteme oder Kommissionierautomaten im Spiel sind, braucht es eine Schicht zwischen der betriebswirtschaftlich denkenden Lagerverwaltung und der elektrotechnisch denkenden Anlage. Diese Schicht heißt üblicherweise Materialflussrechner. Sie übersetzt Aufträge in Fahr- und Transportbefehle, verfolgt Behälter an Übergabepunkten, verwaltet Belegungen und Reihenfolgen, reagiert auf Störungen und liefert die Daten für Verfügbarkeits- und Leistungsauswertungen. Ihre Taktung liegt im Sekundenbereich, was ganz andere Anforderungen an Stabilität und Antwortzeiten stellt als eine Auftragsverwaltung.
Dass Lagerverwaltung und Materialflussrechner aus einer Entwicklungslinie kommen können, ist ein struktureller Vorteil – weil die klassische Streitfrage entfällt, wessen Fehler ein Stillstand war. Zu prüfen ist dennoch die Offenheit: Kann die Schicht Anlagen unterschiedlicher Hersteller ansteuern, welche Protokolle werden unterstützt, wie ist der Notbetrieb bei Ausfall geregelt, und wie werden Anlagenerweiterungen abgebildet. Für die Investitionssicherheit ist das wichtiger als jede Leistungszahl aus einem Referenzprojekt, denn Leistungszahlen sind ohne die zugehörige Anlagenkonfiguration nicht übertragbar.
Ein moderner Lagerbetrieb wird über Kennzahlen geführt, und die Datengrundlage dafür liegt im WMS. Relevant sind Durchsatz je Bereich und Schicht, Auslastung von Lagerplätzen und Anlagen, Fehler- und Korrekturquoten, Bearbeitungszeiten je Auftragsart, Termintreue im Warenausgang und Wartezeiten im Wareneingang. Wichtiger als die Zahl der mitgelieferten Berichte ist die Frage, ob eigene Auswertungen ohne Herstellereingriff möglich sind und ob die Daten in ein vorhandenes Berichtswerkzeug exportiert werden können. Auswertungen, die nur im Systemfenster existieren, werden in Führungsrunden nicht genutzt.
Ergänzend gibt es Module für Personaleinsatzplanung und Leistungserfassung: Schichtbedarf aus dem Auftragsvorlauf ableiten, Qualifikationen berücksichtigen, Leistungen erfassen und zurückmelden. Dieser Bereich ist funktional attraktiv und arbeitsrechtlich sensibel. Individuelle Leistungserfassung berührt Mitbestimmung und Datenschutz, und Projekte scheitern hier nicht an Technik, sondern an fehlender Einbindung des Betriebsrats. Wer solche Funktionen einführt, sollte den Zweck vorher schriftlich klären, mit aggregierten Auswertungen beginnen und die Beteiligung früh organisieren.
Der größte Teil der Intelligenz in einem Lagerverwaltungssystem ist regelbasierte Optimierung: Wegeberechnung, Auftragsbündelung, Ressourcenzuweisung, Reihenfolgebildung, Nachschubauslösung. Diese Verfahren sind bewährt, nachvollziehbar und im Ergebnis oft wirkungsvoller als jedes lernende Modell, weil sie auf klaren Zielgrößen arbeiten. Wenn ein Anbieter Wegeoptimierung als KI bezeichnet, ist das Marketing – aber die Funktion selbst ist wertvoll und sollte bewertet werden.
Echte datengetriebene Verfahren finden sich in Lagerprojekten typischerweise an vier Stellen. Erstens bei der Prognose von Auftragsmengen und Arbeitslast, um Personal und Schichten vorauszuplanen. Zweitens bei der Slotting-Optimierung, also der laufenden Neuzuordnung von Artikeln zu Lagerplätzen anhand tatsächlicher Zugriffsmuster und Saisonalitäten. Drittens bei der Vorhersage von Anlagenzuständen aus Sensordaten, um Wartung vor dem Ausfall zu planen. Viertens in der Bild- und Sprachverarbeitung: Erkennung von Ladungsträgern und Beschädigungen, Volumenerfassung, sprachgeführte Kommissionierung.
Hinzu kommt eine jüngere Kategorie: sprachbasierte Assistenzfunktionen, die Auswertungen in natürlicher Sprache beantworten oder Anwender bei Fehlersuche und Konfiguration unterstützen. Der Nutzen ist real, aber begrenzt auf Bequemlichkeit und Einstiegshilfe. Für Entscheidungen mit Bestands- oder Kostenwirkung sollten solche Funktionen nicht ohne Kontrolle wirken, und die Datenverarbeitung dahinter gehört sauber geklärt – insbesondere die Frage, ob Eingaben und Auswertungsdaten den eigenen Verarbeitungsrahmen verlassen.
Der praktisch wirksamste Automatisierungshebel im Lager ist selten ein Algorithmus, sondern Technik. Ware-zum-Mann-Systeme, Shuttlelager, Kommissionierroboter und fahrerlose Transportfahrzeuge verändern Arbeitsinhalte und Leistung deutlicher als jede Softwareoptimierung. Für das WMS bedeutet das eine anspruchsvolle Rolle: Es muss diese Ressourcen als gleichwertige Akteure führen, Aufträge zwischen manuellen und automatischen Bereichen aufteilen, Übergaben synchronisieren und bei Störungen auf manuelle Abläufe zurückfallen können.
Genau dieser Rückfallbetrieb ist der Punkt, den wir in Projekten am hartnäckigsten prüfen. Was passiert, wenn das automatische Lager stillsteht – gibt es einen definierten Notbetrieb, sind die Bestände im automatischen Bereich manuell erreichbar, kann das System Aufträge umlenken? Automatisierung erhöht die Leistung und senkt die Fehlerquote, sie erhöht aber auch die Abhängigkeit von einem einzelnen Element. Ein Konzept für den Ausfall ist deshalb Teil des Projekts, nicht eine Nachbetrachtung.
Für die Anbindung autonomer Fahrzeuge und moderner Behälterlager haben sich standardisierte Schnittstellen etabliert, die die Kopplung zwischen Leitsystem und Fahrzeugflotte erleichtern. Das ist eine gute Entwicklung, weil sie Anbieterwechsel auf der Fahrzeugseite denkbar macht. Zu prüfen bleibt, welche Standards das jeweilige System in welcher Tiefe unterstützt und ob die Flottensteuerung beim WMS, beim Fahrzeuganbieter oder in einer eigenen Schicht liegt. Diese Zuständigkeitsfrage sollte vor der Beschaffung geklärt sein.
Unsere Empfehlung ist bewusst zurückhaltend und lässt sich auf vier Fragen verdichten. Erstens: Welche Entscheidung trifft die Funktion konkret, und bleibt sie nachvollziehbar? Wenn ein Auftrag anders priorisiert oder ein Artikel umgelagert wird, will man den Grund erkennen können – nicht aus Misstrauen, sondern weil man im Störungsfall handeln muss. Zweitens: Welche Datenmenge braucht das Verfahren, um belastbar zu sein? Muster erkennen setzt Muster voraus; bei kleinen Auftragsmengen liefern lernende Verfahren oft nur teure Zufälligkeit.
Drittens: Welche Daten werden verarbeitet, wo, und werden sie zur Modellverbesserung genutzt? Bewegungsdaten aus dem Lager enthalten regelmäßig Personenbezug über Bediener- und Gerätekennungen, und Auftragsdaten enthalten Kundendaten. Diese Frage gehört in den Vertrag, nicht in die Präsentation. Viertens: Was passiert, wenn die Funktion abgeschaltet wird? Ein Betrieb, der ohne das Modell nicht mehr arbeiten kann, hat ein Verfügbarkeitsproblem geschaffen. Wir empfehlen, jede solche Funktion zunächst begleitend und messbar einzuführen, mit einem Vergleich gegen den bisherigen Ablauf – und sie erst dann scharf zu schalten, wenn der Vorteil belegt ist.
Die wichtigste Integrationsentscheidung in jedem WMS-Projekt ist nicht technisch, sondern konzeptionell: Welches System führt den Bestand? Es gibt zwei saubere Antworten und eine schlechte. Die erste saubere Antwort: Das ERP führt einen summarischen Bestand je Artikel und Lagerort, das WMS führt den lagerplatzgenauen Bestand und meldet Veränderungen zurück. Die zweite: Das WMS ist bestandsführend und das ERP führt nur die kaufmännische Sicht. Die schlechte Antwort ist eine ungeklärte Doppelführung mit gegenseitigen Korrekturbuchungen – sie erzeugt Differenzen, die niemand mehr auflösen kann.
Technisch laufen ERP-Anbindungen über einen überschaubaren Satz an Nachrichten: Artikelstamm und Stammdatenänderungen, Lieferantenavis und Wareneingangsmeldung, Auslieferungsaufträge und Rückmeldung der Kommissionierung, Bestandskorrekturen und Inventurergebnisse, Umlagerungen zwischen Standorten. Für die Bewertung sind vier Punkte entscheidend: die Vollständigkeit dieses Nachrichtensatzes, die Behandlung von Teilmengen und Fehlmengen, das Verhalten bei Verbindungsabbrüchen mit Wiederaufsetzpunkt, und die Nachvollziehbarkeit über ein Protokoll, in dem Fachanwender selbst nachsehen können, warum eine Nachricht nicht verarbeitet wurde.
Im SAP-Umfeld hat inconso historisch eine besondere Rolle, weil es sowohl eigene Lagerverwaltung mit SAP-Anbindung als auch Lösungen innerhalb der SAP-Welt gab. Für Unternehmen mit SAP-Landschaft stellt sich damit eine Grundsatzfrage, die wir im Wettbewerbskapitel aufgreifen: Lagerverwaltung im SAP-Standard oder daneben in einem Spezialsystem. Beide Wege sind vertretbar; die Entscheidung hängt an Automatisierungsgrad, Prozesstiefe, IT-Strategie und vorhandenem Know-how, nicht an einer allgemeinen Überlegenheit.
Nach unten hin ist die Integrationsleistung eines WMS oft der eigentliche Kaufgrund. Regalbediengeräte, Sorter, Shuttlesysteme, Palettierer, Verpackungsanlagen, Etikettierer, Waagen und Volumenmessgeräte müssen angesteuert und in den Auftragsfluss eingebunden werden. Anbieter mit langer Projektgeschichte in automatisierten Lagern bringen dafür erprobte Bausteine mit – das verkürzt Projekte deutlich, weil Schnittstellen nicht neu erfunden werden müssen. Fragen Sie deshalb nach konkreten Referenzen mit dem Anlagentyp, den Sie einsetzen oder planen, nicht nach der Zahl der unterstützten Protokolle.
Bei Behälterlagersystemen wie AutoStore und bei autonomen mobilen Robotern liegt der Kern in der Zuständigkeitsverteilung. Diese Systeme bringen eigene Steuerungen und Flottenmanager mit, die interne Optimierungen selbst übernehmen. Das WMS erteilt Aufträge und erhält Rückmeldungen, greift aber nicht in die Feinsteuerung ein. Diese Arbeitsteilung ist sinnvoll, muss aber vertraglich und technisch scharf gezogen sein: Wer entscheidet über Auftragsreihenfolgen, wer über Behälterzuordnung, wer über Priorisierung im Störungsfall, und wo werden Leistungsdaten für die Auswertung zusammengeführt.
Ein Punkt, der in Angeboten selten steht und im Betrieb regelmäßig weh tut: Testbarkeit. Anlagenintegration lässt sich nur begrenzt am Schreibtisch prüfen, aber ein Simulator oder Emulator für die Anlagenseite ist Gold wert – für Abnahmetests, für Schulungen und für spätere Änderungen. Fragen Sie, ob eine solche Umgebung verfügbar ist und was sie kostet. Ohne Testumgebung wird jede Änderung an einem automatisierten Lager zu einem Eingriff im Produktivbetrieb, und das will man vermeiden.
Neben ERP und Anlagen gibt es eine Reihe weiterer Anbindungen, die im Projektumfang gerne vergessen werden. Paket- und Speditionsdienstleister mit Labelerzeugung und Statusrückmeldung. Zoll- und Außenhandelssysteme, wenn Lager Zollgut führen. Kunden- und Lieferantenportale für Bestands- und Statusabfragen. Etiketten- und Dokumentendruck mit Layoutvarianten je Kunde. Betriebsdatenerfassung und Instandhaltung. Und schließlich die Datenanalyse: Für belastbare Kennzahlen sollten Bewegungsdaten in ein Auswertewerkzeug oder eine Datenplattform übertragbar sein, ohne dass jede Abfrage im Produktivsystem läuft.
Für all diese Anbindungen gilt derselbe Prüfmaßstab: Existiert ein dokumentierter, versionierter Schnittstellenweg, oder entsteht eine Individuallösung? Individuallösungen sind nicht grundsätzlich falsch – im Logistikumfeld sind sie oft unvermeidlich –, aber sie müssen benannt, dokumentiert und im Wartungsvertrag berücksichtigt sein. Die unangenehmen Überraschungen in WMS-Projekten entstehen selten im Standard und fast immer an den Rändern, die niemand aufgeschrieben hat.
Für Unternehmen mit SAP-Landschaft ist die Alternative meist nicht inconso gegen ein anderes Spezialsystem, sondern Spezialsystem gegen SAP-Standard. Für SAP EWM spricht die Durchgängigkeit: ein Datenmodell, eine Benutzerverwaltung, keine Bestandsschnittstelle im engeren Sinne, eine einheitliche Betriebs- und Wartungsstrategie und ein großer Markt an Beratern. Wer eine konsequente SAP-Strategie fährt und ohnehin eine Transformation der Kernsysteme vor sich hat, hat gute Gründe, die Lagerverwaltung dort zu verankern.
Dagegen sprechen zwei Erfahrungen. Erstens der Einführungsaufwand: EWM ist mächtig, aber anspruchsvoll in Konfiguration und Betrieb und verlangt spezialisiertes Wissen, das im Mittelstand selten intern vorhanden ist. Zweitens die Prozesstiefe in Sonderfällen und die Nähe zur Anlagentechnik – hier haben spezialisierte WMS-Anbieter mit langer Automatisierungshistorie oft mehr Erprobtes im Gepäck. Unsere Erfahrung: Je automatisierter das Lager und je untypischer die Prozesse, desto stärker das Argument für ein Spezialsystem. Je standardisierter das Lager und je konsequenter die SAP-Strategie, desto stärker das Argument für den Standard.
Eine dritte Überlegung wird häufig übersehen: Verfügbarkeit und Betriebsrisiko. Ein Lager, das an einem zentralen ERP hängt, steht bei einer ERP-Störung still, wenn keine Entkopplung vorgesehen ist. Ein eigenständiges WMS kann bei Ausfall des Vorsystems eine Zeit lang autark weiterarbeiten, wenn die Aufträge vorliegen. Für Betriebe mit Schichtbetrieb und engen Auslieferterminen ist das ein handfestes Argument, das in Architekturdiskussionen mehr Gewicht verdient, als es meist bekommt.
PSI Logistics ist im DACH-Markt der strukturell nächste Verwandte: deutscher Anbieter, Erfahrung in Lager und Transport, Nähe zur Anlagentechnik, vergleichbare Projektkultur. Die Unterschiede zwischen zwei Anbietern dieses Typs lassen sich nicht auf allgemeiner Ebene entscheiden. Sie zeigen sich in drei Dingen: in der Prozesstiefe für die eigenen Sonderfälle, in Referenzen mit vergleichbarer Branche und Anlagentechnik und in der personellen Verfügbarkeit für Projekt und Betreuung. Deshalb empfehlen wir bei dieser Konstellation immer eine strukturierte Prozess-Demonstration an echten Fällen statt einer Papierbewertung.
Manhattan Associates kommt aus dem internationalen Handels- und Distributionsumfeld und bringt ein sehr breites Portfolio mit ausgeprägter Cloud-Ausrichtung und Stärken im Omnichannel-Geschäft. Für Konzerne mit vielen Standorten und einheitlichem Prozessanspruch ist das ein starkes Profil. Für einen einzelnen mittelständischen Standort mit gewachsenen Sonderprozessen ist der Zuschnitt eher groß, und die Philosophie ist stärker auf Standardnutzung als auf individuelle Ausgestaltung ausgelegt – was Vorteile hat, aber Anpassungsbereitschaft im Prozess verlangt.
Blue Yonder hat den Ursprung in Planung und Prognose und wurde später um Ausführungsfunktionen erweitert. Die Stärke liegt entsprechend dort, wo Planung und Ausführung zusammenhängen: Bedarfsprognose, Bestandsoptimierung, Filialbelieferung, Personaleinsatzplanung. Wer primär ein leistungsfähiges System für ein automatisiertes Lager sucht, bewertet andere Kriterien; wer eine durchgängige Kette von Prognose bis Ausführung über viele Standorte braucht, findet hier ein passendes Profil. Auch hier gilt: Der Zuschnitt richtet sich eher an größere Organisationen.
Die ehrlichste Abgrenzung betrifft nicht die großen Wettbewerber, sondern die Frage, ob überhaupt ein eigenes WMS nötig ist. Für überschaubare Lager mit wenigen tausend Artikeln, moderatem Auftragsvolumen, ohne Automatisierung, ohne Chargenpflicht und ohne Mandantenanforderung leistet ein gut konfiguriertes Lagermodul im ERP häufig genug – und spart Schnittstelle, zweite Wartung und zweite Schulung. Der Wechselpunkt liegt dort, wo Strategien, Durchsatz, Anlagenanbindung, Rückverfolgbarkeit oder Mandantenfähigkeit die Möglichkeiten des ERP-Moduls überschreiten.
Typische Auslöser aus unseren Projekten: Die Kommissionierleistung reicht in Spitzenzeiten nicht mehr, Fehlerquoten steigen, Inventurdifferenzen nehmen zu, neue Kunden verlangen Nachweise, die das ERP nicht liefert, eine Automatisierungsinvestition steht an, oder ein zweiter Standort soll einheitlich geführt werden. Wer diese Auslöser erkennt, sollte den Wechsel planen, bevor der Druck zu groß ist – ein WMS-Projekt unter akutem Leidensdruck ist teurer und riskanter als ein geplantes.
Die Betriebsfrage wird im Lagerumfeld anders beantwortet als in der Bürowelt, und der Grund ist physisch: Ein Lager ohne funktionierendes WMS steht still. Deshalb ist die Netzanbindung eine zentrale Größe. Wer ein automatisiertes Lager mit sekundengenauer Anlagensteuerung betreibt, wird die zeitkritischen Teile nahe an der Anlage halten – Latenz und Ausfallsicherheit sind hier keine akademischen Themen. Wer ein überwiegend manuelles Lager mit Handhelds führt, kann Cloud-Betrieb gut nutzen, sollte aber eine redundante Anbindung und ein definiertes Verhalten bei Netzausfall einplanen.
Für den Cloud-Betrieb sprechen die bekannten Argumente: weniger eigene Infrastruktur, geplante Releasewechsel, Überwachung durch den Anbieter, planbare laufende Kosten, schnellere Bereitstellung von Testumgebungen. Für On-Premises sprechen vollständige Kontrolle über Zeitpunkt von Änderungen, Unabhängigkeit von der Internetverbindung, die Möglichkeit, das System im Notbetrieb autark zu fahren, und in manchen Fällen Vorgaben aus Konzernrichtlinien. Beides ist vertretbar. Was nicht funktioniert, ist eine Entscheidung ohne Blick auf die Ausfallszenarien.
Ein Hinweis, der für deutsche und europäische Anbieter besonders relevant ist: Wenn Cloud-Betrieb gewählt wird, lohnt die konkrete Frage nach dem Serverstandort, nach der eingesetzten Infrastruktur und nach den beteiligten Unterauftragnehmern. Ein Betrieb in einem Rechenzentrum in Deutschland oder der EU ist für viele Unternehmen ein Kriterium – aus Compliance-Vorgaben, aus Kundenanforderungen oder aus einer bewussten Souveränitätsstrategie. Dass ein Anbieter europäisch verankert ist, macht diese Prüfung leichter, ersetzt sie aber nicht.
Ein WMS verändert die Arbeit jedes Menschen im Lager. Wege werden anders vorgegeben, Reihenfolgen anders bestimmt, Quittierungen verlangt, wo vorher Erfahrung genügte. Wer jahrelang wusste, wo etwas liegt, empfindet ein System, das ihm den Weg vorschreibt, zunächst als Kontrollverlust. Diese Reaktion ist normal und lässt sich nicht durch Ankündigungen auflösen, sondern nur durch Beteiligung: Die erfahrenen Mitarbeitenden gehören in die Konzeptphase, nicht erst in die Schulung. Sie kennen die Sonderfälle, an denen Projekte scheitern.
Praktisch bewährt haben sich vier Dinge. Erstens Schulung an echten Geräten in der echten Umgebung statt am Schreibtisch – Handhelds mit Handschuhen bedienen ist etwas anderes als Klicken am Bildschirm. Zweitens Schlüsselanwender je Bereich, die früher geschult werden und im Betrieb erste Anlaufstelle sind. Drittens mehrsprachige Dialoge und Schulungsunterlagen, wo die Belegschaft mehrsprachig ist – ein banaler Punkt mit großer Wirkung auf Fehlerquoten. Viertens eine Hypercare-Phase mit Anwesenheit im Lager, in der Probleme sofort aufgenommen werden, statt über Tickets zu wandern.
Ebenso wichtig ist eine realistische Erwartung an die erste Zeit nach der Umschaltung. Die Leistung sinkt zunächst, weil Abläufe neu sind – das ist keine Fehlfunktion, sondern Lernkurve. Wer diese Phase nicht einplant und in der Hochsaison umschaltet, erzeugt genau die Krisenstimmung, die Projekte in Verruf bringt. Wir empfehlen deshalb: Umschaltung in einer ruhigen Periode, reduzierte Auftragsmengen in den ersten Tagen, zusätzliches Personal für die Anlaufphase und eine offene Kommunikation darüber, dass es zwei bis vier Wochen dauern wird.
Eine ehrliche Einordnung zuerst: Lösungen mit Projektcharakter entfalten ihren Wert dort, wo Prozesse nicht trivial sind. Ein Lager mit tausend Artikeln, gleichmäßigem Auftragseingang und ohne besondere Anforderungen wird von einem tief konfigurierbaren System nicht wirtschaftlich profitieren – hier gewinnt Einfachheit. Umgekehrt gilt: Sobald Chargenführung, Zonenlogik, Automatisierung, Mandantenfähigkeit oder hohe Spitzenlast ins Spiel kommen, zahlt sich Tiefe aus, weil man sonst mit Nebenlisten und Handarbeit arbeitet, die niemand auswertet.
Die zweite Größe ist die interne Kapazität. Ein leistungsfähiges WMS braucht eine benannte Person im Unternehmen, die es versteht – nicht in Vollzeit, aber verlässlich. Diese Person pflegt Strategien, betreut Stammdaten, koordiniert Releasewechsel und ist erster Ansprechpartner im Störungsfall. Fehlt sie, wandert jede Kleinigkeit als bezahlter Auftrag zum Dienstleister, und die Betriebskosten steigen unauffällig, aber stetig. Diese Rolle sollte im Projektauftrag stehen, mit Namen und Zeitanteil.
Die dritte Überlegung ist die Wachstumsperspektive. Wer in drei Jahren einen zweiten Standort, ein automatisiertes Lager oder ein deutlich höheres Auftragsvolumen erwartet, sollte heute eine Architektur wählen, die das mitträgt. Ein System zu wechseln ist erheblich teurer, als es von Anfang an eine Nummer größer zu wählen. Umgekehrt ist es keine gute Idee, eine Architektur für eine Zukunft zu bauen, die niemand konkret benennen kann – die realistische Mitte ist eine Lösung, die den heutigen Bedarf sauber abdeckt und einen benannten Ausbaupfad hat.
Im Mittelstand stellt sich regelmäßig die Frage, ob man alle Logistikschichten bei einem Anbieter bezieht oder gezielt kombiniert. Unsere Position: Bei Lagerverwaltung und Materialflussrechner spricht viel für einen Anbieter, weil die beiden Schichten im Betrieb untrennbar zusammenwirken und die Fehlersuche sonst zur Schuldfrage wird. Bei Transportmanagement und Zeitfensterbuchung ist eine Kombination unproblematischer, weil die Kopplung über klar abgegrenzte Nachrichten läuft und die Marktangebote hier stärker vergleichbar sind.
Was in jedem Fall zur Entscheidung gehört, ist die Frage nach dem Datenexport. Unabhängig davon, wie viele Systeme im Einsatz sind: Die eigenen Stamm- und Bewegungsdaten müssen in strukturierter Form und in vollständigem Umfang exportierbar sein, vertraglich zugesichert und praktisch getestet. Das ist keine Misstrauensfrage, sondern Investitionsschutz – und der beste Zeitpunkt, es zu verhandeln, ist vor der Unterschrift.
Die Gesamtkosten einer Logistiksuite entstehen aus vier Blöcken, die nur zusammen ein Bild ergeben. Der erste ist die Lizenz oder das Abonnement, üblicherweise nach Modulen, Nutzern, Standorten und Mengenklassen bemessen. Der zweite ist der Projekt- und Integrationsaufwand für Konzept, Konfiguration, Schnittstellen, Anlagenanbindung, Test, Datenübernahme und Schulung – in Lagerprojekten häufig der größte Einmalposten. Der dritte ist Betrieb und Wartung mit Support, Hosting, Releasepflege und Testumgebungen. Der vierte ist der interne Aufwand: Projektmitarbeit der Fachbereiche, Stammdatenpflege, Systembetreuung, Nachschulung.
Für eine belastbare Betrachtung empfehlen wir eine Rechnung über fünf bis zehn Jahre, weil Lagersysteme lange laufen und ein Wechsel teuer ist. In diese Rechnung gehören Wachstum und Veränderung: mehr Artikel, mehr Aufträge, ein zweiter Standort, eine Automatisierungsstufe, neue Kundenanforderungen an Nachweise. Und es gehört die Gegenrechnung dazu, die im Lager ungewöhnlich gut greifbar ist: eingesparte Wege, höhere Kommissionierleistung je Stunde, geringere Fehlerquote und damit weniger Retouren und Gutschriften, kürzere Inventuren, geringere Bestände durch bessere Transparenz, vermiedene Wartezeiten im Wareneingang.
Ein Hinweis zur Vorsicht bei Angebotsvergleichen: Angebote verschiedener WMS-Anbieter sind selten direkt vergleichbar, weil Leistungsschnitte unterschiedlich sind – manche kalkulieren Schnittstellen pauschal, andere je Nachricht, manche schließen Testumgebungen ein, andere nicht, manche rechnen Schulung mit, andere separat. Wir empfehlen deshalb, das eigene Mengen- und Prozessgerüst als verbindliche Anfragegrundlage zu formulieren und jeden Anbieter genau darauf antworten zu lassen. Erst dann vergleicht man Äpfel mit Äpfeln – und erkennt, wer die eigenen Sonderfälle wirklich verstanden hat.
Dass eine Logistiksuite in Deutschland entwickelt wurde und in einem europäisch geführten Konzern liegt, ist im aktuellen Umfeld mehr als ein Sympathiepunkt. Es bedeutet europäischer Rechtsrahmen als Ausgangslage, Vertragsunterlagen auf hiesige Verhältnisse zugeschnitten, deutschsprachige Ansprechpartner in Projekt und Support, Dokumentation in der Sprache der Anwender und die Möglichkeit, den Betrieb in einem Rechenzentrum in Deutschland oder der EU zu verankern. Für Unternehmen mit Compliance-Vorgaben, mit Kunden aus dem öffentlichen Sektor oder mit einer bewussten Souveränitätsstrategie ist das ein Argument, das über Funktions- und Preisvergleiche hinausgeht.
Ergänzend ist die On-Premises-Option der stärkste Hebel für Datenhoheit: Wenn das System im eigenen Rechenzentrum läuft, bleiben Bestands-, Auftrags- und Personendaten physisch im eigenen Zugriff, und der Anbieter erhält nur für definierte Supportfälle Zugang. Das ist im Lagerumfeld ohnehin oft die technisch sinnvollere Variante, weil zeitkritische Anlagensteuerung nahe an der Anlage liegen sollte. Wer diesen Weg wählt, tauscht Bequemlichkeit gegen Kontrolle – und sollte den Aufwand für Betrieb, Sicherung und Notfallvorsorge ehrlich einplanen.
Gleichzeitig ersetzt Herkunft keine Prüfung. Drei Fragen gehören in jede Klärung. Erstens: Wo genau werden Daten verarbeitet und gesichert, auf welcher Infrastruktur, und wer sind die Unterauftragnehmer – auch bei Zusatzdiensten wie Auswertung, Fernwartung oder KI-Funktionen. Zweitens: Wie sind Zugriffe zu Supportzwecken geregelt, begrenzt und protokolliert, und wie werden sie beendet. Drittens: Welche Daten verlassen das System für Analyse- oder Verbesserungszwecke, und lässt sich das abschalten. Diese Fragen lassen sich vor der Unterschrift klären; danach sind sie deutlich unangenehmer.
Ein Aspekt, der Logistiksoftware von vielen anderen Systemen unterscheidet: Jede Buchung im Lager trägt eine Bedienerkennung. Damit entsteht ohne besondere Absicht eine sehr detaillierte Leistungshistorie je Person – Zeitpunkte, Mengen, Fehler, Wege. Diese Daten sind für Betriebssteuerung wertvoll und aus Sicht der Beschäftigten sensibel. Der arbeitsrechtlich und praktisch tragfähige Weg führt über frühe Beteiligung: Zweck der Erhebung festlegen, Auswertungstiefe begrenzen, aggregierte Sichten bevorzugen, Fristen für die Aufbewahrung setzen und eine Vereinbarung mit dem Betriebsrat treffen, bevor die Funktion aktiv ist.
Dasselbe gilt für Zusatzmodule wie Personaleinsatzplanung oder Leistungsentlohnung und für Yard-Funktionen, in denen Fahrerdaten, Kennzeichen und Aufenthaltszeiten auf dem Gelände verarbeitet werden. Auch hier gehört die Verarbeitung in das Verzeichnis, und Betroffene müssen informiert werden. Unsere Erfahrung: Projekte, die diese Punkte offen und früh behandeln, werden von der Belegschaft akzeptiert. Projekte, in denen die Auswertungsmöglichkeiten später entdeckt werden, erzeugen Misstrauen, das den fachlichen Nutzen jahrelang beschädigt.
