Blog

KI ist in aller Munde. So auch bei SRB. Wir haben bereits vor einiger Zeit begonnen, uns mit dem Thema in und außerhalb SAP auseinanderzusetzen. Einer der Fragen: Welche Möglichkeiten gibt es, Non-SAP-KI zusammen mit SAP zu nutzen, und wie einfach ist das? Wir haben uns einen recht simplen Case angeschaut – einen Bot für Microsoft Teams.

KI ist da, um Prozesse und Workflows zu unterstützen und unser aller Arbeitsleben zu vereinfachen, lautet der allgemeine Tenor. So weit, so gut. Doch stimmt das auch, wenn man Non-SAP-KI und SAP zusammenspannt?

Wir wollten die Probe aufs Exempel machen und hatten eine Idee: Möglichst einfach Information aus SAP in MS Teams zur Verfügung zu stellen ohne Anmeldung im SAP und Kenntnisse von Transaktionen und deren Funktion. Denn wie wir alle wissen: Der Anmeldeprozess für SAP Cross-Application Time Sheets (CATS) im Web oder im SAP GUI kann „aufwendig“ sein.

SAP-Infos mittels MS-Teams-Chatbot abrufen – wie einfach geht das?

Ziel unseres kleinen Projekts war es, die Leistungsfähigkeit von Künstlicher Intelligenz (KI) bei der Extraktion strukturierter Informationen aus SAP für unstrukturierte Anfragen zu untersuchen. Oder konkret formuliert: Wir wollten einen Chatbot in Microsoft Teams entwickeln, der Mitarbeitenden ermöglicht, mithilfe natürlicher Sprache relevante Informationen aus SAP abzurufen. In unserem Beispiel Arbeitszeiten.

Zu Beginn also hatten wir 10 Fragen definiert, die der Chatbot beantworten sollte. Zum Beispiel: “Was sind meine Arbeitszeiten vom letzten Monat?“ Zwei unterschiedliche Möglichkeiten hatte ich beim ersten kurzen Umschauen gefunden, einen habe ich gewählt: Power Virtual Agents (PVA), ein von Microsoft angebotener Low-Code-Service. Die andere Variante, nämlich den Bot selbst zu programmieren und auf einem Server laufen zu lassen, hatte ich erst mal verworfen, wobei mir klar war, dass ich dort mehr Freiheiten gehabt hätte und nicht so sehr eingeschränkt beim Funktionsumfang gewesen wäre.

In PVA ist es möglich über spezielle „Cards“ einen Power Automate Flow anzudocken. Da man in PVA allein nicht so viele Möglichkeiten hat, wird die meiste Logik in Power Automate umgesetzt. Hier wird mittels Schleifen und Bedingungen die Information verarbeitet und aufbereitet.

Um die Intentionen bzw. die Fragen von Anwendenden zu erkennen, wird noch ein KI-Model gebraucht. Natürlich kam mir da sofort ChatGPT in den Sinn…allerdings nicht ohne Bedenken. Denn die zentralen Fragen, die sich hier auftaten, waren, ob und welche Informationen gespeichert werden und ob die Erkennung von unterschiedlichen Sätzen immer dieselben Informationen zurückgibt. Nach reiflicher Überlegung haben wir und schlussendlich aus genau den beiden Gründen gegen ChatGPT entschieden.

Gewählt habe ich nach reichlicher Überlegung die Cognitive Cloud von Microsoft Azure. Diese lässt sich auch über spezielle Actions in Power Automate einbinden.

Um die Ausgabe zu formatieren und schöner darzustellen, wurden die Azure Functions benutzt. Diese ermöglichen es mit vorgegeben Programmiersprachen Code zu schreiben und diesen serverless ausführen zu lassen. Für das Abrufen der Daten aus dem SAP-System wird das API-Management sowie ein schon vorgefertigter Dienst (CATS) verwendet. Die Daten sind über einen http-Request abrufbar.

Ein KI-Workflow in the making

Wie also funktioniert das Ganze? Microsoft Teams ist unser Startpunkt des Geschehens. Hier erscheint ein neuer Chat-Partner, in unserem Fall der Chatbot, den wir „SRBot“ getauft haben. Um spezifische Fragen zu stellen, muss man erst das passende Thema aufrufen. Dieses kann man über mehrere Befehle, wie zum Beispiel „Öffne SRB Zeit Management“ oder „Zeiten abrufen“ machen. Dadurch wird in PVA das passende Thema als Flow gestartet. Danach kann dann eine der 10 Fragen, auch in abgewandelter Form, gestellt werden.

Die Security Card, die auf dem unteren linken Bild zu sehen ist, loggt den User mit seinen Microsoft-Daten ein. Wenn man zum ersten Mal mit dem Bot schreibt, wird man dazu aufgefordert sich mit der Firmen-E-Mail-Adresse anzumelden. Die Anmeldung generiert einen AuthToken, in welchem wichtige Daten zum Benutzer bzw. der Benutzerin verschlüsselt gespeichert sind. Dieser wird im späteren Verlauf noch wichtig.

Das rechte Bild zeigt, wie Power Automate aufgerufen wird. Hier erfolgt die Übergabe der Frage des Users und der AuthToken an den Flow. Zurück kommt nur die Ausgabe, die dann von PVA wieder zurück an den Bot als Nachricht geschickt wird.

In Power Automate werden dann die einzelnen Schritte zusammengeführt und koordiniert. Zum einen kommt hier die Anfrage von PVA an, zum anderen werden Requests an die Azure Cognitive Services und an das SAP-System getätigt.

Die Variablen selbst werden in CLU Recognition initialisiert. Ein vorgefertigter Baustein schickt einen Aufruf an die Azure Coginitve Services und die Frage des Anwendenden wird übergeben. Je nachdem, was der Baustein als Antwort liefert, sprich welches Intent erkannt wurde, werden unterschiedliche weiterführende Flows aufgerufen.

Auch in der TimeRecordsAnfrage startet der Flow mit dem Initialisieren von Variablen. Dann werden die Parameter, sprich die zwei Daten in ein passendes Format gebracht und überprüft, ob ein Zeitraum abgefragt wird oder nur ein einzelner Tag, danach, ob nur eine gewisse Art an Zeiteinträgen wie zum Beispiel Urlaub oder Krankenstand benötigt wird.

In weiterer Folge gibt es einen Try and Catch Block, in dem ein http-Request an den SAP-CATS-Service durchgeführt wird. Sind die Einträge leer, wird eine vorgefertigte Nachricht ausgegeben. Ansonsten wird das Ergebnis, je nach dem, was der Intent vom Benutzer oder der Benutzerin war, zur Ausgabe verarbeitet und aufbereitet.

Im Language Studio wurde ein Language Understanding Model erstellt, welches in der Lage ist, das Intent eines Satzes in vorgegebene Kategorien einzuordnen. Dafür schreibt man viele Beispielsätze und ordnet diese einer selbst erstellten Kategorie zu. In unserem Fall „Zeiten.Abrufen“.

Zusätzlich dazu werden weitere wichtige Schlüsselmerkmale, die Entities, erkannt. Hierbei gibt unterschiedliche Möglichkeiten: Vorgegebene Kategorien, die selbständig die Entities erkennen, Machine-Learned Entities, welche man in den Sätzen einzeichnen kann und die anhand der Position bestimmt werden, sowie RegEx Pattern.

Da Power Automate bei komplexeren Aufgaben, sehr schnell sehr unübersichtlich wird, habe ich für die Ausgabe Azure Functions verwendet. Hier kann man aus einigen vorgegeben Programmiersprachen auswählen und die Funktion über einen API-Call erreicht werden. Die Daten zur Ausgabe werden im Body an die URL geschickt, dann von der Funktion zur Ausgabe aufbereitet und anschließend wieder zurückgeschickt.

Und wie gut sind die Ergebnisse?

Der Bot konnte alle bekannten Fragen ohne Probleme beantworten. Restliche oder neue Fragen könnte man mit, im Vergleich wenig Zeitaufwand, dazu implementieren. Schließlich steht das Grundgerüst der Programme und Schnittstellen ja schon. Es würde weiters auch noch die Möglichkeit geben, eine detaillierte Ansicht oder die Zusammenfassung der Stunden zu bekommen, aber dies geschieht derzeit nur bei gewissen Anfragen.

Für eine Antwort braucht der Bot ca. 10 Sekunden. Das ist recht lange, aber wenn man den Aufbau des Workflows bedenkt, ist es noch im Rahmen. Diese Zeit kommt vor allem durch die vielen Blöcke in Power Automate zustande, aber auch durch einige Requests an andere Dienste. Aufgrund der Wahl von PVA und Power Automate haben sich viele Schnittstellen ergeben, wo Zeit verloren geht. Dadurch dauert es teilweise länger, bis der Bot eine Antwort schickt.

Das alles zeigt, dass Power Automate sich eigentlich nur für kleine Logiken eignet. Sobald ein bisschen Komplexität ins Spiel kommt, wird es sehr schnell sehr unübersichtlich. Daher habe ich auch als Verarbeitung der Daten Microsoft Azure Functions gewählt. Hier kommt man deutlich übersichtlicher und besser an ein Ergebnis. Der Nachteil jedoch: noch eine Schnittstelle mehr.

Zudem ernüchternd: Bei Microsoft muss man für jedes Produkt extra zahlen. Aber zumindest kann man diese sehr lange gratis testen, um einschätzen zu können, ob sie auch den eigentlichen Zweck erfüllen. Die Preise von Microsoft Azure Lösungen sind sehr unübersichtlich und es ist schwierig den genauen bzw. besten Preis für seinen individuellen Einsatzzweck zu finden, da es bei den meisten unterschiedliche Zahlungsmethoden gibt, z.B. Pakete mit gewissem Limit oder „Pay as you go“.

Für das KI-Model sind darüber hinaus nur wenige Daten zum Trainieren vorhanden. Des Weiteren wird bei Language Studio hauptsächlich nach Position der Schlüsselwörter gesucht. Diese beiden Punkte zusammen machen es dann teilweise schwierig, die richtigen Schlüsselwörter zu erkennen bzw. ein großes Spektrum an Intents abzudecken.

Alles in allem lässt sich zusammenfassen, dass Non-KI-Lösungen mit SAP funktionieren, aber doch einen gewissen Aufwand nach sich ziehen. Die Qualität allerdings ist vollkommen in Ordnung. Wirft man aber einen Blick auf die Geschwindigkeit, in der sich KI weiterentwickelt und den Hype, der um das Thema existiert, ist aber davon auszugehen, dass dies bald zur echten Commodity im Arbeitsalltag wird.