ERP-Daten mit KI auswerten – ohne das ERP neu zu bauen.

Wo das Wissen liegt

Sieben Orte, an denen Ihre Geschäftslogik tatsächlich steht.

Diese Aufstellung ist der Grund, warum ein allgemeines Sprachmodell eine gewachsene Unternehmensdatenbank nicht von selbst fachlich richtig interpretiert.

• Datenbankstrukturen

  Welche Tabelle das führende Geschäftsobjekt enthält und welche eine Nebenrechnung – das Schema sagt es nicht. Namen aus drei Epochen stehen nebeneinander, und der Tabellenname ist in gewachsenen Systemen selten ein verlässlicher Hinweis.

• Tabellenbeziehungen

  Ein Teil der fachlichen Zusammenhänge ist als Fremdschlüssel hinterlegt, ein anderer nicht. Verknüpfungen, die nur im Programmcode existieren, sind aus dem Schema nicht erkennbar – für eine Auswertung sind sie trotzdem entscheidend.

• Statuswerte

  Eine Spalte enthält Zahlen von 1 bis 9. Welche davon „abgeschlossen“ bedeuten, welche nur historisch vorkommen und welche seit einem Release von 2019 nicht mehr vergeben werden, ergibt sich aus dem Code und nicht aus den Daten.

• Sourcecode

  Die meisten Kennzahlen sind berechnet und nicht gespeichert. Ob ein Auftrag als offen zählt, wie ein Storno verrechnet wird, ab wann ein Kunde inaktiv ist: Das steht als Fallunterscheidung in einer Methode und in keiner Tabelle.

• Validierungslogik

  Was das System beim Speichern verhindert, sagt viel darüber, was in den Daten vorkommen kann und was nicht. Eine Auswertung, die Fälle berücksichtigt, die es fachlich gar nicht gibt, rechnet an der Wirklichkeit vorbei.

• Historische Sonderfälle

  Die Migration von damals, das Feld, das zwei Bedeutungen hatte, die Kundengruppe mit eigener Abrechnungslogik. Solche Fälle kennt eine Handvoll Menschen im Haus – und jede Auswertung, die sie übersieht, sieht trotzdem plausibel aus.

• Geschäftsregeln

  Die Definitionen, nach denen Ihr Haus rechnet: Neukunde, Bestandskunde, offener Vorgang, Stornoquote, Durchlaufzeit. Jedes Unternehmen legt sie anders fest, und genau deshalb kann kein Modell sie mitbringen.

Ein allgemeines Sprachmodell sieht von alldem nur die Tabellen- und Spaltennamen. Den Rest muss es erraten – und es rät plausibel, was den Fehler schwerer erkennbar macht als ein offensichtlich falsches Ergebnis.

Beispielfragen

Fragen, für die heute jemand eine Auswertung bauen müsste.

Vier Fragestellungen aus dem operativen Alltag – jeweils mit dem, was dafür fachlich feststehen muss. Sie zeigen die Art von Frage, um die es geht.

• „Welche Bestandskunden bestellen deutlich weniger als im Vorjahr?“

  Setzt voraus: eine Definition von Bestandskunde, zwei nach derselben Regel gebildete Zeiträume und eine Festlegung, ab wann ein Rückgang „deutlich“ ist. Ohne diese drei Festlegungen ist die Frage nicht falsch beantwortet, sondern gar nicht beantwortbar.

• „Welche Aufträge sind ungewöhnlich lange offen?“

  Setzt voraus: welche Statuswerte als offen gelten, ab welchem Ereignis die Laufzeit zählt und woran sich „ungewöhnlich“ misst – am Durchschnitt, am Auftragstyp oder an einer vereinbarten Frist.

• „Welche Neukunden haben bereits mehrfach bestellt?“

  Setzt voraus: die Abgrenzung von Neukunde und Bestandskunde, die fachliche Verknüpfung zwischen Kunde und Bestellung und die Entscheidung, welche Bestellungen zählen – stornierte, retournierte, noch nicht bezahlte.

• „Bei welchen Produktgruppen verändert sich das Buchungsverhalten?“

  Setzt voraus: eine eindeutige Zuordnung von Artikeln zu Produktgruppen über den ganzen Zeitraum – und eine Antwort auf die Frage, was mit Gruppen passiert, die es zwischenzeitlich umbenannt oder neu geschnitten hat.

Diese Fragen sind Beispiele für mögliche Fragestellungen und keine Zusage, dass sie in jedem System beantwortbar sind. Ob eine bestimmte Frage in Ihrem System trägt, hängt davon ab, ob die dafür nötigen Begriffe beschrieben werden können – und das zeigt sich am Datenmodell, nicht an einer Liste auf einer Website.