All das war schon vorher möglich. Genau darum geht es. Geändert hat sich die Anzahl der Schritte zwischen dem Wunsch und dem Ergebnis.
Vorher und nachher: fünf Schritte im Vergleich zu einem einzigen Satz.
1. Aus einer neuen Preisliste eine neue Version erstellen
Ihr Lieferant sendet eine aktualisierte Preisliste. Es ist eine CSV-Datei. Ihre Produkttabelle enthält noch die alten Werte.
Vorher: Öffnen Sie die Datei. Öffnen Sie die Regel. Ermitteln Sie, welche Zeilen aktualisiert werden müssen. Bearbeiten Sie sie einzeln oder exportieren Sie sie nach Excel, passen Sie sie an und importieren Sie sie erneut. Stellen Sie sicher, dass sich sonst nichts verändert hat.
Jetzt: Laden Sie die Datei hoch und sagen Sie dem Assistenten, was er tun soll.
Hier ist die neue Preisliste unseres Lieferanten. Erstellen Sie mit diesen Werten eine neue Version der Lookup-Tabelle Product Prices. Lassen Sie die aktuelle Version unverändert und zeigen Sie mir, welche Zeilen sich geändert haben.
Erstellen Sie aus der Preisliste eines Lieferanten eine neue Regelversion, ohne die Live-Version zu verändern.
Der Assistent liest die aktuelle Tabelle, ordnet die neuen Werte den richtigen Zeilen zu und erstellt eine neue Version. Die verwendete Version bleibt unverändert. Sie prüfen die neue Version zuerst.
Suchen Sie in der neuen Version nach SKU-4410-GOLD. Wie viel bezahlt ein Gold-Kunde für 12 Einheiten?
Fragen Sie den Assistenten nach einem Wert aus der neuen Regelversion und überprüfen Sie das Ergebnis im Chat.
Sie sehen das Ergebnis im selben Chat, direkt neben den Daten, die Sie gerade eingebracht haben.
2. Eine Tabelle aus einer Beschreibung erstellen
Vorher: Überführen Sie die Richtlinie in Spalten. Legen Sie Ein- und Ausgaben fest. Erstellen Sie die Tabelle. Fügen Sie Zeilen hinzu. In Zeile neun stellen Sie fest, dass Sie doch eine berechnete Spalte benötigen.
Jetzt:
Erstellen Sie eine Entscheidungstabelle für einen Rabatt auf Grundlage des Bestellwerts und des Kundenstatus. Gold-Kunden erhalten 15 % bei einem Bestellwert über 500, alle anderen 10 % bei einem Bestellwert über 1000.
Überführen Sie eine natürlich formulierte Richtlinie in eine strukturierte Entscheidungstabelle.
Der KI-Assistent liefert eine Tabelle, die sofort geprüft werden kann. Ein- und Ausgaben sind definiert, die Spaltentypen sind festgelegt und die Zeilen sind ausgefüllt.
Dafür wird dieselbe Engine verwendet, die auch die Regelerstellung im Editor unterstützt. MCP ändert lediglich den Zugangsweg.
3. Testfälle generieren, die tatsächlich etwas testen
Vorher: Verfolgen Sie die Bedingungen über die einzelnen Zeilen hinweg. Schreiben Sie Eingaben von Hand. Das Ergebnis deckt meist die Logik ab, die Sie bereits verstehen, nicht die Lücken, die Sie übersehen haben.
Jetzt:
Generieren Sie 10 Testfälle für die Kreditbewertungsregel, Version 3. Berücksichtigen Sie Grenzwerte und mindestens eine Eingabe, die zu keiner Zeile passt.
Der letzte Teil ist entscheidend. Eingaben, die zu keiner Zeile passen, zeigen Lücken in der Abdeckung. Genau diese Fälle werden nur selten von Hand erstellt.
Darauf kommt es besonders an: Der Assistent schlägt ausschließlich Eingaben vor. Er trägt keine erwarteten Ergebnisse ein. Wenn Sie die Suite speichern, führt DecisionRules die Regel mit genau dieser Version aus, um die Ausgaben festzulegen. Würde die KI beides schreiben, wäre der Test bedeutungslos. Deshalb darf sie die Antwort nicht vorgeben.
Generieren Sie aussagekräftige Testfälle und führen Sie sie als wiederverwendbare Regressionstest-Suite aus.
Die Ergebnisse werden für jeden Fall zurückgegeben. Die Suite bleibt im Tab Tests für die nächste Verwendung gespeichert. So bleiben Regressionstests nützlich. Die Eingaben müssen Sie nun nicht mehr selbst schreiben.
4. Die Tabelle nach dem Warum fragen, nicht nur nach dem Ergebnis
Ein Kunde gibt an, dass ihm der falsche Preis berechnet wurde. Die Preistabelle hat vierzig Zeilen, drei sich überschneidende Bedingungen und eine vor Monaten hinzugefügte Berechnungsspalte. Die Regel wird korrekt ausgewertet, doch das Problem liegt in der Logik.
Vorher: Öffnen Sie die Regel. Erstellen Sie die Eingabe in der Test Bench erneut. Führen Sie sie aus. Gehen Sie die Auswertung Schritt für Schritt durch.
Jetzt:
Führen Sie die Preisregel mit dieser Bestellung aus und erklären Sie mir, welche Zeile übereinstimmte und warum.
Sie erhalten die passende Zeile, die erfüllten oder nicht erfüllten Bedingungen sowie die Berechnung des Endwerts. Anschließend stellen Sie die Frage, die wirklich weiterhilft:
Welche anderen Zeilen hätten zu dieser Bestellung passen können und warum wurden sie nicht ausgewählt?
Ohne den Assistenten würden Sie mindestens zwanzig Minuten mit der Untersuchung verbringen: Eingaben neu erstellen, durch Zeilen scrollen und die Logik Schritt für Schritt nachvollziehen. Der Debug-Modus unterstützt Sie dabei und beschleunigt den Vorgang, indem er Auswertungen auf Zellebene anzeigt. Dennoch ist jede Prüfung manuell. Jetzt genügt eine Frage, um Antworten zur Logik zu erhalten.
Dieselbe Funktion ermöglicht Regelzusammenfassungen im Editor und ist besonders hilfreich bei Regeln, von denen niemand mehr weiß, wer sie erstellt hat.
5. Vor der Veröffentlichung erkennen, was eine Versionsänderung bedeutet
Vorher: Öffnen Sie die Vergleichsansicht. Lesen Sie die Unterschiede zwischen den Versionen. Die Ansicht kann Ihnen jedoch nicht sagen, was diese Änderungen für eine echte Bestellung bedeuten oder wer davon betroffen ist.
Vergleichen Sie Regelversionen, um zu sehen, welche Schwellenwerte sich geändert haben und wie sie sich auf echte Bestellungen auswirken.
Jetzt:
Vergleichen Sie Version 3 und Version 4 der Preistabelle. Was hat sich geändert und was bedeutet das für eine Bestellung über 400?
Die Unterschiede und ihre Auswirkungen werden verständlich dargestellt. Der Schwellenwert wurde von 500 auf 400 verschoben. Dadurch erhält eine Bestellung über 400 nun einen Rabatt, für den sie sich zuvor nicht qualifiziert hat. Eine Zeile wurde deaktiviert. Eine neue Stufe liegt nun über der bisherigen höchsten Stufe.
Danach folgt die entscheidende Prüfung vor der Veröffentlichung:
Wie heißt diese Regel und an welche Versionen sind die Aufrufer gebunden?
Aufrufer, die an Version 3 gebunden sind, bleiben unverändert. Aufrufer mit der Einstellung „Neueste Version“ erhalten die Aktualisierung bei der Veröffentlichung. Ein einziger Satz genügt, um zu erkennen, welcher Aufrufer welche Version verwendet.
6. Die Regel aus dem Ticket erstellen, das sie angefordert hat
Vorher: Ein Business Analyst beschreibt die neue Rabattregelung in einem Ticket. Jemand liest sie. Öffnet DecisionRules. Überführt sie in eine Tabelle. Kehrt anschließend zum Ticket zurück und vermerkt, dass die Aufgabe erledigt ist.
Jetzt: Beide Werkzeuge sind mit demselben Assistenten verbunden.
Das Ticket DRU-4730 ist gerade eingegangen. Aktualisieren Sie die Zinstabelle entsprechend der darin enthaltenen Anforderung.
Verwandeln Sie ein Ticket in eine getestete Regelaktualisierung, ohne den Workflow zu verlassen.
Der Assistent liest die Anforderung in der Form, in der der Fachbereich sie verfasst hat, aktualisiert die Regel, führt die Fälle aus und schließt den Kreis dort, wo die Anfrage begonnen hat.
Der Unterschied zu den anderen fünf Beispielen besteht darin, dass DecisionRules nicht das einzige Werkzeug in der Unterhaltung ist. Dasselbe Muster funktioniert mit einer Tabellenkalkulation anstelle eines Tickets, mit einer Datenbank als Quelle für Referenzdaten oder mit einem Slack-Kanal als Ort für die Bekanntgabe des Ergebnisses. Ihre Regeln sind keine Insel mehr, die sich nur in ihrem eigenen Tab öffnen lässt.
Was daraus folgt
Nichts davon ist funktional neu. Jede Aktion nutzt eine Funktion, die bereits in DecisionRules vorhanden ist. Der Assistent greift auf dieselben Werkzeuge zu, die Sie auch selbst verwenden würden.
Was MCP beseitigt, ist die Distanz. Die Regel, die KI und die Person befinden sich nun an einem Ort. Der Kreislauf von der Idee bis zur Prüfung schließt sich in Sekunden statt in Minuten.
Ivan Peresta arbeitet bei DecisionRules, wo seine Rolle Produktanalyse, Professional Services und Kundensupport umfasst. Er ist am gesamten Lebenszyklus von Produktfunktionen beteiligt, von frühen Entwurfs- und UX-Überlegungen bis hin zu praktischen Tests, Dokumentation und kundenorientierter Auslieferung. Seine Arbeit schlägt eine Brücke zwischen Produktentwicklung und den Menschen, die das Produkt tatsächlich nutzen, sei es, dass er einem Kunden beim Entwurf seines Regelsystems hilft oder dass er sicherstellt, dass eine neue Funktion mit klaren Anleitungen und funktionierenden Beispielen ausgeliefert wird.
