SAP B1 Blog

Dies ist der erste Beitrag einer neuen Reihe auf diesem Blog. Sie beschäftigt sich mit den Möglichkeiten von künstlicher Intelligenz im direkten Zusammenspiel mit SAP Business One. Das soll keine Sammlung von Produktankündigungen werden. Es ist vielmehr der Versuch, grundlegende KI-Themen einmal in Ruhe durchzudenken. Reinforcement Learning, Reward-Modelle, Verifikation, Agenten, was auch immer als nächstes durch die Konferenzvorträge geistert: Jede Folge nimmt sich einen dieser Begriffe vor und stellt am Ende dieselbe Frage — was davon tatsächlich im ERP-Alltag ankommt, und was Vokabular bleibt, das sich gut verkauft. Los geht es mit einem Begriff, der derzeit besonders häufig fällt: RLHF.

Weiterlesen: RLHF und Reward-Modelle: Was hinter dem KI-Hype steckt — und was der Genehmigungsprozess in SAP Business One damit zu tun hat

Die gesunkene Hürde — und was sie am Nachdenken ändert

Man könnte meinen, eine neue Prozessidee scheitert im Mittelstand vor allem an fehlendem Einfallsreichtum — es fehle schlicht an guten Ideen, was man anders machen könnte. Tatsächlich scheitert sie in aller Regel früher, nämlich schon an der stillen Vorab-Kalkulation, was die Umsetzung kosten würde — noch bevor irgendjemand die Idee zu Ende gedacht hat. Genau diese Vorab-Kalkulation ist derzeit in Bewegung.

Die Hürde, die früher zwischen einer Prozessidee und ihrer Umsetzung stand, ist dank künstlicher Intelligenz niedriger geworden. Was vor kurzem noch eine Grundsatzentscheidung mit Beratertagen, Lastenheft und langer Vorlaufzeit war, lässt sich heute schneller und mit weniger Aufwand angehen. Manches, was vor kurzem schlicht nicht in Frage kam, weil es zu aufwendig gewesen wäre, es überhaupt zu probieren, ist inzwischen machbar geworden.

Die naheliegende Folgerung wäre, jetzt mehr Software zu kaufen. Die naheliegendere Folgerung ist eine andere: anders zu denken. Wer die Umsetzungshürde nicht mehr als Erstes im Kopf haben muss, kann von den eigenen Prozessen her denken statt vom vermeintlich Machbaren her. Die Frage verschiebt sich von “Was können wir uns leisten, zu bauen?” zu “Was würde uns eigentlich helfen?” und “Was davon ist mit künstlicher Intelligenz NICHT möglich?” — und das ist keine kleine Verschiebung.

Künstliche Intelligenz hilft Prozesse zu denken

Das eigentliche Zukunftsmodell liegt deshalb nicht in der Technik selbst, sondern davor. Klarheit über die eigenen Prozesse, Ansprüche und Wünsche ist eseziell . Wer weiß, wo im Tagesgeschäft es hakt, welche Entscheidung immer wieder händisch getroffen wird, welche Information nie da ist, wo sie gebraucht wird, hat bereits die halbe Arbeit erledigt . Das gilt unabhängig davon, was am Ende daraus umgesetzt wird. Und genau dieses Klarwerden lässt sich gut gemeinsam mit einer Künstlichen Intelligenz durchdenken, nicht erst die anschließende Umsetzung. Ein Gespräch, in dem man die eigene Unzufriedenheit mit einem Prozess in Worte fasst und dabei Rückfragen bekommt, schärft die Idee oft schneller als jedes Lastenheft.

Was das konkret bedeutet, zeigt sich später in diesem Text an einem einzelnen Beispiel aus SAP Business One: einer Funktion, die dort schon länger unauffällig ihren Dienst tut und sich, genau betrachtet, in denselben Begriffen beschreiben lässt wie das, was gerade zum Nachdenken über eigene Prozesse gesagt wurde. Heute lohnt es sich, solche Gedanken trotzdem durchzuspielen — allein deshalb, weil die Distanz zwischen Idee und Prüfung kleiner geworden ist.

Ein Affe, viele Versuche, ein Prüfer, der auswählt

Die Erwartung ist bekannt: Ein KI-Modell tippt heute einfach die richtige Antwort, druckreif und auf Anhieb. So klingt es jedenfalls in etlichen Beratungsangeboten, die derzeit mit dem Zusatz “KI-gestützt” durch die Postfächer des Mittelstands gehen.

Tatsächlich läuft es meist andersherum. Unter dem Namen “Large Language Monkeys Project” (ernst gemeint, nicht ironisch) ist eine Untersuchung bekannt geworden, die nachweist, was das unendliche Affentheorem behauptet. Im Grund sagt es : Lässt man genug Affen genug oft auf einer Schreibmaschine herumtippen, kommt irgendwann auch ein Shakespeare-Text heraus. Übertragen auf ein Sprachmodell heißt das: Nicht ein perfekter Wurf entscheidet, sondern zehntausend Würfe. Zusätzlich benötigt man jemand der aus diesen zehntausend die richtigen heraussucht. Kleinere Modelle wie Llama 3B, 7B oder 8B lagen dabei mit einem einzigen Antwortversuch noch hinter dem damals aktuellen GPT-4o zurück. Als aber genug Samples pro Aufgabe erzeugt und anschließend geprüft wurden, zogen sie vorbei.

Nebenbei bemerkt: Dieselben Modelle lösen heute auch Aufgaben, die im Prompt nur beschrieben, aber nicht mit Trainingsdaten hinterlegt wurden. “Few-shot” oder “Zero-shot” nennt sich das, und es erklärt, warum ein KI-System heute mehr kann als bloßes Textvervollständigen. Vorher lohnt aber erst der Blick auf die Mechanik hinter dem Affentheorem selbst. Es geht um das Zusammenspiel von Erzeugen und Prüfen.

Vom Fragenkatalog zum Prüfer: wie RLHF und Verifikation zusammenspielen

Der RLHF-Loop in vier Schritten

RLHF steht für “Reinforcement Learning from Human Feedback”, also dem Verstärkungslernen aus menschlichem Feedback. Gemeinsam mit dem Instruction Tuning war es die entscheidende Zutat, die aus einem reinen Textvervollständiger den interaktiven künstliche Intelligenz machte. Der Ablauf dahinter ist nüchterner, als das Wort vermuten lässt, und läuft in vier Schritten.

1. Das Modell erzeugt zu ein und derselben Frage mehrere Antwortkandidaten.
2. Menschen, teils Fachleute, teils gewöhnliche Nutzer, bewerten diese Kandidaten nach Kriterien wie Korrektheit, Nützlichkeit und Harmlosigkeit. Welche Antwort ist besser, welche schlechter.
3. Aus genau diesen Bewertungen wird ein eigenes Modell trainiert, das sogenannte Reward-Modell. Es lernt danbei, menschliche Präferenzen automatisch nachzubilden.
4. Dieses Reward-Modell steuert dann in einem weiteren Trainingsschritt die Parameter des eigentlichen Sprachmodells so, dass künftig eher die Antworten entstehen, die hoch bewertet würden.

Am Ende steht ein Modell, das nicht mehr nur “irgendetwas Plausibles” ausgibt. Es soll sich das an menschlichen Werten und Präferenzen aurichten.

Verifikation: eine zweite, oft unterschätzte Instanz

Der RLHF-Loop passiert einmal, beim Training eines eines Modells. Davon zu unterscheiden ist ein zweiter Mechanismus. Dieser greift bei jeder einzelnen Anfrage nachdem das Training längst abgeschlossen ist: die Verifikation. Statt eine Antwort auszugeben, erzeugt das Modell viele. Ein separater Auswahlmechanismus entscheidet dann, welche davon tatsächlich herausgegeben wird.

In verifizierbaren Domänen wie Programmcode oder Mathematik ist dieser Auswahlmechanismus denkbar nüchtern: Unit-Tests. Jede der erzeugten Code-Varianten läuft gegen automatisierte Tests, und diejenige, die alle Tests besteht, gewinnt. In nicht-verifizierbaren Domänen, etwa bei Fließtext oder kreativem Schreiben, gibt es kein automatisiertes “richtig” oder “falsch”. Hier tritt an die Stelle des Unit-Tests ein zweites Sprachmodell, das als Richter fungiert: “LLM as a Judge”.

Die Generator-Verifizierer-Kluft

Warum lohnt sich dieser ganze Aufwand an mehrfacher Erzeugung überhaupt? Weil Erzeugen billig ist und Prüfen teuer. Ein Modell kann in kurzer Zeit tausende plausibel klingende Antworten produzieren. Ob die Antworten tatsächlich brauchbar sind, ist eine andere Frage. Im “Large Language Monkeys Project” war das bei einigen der schwierigsten Aufgaben durchaus wörtlich zu nehmen: Unter zehntausend mit künstlicher Intelligenz erzeugten Lösungen für ein einziges Problem waren teils nur drei oder vier tatsächlich korrekt. Solange der Verifizierer aber verlässlich zwischen diesen wenigen richtigen und den vielen falschen unterscheiden kann, reicht das aus. Ist der Verifizierer schlecht oder schlicht zu langsam (menschlich), wird ausgerechnet die Prüfung selbst zum Engpass, nicht die Erzeugung.

Der Genehmigungsprozess kennt das Prinzip längst — nur ohne Gedächtnis

Nun zum ERP-System, das die meisten Leser dieses Blogs tatsächlich beschäftigt. SAP Business One hat mit dem Genehmigungsprozess eine Funktion an Bord, die unauffällig ihre Arbeit macht: Verletzt ein Beleg eine hinterlegte Regel (etwa ein Rabatt von zehn Prozent oder mehr) wird er nicht einfach durchgebucht. Das System parkt ihn , bis ein Vorgesetzter ihn freigibt oder ablehnt.

Man kann diesen Mechanismus lesen als eine sehr einfache, menschengeführte Verifikation: Das System erzeugt einen Kandidaten (den Beleg), und ein Prüfer entscheidet, ob er durchgeht. Strukturell ähnelt das der Rolle, die im RLHF-Loop das Reward-Modell übernimmt – ein Mensch bewertet, das System reagiert auf diese Bewertung. Der entscheidende Unterschied liegt aber genau dort, wo es interessant wird: Aus der beschriebenen Mechanik folgt, dass der Genehmigungsprozess in SAP Business One aus keiner einzelnen Freigabe lernt. Ob der Vorgesetzte heute zustimmt oder ablehnt, macht das System für die nächste, strukturell identische Anfrage nicht klüger. Es bleibt, mit Verlaub, der geduldige Prüfer, der nach jedem Fall wieder bei null anfängt. Ein Reward-Modell formt im RLHF-Training aus genau solchen menschlichen Urteilen ein eigenständiges, wiederverwendbares Bewertungsmodell.

Regeln sind noch keine künstliche Intelligenz

Nicht selten wird in Verkaufsgesprächen genau dieser Unterschied verschwiegen oder übersprungen: Ein regelbasiertes System klingt in der Beschreibung schnell “intelligent”. Es ist dabei aber etwas grundlegend anderes als ein System, das aus Bewertungen lernt.

Wer schon dabei ist, findet eine zweite Funktion, die sich in die Betrachtung einordnen lässt: die Alarmfunktionen. Sie benachrichtigen automatisch bei kaufmännischen Abweichungen – Budgetüberschreitung, unterschrittener Mindestbestand, überzogenes Kreditlimit – entweder über vordefinierte Regeln oder über eine selbst formulierte SQL-Abfrage. Man kann auch das als ein regelbasiertes Pendant zur Verifikation lesen: Beide filtern automatisch Abweichungen aus einem größeren Pool heraus. Der Unterschied zur Verifikation im KI-Kontext ist wiederum, dass hier kein Pool aus vielen generierten Varianten existiert, aus dem das System auswählt . Vielmehrprüft die Alarmfunktion einen einzelnen, bereits feststehenden Zustand gegen eine feste Regel, nicht mehrere Kandidaten gegeneinander.

Ein zusätzliches Kriterium im Regelwerk — und eine Weiche, die abgestuft entscheidet

An dieser Stelle darf man ruhig einen Schritt weitergehen, ausdrücklich im Konjunktiv, denn nichts von dem Folgenden existiert als Funktion, und niemand kündigt hier an, so etwas zu bauen. Der Genehmigungsprozess in SAP Business One ließe sich nicht nur beobachten, sondern auch erweitern. Das betrifft nicht durch eine zusätzliche Ebene neben den bestehenden Regeln, sondern Erweiterungen innerhalb des Regelwerks selbst, das heute die Genehmigung auslöst. Aktuell entscheidet ausschließlich, ob ein fest hinterlegter Wert überschritten wird. Das kann etwa ein Rabatt ab zehn Prozent sein. Denkbar wäre, dass neben solche starren Schwellen ein weiteres Kriterium träte, das nicht aus einer festen Zahl, sondern aus der Historie früherer Freigabe- und Ablehnungsentscheidungen abgeleitet wäre. Dieses Kriterium würde nicht ersetzen, was heute auslöst, sondern ergänzen. Es könnte mitbestimmen, ob überhaupt eine Genehmigung nötig wird oder auf welcher Stufe sie landet.

Der Unterschied zur festen Schwelle liegt in dem, was eine einzelne Zahl nicht abbilden kann. Eine Schwelle von zehn Prozent Rabatt kennt nur diese eine Zahl. Sie sieht nicht, ob derselbe Kunde, dieselbe Kombination aus Position und Zeitpunkt oder dieselbe Vertriebsmitarbeiterin in früheren Fällen unauffällig oder auffällig war. Ein Beleg mit acht Prozent Rabatt, der unterhalb jeder festen Schwelle bliebe, könnte trotzdem aus der Reihe fallen. Eben wegen der Kombination der Merkmale die von allem abweicht, was bisher eine Genehmigung auslöste . Ein gelerntes Kriterium könnte genau solche Kombinationen erkennen und eine Genehmigung auslösen, wo eine starre Regel schweigen würde. Oder umgekehrt könnte sie eine höhere Genehmigungsstufe verlangen, obwohl kein einzelner Wert für sich genommen eine Grenze verletzt.

Eine Weiche statt eines Schalters

Bisher klang dieses Kriterium wie ein Schalter mit zwei Stellungen: Genehmigung nötig oder nicht nötig. Denkbar wäre aber eine feinere Abstufung. Statt binär auszulösen, könnte das Kriterium einschätzen, wie hoch das Risiko einer Fehlinterpretation oder einer Regelverletzung im konkreten Fall wäre, und diese Einschätzung als Weiche nutzen, nicht als einfachen Schalter. Fälle mit gering eingeschätztem Risiko liefen ohne weitere Prüfung durch. Fälle mit höher eingeschätztem Risiko gingen an einen Menschen zur Prüfung. Und bei sehr hoch eingeschätztem Risiko könnte das System eine zusätzliche Genehmigungsstufe oder eine weitere prüfende Person verlangen.

Der Nutzen einer solchen Weiche läge nicht in weniger Prüfung insgesamt, sondern in ihrer Verteilung. Menschliche Prüfzeit ist knapp und liegt heute gleichmäßig über allen Fällen, die eine feste Schwelle überschreiten — unabhängig davon, ob der einzelne Fall tatsächlich Aufmerksamkeit verdient oder nur zufällig über der Schwelle liegt. Eine abgestufte Einschätzung würde diese Aufmerksamkeit dorthin verschieben, wo sie tatsächlich etwas ändert, und dort wegnehmen, wo ein Blick ohnehin nichts an der Entscheidung ändern würde.

Wer die Weiche stellt

Damit ändert sich, was eben zum Verhältnis zwischen Kriterium und menschlicher Entscheidung gesagt werden müsste. Nicht mehr jeder einzelne Beleg müsste über einen menschlichen Schreibtisch gehen — das wäre gerade der Gewinn der Abstufung, und es wäre unehrlich, das zu verschweigen, nur um den Menschen an jeder einzelnen Stelle im Bild zu behalten. Was bliebe, ist eine andere, davon zu unterscheidende Verantwortung:
Wie die Weiche eingestellt ist , also welche Risikostufe noch ohne Prüfung durchläuft und welche nicht. Das wäre keine Entscheidung des Systems, sondern eine menschliche. Diese Verantwortung läge auf der Ebene der Regel, nicht auf der Ebene des einzelnen Belegs. Wer die Schwelle für “gering” großzügig auslegt, entscheidet damit im Voraus über viele Einzelfälle zugleich, ohne einen davon je gesehen zu haben.

Der Haken bliebe derselbe wie bei jedem lernenden System, nur mit einer zusätzlichen Facette. Es würde nicht nur aus guten Urteilen lernen, sondern auch aus nachlässigen. Ein Vorgesetzter, der Rabatte aus Zeitdruck regelmäßig ohne genaueren Blick durchwinkt, würde diese Nachlässigkeit in das Kriterium einschreiben, nicht in eine Tugend verwandeln. Eine falsch eingestellte Weiche hätte einen eigenen, zweiten Fehlermodus: Sie ließe genau jene Fälle unbemerkt durch, für die der Genehmigungsprozess ursprünglich eingerichtet wurde.

Für wen sich das lohnt

Dieser Artikel richtet sich an Geschäftsführer und CFOs im Umfeld von SAP Business One, die verstehen wollen, was hinter dem KI-Vokabular in Berater- und Software-Angeboten technisch steckt, bevor sie über Budget oder Automatisierungsgrad entscheiden. Wer kein SAP Business One einsetzt, kann dies meistens durch irgend ein anderes ERP ersetzen. Die Begriffsklärung zu RLHF und Verifikation kann man so oder so trotzdem mitnehmen.
Der Genehmigungsprozess in SAP Business One wird durch keinen dieser Vergleiche schlauer. Aber wer den Unterschied zwischen einer festen Regel und einem lernenden Reward-Modell kennt, hat auch einen Maßstab dafür, welche der eigenen Prozessideen man mit künstlicher Intelligenz inzwischen mutig zu Ende denken kann.