Joule im Fiori-Launchpad – eingebettete Co-Piloten
Worum es geht
Klassische Chatbots sitzen "neben" dem Geschäftsprozess – in einer eigenen URL, mit eigenem Kontext, getrennt vom Arbeitsplatz des Anwenders. Joule kehrt das um: der Assistent sitzt direkt im Fiori-Launchpad und im jeweiligen Fiori-App-Kontext. Er kennt den aktiven Datensatz, den User, die Berechtigungen.
Der Skill Builder in Joule Studio ist die Werkbank, mit der Fachbereiche und IT zusammen zweckgebundene Skills definieren. Ein Skill ist die kleinste sinnvolle Aufgabe, die der Assistent übernimmt – keine Multi-Modal-Wundertüte, sondern eine klar abgegrenzte Funktion mit Tool-Use auf vorhandene SAP-APIs.
Anatomie eines Skills
mermaid
flowchart TD
IM["INTENT-MATCHING<br/>Kann ich Bestellung 4500001234 freigeben?"]
IE["INPUT-EXTRACTION<br/>LLM mit JSON-Schema"]
TL["TOOLS mit Berechtigungs-Check<br/>get_purchase_order · get_supplier_risk_score<br/>get_three_way_match_status · release_purchase_order"]
PO{"POLICY – Mensch im Loop"}
AU["AUDIT<br/>Tools, Inputs, Outputs, Entscheidung"]
IM --> IE --> TL --> PO --> AU
click IM call mmdInfo() "Mehrere Formulierungen, ein Skill: ob nach Freigabe, Freigabe-Status oder den Voraussetzungen gefragt wird – das Matching erkennt die Absicht, nicht den Wortlaut."
click IE call mmdInfo() "Die Extraktion läuft gegen ein striktes JSON-Schema: purchase_order_id, supplier_name, user_intent. Was das Schema nicht hergibt, wird nachgefragt statt geraten."
click TL call mmdInfo() "Vier deklarierte Tools, jedes mit Berechtigungs-Check gegen die SAP-Rolle des Anwenders. Die eigentliche Freigabe ist gated – sie läuft nur nach bestandener Policy."
click PO call mmdInfo() "Beträge über 50.000 CHF erfordern explizite Bestätigung, ein Risk-Score über 0.6 eskaliert. Sonst: direkte Freigabe – aber erst nach Anzeige der 3-Way-Match-Daten."
click AU call mmdInfo() "Jeder Schritt wird protokolliert: aufgerufene Tools, Eingaben, Ausgaben, Policy-Entscheidung und finale Aktion. Revisionsfähig pro Vorgang."
Wie wir ihn implementieren
Phase 1 – Skill-Discovery (1–2 Wochen)
Wir setzen uns mit Power-Usern eines Fachbereichs zusammen und finden 5–8 Skills, die sich klar abgrenzen, nicht zu komplex sind und einen messbaren Nutzen haben. Anti-Pattern: "ein Universal-Skill, der alles kann" – funktioniert in der Praxis nie zuverlässig.
Skill-Discovery-Kriterien:
- Häufigkeit: mindestens täglich von mehreren Usern aufgerufen
- Klarheit: Eingabe und Ausgabe sind eindeutig bestimmbar
- Werkzeug-Verfügbarkeit: alle nötigen APIs existieren oder lassen sich in einer CAP-App ergänzen
- Verantwortung: ein Owner im Fachbereich, nicht nur in der IT
Phase 2 – Erste 2 Skills (3–4 Wochen)
- Skill A in voller Breite umsetzen (Tools, Policy, Audit)
- Skill B als zweite Variante mit anderen Datenquellen
- End-to-End-Tests inklusive Berechtigungen und Eskalationen
- Übergabe an Schulung und Rollout
Phase 3 – Skalierung (laufend)
- Bibliothek aufbauen, Versionierung einführen
- Quartalsweise Review der Confidence- und Eskalations-Quoten
- Feedback-Loop von den Anwendern in den Skill-Owner
Drei realistische Beispiele aus 2026
a) Reporting-Co-Pilot für Finance
Anstatt sich durch Embedded Analytics zu klicken, formuliert ein
Controller eine Frage in natürlicher Sprache:
"Wie haben sich die Personalkosten der DACH-Region im Q1
gegenüber Plan entwickelt, mit Ausreissern grösser 5%?"
Der Skill:
- Erkennt die Intent-Klasse (variance analysis)
- Extrahiert Filter (Region: DACH, Periode: Q1, Schwellwert: 5%)
- Ruft das richtige CDS-View-Modell auf
- Liefert Tabelle, Top-Ausreisser, mögliche Ursachen-Hypothesen
- Bietet als Folgefrage einen Drill-Down auf die Top-3 Abweichungen
b) Service-Techniker im Feld
Ein Service-Techniker auf einer Maschine in St. Gallen fragt:
"Was war beim letzten Service hier schief?"
Der Skill:
- Geo-Kontext aus dem Mobilgerät → Equipment-ID
- Letzte 3 Service-Reports zur Equipment-ID
- Identifizierte Wiederholmuster, offene Punkte
- Empfohlene erste Diagnose-Schritte
c) Bestelleingang-Triage
Eingehende Bestellungen aus E-Mails landen in der Joule-Inbox eines Vertriebs-Innendienst-Mitarbeitenden. Joule:
- Klassifiziert (Standard-Bestellung vs. Sonderfall)
- Extrahiert Felder (Kunde, Artikel, Menge, Wunschtermin)
- Validiert gegen Stammdaten – fehlende oder mehrdeutige Felder werden als Review-Ticket markiert
- Bei "klar": leitet die Erstellung des Sales Orders ein
- Bei "unklar": Vorbereitung für Sachbearbeitung mit konkretem Hinweis, was zu prüfen ist
Architektur
mermaid
flowchart TD
U["Anwender im Fiori-Launchpad"]
JF["Joule Frontend<br/>eingebettet im Launchpad"]
RT["Joule Studio Runtime<br/>auf BTP"]
IMR["Intent-Matcher"]
LLM["LLM-Call via AI Hub"]
ORC["Tool-Use-Orchestrator"]
PE["Policy Engine"]
AL["Audit Logger"]
S4["SAP S/4HANA APIs"]
VE["HANA Cloud Vector Engine"]
BA["BTP-Custom-Apps"]
U -->|"spricht / tippt"| JF
JF --> RT
RT --> IMR
RT --> LLM
RT --> ORC
RT --> PE
RT --> AL
ORC --> S4
ORC --> VE
ORC --> BA
click U call mmdInfo() "Der Anwender bleibt im gewohnten Launchpad – kein Tool-Wechsel, keine neue Oberfläche. Joule ist ein Panel, kein Produktwechsel."
click JF call mmdInfo() "Das Joule-Panel nimmt Sprache oder Text entgegen und ruft die Skill-Runtime über eine klar definierte API auf."
click RT call mmdInfo() "Die Runtime auf der BTP orchestriert alles Weitere: Sie ist der kontrollierte Rahmen, in dem das LLM arbeitet – nicht umgekehrt."
click LLM call mmdInfo() "Der eigentliche Modell-Call läuft über den AI Hub – austauschbar zwischen Anbietern, mit zentraler Kosten- und Mandanten-Kontrolle."
click ORC call mmdInfo() "Der Orchestrator führt deklarierte Tools gegen S/4HANA-APIs, die HANA Cloud Vector Engine für RAG-Quellen und eigene BTP-Apps aus – nichts davon entscheidet das LLM allein."
click PE call mmdInfo() "Schwellwerte, Eskalationen und Mensch-im-Loop-Regeln sind deterministischer Code ausserhalb des Modells."
click AL call mmdInfo() "Lückenloses Protokoll über alle Schritte – die Grundlage für Audit und kontinuierliche Verbesserung der Skills."
KPIs, die wir tatsächlich messen
| Kennzahl | Ziel-Korridor |
|---|---|
| Skill-Trefferquote | > 90 % korrekt |
| Latency end-to-end | < 4 s P95 |
| Eskalations-Rate (Policy-Stops) | 5–15 % |
| User-Satisfaction (CSAT) | ≥ 4.2 / 5 |
| Cost-per-Skill-Call (avg) | < 0.05 CHF |
| Adoption (DAU / WAU) | > 0.4 |
Datenschutz und Compliance
- Input-Filter: PII-Detection vor dem LLM-Call (Namen, IBAN, Telefonnummern). Bei Treffern: Maskierung oder lokales Routing.
- Output-Filter: Halluzinations-Check gegen Tool-Outputs. Wenn das LLM behauptet, ein Feld habe Wert X, prüft der Filter gegen die tatsächliche API-Antwort.
- Region: Joule kann pro Skill auf Schweizer / EU-Region gepinnt werden – wichtig für FINMA-relevante Skills.
- Audit: vollständig, inklusive der Tool-Outputs. Reicht für EDÖB-Anfragen; Aufbewahrungsfrist konfigurierbar.
Was wir nicht tun
- Skills bauen, deren Werkzeuge wir nicht beherrschen. Ein Skill ist nur so gut wie die zugrundeliegenden APIs.
- Free-Form-Antworten ohne Tool-Use. "Erfundene" Antworten ohne Datenrückbezug sind in einem Geschäfts-Kontext nicht tolerierbar – Joule darf nicht halluzinieren.
- Universal-Joule. Skills sind zweckgebunden, klein, prüfbar.
Stand: 2026-05-12
