JTL-Ameise-Export automatisieren oder Live-Dashboard?

Die JTL-Ameise ist seit Jahren das Werkzeug, mit dem WaWi-Admins eigene SQL-Abfragen gegen die Datenbank fahren und das Ergebnis als CSV herausziehen. Für viele Fulfillment-Betriebe war sie der erste Schritt weg vom reinen Bauchgefühl - und für einen Teil davon ist sie bis heute der richtige Weg. Die Frage ist nicht "Ameise oder Dashboard", sondern: Bei welcher Mandantenzahl, welcher Berichtsfrequenz und welcher SLA-Pflicht kippt die Rechnung.

Die JTL-Ameise ist das native Export-Werkzeug der JTL-WaWi, das per eigenem SQL Daten als CSV exportiert, auch automatisiert per Batch. Sie greift direkt auf die WaWi-Datenbank zu, führt ein frei definiertes SQL-Statement aus und schreibt das Ergebnis in eine CSV-Datei - manuell per Klick oder automatisiert über Kommandozeilen-Parameter und Windows-Taskplaner.

01 - Was die Ameise ist und wie der Batch-Export funktioniert

Was es ist. Die Ameise ist ein Zusatzprogramm der JTL-WaWi, das seit den frühen eazybusiness-Versionen mitgeliefert wird. Sie ist im Kern ein SQL-Client mit CSV-Export: Man schreibt (oder bekommt) ein SELECT-Statement gegen die WaWi-Tabellen, die Ameise führt es aus und schreibt die Ergebniszeilen in eine Datei.

Wie der Batch-Weg funktioniert. Für die manuelle Nutzung reicht ein Doppelklick. Für Automatisierung braucht es drei Bausteine, die in der Praxis fast immer zusammen auftauchen:

• Gespeichertes SQL-Statement - eine Datei mit der Abfrage, zum Beispiel Versanddatensätze eines Tages je Auftrag, Mandant und Versanddienstleister.
• Kommandozeilen-Aufruf - die Ameise wird mit Parametern für Statement, Zielpfad und Ausgabeformat gestartet, ohne dass jemand die Oberfläche öffnet.
• Windows-Taskplaner - ein geplanter Task ruft diesen Befehl täglich oder mehrmals täglich auf einem Server oder Terminalserver auf, auf dem die WaWi ohnehin läuft.

Das Ergebnis: Jeden Morgen liegt eine frische CSV-Datei in einem Ordner, zum Beispiel mit gestrigen Versanddaten. Von dort übernimmt in den allermeisten Betrieben ein Excel-Sheet mit Pivot-Tabelle oder ein Power-Query-Import die Weiterverarbeitung. Dieser Weg kostet keine Zusatzlizenz und keine neue Software - er nutzt, was in der WaWi-Installation ohnehin mitkommt.

02 - Die fünf Bruchstellen im Ameise-Batch-Weg

Was passiert. Der Batch-Export läuft technisch zuverlässig - die Bruchstellen liegen nicht im Export selbst, sondern in allem, was danach kommt. Fünf Punkte tauchen in der Praxis immer wieder auf:

• Snapshot statt Live-Zahlen. Der Export zeigt den Stand zum Ausführungszeitpunkt des Tasks, meist einmal täglich nachts. Eine Frage um 14 Uhr ("Wie viele Pakete sind heute schon raus?") beantwortet die gestrige CSV nicht.
• Kein eingebauter Mandanten-Split. Die Ameise kennt Mandanten nur, wenn das SQL-Statement sie explizit filtert oder als Spalte mitführt. Für jeden neuen Mandanten oder jede neue Auswertungsdimension muss das Statement angepasst und erneut getestet werden.
• Manuelle Zwischenschritte. CSV öffnen, Datenformat prüfen (Datumsspalten, Dezimaltrennzeichen, Encoding), in die Pivot-Vorlage einfügen oder per Power Query aktualisieren - jeder dieser Schritte ist eine Stelle, an der ein Report ausfällt oder falsch aussieht, wenn ihn mal jemand anders macht.
• Excel-Fehleranfälligkeit. Verrutschte Zellbezüge, überschriebene Formeln, ein falsch gezogener SVERWEIS oder eine Pivot-Tabelle, die nach dem CSV-Import nicht neu verknüpft wurde - all das fällt oft erst auf, wenn eine Zahl im Kundengespräch schon falsch kommuniziert wurde.
• Fehlende Nachvollziehbarkeit. Wenn drei Personen im Team eigene Varianten desselben SQL-Statements pflegen, driften die Zahlen auseinander, ohne dass jemand sofort merkt, welche Version gerade die richtige ist.

Ein Betrieb mit drei Mandanten hatte drei leicht unterschiedliche Ameise-Exporte im Umlauf - je nachdem, wer sie zuletzt angepasst hatte. Die SLA-Quote für denselben Tag unterschied sich zwischen den Sheets um vier Prozentpunkte, weil eine Version stornierte Aufträge mitzählte und die andere nicht. Beide Zahlen waren "richtig gerechnet" nach ihrer eigenen Logik - nur eine passte zum Vertrag.

03 - Wann der Ameise-/Excel-Weg reicht

Was dafürspricht. Der Batch-Export ist kein Notbehelf, sondern für einen bestimmten Betriebstyp die wirtschaftlich richtige Lösung. Er passt gut, wenn mehrere dieser Bedingungen gleichzeitig zutreffen:

• Ein bis zwei Mandanten, deren Regeln (Cutoff, SLA-Frist) stabil sind und sich selten ändern.
• Reporting-Rhythmus wöchentlich oder monatlich, nicht mehrmals täglich.
• Eine feste Person pflegt die SQL-Statements und kennt die Fallstricke der eigenen Vorlage.
• Kein vertraglich scharfes SLA mit Vertragsstrafen, sondern interne Steuerung oder lockere Kundenzusagen.

In dieser Konstellation ist der Aufwand, ein zusätzliches Tool einzuführen, größer als der Nutzen. Ein sauber gepflegtes Ameise-Statement mit fester Excel-Vorlage liefert hier über Jahre verlässliche Zahlen, ohne laufende Zusatzkosten. Wie SQL-Direktzugriffe grundsätzlich gegen ein fertiges Cockpit abschneiden, inklusive der Frage nach Wartungsaufwand bei WaWi-Updates, steht im Leitfaden SQL-Zugriff vs. Cockpit.

04 - Wann sich ein Live-Dashboard lohnt

Was sich ändert. Der Umschlagpunkt liegt nicht bei einer festen Paketzahl, sondern dort, wo die Kombination aus Mandantenzahl, Frequenz und Vertragsdruck den manuellen Pflegeaufwand explodieren lässt. Typische Signale aus der 3PL-Praxis:

• Mehrere Mandanten mit unterschiedlichen SLA-Regeln. Jeder zusätzliche Mandant vervielfacht die Zahl der Statement-Varianten und Excel-Reiter, die synchron gehalten werden müssen.
• Vertragsstrafen oder scharfe SLA-Zusagen. Wenn eine falsch gerechnete Quote im Kundengespräch Geld kostet, wird die Fehleranfälligkeit von Excel zum echten Risiko statt zur Unbequemlichkeit.
• Tägliches oder untertägiges Reporting. Sobald "wie stehen wir heute" mehr als einmal pro Woche gefragt wird, frisst der manuelle Export-Öffnen-Prüfen-Zyklus reale Arbeitszeit.
• Kunden wollen selbst reinschauen. Ein CSV-Export lässt sich nicht an fünf Kunden gleichzeitig als sicheren, mandantengetrennten Zugang verteilen - ein Kundenportal schon.

Live und pro Mandant getrennt siehst du Versandzahlen, SLA-Quote und Mitarbeiterleistung dann im JTL-Dashboard von max.dash, ohne dass jemand morgens eine CSV öffnen oder eine Pivot-Tabelle aktualisieren muss. Die Auswertungen selbst - Versandvolumen, Pick/Pack-Leistung, Trendverläufe - sind im Detail in den Auswertungen beschrieben.

05 - Rechenbeispiel: Pflegeaufwand gegen Mandantenzahl

Wie sich der Aufwand entwickelt. Nach Erfahrungswerten aus der 3PL-Praxis kostet die Pflege eines Ameise-/Excel-Reports pro Mandant und Woche zwischen 20 und 40 Minuten - SQL bei Regeländerung anpassen, CSV prüfen, Pivot aktualisieren, Ausreißer von Hand nachrechnen. Bei einem Mandanten sind das grob 1,5 bis 3 Stunden im Monat, kaum der Rede wert.

Bei sechs Mandanten mit unterschiedlichen Cutoff-Zeiten und SLA-Fristen steigt das nicht linear, sondern überproportional, weil zusätzlich Zeit für den Abgleich zwischen den Sheets und die Fehlersuche bei Abweichungen dazukommt - in der Praxis oft 15 bis 25 Stunden im Monat. Das entspricht, grob mit 35 EUR/Stunde interner Kosten gerechnet, 525 bis 875 EUR Personalkosten monatlich allein für die Report-Pflege - zusätzlich zum Risiko einer falsch kommunizierten SLA-Quote im Kundengespräch. Diese Größenordnung ist ein Erfahrungswert aus Kundengesprächen, keine feste Norm - der tatsächliche Aufwand hängt an der Zahl der Sonderregeln pro Mandant.

Ab diesem Punkt tragen sich die Anker-Kosten eines Live-Cockpits (Cockpit ab 299 EUR/Monat, Portal ab 499 EUR/Monat, Endpreis im Demo-Gespräch) häufig von selbst, weil die eingesparte manuelle Pflegezeit die Kosten übersteigt - unabhängig vom SLA-Risiko, das sich in Excel kaum beziffern lässt.

06 - Ameise bleibt Werkzeug, kein Auslaufmodell

Einordnung. Die Ameise wird durch ein Dashboard nicht überflüssig. Für Einzelabfragen, Datenexporte an die Buchhaltung oder schnelle Ad-hoc-Checks bleibt sie das richtige Werkzeug - auch in Betrieben, die parallel ein Live-Cockpit einsetzen. Der Unterschied liegt darin, wofür man sie einsetzt: für den punktuellen SQL-Zugriff ist sie unschlagbar direkt, für laufendes Mehrmandanten-Reporting mit SLA-Bezug wird der Pflegeaufwand irgendwann zum limitierenden Faktor.

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.