Wer eine Auswertung braucht, die JTL-WaWi nicht von Haus aus liefert - Versandleistung pro Mitarbeiter, SLA-Quote pro Mandant, ein Mengen-Export fuer die Abrechnung - landet frueher oder spaeter bei derselben Frage: Wer schreibt die Abfrage, und wer pflegt sie, wenn sich etwas aendert? Die Antwort haengt weniger von der ersten Auswertung ab als davon, was danach kommt.
01 - Die drei Wege im Ueberblick
Fuer 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 koennen aus denselben Rohdaten dieselbe Zahl liefern. Der Unterschied zeigt sich erst in der Zeitachse: beim naechsten JTL-Update, beim naechsten Mandanten, bei der naechsten Frage, die dazukommt.
- SQL selbst schreiben: guenstig am Anfang, aber laufende Pflege und Risiko bei Schema-Updates liegen bei dir.
- Servicepartner beauftragen: schnelles Ergebnis, aber eine Einmal-Abfrage veraltet mit dem naechsten Update oder der naechsten neuen Frage.
- Fertiges Cockpit: laufende Kosten, dafuer laufend gepflegt, kein SQL noetig, skaliert mit mehreren Mandanten.
- Ab mehreren Mandanten mit SLA-Zusagen oder eigenem Kundenportal faellt die Rechnung meist zugunsten des Cockpits aus.
02 - SQL selbst schreiben
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. Fuer eine einzelne, klar abgegrenzte Frage ist das der direkteste Weg - die Daten liegen ja bereits da.
Was dagegen spricht. Das JTL-Schema ist historisch gewachsen und in ungarischer Notation benannt (tArtikel, tAuftragPosition, kKunde) - lesbar, aber nicht selbsterklaerend, und ohne Dokumentation ein Ratespiel, welche Tabelle welche Wahrheit traegt. Schwerer wiegt: Mit jedem JTL-Update kann sich das Schema aendern - neue Spalten, verschobene Bedeutungen, umbenannte Felder. Eine Abfrage, die heute laeuft, liefert nach dem naechsten 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 naechste 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.
03 - Servicepartner beauftragen
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 laengst mit anderen Projekten beschaeftigt. Die Rechnung fuer die Wartung kommt dann als neuer Auftrag, nicht als eingeplanter Posten.
Wofuer es gut ist. Fuer eine einmalige Auswertung, eine Migration oder eine Sonderfrage ist Consulting der richtige Hebel. Fuer laufendes, sich wiederholendes Reporting ist es strukturell die teuerste Loesung, weil jede Aenderung erneut Honorar kostet.
04 - Fertiges Cockpit nutzen
Was es ist. Eine Software, die read-only an deine JTL-WaWi andockt und die gaengigen Fulfillment-Auswertungen fertig mitbringt - SLA-Quote pro Mandant, Versandleistung pro Mitarbeiter, Retouren, Lagerwert, Durchlaufzeit, Kommissionierleistung. Kein SQL noetig, 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 zwangslaeufig 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 Ueberblick zum JTL-Dashboard.
05 - Direkter Vergleich
Kein Weg ist per se falsch - sie beantworten unterschiedliche Fragen. "Was kostet die erste Zahl?" gewinnt SQL selbst schreiben. "Was kostet die zehnte Aenderung ueber zwei Jahre?" gewinnt in den meisten Faellen das Cockpit, sobald mehr als eine wiederkehrende Auswertung gebraucht wird.
06 - Fuer wen was passt
SQL selbst schreiben passt, wenn im Team ohnehin SQL-Kenntnisse vorhanden sind, es um eine einzelne, stabile Auswertung geht und die Kapazitaet da ist, sie bei jedem WaWi-Update zu pruefen.
Ein Servicepartner passt, wenn eine einmalige Sonderauswertung oder ein Datenexport fuer ein abgeschlossenes Projekt gebraucht wird - nicht fuer laufendes Monats- oder Wochenreporting.
Ein fertiges Cockpit passt, sobald mehrere Mandanten im Spiel sind, SLA-Zusagen gegenueber Kunden nachweisbar sein muessen oder ein eigenes Kundenportal gebraucht wird. Fuer Fulfiller mit genau diesem Bedarf - mehrere Mandanten, vertragliche SLA-Fristen, wiederkehrendes Reporting - faellt die Wahl in der Praxis auf ein Cockpit: Der Pflegeaufwand einer Eigenloesung uebersteigt hier schnell die laufenden Kosten einer fertigen Loesung, und die Mandantentrennung ist von Anfang an mitgedacht statt nachtraeglich in SQL nachgebaut.
max.dash ist ein read-only Operations-Cockpit fuer 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 fuer 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 fuer alle seine Kunden gemeinsam macht. Alle Details zu den Kennzahlen selbst stehen im Leitfaden zu den Fulfillment-KPIs.