Wer als Fulfillment-Dienstleister startet, kommt in der Regel mit einer Warenwirtschaft und einem Lager aus. Sobald der zweite, dritte, zehnte Mandant dazukommt, wächst der Anspruch an die Software schneller als das ursprüngliche System mitwächst. Die Frage ist selten "welche Software fehlt komplett", sondern "welcher Baustein reicht nicht mehr für mehrere Kunden im selben Lager". Der folgende Überblick ordnet den Stack, bevor es an die konkreten Lücken geht.
01 - Die Bausteine des Software-Stacks
Der Software-Stack eines Fulfillment-Dienstleisters besteht aus Warenwirtschaft, Lagerverwaltung (WMS), Versand-, Abrechnungs- und Reporting-Werkzeugen. Jeder Baustein deckt einen eigenen Teil der Kette ab, von der Bestellung bis zur Rechnung - und jeder Baustein wird mit wachsender Mandantenzahl anspruchsvoller, weil aus "ein Kunde, ein Lager" plötzlich "viele Kunden, ein Lager, viele Verträge" wird.
- Warenwirtschaft (WaWi). Verwaltet Artikelstamm, Aufträge, Bestände und die Anbindung an Marktplätze und Shops. Sie ist die zentrale Datenquelle, aus der fast alle anderen Bausteine ihre Informationen ziehen.
- Lagerverwaltung (WMS). Steuert Kommissionierung, Packprozesse, Lagerplätze und Wareneingang im physischen Lager. Bei mehreren Mandanten im selben Lager entscheidet das WMS, ob Bestände und Prozesse pro Kunde sauber getrennt bleiben.
- Versandsoftware. Erzeugt Labels, wählt Versanddienstleister und liefert Trackingdaten zurück in Auftrag und Kundenkommunikation.
- Abrechnungswerkzeuge. Ermitteln die abrechenbaren Mengen je Mandant und Zeitraum - Pakete, Retouren, Sonderpositionen - als Grundlage für die Rechnungsstellung.
- Reporting. Verdichtet Rohdaten aus WaWi und WMS zu Kennzahlen: Versandleistung, SLA-Quote, Durchlaufzeit, Retourenquote - pro Mandant und pro Mitarbeiter.
In vielen Betrieben decken ein oder zwei Systeme mehrere dieser Bausteine gleichzeitig ab. Das ist kein Problem, solange die Datenqualität stimmt - wird aber zur Belastungsprobe, sobald Reporting und Abrechnung mandantenübergreifend zusammenlaufen müssen.
- Der Stack besteht aus WaWi, WMS, Versand, Abrechnung und Reporting - fünf Bausteine, fünf unterschiedliche Anforderungen.
- JTL-WaWi mit JTL-WMS oder JTL-FFN deckt Auftragsabwicklung und Lagerprozesse solide ab.
- Mandantenübergreifendes Reporting, SLA-Nachweis und Abrechnungsmengen sind in der Standardsoftware nicht vorgesehen.
- Eine read-only Reporting-Schicht schließt die Lücke, ohne WaWi oder WMS zu ersetzen.
02 - Die Rolle von JTL-WaWi, JTL-WMS und JTL-FFN
Was sie leisten. JTL-WaWi ist im deutschsprachigen Fulfillment-Markt eine der am weitesten verbreiteten Warenwirtschaften. Für Betriebe, die zusätzlich Lagerdienstleistungen für Dritte anbieten, ergänzt JTL-WMS die stationäre Kommissionierung mit Scannerprozessen und Lagerplatzverwaltung, JTL-FFN richtet sich an Fulfillment-Netzwerke mit mehreren Standorten. Zusammen deckt dieses Set die Kette von Auftragseingang bis Versandmeldung technisch solide ab.
Warum das die richtige Grundlage bleibt. Für die meisten JTL-Fulfillment-Dienstleister ist die Frage nicht, ob JTL-WaWi ausgetauscht werden muss, sondern was zusätzlich gebraucht wird, sobald mehrere Mandanten im selben System abgewickelt werden. Die Auftrags- und Lagerlogik selbst funktioniert - was fehlt, sind die Auswertungen, die aus dieser Logik pro Mandant und pro Mitarbeiter entstehen sollen.
- JTL-WaWi: Artikelstamm, Aufträge, Marktplatz- und Shopanbindung, Kern-Datenquelle für alles Weitere
- JTL-WMS: Kommissionierung per Scanner, Lagerplätze, Wareneingang im stationären Lager
- JTL-FFN: Fulfillment-Netzwerk-Logik für mehrere Standorte und externe Kommissionierleistung
03 - Wo die Standardsoftware für 3PL an Grenzen stößt
Was das Problem ist. JTL-WaWi und die zugehörigen Module sind für den Einzelbetrieb und den Handel konzipiert, nicht primär für den 3PL-Betrieb mit mehreren fremden Mandanten im selben System. Drei Lücken zeigen sich in der Praxis besonders häufig, sobald ein Fulfillment-Dienstleister über eine Handvoll Kunden hinauswächst.
Mandantenübergreifendes Reporting. Die Standardauswertungen der WaWi sind auf den Gesamtbetrieb ausgelegt, nicht auf die saubere Trennung nach Mandant. Wer wissen will, wie viele Pakete Mandant A gestern versendet hat und wie das im Vergleich zu Mandant B aussieht, baut sich das in der Regel manuell zusammen - über Filter, Exporte und Excel. Das funktioniert für einen Monatsbericht, nicht für eine tägliche Steuerung.
SLA-Nachweis. Verträge mit Mandanten enthalten fast immer eine Zusage zur Versandgeschwindigkeit - "Versand am selben Tag" oder "Versand in 24 Stunden". Ob diese Zusage eingehalten wurde, ist in der Standardsoftware nicht als Kennzahl hinterlegt. Cutoff-Zeiten, Werktagsregeln und Rückhalte pro Mandant müssten erst modelliert werden, bevor daraus eine belastbare Quote entsteht - dafür ist die WaWi nicht gebaut.
Abrechnungsmengen. Wer mehrere Mandanten abrechnet, braucht pro Kunde und Zeitraum die Summe der versendeten Pakete, bearbeiteten Retouren und vereinbarten Sonderpositionen. Diese Verdichtung ist in JTL-WaWi kein Standardbericht, sondern entsteht typischerweise durch manuelles Zusammenzählen am Monatsende - fehleranfällig und ein wiederkehrender Streitpunkt mit dem Mandanten, wenn die Zahlen nicht auf Knopfdruck nachweisbar sind.
Die Standardsoftware liefert die Rohdaten vollständig. Was fehlt, ist die Schicht, die daraus mandantengetrennte Kennzahlen und Abrechnungsmengen macht - nicht ein neues WMS.
04 - Die read-only Reporting-Schicht als Lösung
Was es ist. Statt WaWi oder WMS zu ersetzen, wird eine zusätzliche Schicht auf das bestehende System aufgesetzt, die die Datenbank rein lesend ausliest und daraus die fehlenden Auswertungen baut - mandantengetrenntes Reporting, SLA-Quote, Versandleistung pro Mitarbeiter, Abrechnungsmengen. Die WaWi bleibt einzige Quelle der Wahrheit für Bestände, Aufträge und Versand.
Warum das der pragmatische Weg ist. Ein Systemwechsel bringt Migrationsrisiko, Schulungsaufwand und Monate Projektlaufzeit in einen laufenden Betrieb - nur um an Auswertungen zu kommen, deren Rohdaten längst vorhanden sind. Ein rein lesender Zugriff kann den Lagerbetrieb nicht stören, weil er nichts zurückschreibt und keine bestehenden Prozesse verändert.
- Kein Systemwechsel, keine Migration, kein Parallelbetrieb zweier Warenwirtschaften
- Mandantentrennung folgt der bestehenden Markenlogik in der JTL-WaWi
- Umsetzung in Wochen statt Monaten, weil keine Prozesse im Lager angefasst werden
Typischer Fallstrick. Wer die Lücke mit einem BI-Tool ohne Fulfillment-Kontext schließen will, baut sich SLA-Regeln, Mandantenlogik und Abrechnungspositionen von Grund auf selbst - das dauert und bleibt wartungsintensiv. Eine Schicht, die für den 3PL-Anwendungsfall gebaut ist, bringt diese Logik bereits mit.
05 - Was max.dash konkret liefert
max.dash ist ein read-only Operations-Cockpit für JTL-Fulfillment-Dienstleister (3PL) im DACH-Raum. Wir lesen die JTL-WaWi (eazybusiness) rein lesend und liefern SLA-Reporting pro Mandant, Versandleistung pro Mitarbeiter, ein mandantengetrenntes Kundenportal und Abrechnungs-Mengen-Export - ohne Systemwechsel.
Konkret heißt das: Reporting und Auswertungen laufen live auf den Daten aus JTL-WaWi, JTL-WMS oder JTL-FFN, aufgeschlüsselt pro Mandant und pro Mitarbeiter. Details zu den einzelnen Kennzahlen stehen bei den Auswertungen, die Anbindung an die JTL-Systeme im JTL-Dashboard. Wer den Zugang zusätzlich für Mandanten selbst öffnen will, findet die Details im Kundenportal.
Wie die einzelnen Kennzahlen korrekt definiert und gemessen werden, steht im Leitfaden zu den Fulfillment-KPIs.