Am 30. Juni und dem 1. Juli fanden die DSAG KI Thementage im Harres, St. Leon-Rot, statt. Es war eine bezahlte Veranstaltung die recht gut besucht war. Der erste Tag war darauf ausgerichtet die generelle KI Strategie der SAP zu veranschaulichen. Der zweite Tag legte den Fokus in 3 Thementracks auf die konkrete Verwendung von KI in SAP Lösungen. Das Thema KI ist natürlich aktuell eines der wichtigeren Themen der SAP und der generellen SAP Welt. Auf der Sapphire 2026 war das neu vorgestellte Autonomous Enterprise ein ganz großes Thema.
Der generelle Eindruck der Veranstaltung ist, das man von Seitens DSAG hier nicht falsch machen konnte. Das Thema KI ist gerade im SAP Umfeld noch recht neu. Mit der SAP findet man hierzu auch einen willigen Partner wenn es darum geht die Agenda mit Vorträgen zu füllen. Wo, wenn nicht bei so einer Veranstaltung, kann man besser einem dankbaren und verlässlichen Publikum die Strategie platzieren? Das Problem ist halt wie immer bei so etwas: es muss auch Inhalte geben. Gerade der erste Tag zeigte eines deutlich: dafür war zu früh.
Bis auf eine Idee der Vision hat die SAP nicht viel anzubieten. Die gleiche Veranstaltung ein Jahr später, oder vielleicht nach der TechEd im Herbst, hätte mehr Inhalt bieten können. Oder: muss dann Inhalte bieten.
Aktuell hat die SAP als Vision: irgendwas mit KI. Es gibt einzelne Bereiche die sich schon länger damit beschäftigen. Dort ist das Thema dann auch besser ausgearbeitet. Vor allem in Hinblick auf Kundenfragen wie: Warum? Wieso? Weshalb? Und natürlich: was habe ich davon? Wie komme ich da hin? In einem einzelnen Modul zu sehen wie über ein Chat Anfrage an Joule die Antwort generiert wird, wie Daten analysiert werden können. Ja, das ist gut. Aber das ist halt nur die eine Insel. Wie komme ich aber über den Ozean auf zu den anderen Inseln? Und wie bekomme ich mit meinen vorhandenen Resourcen eigentlich ein Boot gebaut? Kurz: einzelne Lösungen mögen schon weiter sein als andere und wie Inseln aus dem Ozean aufragen. Da müssen aber mindestens jetzt von der SAP ganz schnell Brücken gebaut werden, wenn nicht sogar der Ozean tiefer gelegt werden und ein Kontinent entstehen.
Ja, die Ankündigung des Autonomous Enterprise ist noch recht neu. Etwas mehr als “wir arbeiten daran” und “Agenten werden irgendwie dann schon funktionieren” sollte es aber schon sein. Um bei der Idee der Vision zu bleiben: es gibt aktuell kein Walking Skeleton für das Autonomous Enterprise. Einzelne Knochenfragment, ja. Ein Skelet ist aber nur mit Fanatasie herleitbar. Von Muskeln, Sehnen oder gar Haut muss man gar nicht erst anfangen. Aber das darf man auch erst nächstes Jahr erwarten.
Was man hat ist die North Star Architektur 🔗, hier in der Web Version 🔗. Hier gäbe es Informationsbedarf. Wie passt das mit dem Schaut-mal-so-viel-KI-in-BTP Dokument zusammen? Wie mit der Business Suite 2.0 aus dem letzten Jahr? Viele Teile waren da ja schon da. Wurden schon (fast) exakt so vorgeführt. Welche Deltas gibt es denn? Wo ist man denn hier schon bereit für den produktiven Einsatz? Man kann - und sollte - nicht in einem Nebensatz Fiori beerdigen ohne mal klar sagen zu können wie es denn UX mäßig jetzt weitergeht. Mit einer 13 Jahre alte Technologie möchte niemand arbeiten müssen? Tja, sieht schlecht aus für SAP. Da kommt man auf ein mehrfaches von 13 Jahren. Schon interessant das es den Sprechern nicht auffällt wenn man so eine Aussage tätigt. Und gerade Fiori hat in den letzten Jahren sich erneuert und erweitert. Der Kontext in dem sich hier die UX und Fiori bewegen wäre wichtig gewesen. War wohl keine Zeit oder Veranstaltung für die notwendige Tiefe. App-less UI sollte ja (hoffentlich) nur eine Alternative sein. Fachbearbeiter werden auch in Zukunft mit Tabellen arbeiten, denn - obacht: Realität!, das ist oft der beste Weg mit den ganazen Daten sinnvoll zu arbeiten. Aber ja, Schade, wirklich Schade, das man den Weg den Fiori und das Compositional Design System 🔗 im Sinne von KI und Design 🔗 weitergeht nicht vertieft hat. Stichwort: liebe Kunden und Partner, wie bereitet man sich auf die neue Welt vor? Hier bahnt sich das gleiche Fiasko an wie damals als in einem Nebensatz der Fiori Frontend Server beerdigt wurde.
Zurück zum Inhalt. Vorgeführt wurde Joule Work, Build, Joule for Developers, Joule for Consultants, Joule for einer-geht-noch. Wer sich da jetzt nicht wirklich auskennt, der ist verwirrt. Welches Joule braucht man denn jetzt genau um diese Frage zu stellen oder dieses Coding abzuändern? Die Antwort auf eine Frage kann die Materialnummer des Services sein den man bestellen könnte, aber man erst mal nachschauen muss ob man darf, und wenn ja, wie und wo man das bestellt. Ist ja auch das Enterprise-Problem: man weiss ja gar nicht was benötigt wird. Würde man wohl mal alle Services aufschreiben die man benötigt um einen Joule Agent einzusetzen … es würde mich nicht überrraschen wenn diese Liste ein paar Seiten füllt. Wenn man dann mal aufzeigen würde welcher dieser Services denn 24/7 einfach mal durchlaufen und keine Probleme machen … diese Liste dürfte ziemlich ausgedünnt sein. Komplexe Landschaften bedeuten auch: Ausfälle kleinerer Services können katastrophal sein. Hier hat sich in den letzten 10+ Jahren nichts geändert: die Services müssen verfügbar sein. Wissen muss vorhanden sein.
Besser ist aber hier immer noch Guidelines, Richtlinien und Best Practices anzubieten. Das kam dann auch etwas zu brutal bei den Kundenvorträgen zum Vorschein. Da werden dann halt die Lücken geschlossen, da wird dann mit KI so gearbeitet das es halt klappt. Und das bedeutet dann doch recht oft: sich den Weg zum Ziel selbst suchen. Wohl dem der dann gute Partner hat. Für den Großteil der SAP Kunden sieht die Realität aber dann doch so aus das man da in der KI Ecke alleine steht, erst intern Wissen aufbauen muss oder generell etwas von der Stange von der SAP will. Wie das jetzt klappen soll mit den ganzen kundenspezifischen Coding? Eigenentwicklungen? Wohl erst mal gar nicht. Denn, und das ist jetzt das ganz große Problem, der Elefant im Raum: keiner ist wirklich auf die KI Welle vorbereitet. Die SAP versucht noch irgendwie vor die Welle zu kommen. Aber die Kunden? Die müssen ja warten bis da was kommt von der SAP. Das wird nicht lustig werden. Schön wenn die SAP es bis 2027 irgendwie hinbekommt was zu haben, aber bis das dann bei Kunden landet ist halt auch schon 2028, und dann auch nur wenn der Kunde, ja was denn nun? hat: erst noch auf S/4HANA, mit RISE Vertrag? In die public cloud? Zeitpunkt für die Partner hier zu helfen. Aber die waren nicht auf der Veranstaltung.
Bei den Vorträgen von IBSolution und SFS, cbs wurde das Problem ehrlich angesprochen. Vor allem der von Felix Weyde: unspektakulär, dafür aber eindringlich. Die Zukunft steht und fällt mit der Datenqualität. Shit in, shit out. Und hier muss man sagen: die Sünden der Vergangenheit werden uns einholen. Zu lange, zu oft war die Datenqualität zwar ein Kriterium, aber man scheute den Aufwand. Jetzt wird man halt feststellen: das wird teuer. Beim Beispiel mit den Bestellungen von SFS/cbs hat man gesehen: das Chaos regiert halt in der Realität. Solche Bestellungen sind eine Herausforderung. Aber halt auch normal. Da muss dann die Qualität passen. Aber wer hat denn alles seine Lieferanten, Kunden, Stammdaten denn im Griff? KI trifft auf SAP. LLMs die Text mögen, treffen auf 50 Jahre alte Daten, rechtliche Vorgaben, Prozesse die von Menschen, für Menschen gemacht wurden. In 1.000 Fällen darf es halt nicht sein das 999 geklappt haben und einer nicht. Das muss skalieren. Aber wie?
Wenn die Vision noch eher eine Idee ist, dann doch bitte erklären was ich tun muss um an der Idee teilhaben zu können. Wie funktioniert es denn jetzt das ich der SAP AI beibringe wie mein Unternehmen funktioniert? Das Company Memory 🔗 ist ja interessant. Aber was muss ich tun um es verwenden zu können? Wie bekomme ich meine Dokumente da rein? Muss ich die aufarbeiten, in eine bestimmte Struktur bringen oder generell: was kann ich heute tun um in der Zukunft davon einen Nutzen zu haben? Wie sieht das mit den unterschiedlichen Realitäten aus? Mehr als eine Folie wäre nett gewesen, aber dann gilt ja wieder: das kommt erst in Q4 2026. Ebenso: was wenn man auf eine Lösung setzt die die SAP zwar hat, aber nicht wirklch liebt? Die Wartungsgebühr wird ja gernde genommen. Aber ist die jetzt auch Zukunfts- und KI-sicher? Wie wäre es mit einer Liste der Lösungen die heute, morgen, übermorgen KI ready sind und bei welchen man nicht hoffen sollte? Und da meine ich nicht die Produktebene wie S/4HANA: runter auf Modul -> Komponente. Kommt da was von der SAP? Und wenn nicht: was kann ich tun?
Was es schon gibt is Joule, sind Agenten. Was es nicht gibt, sind Kunden. Über der ganzen Veranstaltung hing natürlich die nicht explizit erwähnte Grundvoraussetzung für vieles: SAP Cloud, irgendwie. Anzahl Anwesender die S/4HANA Publich Cloud nutzen: an 2 Fingern abzählbar. RISE Kunden? besser, aber auch hier gilt halt: es ist kompliziert. BTP? Klar, viele. Aber BTP für AI? Seien wir ehrlich: der Use Case für die BTP ist Integration, dann Workzone, Build. Man kann vieles auch ohne RISE inzwischen machen. Nach dem Cloud-nur-mit-RISE Fiasko ist es jetzt halt ein Cloud-nur-mit-RISE-Vertrag Fiasko. Man fragt sich ja warum es nicht ein ganz einfaches, simples, kostengünstiges Vertragsmodell gibt mit dem eigentlich (fast) jeder zumindest auf BTP gehen könnte. Ein SaaS ATC inkl. CVA wäre etwas. Aber auch ein einfaches onboarding auf Workzone, Build, AI etc. Und ja, das scheitert zu oft, nämlich fast immer, an den Kunden und deren Unfähigkeit sich mit den Basics wie SSO auseinander zu setzen oder sich mal klar zu machen was der Cloud Connector ist und wie der funktioniert. Oder einfach mal dafür zu sorgen das die eigenen on-premise Systeme SSO fähig sind, sei es per OIDC, SAML oder SNC. Gute Doku kann hier helfen oder ein kostenloser Service beim Buchen der Joule-für-Einstieger BTP Lösung: die SAP Berater kommen vorbei und sorgen dafür das die Verbindung in 1-2 Tagen steht. Wenn nicht, dann bekommt der CIO, CTO und CEO eine Liste mit den Dingen die intern die erfolgreiche Konfiguration verhindert haben.
Während bei der SAP die einzelnen Bereiche die KI erkunden und neben Demos auch Ankündigen haben (wir haben 1 Agenten, der nächste kommt dann bald), sind einige aber noch abgehängt. Bei vielen Kunden sieht man mehr Verunsicherung als gesetztes Wissen. Was ist denn Joule jetzt überhautp? Ist das die Chat Eingabe? Der Agent? Plattform? Joule Workzone? Ist Joule ein LLM? Und was ist denn jetzt diese Amazon Q schon wieder? Und was kostet der Spass? Bei den Kosten muss leider sagen: nicht einfach mal auf den Estimator verweisen oder sagen: oh, Lizenzen, da bin ich raus. Ich mach nur Produkt, nicht Kommerzialisierung. Liebe SAP, wenn man eine Demo hat in der so schön gezeigt wird wie von einem Prompt aus die Daten ausgelesen werden und in der neuen post-Fiori UI dargestellt werden. Dann liefert auch die Hintergrundinfos dazu: welches Release? Was wurde gerade von der KI getan? Wie viele Token hat das verbraucht? Welche LLM wurde verwendet? Waren Zusatzinfos / Kontext notwendig und: was hat diese Demo denn gekostet? Einfach mal zeigen: wenn man diese Vertragsart hat, wurde so viel davon aufgebraucht. Ja, das ist kompliziert. Aber so langsam hat man keine Luste mehr die Katze im Sack zu kaufen und später festzustellen das der Einsatz irgendwie x-fach teurer ist als gedacht.
Bei meiner Anmeldung war der Inhalt zum Technology Track ausgereifter als die Lücken in den Tracks Finance und Vertriebsprozesse. Von der finalen Agenda ausgehend hätte ich wohl doch ein, zwei Vorträge von dort mir anschauen sollen. Bei Finance und Vertrieb findet man eher die oben erwähnten Inseln. Wie denn KI Agenten erstellt und eingesetzt werden in konkreten Szenarien wäre schon interessant gewesen. Aber leider verpasst. Die Anzahl der Partner / Kunden kam mir auch etwas höher vor als im Track Technologie. Hier gilt wohl auch: die Kunden machen halt mal und suchen sich ihre Partner.
Ein Partner (AWS) hat ja einen eigenen ABAP MCP Server entwickelt, sowie - und das ist in meinen Augen der eigentliche Mehrwert - ABAP Skills. So ein Skill übernimmt die Arbeit. Ein MCP Server stellt ja nur der KI / LLM die Möglichkeit bereit Dinge zu tun, also mit einem Dienst oder ähnliches zu interagieren. Ein Skill übernimmt die Arbeit eines Menschen: lese die Klassen aus und dokumentiere sie. Finde die Fehler, schreibe Unit Tests, erstelle Tickets dazu, erstelle einen Management Report. Bei der SAP ist das dann ein Agent. Einer für ABAP ist verfügbar, einer angekündigt. Man braucht wohl Joule um den auszuführen. Aber warum? Ist ja (habe nachgefragt) nur ein Markdown Text. Verfügbar in einer SAP Note. Der Gag: so ein Skill kann ich halt ohne Probleme in VS Code meinem Repo hinzufügen. Wird auch genau so gemacht in der Fiori Entwicklung. Die KI findet den Skill und kann damit arbeiten. In der ABAP Welt … kann man halt keine Markdown Datei (*.md) dem Repo hinzufügen. Also: Agent. Ich würde ja sagen: einfach mal md als ABAP Dateityp zulassen, oder … schickt doch dieses virtuelle Dateisystem für ABAP in Rente. Lokale Dateien, und dann halt die kompatiblen ins SAP ABAP synchronisieren. ja, ich weiß: Aufwand. Aber halt nur auf der SAP Seite. Damit: kundenfokus zuerst, macht einfach mal liebe SAP. KI Use Cases sagen schon mal Danke.
Und jetzt? Während den 2 Tagen kam in der Presse die Meldung das der SAP CEO sich dem Thema KI annimmt. Es hat sich wohl innerhalb der SAP rumgesprochen das man außer Fragmente eines Skeletts nicht viel hat. Mal schauen ob die Bündelung der KI Themen beim CEO hilft. So schnell wird es keine Besserungen geben. Aber nächstes Jahr, sollte es dann wieder einen DSAG KI Tag geben, wäre es gut zumindeset die Brücken zwischen den Inseln zu haben. Ach ja, natürlich nicht nur für die 0,01% derer die dann die ganzen Anforderungen und Sonderlocken wie: S4 Public Cloud, BTP, BDC, Signavio, LeanIX, Entra ID, RISE, Joule, und und und erfüllen.