„Dafür haben wir dieses Jahr keine Kapazität." Dieser Satz aus der IT stoppt Automatisierungsprojekte, die operativ längst entschieden sind - und er fällt fast immer, bevor jemand den Aufwand sauber gerechnet hat. Ein AMR-Retrofit bindet 10 bis 15 IT-Entwicklungstage über rund vier Wochen. Bei fest verbauter Automatisierung lässt sich eine vergleichbare Zahl häufig erst nach Vertragsschluss ermitteln. Woran das liegt, wer welchen Teil des Aufwands trägt und wie sich beides für eine Freigaberunde beziffern lässt, klärt dieser Artikel.
Die IT entscheidet mit, auch wenn sie das Projekt nicht anstößt
Ein Projekt zur Lagerautomatisierung hat im Mittelstand selten weniger als sechs Stakeholder am Tisch: Standort- oder Logistikleitung, Geschäftsführung, CFO, Einkauf - und die IT. Angestoßen wird es fast immer von der operativen Seite, die Personalmangel und Peaks täglich spürt. Genehmigt wird es nur, wenn keine dieser Rollen ihr Veto einlegt.
In der Praxis hat der IT-Lead genau dieses Veto. Ein Projekt, das die Logistikleitung begeistert und die IT abschreckt, kommt nicht durch die Freigabe, und die Bedenken müssen dafür nicht einmal ausformuliert werden. Die Kapazität ist im Mittelstand real knapp: Dieselbe kleine Abteilung betreut ERP, WMS, Versandsysteme und das Tagesgeschäft parallel, im IT-Lead oft in Personalunion mit der Systemverantwortung. Jeder Tag, den ein Projekt bindet, fehlt in einem Kalender, der ohnehin schon verplant ist.
Deshalb lautet die entscheidende Frage der IT selten „ist das technisch gut?", sondern „wie tief greift das in meine Landschaft ein, und wie viele Personentage kostet es mich?". Wer darauf keine belastbare Antwort hat, bekommt kein Ja - unabhängig davon, wie überzeugend der Business Case für alle anderen ist.
Warum die Zahl bei vielen Anbietern vor der Entscheidung nicht vorliegt
Die verbreitete Annahme ist, dass Anbieter den IT-Aufwand kleinreden. Oft liegt es an etwas anderem: Sie können ihn zum Zeitpunkt der Entscheidung schwer belegen, weil die Grundlage dafür vertraulich ist.
Die Spezifikation kommt nach der Unterschrift
Bei cube-basierten Grid-Lagern ist die Schnittstellendokumentation üblicherweise nicht frei zugänglich. Verbreitet ist, dass ein Anbieter die Spezifikation erst nach einer Geheimhaltungsvereinbarung herausgibt und die Entwicklerdokumentation hinter einem Login liegt. Für die interne IT heißt das: In genau der Phase, in der sie eine Aufwandsschätzung abgeben soll, fehlt ihr häufig die Grundlage, um sie zu prüfen. Sie ist dann auf die Angabe des Anbieters angewiesen, statt sie nachrechnen zu können.
Bei Shuttle- und AKL-Anlagen liegt die Anbindung eine Ebene tiefer, auf Steuerungsebene. Dort werden Telegrammstrukturen je Lager, Schnittstellentyp und Gerätetyp definiert, und ein realistischer Test verlangt in der Regel Stillstand im Lager. Beides schätzt eine Mittelstands-IT selten aus dem Stand ein.
Der Markt für Konnektoren ist der eigentliche Beleg
Allein im deutschsprachigen Raum verkaufen mehrere Softwarehäuser die Anbindung eines Cube-Lagers als eigenes Produkt - zum Festpreis, mit dem ausdrücklichen Versprechen, dass zeitaufwändige Softwareentwicklung damit entfällt. Um eine Schnittstelle, die in zwei Wochen gebaut ist, entsteht selten ein eigener Produktmarkt. Ein deutsches Softwarehaus beschreibt seine eigene Anbindung öffentlich als Jahresprojekt seines größten Entwicklerteams, bewusst ohne Middleware - ein einzelner Fall, aber ein dokumentierter.
Das ist keine Kritik an der Technologie. Cube- und Shuttle-Systeme lösen Dichte- und Durchsatzprobleme, die ein Retrofit nicht löst, und wer diese Probleme hat, trifft mit ihnen die richtige Wahl. Es ist eine Aussage über die Planbarkeit: Der IT-Aufwand dieser Architekturen ist vor der Entscheidung schwerer greifbar, und er taucht in der Freigaberunde deshalb eher als Risiko auf denn als kalkulierte Position.
Prüfbarkeit als Auswahlkriterium
Für die Anbieterauswahl ist damit weniger interessant, welche Zahl jemand nennt, als woran sie sich vorab überprüfen lässt.
| Prüfpunkt vor Vertragsschluss | Fest verbaute Automatisierung | AMR-Retrofit |
|---|---|---|
| Schnittstellenspezifikation | Häufig erst nach Vertragsschluss, unter Geheimhaltung | Dokumentiert, vorab einsehbar |
| Eigener Test möglich | Meist erst mit Projektstart, oft über Emulation des Integrators | Sandbox mit identischem Schnittstellenvertrag |
| Wer baut die Anbindung | Integrator oder zugekaufter Konnektor | Eigenes IT-Team gegen dokumentierte API |
| Form der Aufwandsangabe | Überwiegend Projektlaufzeit in Monaten | Entwicklungstage auf Kundenseite |
Die Spalten beschreiben das verbreitete Muster, nicht jeden Einzelfall - es gibt Integratoren, die früh sehr transparent arbeiten. Genau deshalb lohnt es sich, diese vier Punkte in jedem Anbietergespräch abzufragen, lange bevor über Preise gesprochen wird. Ein Anbieter, der die Spezifikation vorab herausgibt, macht seine Aufwandsangabe überprüfbar.
Wo die Logik landet - der Aufwandstreiber, den kein Angebot ausweist
Der zweite Block hat mit Programmierung wenig zu tun und mit Zuständigkeit viel. Er entscheidet, ob nach dem Projekt ein System mehr im Haus steht, das jemand betreuen muss.
Bei cube-basierten Systemen ist die mitgelieferte Steuerungssoftware typischerweise kein vollwertiges Lagerverwaltungssystem. Die Inhalte der Behälter werden dann im WMS des Kunden geführt und gesichert, und jede Bewegung wird von einem übergeordneten System angestoßen. Je nach gewählter Schnittstellenebene können zusätzlich Gruppierung, Behältervorbereitung und Optimierungslogik dorthin wandern. Aus einer Anbindung wird in diesem Fall eine Erweiterung des eigenen Systems - mit allem, was das über die Jahre an Pflege bedeutet.
Bei einem AMR-Retrofit bleibt das WMS das führende System. Die Orchestrierungssoftware übersetzt dessen Aufträge in Roboterlogistik und meldet jeden Pick zurück; es entsteht keine zweite Bestandsführung, die mit der ersten synchron gehalten werden muss. Welche Schnittstellen-Typen dafür in Frage kommen und wie die Anbindung technisch abläuft, beschreibt der Artikel zur WMS-Anbindung im Detail. Für die Aufwandsfrage zählt nur die Konsequenz: Was nicht ins eigene System wandert, muss dort auch nicht gewartet werden.
Wer stellt was
Der einzelne Aufwandsblock sagt noch nichts darüber, wer ihn trägt. Für die IT-Planung ist genau diese Aufteilung entscheidend, denn nur der eigene Anteil belastet das eigene Team.
Was der Anbieter übernimmt
Auf der Anbieterseite liegt der Löwenanteil der Vorarbeit: die dokumentierte API-Spezifikation, eine Mapping-Vorlage für die Datenfelder, vorbereitete Testszenarien, eine Sandbox mit identischem Verhalten und die Hypercare-Begleitung in den ersten Wochen nach dem Go-live. Dazu kommt die Orchestrierungssoftware selbst - bei NEO ist das NEO:os, das als Schicht zwischen bestehendem WMS und Roboterflotte arbeitet, nicht als zweites, konkurrierendes Lagerverwaltungssystem. Wie die NEO-Plattform aus Software, Roboterflotte und Kommissionierstation aufgebaut ist, zeigt die Plattform-Seite.
Was Ihr Team stellt
Der Kundenanteil ist klar umrissen, aber er ist zu einem guten Teil Entwicklungsarbeit. Ihr Team baut den Client gegen die dokumentierte Schnittstelle, bildet die Datenfelder des eigenen WMS auf das Auftrags- und Rückmeldeformat ab und implementiert Fehlerbehandlung und Wiederanlauf. Dazu kommen die Punkte, die keine Programmierung sind: Zugang zum WMS und ein fester Ansprechpartner, die Klärung von Fragen zum Artikelstamm, die Freigabe der Testfälle - und die interne IT-Sicherheitsprüfung. Dieser letzte Punkt wird gern unterschätzt. Wenn eine externe Software an das WMS andockt, will die IT-Sicherheit Authentifizierung und Datenzugriff prüfen, und dieser Freigabeprozess hat in vielen Häusern seine eigene Vorlaufzeit. Er gehört an den Anfang des Projekts, nicht ans Ende, sonst wird aus einem Ein-Tages-Review der Engpass kurz vor dem Go-live.
Insgesamt summiert sich der Kundenanteil bei einem AMR-Retrofit auf 10 bis 15 IT-Entwicklungstage, verteilt über rund vier Wochen Kalenderzeit. Die Differenz zwischen beiden Zahlen ist der entscheidende Punkt für die Planung: Die Personentage sind die tatsächliche Arbeit, die vier Wochen sind der Zeitraum, in dem sie anfällt - mit Wartezeiten, Freigabeschleifen und Testläufen dazwischen. Wer die vier Wochen als Vollauslastung eines Mitarbeiters liest, überschätzt den Aufwand um mehr als das Doppelte.
Was bei einem Retrofit nicht anfällt
Ebenso wichtig ist die Liste dessen, was gar nicht erst zur Debatte steht. Ein AMR-Retrofit verlangt keinen Wechsel des WMS, keine Wartung eines Materialflussrechners, keine SPS-Anbindung und kein Customizing der bestehenden Systeme. Genau diese Posten machen bei klassischen Automatisierungsprojekten den größten Teil des IT-Aufwands aus und sind ein wesentlicher Treiber der 12 bis 36 Monate, die solche Systeme bis zum Go-live brauchen.
Brutto gegen Netto
Bis hierhin steht nur die Bruttozahl: der Projektaufwand für die Einführung. Für eine ehrliche Bewertung fehlt der Gegenposten, und der wird in fast jeder Aufwandsschätzung übersehen.
Manuelle Kommissionierung ist für die IT nicht kostenlos. Excel-Workarounds, die jemand pflegt und repariert. Bestandskorrekturen, wenn WMS und Realität auseinanderlaufen. Scanner-Support, Schnittstellen zu Versanddienstleistern, wiederkehrende Sonderauswertungen für die Peak-Planung. Diese Last taucht in keinem Projektplan auf, weil sie schon da ist, aber sie bindet laufend Kapazität.
Nach dem Go-live sinkt ein Teil dieser Daueraufgaben, weil die Automatisierung Bestände in Echtzeit führt und Fehlerquellen schließt. Die 10 bis 15 Tage sind damit Projektlast, keine Dauerlast. Wer nur die Bruttozahl in die Freigaberunde trägt, argumentiert gegen sich selbst. Die belastbare Größe ist der Netto-Aufwand: Projekttage minus der Kapazität, die der Status quo heute schon verschlingt.
Was nach dem Go-live bleibt
Die Aufwandsdiskussion endet in den meisten Angeboten am Go-live. Der laufende Anteil entscheidet aber darüber, ob die Rechnung nach drei Jahren noch stimmt.
Steht eine eigene Steuerungs- oder Middleware-Schicht zwischen WMS und Anlage, laufen Lizenz-, Support- und Upgradeverträge über die Lebensdauer des Systems mit. Beide Seiten sind dann versionsgekoppelt: Ein WMS-Release kann Anpassungen in der Zwischenschicht nach sich ziehen, und umgekehrt. Spätere Erweiterungen - eine zusätzliche Station, ein neuer Auftragstyp, ein weiterer Standort - laufen meist als Änderungsauftrag über den Integrator, weil das Wissen über die Schnittstelle dort liegt und nicht im eigenen Haus.
Bei einer gehosteten Orchestrierungsschicht mit versionierter Schnittstelle fällt dieser Block weitgehend weg. Updates laufen serverseitig, und die einmal aufgesetzte Anbindung trägt den Ausbau von einer auf mehrere Stationen ohne neuen Integrationsaufwand. Für die IT ist das der Unterschied zwischen einem Projekt, das abgeschlossen wird, und einem System, das dauerhaft im Betreuungsplan steht.
Wie die IT die Zahl in die Freigaberunde trägt
Die Zahlen stehen. Jetzt müssen sie in ein Format, das eine Geschäftsführung in einer Sitzung genehmigt.
Personentage, nicht Monate, nicht FTE
Ein Aufwand, der in Monaten angegeben wird, klingt nach einem gebundenen Mitarbeiter und lädt zu einem schnellen Nein ein. Derselbe Aufwand als „15 Personentage über vier Wochen, parallel zum laufenden Betrieb leistbar" ist eine Ressourcenentscheidung, die ein COO trifft, ohne die IT lahmzulegen. Die Einheit ist nicht kosmetisch, sie ist der Unterschied zwischen einer genehmigungsfähigen und einer blockierten Zahl. FTE-Angaben taugen hier nicht, weil sie eine Vollzeit-Abstellung suggerieren, die es nicht gibt.
Der Workshop vor der Genehmigung
Die belastbare Zahl entsteht nicht am Schreibtisch, sondern in einem gemeinsamen Termin zwischen der internen IT und dem technischen Team des Anbieters - und zwar vor der Genehmigung, nicht danach. Drei Punkte werden dort geklärt: die Schnittstellenspezifikation, der interne Aufwand in Personentagen und eine Timeline mit Meilensteinen. Das Ergebnis ist ein einseitiges Dokument, das der IT-Lead in die Freigaberunde mitnehmen kann. Keine Schätzung, sondern eine gemeinsam getragene Aufwandszusage.
Anbieter, die ihre Spezifikation ohnehin offenlegen, können diesen Termin früh anbieten. Wo die Dokumentation erst nach Vertragsschluss verfügbar ist, verschiebt sich der Workshop hinter die Entscheidung - und damit auch die Aufwandsklarheit.
Der Fallback, wenn selbst vier Wochen nicht passen
Manchmal ist die IT auch für vier Wochen verplant. Dann ist das Projekt nicht tot, es startet kleiner. Ein Pilot lässt sich ohne vollständige WMS-Integration betreiben, mit manueller Auftragsübergabe oder einer einfachen Datei-Anbindung. Die operative Seite sammelt reale Daten, die Vollintegration folgt, sobald IT-Kapazität frei wird. Der Aufwand wird so nicht vermieden, aber entkoppelt.
Die ehrliche Einordnung
Zwei Dinge gehören zu einer belastbaren Bewertung dazu, die in Anbietermaterial selten stehen.
Erstens sind 10 bis 15 Entwicklungstage kein Alleinstellungsmerkmal. Für die Anbindung einer modernen Roboter-API ist eine Größenordnung von zwei bis vier Entwicklerwochen marktüblich, und andere AMR-Anbieter bewegen sich in derselben Spanne. Der Unterschied liegt nicht im Zahlenwert, sondern darin, ob die Zahl vor der Unterschrift überprüfbar ist und ob nach dem Projekt eine zweite Bestandsführung im Haus steht.
Zweitens ist der stärkste Punkt für die IT struktureller Natur: Bei einem AMR-Retrofit bleibt die Regalstruktur unverändert. Fällt die Integration am Go-live-Tag aus, kommissioniert das Team manuell weiter, während der Fehler behoben wird. Das Sicherheitsnetz ist der bestehende manuelle Prozess, kein Notfallplan, der erst gebaut werden muss - wie dieser Rückfall im Detail abläuft, steht im Risiko-Katalog des Artikels zur WMS-Anbindung. Bei fest verbauten Architekturen gibt es diesen Weg zurück nach dem Umbau nicht.
Dass diese Rechnung im Mittelstand mit dünnen IT-Ressourcen besonders trägt, ist kein Zufall. Sie ist für diese Ausgangslage gebaut. Im Pay-per-Pick-Modell verschiebt sich zusätzlich das kommerzielle Risiko zum Anbieter, der Roboter, Station und Software stellt.
Nächster Schritt: den IT-Aufwand für Ihr Lager konkret machen
Der Marktüberblick „Lagerautomatisierung 2026" stellt die Architekturen mit ihren Integrations-, Zeit- und Risikoprofilen gegenüber - inklusive der IT-Dimension, die für die Freigabe zählt: Whitepaper herunterladen.
Wenn Sie mit einer belastbaren Aufwandsschätzung für Ihr eigenes WMS in die Freigaberunde wollen, klären wir Schnittstellen, Datenflüsse und den realistischen Zeitplan kostenlos in einem Termin: NEO im Einsatz sehen.