Neu askJan | Neuer KI-Assistent für JTL-Wawi - schnelle, effiziente und transparente KI-Datenanalyse - ohne SQL!

AlenaMM

Neues Mitglied
8. Januar 2026
18
1
Buchholz in der Nordheide
Firma
askJan
Hallo an alle,

JTL-Wawi speichert alles: Verkäufe, Lagerbewegungen, Kunden, Prozesse. Was fehlt, sind klare Antworten im richtigen Moment.
Die Daten sind da. Aber der Weg zur Antwort ist oft zu langsam, zu technisch oder zu aufwendig.
Deshalb haben wir in den letzten Monaten askJan entwickelt - ein KI-gestütztes Analysetool für deine JTL-Wawi Daten!

askJan DEMO:

Unsere Mission: askJan ist das Tool, das:
  • JTL-Wawi-Daten sofort verständlich macht
  • Fragen in natürlicher Sprache beantwortet
  • nicht erklärt werden muss
  • und keine technischen Vorkenntnisse verlangt
Kurz gesagt: askJan ist kein Hype. Keine Spielerei. Sondern ein Werkzeug für bessere Entscheidungen. Für alle!

Werde Early Adopter und sichere dir:
  • 125 Bonus Credits im Wert von 24,50€ - genug für einen intensiven Test
  • Nutze die KI für JTL-Wawi bevor es alle anderen tun und verschaffe dir einen Vorsprung
  • Dein Feedback prägt askJan. Als Early Adopter hast du echten Einfluss auf die Weiterentwicklung
Jetzt Early Adopter werden!

Anbei eine kleine Sneak Peak direkt aus askJan!

Bei Interesse meldet euch gern per PN oder per Mail: askalena@askjan.de
 

Anhänge

  • Preview_Demo.jpeg
    Preview_Demo.jpeg
    341,8 KB · Aufrufe: 37
  • Preview_Frage1.jpeg
    Preview_Frage1.jpeg
    277,2 KB · Aufrufe: 38
  • Preview_Frage2.jpeg
    Preview_Frage2.jpeg
    380,7 KB · Aufrufe: 34
  • Preview_Frage3.jpeg
    Preview_Frage3.jpeg
    313,1 KB · Aufrufe: 37
  • Traurig
  • Ich liebe es
Reaktionen: John und JanJan

John

Sehr aktives Mitglied
3. März 2012
3.919
964
Berlin
Wow.:)

DAS dürfte spannenden Ergebnisse bringen, wenn ich mich anschaue, was an KI-SQL hier bisher im Forum aufgetaucht ist.

Sind die SQLs, die verwendet werden durch EUCH validiert und haftet Ihr für Fehler?
 
  • Gefällt mir
Reaktionen: MichaelH

John

Sehr aktives Mitglied
3. März 2012
3.919
964
Berlin
Angehängt der SQL aus Deinem Demo Video.

Es ist genau wie vermutet:

1. Veraltete Datenbankstruktur benutzt.
Die Abfrage funktioniert überhaupt nur noch, weil JTL die inzwischen gelöschten Tabellen (noch) als Views mitschleppt.

2. GROTTENFALSCHES Ergebnis, weil SQL fehlerhaft
Die KI hat eben KEINE Ahnung von der JTL-DB Struktur weil die Trainingsdatenbasis ist zu klein.
Entsprechend wird sich etwas zusammengereimt, was ein falsches Ergebnis liefert.

Euer Tool schaut toll aus. Absolut Respekt dafür. Das bekomme ich so nicht hin.
Das Euch aber der falsche SQL durchrutscht bis ins Werbevideo zeigt, dass Ihr nicht wirklich tief in der JTL SQL Thematik steckt und KI Ergebnisse selbst nicht validieren könnt.

Und damit sollen Kunden ENTSCHEIDUNGEN treffen?!?
 

Anhänge

  • Au-weia.png
    Au-weia.png
    558,8 KB · Aufrufe: 30
Zuletzt bearbeitet:

ple

Sehr aktives Mitglied
20. August 2019
801
161
Ja schaut echt gut aus das Frontend, aber die ki auf die Datenbank drauf loslassen, sehr gefährlich.
Solange es nur Daten abfragen ist, ok, muss der User entscheiden ob die stimmen oder nicht und ob die Qualität gut ist, aber wehe die ki gibt ne sql mit Update insert oder so aus, das geht zu 100% in die Hose.
 

John

Sehr aktives Mitglied
3. März 2012
3.919
964
Berlin
Solange es nur Daten abfragen ist, ok, muss der User entscheiden ob die stimmen oder nicht und ob die Qualität gut ist

Lustig, wie sich der Qualitätsanspruch geändert hat.

Früher:
Experten programmieren etwas nach bestem Wissen.
Anwender können sich darauf verlassen, andernfalls BUG.

Heute:
KI schwadroniert etwas zusammen und verpackt es schön.
Der User braucht Fachwissen wie früher die Experten, um das Ergebnis zu prüfen.
Ist es falsch, isses halt so, weil niemand Schuld...ist halt KI.
 

AlenaMM

Neues Mitglied
8. Januar 2026
18
1
Buchholz in der Nordheide
Firma
askJan
Angehängt der SQL aus Deinem Demo Video.

Es ist genau wie vermutet:

1. Veraltete Datenbankstruktur benutzt.
Die Abfrage funktioniert überhaupt nur noch, weil JTL die inzwischen gelöschten Tabellen (noch) als Views mitschleppt.

2. GROTTENFALSCHES Ergebnis, weil SQL fehlerhaft
Die KI hat eben KEINE Ahnung von der JTL-DB Struktur weil die Trainingsdatenbasis ist zu klein.
Entsprechend wird sich etwas zusammengereimt, was ein falsches Ergebnis liefert.

Euer Tool schaut toll aus. Absolut Respekt dafür. Das bekomme ich so nicht hin.
Das Euch aber der falsche SQL durchrutscht bis ins Werbevideo zeigt, dass Ihr nicht wirklich tief in der JTL SQL Thematik steckt und KI Ergebnisse selbst nicht validieren könnt.

Und damit sollen Kunden ENTSCHEIDUNGEN treffen?!?
Hallo John und danke für dein aufmerksames Auge.
Das Ergebnis zu der Frage ist nicht falsch, die dargestellte Query jedoch schon, da hast du Recht und wir müssen dies korrigieren.

Bzgl. der Datenbankstruktur analysiert askJan zuerst bei der Installation die User-Individuelle Datenbankstruktur um daraufhin bestmögliche Ergebnisse liefern zu können. Dabei liegt es am KI-Sprachmodell, die „dahinterliegende“ SQL zu generieren. Kommt es dabei zu einem Fehler, iteriert askJan, sodass z.B. SQL-Syntaxfehler selbstständig korrigiert werden! Ob dabei eine View oder eine dahinterliegende Tabelle genutzt wird, ist dabei die Entscheidung vom Sprachmodell.
askJan nutzt die aktuell besten Modelle und bewährten Methoden, um KI-gestützt bestmögliche Ergebnisse liefern zu können. Dabei kann die KI auch Fehler machen, das ist denke ich allen klar. Der User sollte natürlich immer prüfen, ob die Ergebnisse plausibel sind. Aber der Nutzen aus einer schnellen Antwort, die den User sehr wohl zum Ziel führen kann, kann ebenso enorm sein! Wie im Video zusehen, ist die Antwort auf die Frage "Zu welcher Uhrzeit verkaufe ich am meisten?" jedoch korrekt und bietet dem User binnen Sekunden eine Antwort in natürlicher Sprache.

Probiere askJan doch gern selbst aus, es ist wirklich Cool und kann bei vielen Dingen bereits verdammt gut helfen! Schreib mir gern eine PN und ich schalte dir unsere 125 Credits zum Testen frei damit du dir selbst ein Bild machen kannst und meld dich bei weiterem Feedback. Wir sind immer offen für den fachlichen Austausch und wollen askJan stets weiterentwickeln!
 

AlenaMM

Neues Mitglied
8. Januar 2026
18
1
Buchholz in der Nordheide
Firma
askJan
Ja schaut echt gut aus das Frontend, aber die ki auf die Datenbank drauf loslassen, sehr gefährlich.
Solange es nur Daten abfragen ist, ok, muss der User entscheiden ob die stimmen oder nicht und ob die Qualität gut ist, aber wehe die ki gibt ne sql mit Update insert oder so aus, das geht zu 100% in die Hose.
Hallo ple,
askJan ist so konzipiert, dass es über die Datenbank lesen kann! Geschrieben wird nicht in der Datenbank, wenn gewünscht, kann askJan aber die JTL-API bedienen (und darüber sicher schreiben).
Bzgl. Inserts, Updates, etc. gibt es Sicherheitsmechanismen, die genau auf solche Punkte prüfen. Wenn diese vorkommen, wird ein Absetzen unterbunden, sodass ein wirksamer Schutz vor Schreib-, Update-, Drop- oder bspw. Delet-Operationen sichergestellt werden kann.
askJan analysiert die User-Individuelle Datenbankstruktur bei der Installation, um daraufhin bestmögliche Ergebnisse liefern zu können.

Probiere auch du askJan gern selbst aus und gib uns dein fachliches Feedback! Ich würde mich sehr über einen weiteren Austausch freuen!
 

AlenaMM

Neues Mitglied
8. Januar 2026
18
1
Buchholz in der Nordheide
Firma
askJan
Lustig, wie sich der Qualitätsanspruch geändert hat.

Früher:
Experten programmieren etwas nach bestem Wissen.
Anwender können sich darauf verlassen, andernfalls BUG.

Heute:
KI schwadroniert etwas zusammen und verpackt es schön.
Der User braucht Fachwissen wie früher die Experten, um das Ergebnis zu prüfen.
Ist es falsch, isses halt so, weil niemand Schuld...ist halt KI.
Hallo John,
der Punkt ist absolut nachvollziehbar – und genau deshalb ist Transparenz hier so wichtig.
askJan ist kein System, das „einfach irgendetwas ausspuckt und dann egal“. Es ist als Werkzeug gedacht, um u.a. Daten schnell verständlich zu machen und Fragestellungen in natürlicher Sprache zu analysieren.
Aus unserer Sicht geht es weniger um einen gesunkenen Qualitätsanspruch, sondern um eine veränderte Sichtbarkeit von Annahmen. Früher lag das Risiko stillschweigend beim Entwickler, heute wird es offen – und damit überprüfbar.

Auch klassische Software war und ist nie automatisch korrekt, nur waren Fehler oft schwerer nachzuvollziehen. KI macht Annahmen explizit, die man prüfen kann – und sollte, da stimme ich dir zu 100% zu!

Liebe Grüße!
 

AlenaMM

Neues Mitglied
8. Januar 2026
18
1
Buchholz in der Nordheide
Firma
askJan
Wow.:)

DAS dürfte spannenden Ergebnisse bringen, wenn ich mich anschaue, was an KI-SQL hier bisher im Forum aufgetaucht ist.

Sind die SQLs, die verwendet werden durch EUCH validiert und haftet Ihr für Fehler?
Hey John,
Kurz gesagt: Nein – wie bei jeder heute nutzbaren KI.
Lässt du askJan SQLs zu einer Fragestellung erzeugen, werden diese nicht im Sinne klassischer Software noch einmal menschlich validiert, und wir übernehmen keine Haftung für deren inhaltliche Richtigkeit.
Wichtig dabei: askJan greift ausschließlich lesend auf Daten zu und nimmt keine Änderungen vor. Die fachliche Prüfung und Verwendung der generierten SQL-Abfragen liegt – wie bei manuell erstelltem SQL – beim Anwender.

Liebe Grüße!
 

ple

Sehr aktives Mitglied
20. August 2019
801
161
Lustig, wie sich der Qualitätsanspruch geändert hat.
Wo haben die sich geändert? Die Qualität sollte immer noch hoch sein, wenn man was kauft. Nur kann der User, der null Ahnung hat, deinen Code sowie den Code einer KI oder meinen einfach nicht bewerten. Da ist eher das Problem, dass die Katze im Sack gekauft wird. Hatte ich auch schon ein paar mal und ein paar hundert € in den Sand gesetzt.
Ki ist wirklich toll, man kann mit Ihr viel und schnell lernen. Grok und Claude nutze ich am liebsten, damit hatte ich bisher die besten Erfahrungen. Aber das man denen blind vertrauen kann, da sind wir noch weit von entfernt, vielleicht in 5 Jahren.
Aber würde ich komplexe Abfragen schnell benötigen, dann wäre KI sicherlich nicht meine erste Wahl.

Gruß
 
  • Gefällt mir
Reaktionen: no80

no80

Sehr aktives Mitglied
28. Juni 2023
579
65
Angehängt der SQL aus Deinem Demo Video.

Es ist genau wie vermutet:

1. Veraltete Datenbankstruktur benutzt.
Die Abfrage funktioniert überhaupt nur noch, weil JTL die inzwischen gelöschten Tabellen (noch) als Views mitschleppt.

2. GROTTENFALSCHES Ergebnis, weil SQL fehlerhaft
Die KI hat eben KEINE Ahnung von der JTL-DB Struktur weil die Trainingsdatenbasis ist zu klein.
Entsprechend wird sich etwas zusammengereimt, was ein falsches Ergebnis liefert.

Euer Tool schaut toll aus. Absolut Respekt dafür. Das bekomme ich so nicht hin.
Das Euch aber der falsche SQL durchrutscht bis ins Werbevideo zeigt, dass Ihr nicht wirklich tief in der JTL SQL Thematik steckt und KI Ergebnisse selbst nicht validieren könnt.

Und damit sollen Kunden ENTSCHEIDUNGEN treffen?!?
Man müsste der KI die Tabelle Zusammenhänge mit geben, oder als json/toon querie definieren.
Bei jeden JTL Update alles gegenprüfen.
 

AlenaMM

Neues Mitglied
8. Januar 2026
18
1
Buchholz in der Nordheide
Firma
askJan
Man müsste der KI die Tabelle Zusammenhänge mit geben, oder als json/toon querie definieren.
Bei jeden JTL Update alles gegenprüfen.
Hallo no80,
Das Datenbankschema wird von askJan bei der ersten Installation und danach in regelmäßigen Abständen geprüft, um der KI ein bestmögliches „Datenbankschema-Werkzeug“ an die Hand zu geben.
Liebe Grüße
 

AlenaMM

Neues Mitglied
8. Januar 2026
18
1
Buchholz in der Nordheide
Firma
askJan
Wo haben die sich geändert? Die Qualität sollte immer noch hoch sein, wenn man was kauft. Nur kann der User, der null Ahnung hat, deinen Code sowie den Code einer KI oder meinen einfach nicht bewerten. Da ist eher das Problem, dass die Katze im Sack gekauft wird. Hatte ich auch schon ein paar mal und ein paar hundert € in den Sand gesetzt.
Ki ist wirklich toll, man kann mit Ihr viel und schnell lernen. Grok und Claude nutze ich am liebsten, damit hatte ich bisher die besten Erfahrungen. Aber das man denen blind vertrauen kann, da sind wir noch weit von entfernt, vielleicht in 5 Jahren.
Aber würde ich komplexe Abfragen schnell benötigen, dann wäre KI sicherlich nicht meine erste Wahl.

Gruß
Ich würde wirklich gern dein Feedback aufgrund deines Fachwissens bekommen. Du scheinst - genau wie wir - schon sehr tief in der KI Materie drinzustecken. Damit du dir einen fundierten Überblick verschaffen kannst, bekommst du von uns Credits zum Testen; um eben nicht hunderte von Euros in den Sand setzen zu müssen!
 

frankell

Sehr aktives Mitglied
9. September 2019
2.372
724
Flensburg
@AlenaMM,

bei der Nutzung von Technologien liegt es natürlich immer in der Verantwortung des Nutzers, dass er sich über das Für und Wider möglichst vollständig im Klaren ist. Wichtig dabei ist Verlässlichkeit. Setzt man Technologien eines etablierten Herstellers ein, der ein Image hat, zu dem Verlässlichkeit gehört, dann hat man es als Nutzer vergleichsweise einfach. Dabei war es in der Vergangenheit eine Selbstverständlichkeit, dass die Verlässlichkeit daher rührte, dass eine Prüfung durch Menschen (idR Experten) stattfand. Denen man im Fall der Fälle auch auf die Finger hauen konnte. Genau das ist aber bei KI nicht der Fall. Kein Anbieter validiert die Ergebnisse, und alle halten schön das Schild "Keine Haftung, auf eigenes Risiko" hoch, loben die Software aber in den allerhöchsten Tönen und vermitteln damit ein Maß an Verlässlichkeit, das zumindest Stand heute noch nicht erreicht ist.

Das ist für unbedarfte Nutzer im Umgang mit geschäftlichen Daten hochriskant und daher eigentlich nur tragbar, wenn ein Nutzer die Validierung selbst übernehmen kann. Das dürfte für 98 % der Nutzer nicht der Fall sein. Passt aber gut in die heutige Zeit, dass "Leistung" und Haftung gänzlich entkoppelt werden.

Ich bin kein Gegner von neuen Technologien und auch nicht von KI. Im Gegenteil: Ich nutze sie gerne als eine Art "Denksprechpartner" und behaupte mal ganz keck von mir, sowohl die Wawi als auch deren Datenbank als auch den aktuellen Qualitätsstand der Software auf der einen und die Leistungsfähigkeit von aktuellen LLMs darauf bezogen sehr gut einschätzen zu können. Ich würde aber im Traum nicht auf die Idee kommen, etwas zu verwenden, das ich nicht selbst verstehe. Nicht für mein eigenes Business, und schon gar nicht für das meiner Kunden.

Wenn eine KI die Wawi wirklich verstehen soll, benötigt sie eine entsprechend große Menge an Trainingsdaten. Da reicht eben nicht nur, die DB-Struktur einzulesen und zu verstehen, wie die Views geschrieben sind, so hilfreich das auch ist. Sie müsste wissen, wie die Applikation geschrieben ist, alle Bugs kennen, also bspw. den Issuetracker sowie das Forum komplett scannen und auch die jeweils genannten Lösungen und Workarounds lernen. Wobei man dann durchaus die Frage beantworten müsste, inwieweit die Urheber dieser Lösungen/Workarounds der Verwendung zum Training überhaupt zugestimmt hätten...

Dass Ihr selbst offenkundig nicht besonders tief in der JTL-Wawi steckt, sieht man recht gut an diesem Thread: https://forum.jtl-software.de/threads/ameise-importiert-artikelbeschreibung-nicht.244032/
Natürlich ist es nicht ausgeschlossen, dass es sich nicht um den von mir genannten Bug handelt, aber aktuell ist es halt noch sehr wahrscheinlich. Deutlich wahrscheinlicher jedenfalls als das, was Eure Software ausspuckt. Sollte sich meine Vermutung als wahr herausstellen, ist das ein echtes Negativbeispiel, was die Leitungsfähigkeit der Software angeht. Denn wenn sie wirklich gut wäre, dann würde sie diesen Bug zumindest erwähnen, gerne als erstes, weil das eben aktuell noch am wahrscheinlichsten ist.

Natürlich wird Eure Software auch Gutes und sehr Hilfreiches produzieren (weil das eben bereits der Fall ist, wenn man mit den üblichen Modellen arbeitet), das will ich hier gar nicht in Frage stellen. Ob etwas aber gut oder zumindest hilfreich ist, das können die allermeisten User nicht sofort erkennen. Was aber noch viel Schlimmer ist: Sie werden nicht erkennen können, wenn etwas wirklich komplett falsch ist, obwohl es super gut und fancy aussieht. Mit all den potentiell negativen Folgen.

Es wird sicher der Tag kommen, an dem die Fehlerquote vernachlässigbar gering ist bzw. der eines handelnden Menschen mit entsprechender Expertise entspricht. Der ist nur noch nicht gekommen. Daher kann ich so ein Angebot wie das Eure nicht für gut heißen, zumindest Stand heute nicht.

By the way: Wie genau sichergestellt ist, dass keine personenbezogenen Daten den Rechner, auf dem die Software läuft, verlassen, ist leider nicht genau dokumentiert. Da muss man sich also auf Euer Wort verlassen. Da aber bereits im Schritt 2 die "lokale" KI und damit wohl "nur" ein "kleines" Modell zum Einsatz kommt, wäre ich da schon skeptisch, ob das als Filter wirklich ausreichend ist. Und dass man die Pseudonymisierung ausschalten kann... Hui!
 
  • Gefällt mir
Reaktionen: John

AlenaMM

Neues Mitglied
8. Januar 2026
18
1
Buchholz in der Nordheide
Firma
askJan
@AlenaMM,

bei der Nutzung von Technologien liegt es natürlich immer in der Verantwortung des Nutzers, dass er sich über das Für und Wider möglichst vollständig im Klaren ist. Wichtig dabei ist Verlässlichkeit. Setzt man Technologien eines etablierten Herstellers ein, der ein Image hat, zu dem Verlässlichkeit gehört, dann hat man es als Nutzer vergleichsweise einfach. Dabei war es in der Vergangenheit eine Selbstverständlichkeit, dass die Verlässlichkeit daher rührte, dass eine Prüfung durch Menschen (idR Experten) stattfand. Denen man im Fall der Fälle auch auf die Finger hauen konnte. Genau das ist aber bei KI nicht der Fall. Kein Anbieter validiert die Ergebnisse, und alle halten schön das Schild "Keine Haftung, auf eigenes Risiko" hoch, loben die Software aber in den allerhöchsten Tönen und vermitteln damit ein Maß an Verlässlichkeit, das zumindest Stand heute noch nicht erreicht ist.

Das ist für unbedarfte Nutzer im Umgang mit geschäftlichen Daten hochriskant und daher eigentlich nur tragbar, wenn ein Nutzer die Validierung selbst übernehmen kann. Das dürfte für 98 % der Nutzer nicht der Fall sein. Passt aber gut in die heutige Zeit, dass "Leistung" und Haftung gänzlich entkoppelt werden.

Ich bin kein Gegner von neuen Technologien und auch nicht von KI. Im Gegenteil: Ich nutze sie gerne als eine Art "Denksprechpartner" und behaupte mal ganz keck von mir, sowohl die Wawi als auch deren Datenbank als auch den aktuellen Qualitätsstand der Software auf der einen und die Leistungsfähigkeit von aktuellen LLMs darauf bezogen sehr gut einschätzen zu können. Ich würde aber im Traum nicht auf die Idee kommen, etwas zu verwenden, das ich nicht selbst verstehe. Nicht für mein eigenes Business, und schon gar nicht für das meiner Kunden.

Wenn eine KI die Wawi wirklich verstehen soll, benötigt sie eine entsprechend große Menge an Trainingsdaten. Da reicht eben nicht nur, die DB-Struktur einzulesen und zu verstehen, wie die Views geschrieben sind, so hilfreich das auch ist. Sie müsste wissen, wie die Applikation geschrieben ist, alle Bugs kennen, also bspw. den Issuetracker sowie das Forum komplett scannen und auch die jeweils genannten Lösungen und Workarounds lernen. Wobei man dann durchaus die Frage beantworten müsste, inwieweit die Urheber dieser Lösungen/Workarounds der Verwendung zum Training überhaupt zugestimmt hätten...

Dass Ihr selbst offenkundig nicht besonders tief in der JTL-Wawi steckt, sieht man recht gut an diesem Thread: https://forum.jtl-software.de/threads/ameise-importiert-artikelbeschreibung-nicht.244032/
Natürlich ist es nicht ausgeschlossen, dass es sich nicht um den von mir genannten Bug handelt, aber aktuell ist es halt noch sehr wahrscheinlich. Deutlich wahrscheinlicher jedenfalls als das, was Eure Software ausspuckt. Sollte sich meine Vermutung als wahr herausstellen, ist das ein echtes Negativbeispiel, was die Leitungsfähigkeit der Software angeht. Denn wenn sie wirklich gut wäre, dann würde sie diesen Bug zumindest erwähnen, gerne als erstes, weil das eben aktuell noch am wahrscheinlichsten ist.

Natürlich wird Eure Software auch Gutes und sehr Hilfreiches produzieren (weil das eben bereits der Fall ist, wenn man mit den üblichen Modellen arbeitet), das will ich hier gar nicht in Frage stellen. Ob etwas aber gut oder zumindest hilfreich ist, das können die allermeisten User nicht sofort erkennen. Was aber noch viel Schlimmer ist: Sie werden nicht erkennen können, wenn etwas wirklich komplett falsch ist, obwohl es super gut und fancy aussieht. Mit all den potentiell negativen Folgen.

Es wird sicher der Tag kommen, an dem die Fehlerquote vernachlässigbar gering ist bzw. der eines handelnden Menschen mit entsprechender Expertise entspricht. Der ist nur noch nicht gekommen. Daher kann ich so ein Angebot wie das Eure nicht für gut heißen, zumindest Stand heute nicht.

By the way: Wie genau sichergestellt ist, dass keine personenbezogenen Daten den Rechner, auf dem die Software läuft, verlassen, ist leider nicht genau dokumentiert. Da muss man sich also auf Euer Wort verlassen. Da aber bereits im Schritt 2 die "lokale" KI und damit wohl "nur" ein "kleines" Modell zum Einsatz kommt, wäre ich da schon skeptisch, ob das als Filter wirklich ausreichend ist. Und dass man die Pseudonymisierung ausschalten kann... Hui!
Guten Morgen frankell,
danke für dein ehrliches und ausführliches Feedback. Wie zuvor erwähnt geht es immer um die User individuellen Einstellungen, die im Installationsprozess (und natürlich folgend) genommen werden. Dabei ging es, wie formuliert, um einen Denkanstoß und nicht um DIE Lösung. Die kann natürlich nur mit den User-Einstellungen für genau den Fehler erzielt werden.
Den Hinweis mit den Bugs nehme ich sehr gern noch mal auf und wir werden prüfen, wie wir diesen "Abgleich" effizienter darstellen können.
Auch du bist herzlich eingeladen dir ein genaues, eigenes Bild zu machen und askJan unverbindlich zu testen. Über einen weiteren fachlichen Austausch würde ich mich sehr freuen! Meld dich gern per PN.
Liebe Grüße und einen angenehmen Sonntag!
 

AlenaMM

Neues Mitglied
8. Januar 2026
18
1
Buchholz in der Nordheide
Firma
askJan
@AlenaMM,

bei der Nutzung von Technologien liegt es natürlich immer in der Verantwortung des Nutzers, dass er sich über das Für und Wider möglichst vollständig im Klaren ist. Wichtig dabei ist Verlässlichkeit. Setzt man Technologien eines etablierten Herstellers ein, der ein Image hat, zu dem Verlässlichkeit gehört, dann hat man es als Nutzer vergleichsweise einfach. Dabei war es in der Vergangenheit eine Selbstverständlichkeit, dass die Verlässlichkeit daher rührte, dass eine Prüfung durch Menschen (idR Experten) stattfand. Denen man im Fall der Fälle auch auf die Finger hauen konnte. Genau das ist aber bei KI nicht der Fall. Kein Anbieter validiert die Ergebnisse, und alle halten schön das Schild "Keine Haftung, auf eigenes Risiko" hoch, loben die Software aber in den allerhöchsten Tönen und vermitteln damit ein Maß an Verlässlichkeit, das zumindest Stand heute noch nicht erreicht ist.

Das ist für unbedarfte Nutzer im Umgang mit geschäftlichen Daten hochriskant und daher eigentlich nur tragbar, wenn ein Nutzer die Validierung selbst übernehmen kann. Das dürfte für 98 % der Nutzer nicht der Fall sein. Passt aber gut in die heutige Zeit, dass "Leistung" und Haftung gänzlich entkoppelt werden.

Ich bin kein Gegner von neuen Technologien und auch nicht von KI. Im Gegenteil: Ich nutze sie gerne als eine Art "Denksprechpartner" und behaupte mal ganz keck von mir, sowohl die Wawi als auch deren Datenbank als auch den aktuellen Qualitätsstand der Software auf der einen und die Leistungsfähigkeit von aktuellen LLMs darauf bezogen sehr gut einschätzen zu können. Ich würde aber im Traum nicht auf die Idee kommen, etwas zu verwenden, das ich nicht selbst verstehe. Nicht für mein eigenes Business, und schon gar nicht für das meiner Kunden.

Wenn eine KI die Wawi wirklich verstehen soll, benötigt sie eine entsprechend große Menge an Trainingsdaten. Da reicht eben nicht nur, die DB-Struktur einzulesen und zu verstehen, wie die Views geschrieben sind, so hilfreich das auch ist. Sie müsste wissen, wie die Applikation geschrieben ist, alle Bugs kennen, also bspw. den Issuetracker sowie das Forum komplett scannen und auch die jeweils genannten Lösungen und Workarounds lernen. Wobei man dann durchaus die Frage beantworten müsste, inwieweit die Urheber dieser Lösungen/Workarounds der Verwendung zum Training überhaupt zugestimmt hätten...

Dass Ihr selbst offenkundig nicht besonders tief in der JTL-Wawi steckt, sieht man recht gut an diesem Thread: https://forum.jtl-software.de/threads/ameise-importiert-artikelbeschreibung-nicht.244032/
Natürlich ist es nicht ausgeschlossen, dass es sich nicht um den von mir genannten Bug handelt, aber aktuell ist es halt noch sehr wahrscheinlich. Deutlich wahrscheinlicher jedenfalls als das, was Eure Software ausspuckt. Sollte sich meine Vermutung als wahr herausstellen, ist das ein echtes Negativbeispiel, was die Leitungsfähigkeit der Software angeht. Denn wenn sie wirklich gut wäre, dann würde sie diesen Bug zumindest erwähnen, gerne als erstes, weil das eben aktuell noch am wahrscheinlichsten ist.

Natürlich wird Eure Software auch Gutes und sehr Hilfreiches produzieren (weil das eben bereits der Fall ist, wenn man mit den üblichen Modellen arbeitet), das will ich hier gar nicht in Frage stellen. Ob etwas aber gut oder zumindest hilfreich ist, das können die allermeisten User nicht sofort erkennen. Was aber noch viel Schlimmer ist: Sie werden nicht erkennen können, wenn etwas wirklich komplett falsch ist, obwohl es super gut und fancy aussieht. Mit all den potentiell negativen Folgen.

Es wird sicher der Tag kommen, an dem die Fehlerquote vernachlässigbar gering ist bzw. der eines handelnden Menschen mit entsprechender Expertise entspricht. Der ist nur noch nicht gekommen. Daher kann ich so ein Angebot wie das Eure nicht für gut heißen, zumindest Stand heute nicht.

By the way: Wie genau sichergestellt ist, dass keine personenbezogenen Daten den Rechner, auf dem die Software läuft, verlassen, ist leider nicht genau dokumentiert. Da muss man sich also auf Euer Wort verlassen. Da aber bereits im Schritt 2 die "lokale" KI und damit wohl "nur" ein "kleines" Modell zum Einsatz kommt, wäre ich da schon skeptisch, ob das als Filter wirklich ausreichend ist. Und dass man die Pseudonymisierung ausschalten kann... Hui!
Vielen Dank für deine ausführliche und fachlich fundierte Einordnung – viele der angesprochenen Punkte sind absolut nachvollziehbar. Ich möchte auf ein paar deiner angesprochenen Punkte gern näher eingehen:

askJan ist ein Assistenzsystem, das Wissen strukturiert zugänglich macht und Analyseprozesse unterstützt. Entsprechend handelt es sich nicht um eine „trainierte JTL-KI“, sondern um ein RAG-basiertes System, das etablierte große Sprachmodelle mit JTL-spezifischem Kontext und Regeln kombiniert.

Als externer Anbieter haben wir keinen Zugriff auf interne JTL-Quellcodes, vollständige Issue-Tracker oder alle historischen Sonderfälle. askJan kann daher (noch) nicht jeden bekannten Bug automatisch priorisieren. Vielleicht kommt sowas in Zukunft ja noch aber da müssen wir sicher mit JTL drüber sprechen. Ziel ist es also, Hypothesen, Ansatzpunkte und Struktur zu liefern.

Wir kennen uns sehr gut mit JTL aus, da wir auf der Basis von JTL selbst in der Vergangenheit einige Unternehmen „auf die Beine gestellt haben“ und uns dabei ein Tool wie askJan selbst gewünscht hätten. askJan erhebt nicht den Anspruch alle JTL-Probleme zu lösen aber es kann helfen eine Antwort oder Insights zu liefern - probiere es doch selbst aus. Es soll Orientierung geben, Analysen beschleunigen und neue Blickwinkel eröffnen – insbesondere für Nutzer, die Ergebnisse einordnen möchten, ohne jedes Thema selbst vollständig durchdringen zu müssen.

Datenschutz und Pseudonymisierung sind fester Bestandteil der Architektur und standardmäßig aktiv. Gleichzeitig setzen wir bewusst auf Transparenz und Kontrolle statt auf blinde Automatisierung. Aber hier liegt der verantwortungsvolle Umgang natürlich auch beim User, wie bei jedem Umgang mit sensiblen Daten. Da die Eingabeerkennung recht sensitiv eingestellt ist, kann der User die Erkennung auch manuell „overpowern“.

Schau gern mal rein und gib uns dein fundiertes Feedback. Konstruktiver Diskurs ist bei uns immer willkommen.
 

John

Sehr aktives Mitglied
3. März 2012
3.919
964
Berlin

Super!
Schreib doch mal eben den korrekten SQL für den von mir als fehlerhaft bemängelten Code.
Bitte ohne Referenz auf veraltete Tabellen.

Ansonsten kann ich @frankell vollumfänglich zustimmen.
Der Tag, an dem KI und JTL auch nur ansatzweise brauchbar korrekte Resultate liefert, ist der Tag, an dem ich bei Euch richtig gut Geld lassen und meine Produktivität vervielfachen werde.
Ich sehe den Tag aber nicht einmal ansatzweise am Horizont, weil die Traningsdaten nicht vorhanden sind und KI nunmal heute eine wahrscheinblichkeitsbewertene Aussagewiederholungsmaschine ist.
Es ist aktuell ein ungeeignetes Werkzeug, das nicht für Endnutzer geeignet ist, weil sie das Ergebnis nicht validieren können.

Im Bezug auf JTL SQL wird das überdeutlich.
Neben ein paar wenigen Mitgliedern hier im Forum und eine paar Servicepartner Blog Einträgen gibt es keine Veröffentlichungen.
Wo sollen die Trainigsdaten herkommen?
 
  • Gefällt mir
Reaktionen: ple

John

Sehr aktives Mitglied
3. März 2012
3.919
964
Berlin
...ich habe mir das mal zum Spaß installiert.

1. Frage (wie in der angesprochenen Demo)
Wann verkaufe ich am Besten?

Benutzter SQL (aufgenommen mit dem Profiler)
Code:
SELECT
 DATEPART(HOUR, dErstellt) AS Stunde,
 COUNT(*) AS AnzahlBestellungen,
 ROUND(SUM(fVersandBruttoPreis), 2) AS GesamtUmsatz
FROM tBestellung
WHERE dErstellt IS NOT NULL
 AND DATEPART(YEAR, dErstellt) = 2025 -- Aktuelles Jahr
 AND DATEPART(HOUR, dErstellt) BETWEEN 6 AND 22 -- Hauptgeschäftszeiten
GROUP BY DATEPART(HOUR, dErstellt)
ORDER BY AnzahlBestellungen DESC

-> Die Versandkosten der Aufträge werden als Gesamtumsatz interpretiert.
Die gleiche Frage mehrfach stellen (auch mit anderen Sprachmodellen) führte zu unterschiedlichen Ergebnissen im SQL, von denen eines korrekt aussah.


2. Frage
"Artikel mit Artikelnummer 79. Wert des Eigenen Feldes mit dem Namen Integer?

Antwort
Erstmal Warnung nach möglichem Risiko für personenbezogene Daten abnicken.
Jan denkt nach....
Ergebnis: Viel Text, den mir zu lesen zu langatmig war.
Der Wert des Eigenen Feldes wurde nicht ausgegeben.


Mein Fazit
Ja, was soll ich sagen...als Denkhilfe für Kunden, die SQL validieren können, mag das im Ansatz interessant sein.
Für den normalen User ist es leider ein Werkzeug mit sehr hohem Potential zur versteckten Falschaussage mit der Gefahr auf Basis unentdeckt falscher Antworten falsche Entscheidung zu treffen.
Die Frage, ob einem kein Wissen gratis oder Wissen mit unbekannter Richtigkeit erkauft lieber ist, mag jeder selbst beurteilen.

Ich finde Eurer Engagement in kritisches Neuland bei bekannt mieser Datenlage mutig und interessant zu beobachten und wünsche viel Erfolg.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: frankell und no80

AlenaMM

Neues Mitglied
8. Januar 2026
18
1
Buchholz in der Nordheide
Firma
askJan
...ich habe mir das mal zum Spaß installiert.

1. Frage (wie in der angesprochenen Demo)
Wann verkaufe ich am Besten?

Benutzter SQL (aufgenommen mit dem Profiler)
Code:
SELECT
 DATEPART(HOUR, dErstellt) AS Stunde,
 COUNT(*) AS AnzahlBestellungen,
 ROUND(SUM(fVersandBruttoPreis), 2) AS GesamtUmsatz
FROM tBestellung
WHERE dErstellt IS NOT NULL
 AND DATEPART(YEAR, dErstellt) = 2025 -- Aktuelles Jahr
 AND DATEPART(HOUR, dErstellt) BETWEEN 6 AND 22 -- Hauptgeschäftszeiten
GROUP BY DATEPART(HOUR, dErstellt)
ORDER BY AnzahlBestellungen DESC

-> Die Versandkosten der Aufträge werden als Gesamtumsatz interpretiert.
Die gleiche Frage mehrfach stellen (auch mit anderen Sprachmodellen) führte zu unterschiedlichen Ergebnissen im SQL, von denen eines korrekt aussah.


2. Frage
"Artikel mit Artikelnummer 79. Wert des Eigenen Feldes mit dem Namen Integer?

Antwort
Erstmal Warnung nach möglichem Risiko für personenbezogene Daten abnicken.
Jan denkt nach....
Ergebnis: Viel Text, den mir zu lesen zu langatmig war.
Der Wert des Eigenen Feldes wurde nicht ausgegeben.


Mein Fazit
Ja, was soll ich sagen...als Denkhilfe für Kunden, die SQL validieren können, mag das im Ansatz interessant sein.
Für den normalen User ist es leider ein Werkzeug mit sehr hohem Potential zur versteckten Falschaussage mit der Gefahr auf Basis unentdeckt falscher Antworten falsche Entscheidung zu treffen.
Die Frage, ob einem kein Wissen gratis oder Wissen mit unbekannter Richtigkeit erkauft lieber ist, mag jeder selbst beurteilen.

Ich finde Eurer Engagement in kritisches Neuland bei bekannt mieser Datenlage mutig und interessant zu beobachten und wünsche viel Erfolg.
Vielen Dank, dass du dir die Zeit genommen hast, askJan selbst zu installieren und anhand eines konkreten Beispiels zu testen.
Genau dieses praxisnahe Feedback ist für uns wertvoll.

Zu deinem ersten Beispiel („Wann verkaufe ich am besten?“):
Das von dir mitgeloggte SQL-Statement ist fachlich tatsächlich nicht korrekt, da hier Versandkosten als Umsatz interpretiert werden. Wichtig für das Verständnis ist allerdings die Arbeitsweise von askJan: askJan arbeitet iterativ. Das heißt, es werden intern mehrere Ansätze erzeugt, ausgeführt und anhand der Ergebnisse geprüft. Einzelne SQL-Statements, die während dieses Prozesses entstehen, sind Zwischenschritte und nicht zwingend die Grundlage der finalen Auswertung. Maßgeblich ist immer das Statement, das am Ende zur Ergebnisdarstellung herangezogen wird – nicht jede Variante, die unterwegs ausprobiert wird.
Dass bei identischer Fragestellung unterschiedliche SQL-Ansätze entstehen können, ist daher kein Zufall, sondern Teil dieses iterativen Vorgehens. askJan nähert sich so schrittweise der fachlichen Auswertung an, statt starr auf einem festen Query zu bestehen.

Zu deinem zweiten Beispiel (Eigenes Feld / Artikelnummer 79):
Die vorgeschaltete Warnung zur möglichen Verarbeitung sensibler Inhalte ist bewusst defensiv ausgelegt. Dass in diesem Fall kein Ergebnis geliefert wurde, zeigt, dass askJan hier eher zurückhaltend agiert, als unklare oder potenziell problematische Annahmen zu treffen.

Deinen abschließenden Kommentar zu unserem Engagement verstehen wir ausdrücklich als Kompliment.
Wir bewegen uns ganz bewusst in einem anspruchsvollen und komplexen Umfeld. askJan erhebt dabei nicht den Anspruch, jedes Problem vollständig zu lösen, sondern versteht sich als Werkzeug, datenbezogene Fragestellungen, sowie Analyse- und Auswertungsprozesse für z.B. operative User deutlich zu beschleunigen und zu strukturieren, um so u.a. Routine- und Suchaufwände zu reduzieren und letztendlich Zeit für fachliche Bewertung, Entscheidungen und andere wichtige Themen zu schaffen. Genau aus Rückmeldungen wie deiner lernen wir und entwickeln askJan Schritt für Schritt weiter.
Vielen Dank für die offene und sachliche Kritik.
 

merres

Gut bekanntes Mitglied
28. März 2024
108
90
Hallo miteinander,

da ich schon sehr viele Stunden in ein ähnliches System gesteckt habe, inklusive Fine-Tuning von eigenen Modellen, aber bisher mit den Ergebnissen nicht so zufrieden war, um das produktiv auf Kunden loszulassen, wollte ich hier auch mal meinen Senf loswerden :p
Erst mal Respekt, dass ihr das Produkt auf die Beine gestellt habt. UI sieht schick aus und Gesamtauftritt macht auch was her.

Ich finde die Kritik von @John und @frankell allerdings berechtigt und anhand der Schilderungen von John die Ergebnisse des Tools nicht ausreichend.

Gerade wenn es um die Beispiele von John geht, bringt es nichts, wenn das System "iterativ" vorgeht. Eine solche Anfrage muss euer System intern schon vorhalten (z.B. per RAG) um auf keinen Fall einen solch gravierenden Fehler zu machen, wie den Gesamtumsatz aus Versandkosten zu berechnen.
Eigene Felder im Kontext von Kunden und Aufträgen sind eigentlich auch absoluter Standard und sollten entweder über den System-Prompt oder ebenfalls per RAG abgedeckt werden. Mich würde interessieren, woran das in eurem Setup scheitert.

Rein von der Architektur her frage ich mich ob ein lokales LLM für die PII-Daten wirklichen Mehrwert bringt. Wenn man sich mit der DB von JTL auskennt, kann man die entsprechenden Tool-Calls eigentlich so einrichten, dass beim Abruf von bestimmten Tabellen nur Pseudo-Daten rausgehen. Am Ende des Tages sorgt ein lokales LLM bzw. SLM ja nur für weitere Latenz in der Abfrage, vor allem, wenn es auf der CPU läuft. Ja, man kann hier die kleinen Gemma Modelle oder sowas wie Qwen 0.3B nehmen, die recht fix sind und sich auch gut finetunen lassen...aber ich glaube das braucht es nicht zwingend, da die kritischen Tabellen im Fall von JTL schon klar sind.

Für produktiven Kundeneinsatz wäre mir das noch zu riskant, eine Beta-Phase zum Sammeln von Fällen könnte das schnell robuster machen. Den jetzigen Stand finde ich bis jetzt nicht ausreichend, wünsche euch aber trotzdem viel Erfolg.

LG
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: no80

Ähnliche Themen