Die neue Mode in der Unternehmens-KI: „Frag dein ERP auf Deutsch". Der Inhaber tippt „Wieviel haben wir im August mit Kunde X verdient?" in ein Chatfenster, das Modell übersetzt das in SQL, geht auf die Datenbank, liefert eine Zahl. In der Demo wirkt das wie Magie. In Produktion liefert es Zahlen, die es schlicht nicht gibt.
Dieser Text sagt nicht, dass KI „nicht funktioniert". Text-to-SQL funktioniert und ist in bestimmten Einsatzfeldern wirklich nützlich. Es geht um etwas anderes: um eine Voraussetzung, ohne die aus der Magie ein sehr teurer Generator plausibel wirkenden Unsinns wird. Diese Voraussetzung erfüllt fast kein KMU von Anfang an — und der Anbieter, der es verkauft, sagt das üblicherweise nicht.
Wo die Magie zerbricht
Text-to-SQL scheitert in KMU nicht, weil das Sprachmodell zu schwach ist. Es scheitert aus drei Gründen, und die sind immer dieselben.
Erstens — die Tabellen in Ihrem ERP sind kryptisch. Comarch Optima, enova365, Subiekt, Microsoft Dynamics AX halten Daten in Tabellen mit Namen wie CDN.TraNag, K_KLIENT, TWG_ID. Spalten heißen Kwo, TrN_TrNId, Typ_dokumentu. Das Modell hat keine Ahnung, dass Kwo ein Nettobetrag ist und TrN_TrNId eine Transaktions-Kopf-ID. Es rät — mal richtig, mal nicht. Niemand prüft es, weil die Antwort überzeugend klingt.
Zweitens — die Definition von „Umsatz" ist in Ihrem Unternehmen nicht eindeutig. Fragen Sie drei Personen in einem 30-Personen-Betrieb „Wieviel haben wir im August verkauft?", und Sie bekommen vier Antworten. Denn „verkauft" heißt: Betrag auf Rechnungen (was ist mit Gutschriften?), auf Bestellungen (was ist mit stornierten?), auf Warenausgängen (was ist mit Retouren?), nach Verkaufsdatum oder Rechnungsdatum (was ist mit verspätet ausgestellten Rechnungen?). Das Modell weiß das nicht. Es fragt das erste Feld ab, das plausibel aussieht — und legt Ihnen eine Zahl vor.
Drittens — das Modell halluziniert Beziehungen zwischen Tabellen. Klassischer Fall: die Frage „Wieviel haben wir mit Kunde X verdient?" verlangt, Rechnungen mit dem Einkaufspreis zu verknüpfen (um die Marge zu berechnen). In den meisten ERPs liegt der Einkaufspreis in einer ganz anderen Tabelle als der Verkauf, und der Join-Schlüssel ist nicht offensichtlich (Artikelcode mit Suffix, Variante, Mengeneinheit). Das Modell klebt das über Spaltennamenähnlichkeit zusammen. Sie bekommen eine Zahl, die wie eine Marge aussieht — und keine Marge ist.
Ein konkretes Beispiel aus diesem Jahr
Bei einem unserer Kunden — einem 40-Personen-Großhändler für Möbelteile bei Wrocław, der mit Comarch Optima arbeitet — kaufte der Inhaber bei einem externen Anbieter einen „intelligenten Reporting-Assistenten". Der Pilot lief drei Wochen und kostete 28.000 PLN.
Die ersten zwei Wochen waren alle begeistert. „Wieviel Artikel X haben wir im Juli verkauft?" — funktionierte. „Welcher Vertriebler hatte letzten Monat die meisten Aufträge?" — funktionierte. „Zeig die Top-10-Kunden nach Umsatz" — funktionierte. In der dritten Woche fragte der Inhaber nach der Marge einer bestimmten Produktgruppe. Das Modell antwortete: „24,3 %". Eine schöne, konkrete Zahl.
Drei Tage später rechnete die Buchhalterin dieselbe Zahl von Hand nach — für einen Bankbericht. Es kamen 11,8 % heraus. Die Differenz kommt daher, dass das Modell den Verkauf mit dem letzten Einkaufspreis aus dem Artikelstamm verknüpft hatte — die Einkaufspreise waren in diesem Unternehmen im Laufe des Jahres aber um einen niedrigen zweistelligen Prozentsatz gestiegen. Die tatsächliche Marge rechnet sich aus dem Einkaufspreis der konkreten Lieferung, aus der die Ware ausgeliefert wurde. Das wusste das Modell nicht, weil ihm es niemand gesagt hatte. Es hat geraten. Es hat falsch geraten.
Wäre die Preisentscheidung für September auf dieser Zahl gefallen, hätte das Unternehmen ein volles Quartal lang die halbe Sortimentsbreite subventioniert.
Wann Text-to-SQL wirklich funktioniert
Nach dieser Lektion haben wir dasselbe Unternehmen zu einem vernünftigen Piloten geführt. Das dauerte sechs Wochen und verlangte drei Dinge.
Eine Reporting-Schicht statt roher ERP-Tabellen. Statt dem Modell 400 Comarch-Optima-Tabellen zu zeigen, haben wir sechs „Reporting-Views" (SQL-Views) mit klar benannten Spalten gebaut: nettoumsatz_beleg, einkaufspreis_lieferung, marge_betrag, belegdatum, verkaufsdatum. Das Modell sieht nur diese Views. Es kann keine falsche Tabelle abfragen, weil es für das Modell keine falschen Tabellen gibt.
Ein schriftliches Glossar der Geschäftsbegriffe. Zum Piloten gehört ein einseitiges Dokument: was hier „Verkauf", „Marge", „Umsatz", „aktiver Kunde" genau bedeutet. Ohne dieses Dokument liefert selbst die Fassung mit Views auf dieselbe Frage unterschiedliche Zahlen, weil das Modell Wörter auf eigene Art interpretiert. Das Glossar entstand in einem vierstündigen Termin zwischen Inhaber und Buchhalterin — und war der schwierigste Teil des Projekts, denn dabei kam heraus, dass die beiden bisher untereinander uneins gewesen waren.
Ein Mensch zwischen Modell und Entscheidung. Alle Zahlen, mit denen das Unternehmen Preise ändert, mit Lieferanten verhandelt oder Verträge über 20.000 PLN abschließt, gehen über die Augen der Buchhalterin. Das Modell beschleunigt die Arbeit — es ersetzt nicht die Verantwortung. Banal, aber Sie wären überrascht, wie viele Rollouts das „vergessen".
Nach diesem Piloten bekommt der Inhaber in einer Minute Antworten auf 80 % der typischen Fragen, die vorher 2–3 Stunden Excel-Arbeit der Buchhalterin verlangten. Die restlichen 20 % (komplexe Mehrperiodenauswertungen, Korrekturen, Sonderbelege) macht weiterhin die Buchhalterin — und das ist in Ordnung.
Was vor dem Piloten zu tun ist
Wenn Ihnen jemand Text-to-SQL für Ihr ERP anbietet, fragen Sie vor der Unterschrift vier Dinge.
- Auf welcher Datenschicht wird das Modell arbeiten? Auf rohen ERP-Tabellen (weglaufen) oder auf vorbereiteten Views und semantischen Modellen (weiterreden)?
- Wer erstellt das Glossar der Geschäftsbegriffe, und wann? Wenn die Antwort lautet „das Modell versteht das aus dem Kontext" — wird es das nicht. Diese Arbeit muss jemand leisten, der Ihr Unternehmen kennt.
- Wie werden die vom Modell gelieferten Zahlen validiert? Wird im ersten Monat jede Antwort mit einer manuellen Berechnung abgeglichen? Gibt es einen Audit, der „24,3 % statt 11,8 %" auffängt?
- Was passiert, wenn das Modell falsch antwortet? Zeigt die Oberfläche das erzeugte SQL, damit die Buchhalterin prüfen kann, welche Tabellen benutzt wurden? Gibt es einen Knopf „das ist falsch, korrigiere die Definition"?
Wenn der Anbieter diese Fragen mit „das erledigt die KI" abwiegelt, haben Sie es mit einer Demo zu tun, nicht mit einem Produkt. In polnischen KMU funktioniert die Demo drei Wochen. Danach trifft jemand darauf eine Entscheidung, und die Probleme fangen an.
Wie weiter
Text-to-SQL ist kein Unsinn. Es ist ein Werkzeug, das bei richtiger Einrichtung dem Inhaber und dem Buchhaltungsteam über zehn Stunden pro Monat spart. Aber „richtige Einrichtung" ist nicht die Lizenz und ein Login zum ERP. Es ist eine Reporting-Schicht, ein Glossar der Begriffe und ein Mensch, der darauf achtet, dass die Zahlen am Ende des Tages stimmen.
Wenn Ihnen so etwas gerade angeboten wird oder Sie selbst über einen Piloten nachdenken — es lohnt sich, eine halbe Stunde mit jemandem zu sprechen, der so etwas in anderen KMU aufgesetzt und gesehen hat, wo solche Projekte auseinanderfallen. Das erste Gespräch ist kostenlos.
Ein Sprachmodell kennt Ihr Unternehmen nicht. Es kennt Spaltennamen — und rät, was sie bedeuten. Ohne Glossar und Reporting-Schicht rät es falsch.