Dieselbe Aufgabe zweimal gestellt, zweimal ein anderes Ergebnis: daran bleibt KI in Unternehmen oft beim Lesen stehen. Ein Skill legt Schritte, Werkzeuge und Freigaben vorab fest und lässt die KI nur dort arbeiten, wo sie stark ist. Und Sie bauen ihn in einer Sitzung.
Stellen Sie einer KI zweimal dieselbe Aufgabe. Kommt zweimal dasselbe heraus?
Bei einer einzelnen Frage ist das egal. Bei 200 Belegen pro Woche nicht. Genau daran bleibt KI in Unternehmen oft beim Lesen stehen. Nicht weil sie zu wenig könnte, sondern weil niemand vorhersagen kann, was sie im nächsten Durchlauf tut.
Ein Skill nimmt ihr genau diese Freiheit. Die Struktur liegt fest, bevor der erste Lauf startet: welche Schritte, welche Werkzeuge, in welcher Reihenfolge, an welcher Stelle jemand freigibt. Die KI arbeitet weiter mit, aber nur dort, wo sie stark ist. Heraus kommt kein Ergebnis, das zufällig gut ausfällt, sondern ein Vorgang, der jedes Mal gleich läuft und sich hinterher belegen lässt.
Gebaut wird er in Alltagssprache. Ohne eine einzige Feldzuordnung.
Ein Skill besteht aus einzelnen Schritten: Daten lesen, eine KI-Bewertung, eine Verzweigung, eine Freigabe, eine Buchung. Diese Schritte und alle Verzweigungen sind vorab festgelegt und versioniert. Die KI kann keinen anderen Weg nehmen, keinen Schritt überspringen und keinen dazu erfinden.
Innerhalb dieses Wegs arbeitet sie an vier Stellen. Sie füllt die Eingaben eines Schritts aus den Ergebnissen der vorherigen. Sie entscheidet Bedingungen, die in natürlicher Sprache formuliert sind. Sie löst Listen auf, über die eine Schleife laufen soll. Und wo ein Schritt ausdrücklich ein KI-Schritt ist, liefert sie das Ergebnis.
Das ist der Unterschied zum frei agierenden Agenten. Der ist stark, wenn vorher niemand weiß, welche Schritte nötig sind. Bei einem Vorgang, der jede Woche läuft, weiß man es.
Die Werkzeuge fallen nicht vom Himmel. Sie entstehen aus den Systemen, die angebunden sind, und liegen dem Builder als fertige Liste vor: dieser SAP-Mandant, dieser Aufruf, dieses Eingabeschema. Die KI kann sich keinen Endpunkt ausdenken und keinen Parameter erfinden, den es nicht gibt.
Sichtbar ist außerdem nur, wofür Ihr Team berechtigt ist. Was Sie nicht dürfen, können Sie nicht einbauen, und was nicht eingebaut ist, kann zur Laufzeit nicht passieren.
Für Schreibaktionen kommt eine zweite Sicherung dazu. Die Freigabe hängt an genau den Daten, die anschließend an das System gehen, nicht an einer ungefähren Vorschau. Und ein freigabepflichtiges Werkzeug darf nicht in einer Schleife stehen, sonst wäre die Freigabe bei Position 200 nur noch Dekoration.
Der Editor zeigt den Prozess als Graph. Sieben Bausteine stehen zur Verfügung: Werkzeug, KI-Schritt, Bedingung, Schleife, Freigabe, Eingabe und Ende. Ziehen, verbinden, löschen.
Interessant ist, was an einem Schritt nicht steht. Kein Mapping-Formular, keine Ausdruckssprache, keine Feldpaare. An einem Werkzeug-Schritt stehen zwei Dinge: welches Werkzeug, und eine Anweisung in Alltagssprache, was es tun soll. Bedingungen genauso: keine Formel mit Operatoren, sondern in natürlicher Sprache, etwa „Auffällig, wenn der Betrag über 5.000 Euro liegt oder der Lieferant gesperrt ist."
Damit verschwindet der Teil eines Workflow-Projekts, der die meiste Zeit frisst und bei jeder Schnittstellenänderung zurückkommt. Die Zuordnung auf die Felder entsteht zur Laufzeit, gegen das echte Schema des Systems.
Sie starten mit einem Satz: „Montags die offenen Lieferantenrechnungen prüfen, Auffälligkeiten an den Einkauf zur Freigabe, den Rest buchen."
Fehlt etwas Wesentliches, zeichnet die KI nicht drauflos. Sie stellt gezielte Rückfragen: Welches System, SAP Deutschland oder Frankreich? Wer gibt frei? Läuft das zeitgesteuert? Die Fragen kommen als anklickbare Optionen, nicht als Fragebogen. Erst danach entsteht der Entwurf.
Verfeinert wird im selben Chat: „Füge vor der Buchung eine Freigabe ein." Der Graph aktualisiert sich mit. Umgekehrt genauso: Was Sie im Editor ändern, kennt der Chat beim nächsten Satz. Beide Wege arbeiten am selben Prozess, es gibt keine zweite Wahrheit.
Vor dem ersten echten Lauf drücken Sie auf Probelauf. Er läuft in einer Sandbox: Lesende Werkzeuge und KI-Schritte laufen echt, damit Sie an realen Daten sehen, was herauskommt. Schreibende Werkzeuge werden simuliert. Schleifen kappt der Probelauf bei zwei Positionen, damit ein Test nicht zehn Minuten dauert.
Das Ergebnis kommt Schritt für Schritt zurück, mit dem, was der Schritt geliefert hat. Scheitert einer, nennt der Builder den Schritt und die genauen Eingaben, mit denen er es versucht hat. Ein Klick schickt den Fehler zurück in den Chat, und die KI korrigiert den Entwurf.
Ein Entwurf geht nicht ungeprüft live. Der Builder prüft unter anderem: Sind alle Schritt-Namen eindeutig? Hängt ein Schritt in der Luft, den nie jemand erreicht? Gibt es ein erreichbares Ende? Existiert jedes referenzierte Werkzeug, und ist das Team dafür berechtigt? Hat jede Bedingung beide Zweige?
Veröffentlichen erzeugt eine neue Version. Laufende Vorgänge bleiben auf der Version, mit der sie gestartet sind. Das ist die letzte Zutat zum gleichbleibenden Ergebnis: Ein Lauf von heute verhält sich morgen noch genauso, auch wenn jemand den Skill inzwischen weiterentwickelt hat. Alte Versionen bleiben einsehbar, samt der Unterschiede zwischen zwei Ständen.
Zum Schluss legen Sie fest, wodurch der Skill startet: nach Zeitplan, per Webhook, durch ein Ereignis oder über die Schnittstelle. Zusätzlich steht er dem Chat-Agent als Werkzeug zur Verfügung, ein Mitarbeitender kann ihn also im Gespräch anstoßen. Derselbe Prozess, verschiedene Türen.
Beide Werkzeuge sind gut, wenn der Use Case passt. Sie lösen das Problem nur anders.
SAP Joule Studio verankert die Automatisierung im SAP-Geschäftskontext, und das ist ein echter Vorteil, solange der Prozess dort lebt. Der Skill Builder ist seit Mitte 2025 verfügbar, der Agent Builder seit Anfang 2026. Eine Joule Skill ist dabei eine regelbasierte Fähigkeit, die eine API-Action aufruft. Rechnen Sie die Voraussetzungen mit ein: BTP-Entitlements, SAP Build Process Automation, Joule, SAP Cloud Identity Services und eine SAP Build Developer License. Das ist keine Nachmittagsentscheidung, sondern ein Plattformthema.
Microsoft Copilot Studio ist stark, wenn Ihre Welt ohnehin M365 ist. Seit August 2026 gibt es einen visuellen Workflow-Designer mit deterministischen Schritten, Reasoning-Knoten, Test pro Knoten und eigener Versionierung; Genehmigungen gehören dort zum Standard. Zwei Punkte gehören in die Rechnung: Ihre Prozessdaten laufen durch die Microsoft-Cloud, und autonome Auslöser kosten pro Auslösung Credits. Je weiter der Prozess von M365 wegführt, desto mehr Konnektoren bauen Sie selbst.
| Kriterium | ORAI Agent | SAP Joule Studio | Microsoft Copilot Studio |
|---|---|---|---|
| Wiederholbarkeit | fester Graph, jeder Lauf auf seine Version gepinnt | Skill regelbasiert, Agent plant selbst | deterministische Schritte, Reasoning-Knoten planen selbst |
| Bauen | im Chat beschreiben, im Graph prüfen | Skill Builder: regelbasierte Fähigkeit auf einer API-Action | visueller Workflow-Designer: deterministische Schritte plus Reasoning-Knoten |
| Feldzuordnung | macht die KI zur Laufzeit | Parameter am Skill gepflegt | Parameter am Knoten gepflegt |
| Voraussetzungen | die eigene Umgebung, on-premise möglich | BTP-Entitlements, SAP Build Process Automation, Joule, Cloud Identity Services, Developer License | Microsoft-365-Umgebung, Lizenz, Credits für autonome Auslöser |
| Freigabe durch Menschen | eigener Schritt im Prozess, über Web, Teams oder API | über SAP Build Process Automation | Genehmigungen im Standard |
| Stärkste Position | gemischte Landschaft, self-hosted, Nachweispflicht | Prozesse im SAP-Kern mit SAP-Geschäftskontext | Prozesse, die ohnehin in M365 leben |
Und bei uns? Der ORAI Agent läuft in Ihrer Umgebung, auf Wunsch ohne Internetanbindung. Er spielt seine Stärke aus, wenn die Landschaft gemischt ist und wenn Sie in einem halben Jahr belegen müssen, wer was freigegeben hat. Er ist die falsche Wahl, wenn Sie eine reine SAP-Fiori-Erweiterung suchen, oder wenn ein Prozess tausende Positionen parallel abarbeiten soll: Schleifen laufen bei uns nacheinander.
Die Frage ist selten, ob eine KI eine Aufgabe lösen kann. Die Frage ist, ob sie dieselbe Aufgabe beim zwanzigsten Mal noch genauso löst, dabei die richtigen Systeme anfasst und die Freigaben einhält, die Sie vorgesehen haben. Genau das leistet ein Skill, und der Builder macht ihn in einer Sitzung baubar.
Wenn Sie es ausprobieren wollen, nehmen Sie nicht den größten Prozess. Nehmen Sie den, den heute drei Leute unterschiedlich erledigen. Danach wissen Sie, ob der Weg für Sie trägt.
Termin buchen
In 30 Minuten bauen wir live im Editor einen Skill an einem Ihrer Prozesse, lassen ihn im Probelauf gegen echte Daten laufen und zeigen, was er ohne Feldzuordnung schon kann.
Schreib uns oder buche direkt ein kurzes Meeting.