SAP Joule Studio in der Praxis: Wie sich Skills für den Business-Alltag einfach erstellen lassen
Im Business-Umfeld sind digitale Assistenten da, um komplexe Workflows und Prozesse zu unterstützen. Doch tun sie sich schwer bei manchem simplem Alltagstask. Oder nicht? Ich bin der Frage nachgegangen, habe mit SAP Joule Studio konkrete Use Cases durchexerziert und geschaut, wie einfach Skills-Erstellen mit dem Business-Tool ist.
Digitale Assistenten sind im Business-Umfeld wahnsinnig hilfreich: Sie können komplexe Prozesse unterstützen, sie können Reports automatisch aufbereiten, sie können Ressourcen im Kundenservice optimieren.
Aber dann gibt es diese kleinen Momente, in denen man sich im Business-Alltag fragt: Warum funktioniert das eigentlich nicht einfach? Ein sehr simples Beispiel: das Wetter. Wenn ich Alexa, Siri oder Google frage, wie das Wetter in Wien oder Graz ist, bekomme ich sofort eine Antwort. Warum also nicht in SAP?
Das Tool der Wahl in SAP ist SAP Joule. In dieser Entwicklungsumgebung lassen sich maßgeschneiderte Skills und KI-Agenten bauen. Natürlich ist SAP Joule kein klassischer Consumer-Assistent und der Vergleich mit Alexa ist deshalb nicht ganz fair. SAP Joule lebt in einem anderen Kontext: Business-Prozesse, Unternehmensdaten, Berechtigungen, SAP-Anwendungen und Produktivität im Arbeitsalltag.
Und genau bei Letzterem wurde ich stutzig: Warum sollte Joule nicht auch gezielt zusätzliche Fähigkeiten bekommen können, wenn sie im jeweiligen Unternehmenskontext sinnvoll sind und die Produktivität erhöhen?
Probe aufs Exempel
Genau hier wird SAP Joule Studio, praktisch der Co-Pilot von SAP, spannend. Ich wollte es genauer wissen und habe mich deshalb in den letzten Wochen intensiver damit beschäftigt. Das Ziel: eigene Skills zu bauen, die mir den Arbeitsalltag erleichtern. Nicht als rein theoretische Demo, sondern konkrete Use Cases:
- einen Wetter-Skill, der aktuelle Wetterdaten für eine Stadt abfragt.
- einen Kalender-Skill, der Termine aus der SAP Sales and Service Cloud liest.
Darüber hinaus sollte die Joule-Bereitstellung zentral in der SAP-Landschaft passieren, sodass die Funktionen auch in angebundenen SAP-Produkten wie SAP S/4HANA Cloud genutzt werden können.
Ich nehme es vorweg: Das Ergebnis fühlt sich ein bisschen so an, als würde man SAP Joule neue Werkzeuge in die Hand geben. Doch gehen wir erst einmal einen Schritt zurück und schauen uns SAP Joule Studio im Detail an.
Was ist SAP Joule Studio?
Kurz gesagt: Mit SAP Joule Studio lassen sich eigene Skills für Joule erstellen. Diese Skills können externe APIs, SAP-Services oder eigene Geschäftslogik verwenden und damit SAP Joule um Fähigkeiten erweitern, die im Standard nicht oder noch nicht vorhanden sind.
Technisch übersetzt besteht ein Skill in SAP Joule Studio also typischerweise aus mehreren Bausteinen.
- Trigger: Dieser definiert, wann ein Skill gestartet wird. Das kann direkt durch den Benutzer passieren oder durch SAP Joule, wenn die Anfrage semantisch zum Skill passt.
- Aktion: Diese enthalten die eigentliche Logik. In meinen Beispielen sind das HTTP-GET-Aufrufe gegen eine Wetter-API beziehungsweise gegen den Appointment Service der SAP Sales and Service Cloud.
- Parameter: Über solche werden Informationen aus der Benutzerfrage an die Aktion übergeben. Beim Wetter-Skill ist das zum Beispiel die Stadt. Beim Kalender-Skill können perspektivisch Datum, Datumsbereich oder andere Filter relevant sein.
- Response-Konfiguration: Diese entscheidet, wie das Ergebnis dargestellt wird: als Text, Karte, Liste oder strukturierte Antwort.
Weiterer Bonus: Über die Einbindung von SAP Joule im KI-Portal können die Skills zentral bereitgestellt und in Joule-fähigen SAP-Anwendungen genutzt werden.
APIs als Schlüssel zum Erfolg
Damit SAP Joule über einen Skill nicht nur antwortet, sondern wirklich etwas tun kann, braucht es eine Verbindung zu einem System, einem Service oder einer Datenquelle. Genau hier kommen APIs ins Spiel. Und deren Bedeutung ist nicht zu unterschätzen.
Eine API, also ein Application Programming Interface, ist vereinfacht gesagt eine definierte Schnittstelle, über die Systeme miteinander sprechen können. Ein System stellt bestimmte Funktionen oder Daten bereit, ein anderes System ruft diese kontrolliert ab.
Im Alltag begegnet uns dieses Prinzip ständig, auch wenn wir es meistens nicht bewusst wahrnehmen. Eine Wetter-App ruft Wetterdaten über eine API ab. Ein Onlineshop prüft über eine API die Verfügbarkeit eines Produkts. Ein CRM-System stellt Kundendaten über eine API bereit. Ein SAP-System bietet Services an, um zum Beispiel Geschäftspartner, Termine, Belege oder Aufträge abzufragen.
Das gilt auch hier. Ohne APIs wären jegliche Skills zum Scheitern verurteilt.
Use Case 1: Wetter-Skill
Mein erster Skill war bewusst einfach gewählt: ein Wetter-Skill. Die Idee ist schnell erklärt. Der Benutzer fragt Joule zum Beispiel:
Ohne eigenen Skill kann SAP Joule in meinem Setup damit zunächst nichts Sinnvolles anfangen. SAP Joule ist schließlich nicht automatisch ein Wetterassistent.
Mit einem eigenen Skill sieht das anders aus: Der Skill nimmt die Stadt als Parameter entgegen, ruft eine Wetter-API auf und gibt die aktuellen Bedingungen zurück. In meinem Beispiel habe ich mit einer OpenWeatherMap-Integration gearbeitet. Die Aktion ist als GET-Request modelliert und enthält einen Parameter für die Stadt.
Der technische Aufruf sieht vereinfacht so aus:
Der Parameter {City} wird dabei aus der Benutzerfrage ermittelt. Fragt der Benutzer nach Wien, wird Wien an die API übergeben. Fragt der Benutzer nach Graz, entsprechend Graz.
Die API liefert strukturierte JSON-Daten zurück, zum Beispiel Temperatur, Luftfeuchtigkeit, Wetterbeschreibung, Koordinaten und weitere technische Details.
Ein stark vereinfachter Ausschnitt sieht so aus:
Diese technischen Daten sind für Endbenutzer natürlich nicht ideal. Niemand möchte rohe JSON-Strukturen lesen, nur um zu erfahren, ob er einen Regenschirm braucht. Deshalb wird das Ergebnis in SAP Joule wieder in eine natürliche Antwort und eine kompakte Karte übersetzt.
Gerade hier merkt man sehr schön, was SAP Joule Studio ermöglicht: Der Skill ist technisch betrachtet ein API-Aufruf mit Parameterübergabe und Mapping. Für den Benutzer fühlt es sich aber wie eine neue Fähigkeit von SAP Joule an.
Warum der Wetter-Skill ein guter Use Case ist
Natürlich ist eine Wetter-Abfrage kein klassischer Enterprise-Prozess. Aber genau deshalb eignet sich der Use Case so gut als Einstieg. Er ist leicht verständlich, schnell testbar und zeigt die wichtigsten Konzepte von SAP Joule Studio in einer kompakten Form:
- natürliche Sprache als Einstiegspunkt
- automatische Auswahl eines passenden Skills
- Extraktion eines Parameters aus der Benutzerfrage
- Aufruf einer externen API
- Verarbeitung einer strukturierten Response
- Darstellung als verständliche SAP-Joule-Antwort
Das Prinzip dahinter ist viel wichtiger als das Wetter selbst. Denn dieselbe Architektur lässt sich auf echte Business-Szenarien übertragen:
- Status einer Lieferung abfragen
- Offene Tickets anzeigen
- Kundeninformationen abrufen
- Angebotsdaten zusammenfassen
- Serviceaufträge suchen
- Projektzeiten prüfen
- Kalendereinträge aus einem SAP-System lesen
Der Wetter-Skill ist damit weniger der eigentliche Business Case, sondern eher das „Hello World“ für eigene SAP-Joule-Fähigkeiten.
Use Case 2: Kalender-Skill
Der zweite Skill ist deutlich näher an einem echten SAP-Szenario: ein Kalender-Skill zum Abrufen von Terminen aus der SAP Sales and Service Cloud. Auch hier ist die Fragestellung simpel:
Das ist noch nicht das Ende der Reise. Gerade bei Kalenderdaten kann man den Skill sehr gut weiterentwickeln:
- Filter nach „heute“
- Filter nach Datumsbereich
- Filter nach Kunde
- Filter nach Status
- Zusammenfassung des Tages
- Vorbereitung auf den nächsten Termin
- Anzeige relevanter Kundeninformationen zum Termin
Aber auch schon die erste Version zeigt sehr gut, wie SAP Joule nicht nur generisch antwortet, sondern tatsächlich Unternehmensdaten über einen definierten, kontrollierten Skill abrufen kann.
Der eigentliche Mehrwert: SAP Joule wird erweiterbar
Was also sollen uns diese zwei kleinen Use Cases sagen? Für mich ist klar: Der spannende Punkt ist nicht, dass SAP Joule jetzt das Wetter kennt oder Termine anzeigen kann. Der spannende Punkt ist:Joule kann durch eigene Skills gezielt um Funktionen erweitert werden, die zum eigenen Unternehmen, zur eigenen Systemlandschaft und zu den eigenen Prozessen passen.
Und das ist ein großer Unterschied zu einem reinen Chatbot. Ein Chatbot kann Text generieren. Ein SAP Joule Skill kann eine konkrete Aktion ausführen.
Er kann eine API aufrufen, Parameter verarbeiten, Daten zurückgeben und diese für den Benutzer verständlich darstellen. Dadurch wird SAP Joule nicht nur zu einer Oberfläche für Fragen, sondern zu einem Einstiegspunkt in Geschäftsprozesse.
Deployment über Unified Joule
Besonders interessant wird es durch das Deployment in Unified Joule. Dadurch sind die entwickelten Skills nicht nur isoliert in Joule Studio verfügbar, sondern können in vielen SAP-Produkten genutzt werden, in denen Unified Joule angebunden ist. In meinem Setup beispielsweise konnte ich die Skills dadurch auch in SAP S/4HANA Cloud verwenden.
Doch warum ist das so bedeutend und aus meiner Sicht einer der wichtigsten Punkte?
Ein zentrales Deployment verhindert, dass nicht für jedes System ein separater Assistent mit separater Logik entsteht bzw. erstellt werden muss. Stattdessen können Skills zentral entwickelt, verwaltet und bereitgestellt werden.
Das bedeutet:
Für Unternehmen ist das ein sehr starkes Konzept. Es reduziert Redundanz, schafft Wiederverwendbarkeit und macht Joule zu einer übergreifenden Erweiterungsschicht über verschiedene SAP-Produkte hinweg.
Vier essenzielle Tipps für das Erstellen von Skills mit SAP Joule
Das Erstellen dieser kleinen SAP Joule Skills hat Spaß gemacht. Darüber hinaus hat mir dieses „Herumspielen“ aber einige wichtige Erkenntnisse beschert, die für mich besonders relevant waren. Meine Top 4 möchte ich mit Euch teilen, weil ich überzeugt bin, dass diese Euch helfen, bessere Skills in SAP Joule zu erstellen:
- Gute Skill-Beschreibungen sind wichtig
SAP Joule muss verstehen, wann ein Skill relevant ist. Eine gute Beschreibung hilft dabei, dass Joule den Skill bei passenden Benutzerfragen auch wirklich auswählt. Gerade bei mehreren, ähnlichen Skills sollte die Beschreibung klar machen, wofür der Skill gedacht ist und wofür nicht.
- Parameterdesign entscheidet über die Nutzbarkeit
Beim Wetter-Skill ist der zentrale Parameter einfach: die Stadt. Bei Business-Skills wie beim Kalender-Beispiel hingegen wird es schnell komplexer. Datum, Zeitraum, Kunde, Status, Organisationseinheit oder Verantwortlicher können wichtige Filter sein. Je sauberer diese Parameter modelliert sind, desto natürlicher kann der Benutzer mit SAP Joule interagieren.
- Die Response-Konfiguration macht den Unterschied
Eine API kann technisch korrekt antworten und für den Benutzer trotzdem unbrauchbar sein. Erst durch Karten, Listen, sinnvolle Titel und verständliche Texte entsteht ein gutes Erlebnis. Der Unterschied zwischen rohem JSON und einer gut dargestellten SAP-Joule-Karte ist enorm.
- Klein anfangen lohnt sich
Ein einfacher GET-Aufruf mit klarer Ausgabe ist ein guter Start. Danach kann man Filter, Fehlerbehandlung, weitere Parameter, Berechtigungslogik und bessere Darstellung ergänzen. Alles Schritt für Schritt. Gerade bei Joule Studio ist ein iteratives Vorgehen sinnvoll: erst den Datenzugriff stabil bekommen, dann die Benutzererfahrung verbessern.
Kleine Skills, große Wirkung
Meine ersten Experimente mit SAP Joule Studio haben gezeigt, wie schnell aus einer Idee ein konkreter Joule-Skill werden kann. Und mehr noch: Es zeigt anhand dieser kleinen Beispiele bereits das große Potenzial, das in diesen Skills schlummert. In Zukunft werden Benutzer nicht mehr wissen müssen, wo eine Information liegt oder welche App sie öffnen müssen. Sie fragen Joule, und der passende Skill holt die Daten.
Für mich ist Joule Studio damit nicht als reines Konfigurationstool zu verstehen, sondern muss als ein Baukasten für unternehmensspezifische KI-Erweiterungen gesehen werden. Denn wie bei jeder KI gilt: SAP Joule wird nicht nur smarter, weil das Sprachmodell besser wird. Joule wird smarter, weil wir ihm die richtigen Skills geben. Lasst uns das gemeinsam tun!
Teilen
Autor
Michael Henninger
Michael Henninger, Experte, wenn es um die Interaktion mit Benutzern geht. Bei Themen wie Userexperience und Userinterface, ist er der richtige Ansprechpartner.Seit 2012 beschäftigt sich Michael mit diesen Themen und konnte durch viele umfangreiche Projekte viel Erfahrung in diesen Bereichen sammeln. Als ursprünglicher Elektrotechniker fällt es ihm sehr leicht, neue Prozesse und Technologien zu verstehen und anzuwenden.
Kommentare