JTL hat mit Version 2.0.0 eine Software in die Händlerschaft geschmissen, die nach Aussage eines eigenen Servicepartners „hunderte schwere Bugs“ enthält. Was in jeder anderen Branche ein Skandal wäre, wird in der JTL-Welt achselzuckend hingenommen. Wie demütig und erduldend doch die JTL-Software Kunden sind.
Inhaltsverzeichnis
Fasse den Artikel im Bullet-Stil zusammen.
Was passiert ist
Onlinehändler Torge Baumbach hat über die Ostertage auf JTL WMS 2.0.0 aktualisiert – und stand danach vor einem leeren Bildschirm. Das WMS zeigte keine Lager mehr an, obwohl die Wawi die Lager korrekt anzeigte, der FFN-Abgleich lief und alle Lizenzen aktualisiert waren. Ein Fehler, der nach einem Update nicht passieren darf.
Baumbach wandte sich an die offizielle JTL-Facebook-Gruppe. Was er dort bekam, war keine Lösung – sondern ein Geständnis und Schuld zugesprochen.
Robert Wall (T4DT GmbH) sagt es selbst
Robert Wall, Geschäftsführer der T4DT GmbH und offizieller JTL-Servicepartner, kommentierte in dem Thread unverblümt:
„Warum macht man an einem Feiertag ein Update? Kein Support ist verfügbar. Die Version hat hunderte schwere Bugs. Und spätestens Ende April kommt eine stabile Variante raus.“
Wall richtete seinen Kommentar explizit an die „geneigten Mitleser“, um sie davor zu warnen, es Baumbach gleichzutun. Das hat was: Ein offizieller JTL-Servicepartner warnt öffentlich vor der aktuellen Stable-Version – in der offiziellen JTL-Gruppe. Und JTL? Schweigt.
Wall räumt außerdem ein, dass er die Version „außerhalb vom Labor“ nicht am Feiertag updaten würde. Ein Servicepartner, der seinen eigenen Kunden die aktuelle Stable-Version nur im Testbetrieb anfasst. Das sagt alles über den Zustand dieser Software.
Kaltschmidt zeigt die typische Reaktion
Auch René Kaltschmidt, ehemaliger JTL-Servicepartner, meldete sich zu Wort – nicht mit Kritik an JTL, sondern mit einem Kommentar über Baumbach persönlich:
„Das nenne ich mal Leben am Limit… also wenn deine Frau im öffentlichen Dienst arbeitet und du von deinen eigenen Umsätzen nicht abhängig bist, kann man das machen, aber sonst 🤦♂️“
Mit anderen Worten: Schuld ist der Händler, der das Update eingespielt hat. Nicht JTL, das eine fehlerhafte Software als „Stable Release“ deklariert hat.
Das eigentliche Problem: niemand benennt es
Markus Kießling brachte im Thread den entscheidenden Punkt:
„Bei jeder anderen Software die ich kenne, laufen Updates ohne großen Zauber und der Erwartung den Kundendienst zu benötigen problemlos durch. Nur diejenigen, die in der JTL-Blase stecken sehen ‚hundert schwere Bugs‘ als normal an.“
Genau das ist der Kern. In der JTL-Welt hat sich eine Kultur etabliert, in der fehlerhafte Releases als gottgegeben hingenommen werden. Die Diskussion dreht sich nicht um die Frage, warum JTL Software mit hunderten Bugs als stabil klassifiziert – sondern darum, ob Baumbach den falschen Zeitpunkt für sein Update gewählt hat.
Das ist die falsche Frage. Die richtige lautet: Warum darf ein Softwareanbieter eine Version mit hunderten schweren Bugs unter „Stable Releases“ veröffentlichen – und niemand im Ökosystem nimmt ihn dafür in die Pflicht?
Was das für Händler bedeutet
JTL ist das Herz in den Händlerfirmen. Es steuert Lager, Kommissionierung, Versandprozesse. Ein Ausfall im laufenden Betrieb kostet echtes Geld – pro Stunde, pro Fehler, pro nicht ausgelieferter Bestellung. Wenn eine „stabile“ Version im Wortsinn nicht stabil ist, ist das kein Kavaliersdelikt. Es ist ein Geschäftsschaden, den JTL mit dem Release verursacht.
JTL ist für diesen Schaden verantwortlich.
Stattdessen erklärt man Händlern, sie sollen mit Updates warten. Oder nur dann updaten, wenn niemand arbeitet. Oder – wie Kaltschmidt – dankbar sein, dass ihre Frau ein geregeltes Einkommen hat.
JTL muss in die Pflicht genommen werden
Das Problem ist nicht Torge Baumbach, der ein Update eingespielt hat. Das Problem ist ein Softwareanbieter, der Releases als stabil kennzeichnet, die es nicht sind – und ein Ökosystem aus Servicepartnern, das diese Praxis deckt statt benennt.
Hunderte schwere Bugs in einer Warenwirtschaft sind kein Naturereignis. Sie sind das Ergebnis von schlechter Arbeit. Solange niemand – auch nicht die Servicepartner, die täglich mit JTL ihr Geld verdienen – klar ausspricht, was hier passiert, ändert sich nichts. Robert Wall hat wenigstens gewarnt. Das ist mehr als JTL selbst getan hat.
Was hier beschrieben wird, verdient eine ernsthafte rechtliche Einordnung – jenseits des üblichen Community-Seufzens.
Der Begriff „Stable“ ist im Softwarerecht keine bloße Marketingvokabel, sondern eine konkludente Beschaffenheitsangabe: Der Anbieter erklärt damit, dass die Software produktionsreif ist. Wenn nun ein offizieller JTL-Servicepartner – nicht irgendein Forumnutzer – öffentlich erklärt, die Version habe „hunderte schwere Bugs“ und eine wirklich stabile Variante komme erst Ende April, dann stellt sich für mich eine ganz konkrete Frage: Kann JTL ernsthaft behaupten, von diesem Zustand nichts gewusst zu haben?
Denn das wäre die entscheidende Weiche: Wer als „Stable“ kennzeichnet, obwohl das eigene Servicepartner-Netzwerk intern offenbar sehr genau weiß, dass dem nicht so ist, bewegt sich nach meiner Einschätzung in einem Bereich, der über leichte Fahrlässigkeit deutlich hinausgeht. Grobe Fahrlässigkeit liegt nach ständiger BGH-Rechtsprechung dann vor, wenn dasjenige unbeachtet bleibt, was im gegebenen Fall jedem hätte einleuchten müssen. Dass ein ERP-System mit hunderten schwerer Bugs nicht produktionsreif ist, dürfte jedem einleuchten – offenbar auch dem Servicepartner, der es „außerhalb vom Labor“ nicht anfassen würde.
Hinzu kommt das Muster: Dies ist kein einmaliger Ausrutscher, sondern eine von der Community seit Jahren beklagte Wiederholung. Wer strukturell und wiederholt fehlerhafte Releases produziert, ohne die Qualitätssicherung anzupassen, handelt nicht versehentlich – sondern trifft eine organisatorische Entscheidung.
Betroffene Händler, die durch dieses Update konkrete, bezifferbare Schäden erlitten haben, sollten sich die Frage stellen, ob ein Gang zum IT-Fachanwalt sinnvoll ist – denn Haftungsausschlüsse in AGB greifen bei grober Fahrlässigkeit schlicht nicht.
Woran es JTL in der Softwareentwicklung (wie in vielen anderen Firmen auch) fehlt, ist ganz klar an einem etablierten Testmanagement.
Software testen nach ISTQB-Standard hat sich in der Branche vielfach bewährt und kann durch eigenes Personal besetzt werden.
Was ist ISTQB®? Definition, Erläuterung und Zertifizierung
Das International Software Testing Qualifications Board (ISTQB®) mit Sitz in Belgien trägt praxiserprobte Konzepte und Begriffe des Testmanagements als Teilbereich des Qualitätsmanagements zusammen. Daraus entstehen Lehrpläne, die dieses Wissen strukturiert vermittelbar machen.
Die Idee dahinter: Software hat sich längst zu einem selbstverständlichen wie auch unverzichtbaren Teil unseres Alltags entwickelt. Wenn Softwareprodukte nicht so funktionieren, wie sie sollten, ist das nicht nur ärgerlich, sondern häufig auch schädlich für die Produktivität eines Unternehmens oder sogar sicherheitsrelevant. Qualitätsmanagement sollte daher ein zentraler Bestandteil vorausdenkender Softwareentwicklung sein.
Fehlerquellen und Qualitätsanforderungen strukturiert ergründen: Die ISTQB-Methode
Jede Software verarbeitet Daten mittels Regeln. Die Vielzahl der Kombinationsmöglichkeiten macht es jedoch schon bei sehr einfachen Anwendungen unmöglich, eine korrekte Verarbeitung formal zu beweisen. Auch, weil sich in der Praxis nicht sämtliche Kombinationen aus Daten und Regeln testen lassen.
ISTQB-Trainings vermitteln daher die Kenntnisse und Fähigkeiten, um beim Testmanagement einen anderen, smarteren Ansatz zu verfolgen: Wer die Testobjekte aus möglichst vielen unterschiedlichen Perspektiven betrachtet und bewertet, kann die Qualitätsanforderungen effektiv und effizient erfüllen.
Das wache Auge des Qualitätsmanagements – unentbehrlich von Anfang an
Mit Softwareentwicklung verhält es sich wie mit dem Hausbau: Nur auf einem soliden Fundament kann Großes entstehen. Nur wenn das Qualitätsmanagement von Beginn an fest in den Entwicklungsprozess eingebunden ist und Fehler von Testteams schon im Entwurf und am Anfang der Implementierungsphase erkannt werden, lassen sie sich ohne großen Zeit- und Kostenaufwand beheben. Auch eine Testautomatisierung kann ihre Möglichkeiten nur dann voll ausschöpfen, wenn erste Vorbereitungsschritte bereits in der Entwicklungsphase getroffen worden sind.
Dabei steht das Testmanagement natürlich nicht für sich alleine. Im Idealfall ist es in agile (Scrum, DevOps) oder traditionelle Entwicklungsmodelle eingebunden, nutzt die Ergebnisse des Anforderungsmanagements (IREB) und teilt die Ziele des IT-Servicemanagements (ITIL: Utility und Warranty).
ISTQB Projekte profitieren von Testmanagern
Was zunächst komplex klingen mag, nimmt in den ISTQB-Trainings konkrete, greifbare Formen an: Die Kurse liefern Praxistipps für den optimalen Aufbau eines Testprozesses, der ideal zum jeweiligen Anwendungsfall passt. Denn wer als Testmanager die unterschiedlichen Reviewarten, Use Cases und statische wie auch dynamische Tests souverän beherrscht, ist ein unschätzbarer Gewinn für jedes Entwicklungsprojekt. Um das zu erreichen, vermitteln ISTQB Schulungen, wie Testdaten, -umgebungen und -werkzeuge zielgerichtet eingesetzt und die Testergebnisse rückverfolgbar protokolliert werden können. So wird und bleibt die Effizienz des gesamten Testprozesses steuerbar.
Wie ich vor Jahren einmal von einem früheren Mitarbeiter von JTL gehört habe, reichte es wohl bei manchen Komponenten der JTL-Software aus, wenn ein Entwickler und ein Supporter die Komponente testen und der Bug nicht mehr auftrat. Ob gleichzeitig ggf. andere Bugs dadurch eingeschleppt worden waren, wurde vermutlich nicht getestet. Es würde mich nicht wundern, wenn das bei anderen Komponenten oder generell so gehandhabt wurde und vielleicht auch bis heute wird.
Langsam kommt mir JTL vor wie Volkswagen. Am Anfang gut und bezahlbar, jetzt bei jeder Version schlimmere Bugs und die Preise steigen.