Wer eine Auswertung braucht, die JTL-WaWi nicht von Haus aus liefert - Versandleistung pro Mitarbeiter, SLA-Quote pro Mandant, ein Mengen-Export für die Abrechnung - landet früher oder später bei derselben Frage: Wer schreibt die Abfrage, und wer pflegt sie, wenn sich etwas ändert? Die Antwort hängt weniger von der ersten Auswertung ab als davon, was danach kommt.
Welche drei Wege gibt es im Überblick?
Für JTL-Reporting gibt es drei Wege: SQL selbst schreiben, einen Servicepartner beauftragen oder ein fertiges Cockpit nutzen - sie unterscheiden sich in Aufwand, Wartung und Skalierung. Alle drei können aus denselben Rohdaten dieselbe Zahl liefern. Der Unterschied zeigt sich erst in der Zeitachse: beim nächsten JTL-Update, beim nächsten Mandanten, bei der nächsten Frage, die dazukommt.
- SQL selbst schreiben: günstig am Anfang, aber laufende Pflege und Risiko bei Schema-Updates liegen bei dir.
- Servicepartner beauftragen: schnelles Ergebnis, aber eine Einmal-Abfrage veraltet mit dem nächsten Update oder der nächsten neuen Frage.
- Fertiges Cockpit: laufende Kosten, dafür laufend gepflegt, kein SQL nötig, skaliert mit mehreren Mandanten.
- Ab mehreren Mandanten mit SLA-Zusagen oder eigenem Kundenportal fällt die Rechnung meist zugunsten des Cockpits aus.
Wie schreibt man SQL selbst?
Was es ist. Du oder jemand aus deinem Team schreibt SQL-Abfragen direkt gegen die JTL-Datenbank (eazybusiness), meist per SQL Server Management Studio oder einem BI-Tool, das sich per ODBC verbindet. Für eine einzelne, klar abgegrenzte Frage ist das der direkteste Weg - die Daten liegen ja bereits da. Wie derselbe Lesezugriff stattdessen als fertige, gepflegte Anbindung aussieht, zeigt die JTL-Anbindung.
Was dagegen spricht. Das JTL-Schema ist historisch gewachsen und in ungarischer Notation benannt (tArtikel, tAuftragPosition, kKunde) - lesbar, aber nicht selbsterklärend, und ohne Dokumentation ein Ratespiel, welche Tabelle welche Wahrheit trägt. Schwerer wiegt: Mit jedem JTL-Update kann sich das Schema ändern - neue Spalten, verschobene Bedeutungen, umbenannte Felder. Eine Abfrage, die heute läuft, liefert nach dem nächsten Update im schlimmsten Fall stillschweigend falsche Zahlen, im besten Fall einen Fehler. Wie das im Detail aussieht, steht im Leitfaden zum JTL-Schema-Update.
Der eigentliche Aufwand. Nicht das Schreiben der ersten Abfrage kostet Zeit, sondern die laufende Pflege danach: Update-Watch, Nachbesserung, Testen gegen die nächste WaWi-Version. Wer das nicht einplant, hat nach einem Jahr eine Sammlung von SQL-Skripten, bei denen niemand mehr sicher sagen kann, ob sie noch stimmen.
Wie beauftragt man einen Servicepartner?
Was es ist. Ein JTL-Dienstleister oder freier SQL-Consultant schreibt dir die Abfrage oder den Report gegen Honorar. Du bekommst schnell ein Ergebnis, ohne selbst SQL zu lernen oder Zeit im eigenen Team zu binden.
Was dagegen spricht. Beauftragt wird typischerweise eine Momentaufnahme: eine Abfrage, ein Report, ein Excel-Export - passend zur heutigen Frage und zum heutigen Schema. Kommt eine neue Frage dazu (ein weiterer Mandant, eine andere Kennzahl), beginnt der Auftrag von vorn. Aendert sich das JTL-Schema durch ein Update, veraltet der Report, ohne dass jemand automatisch benachrichtigt wird - der Consultant ist zu diesem Zeitpunkt meist längst mit anderen Projekten beschäftigt. Die Rechnung für die Wartung kommt dann als neuer Auftrag, nicht als eingeplanter Posten.
Wofür es gut ist. Für eine einmalige Auswertung, eine Migration oder eine Sonderfrage ist Consulting der richtige Hebel. Für laufendes, sich wiederholendes Reporting ist es strukturell die teuerste Lösung, weil jede Aenderung erneut Honorar kostet.
Wie nutzt man ein fertiges Cockpit?
Was es ist. Eine Software, die read-only an deine JTL-WaWi andockt und die gängigen Fulfillment-Auswertungen fertig mitbringt - SLA-Quote pro Mandant, Versandleistung pro Mitarbeiter, Retouren, Lagerwert, Durchlaufzeit, Kommissionierleistung. Kein SQL nötig, keine eigene Wartung der Abfragen.
Was dagegen spricht. Laufende Kosten statt einer Einmalzahlung, und du bist an den Funktionsumfang des Anbieters gebunden - eine sehr spezielle Einzelfrage, die kein anderer Fulfiller je gestellt hat, deckt ein Standard-Cockpit nicht zwangsläufig ab.
Warum die Pflege hier anders liegt. Bei einem Schema-Update ist es Aufgabe des Anbieters, das Mapping nachzuziehen - nicht deine. Neue Auswertungen kommen mit Produkt-Updates dazu, ohne dass du sie separat beauftragst. Der zentrale Unterschied zu den ersten beiden Wegen: Die Wartungslast wird auf viele Kunden verteilt statt bei dir allein zu liegen. Wie das bei max.dash konkret aussieht, zeigen die Auswertungen und der Überblick zur JTL-Anbindung.
Wie sieht der direkte Vergleich aus?
Kein Weg ist per se falsch - sie beantworten unterschiedliche Fragen. "Was kostet die erste Zahl?" gewinnt SQL selbst schreiben. "Was kostet die zehnte Aenderung über zwei Jahre?" gewinnt in den meisten Fällen das Cockpit, sobald mehr als eine wiederkehrende Auswertung gebraucht wird.
Für wen passt was?
SQL selbst schreiben passt, wenn im Team ohnehin SQL-Kenntnisse vorhanden sind, es um eine einzelne, stabile Auswertung geht und die Kapazität da ist, sie bei jedem WaWi-Update zu prüfen.
Ein Servicepartner passt, wenn eine einmalige Sonderauswertung oder ein Datenexport für ein abgeschlossenes Projekt gebraucht wird - nicht für laufendes Monats- oder Wochenreporting.
Ein fertiges Cockpit passt, sobald mehrere Mandanten im Spiel sind, SLA-Zusagen gegenüber Kunden nachweisbar sein müssen oder ein eigenes Kundenportal gebraucht wird. Für Fulfiller mit genau diesem Bedarf - mehrere Mandanten, vertragliche SLA-Fristen, wiederkehrendes Reporting - fällt die Wahl in der Praxis auf ein Cockpit: Der Pflegeaufwand einer Eigenlösung übersteigt hier schnell die laufenden Kosten einer fertigen Lösung, und die Mandantentrennung ist von Anfang an mitgedacht statt nachträglich in SQL nachgebaut.
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.
Von der Frage zur Zahl, ohne eigenes SQL
Die Rohdaten für SLA-Quote, Versandleistung und Retourenquote liegen in jeder JTL-WaWi bereits vor. Die Frage ist nur, wer die Schicht dazwischen baut und pflegt - du selbst per SQL, ein Consultant je Auftrag, oder ein Anbieter, der das für alle seine Kunden gemeinsam macht. Alle Details zu den Kennzahlen selbst stehen im Leitfaden zu den Fulfillment-KPIs.
Diese Abwägung - SQL selbst pflegen, einen Consultant je Auftrag bezahlen oder ein fertiges Cockpit nutzen - stellt sich genauso, wenn im Lager kein JTL, sondern ein anderes System steht. Nur die Tabellennamen und die SQL-Dialekte wechseln, die Wartungslast bleibt dieselbe Rechnung. Welche Systeme max.dash dafür direkt anbindet, zeigt die Liste der Quellsysteme.