TECH MONDAY: Sprachkommunikation mit Dynamics 365 CE-Systemen

Bis vor kurzem war die Arbeit mit einem CRM-System noch untrennbar mit einem Bildschirm, einer Tastatur und Dutzenden von Bildschirmansichten sowie Klicks verbunden. Heute wird dank des Einsatzes von Sprachmodellen und Mechanismen der künstlichen Intelligenz ein Szenario Realität, in dem ein Vertriebsmitarbeiter auf dem Weg von einem Termin eine Notiz diktieren, ein Servicetechniker die Historie der Kundenanfragen abfragen und ein Geschäftsführer mit einem einzigen Satz den Status des Verkaufstrichters überprüfen kann, ohne eine Anwendung öffnen zu müssen. Der Schlüssel zu diesem Ansatz ist das Konzept des „Headless CRM“. Im klassischen Modell bildet das CRM-System eine untrennbare Einheit: Daten, Geschäftslogik und Benutzeroberfläche bilden ein einziges Produkt, das über eine dedizierte Anwendung genutzt wird. Bei dem hier beschriebenen Ansatz wird die Präsentationsschicht von den Daten, Geschäftsregeln, Berechtigungen und Prozessen getrennt. Das CRM wird zu einem über eine API verfügbaren Dienst, und die Schnittstelle für die Kommunikation kann ein Webformular, eine mobile App, ein KI-Agent oder die Stimme des Nutzers sein. Die Daten und die Regeln für ihre Verarbeitung bleiben unverändert, während sich die Art und Weise der Interaktion des Menschen mit dem System ändert.

Es ist hervorzuheben, dass sich das behandelte Thema, trotz des Verweises auf Dynamics 365 CE (Customer Engagement) im Titel, nicht auf ein einziges Produkt beschränkt. Die Grundlage bildet in diesem Fall Microsoft Dataverse, also ein Cloud-Dienst, auf dem die Anwendungen von Microsoft (Dynamics 365 Sales, Customer Service, Field Service und Customer Insights) sowie maßgeschneiderte Lösungen, die auf der Power Platform entwickelt wurden, aufbauen. Der besagte Dienst stellt ein einheitliches API, ein Sicherheitsmodell und Automatisierungsmechanismen sowie einen MCP-Server (Model Context Protocol) bereit – einen offenen Standard, über den KI-Agenten mit externen Datenquellen und Tools kommunizieren. Daher ist Dataverse ein ideales Beispiel für eine Technologie, die im Rahmen eines Headless-CRM-Ansatzes eingesetzt werden kann.

In den folgenden Abschnitten des Artikels werde ich mögliche Ansätze zur Implementierung eines Voice-Chat-Systems beschreiben, das die Interaktion mit Daten im Dataverse-Repository ermöglicht. Da sich der Inhalt des Artikels auf unsere tatsächlichen Erfahrungen bei der Implementierung der besprochenen Lösung stützt, werden darin auch die „Sackgassen“ erwähnt, auf die wir bei der Entwicklung der Anwendung gestoßen sind. Wir werden außerdem den Ansatz zur Datensicherheit in Systemen erörtern, die von KI-Agenten genutzt werden.

Kapitel 1: Der Copilot steht über allem!

Da wir ein Unternehmen sind, das sich seit vielen Jahren auf die Bereitstellung von Geschäftslösungen auf Basis der Microsoft Power Platform spezialisiert hat, war für uns der mit dem Microsoft-Tool „ Copilot Studio “ erstellte Agent die naheliegende erste technologische Wahl. Für die Kommunikation mit dem Dataverse-Repository (die in diesem Anwendungsfall darin bestand, die Aktivitäten der Vertriebsmitarbeiter im System zu erfassen) nutzten wir das MCP-Protokoll sowie den Server, der nativ im Rahmen des Dataverse-Dienstes verfügbar ist. Die ursprüngliche Version der Lösungsarchitektur sollte wie folgt aussehen:

Leider zeigte sich bereits in der Prototypenphase eine grundlegende Schwäche des oben beschriebenen Ansatzes. Keiner der Standardkanäle, in denen wir einen mit Copilot Studio erstellten Agenten veröffentlichen können, bietet die Möglichkeit zur Kommunikation per Sprachchat. Die mobile App und die Benutzeroberfläche des Microsoft 365-Portals bieten zwar die Möglichkeit, Sprachnachrichten in Text umzuwandeln, was wir jedoch als wenig komfortablen Kompromiss betrachteten. Bei der Kommunikation mit dem Agenten in der mobilen Microsoft Teams-App erwies sich hingegen die Textkommunikation als einzige unterstützte Form der Konversation, was die Möglichkeit, diesen Client im vorliegenden Anwendungsfall einzusetzen, gänzlich zunichte machte. Das ist insofern interessant, als beim Standard-Agenten Microsoft Copilot die Sprachchat-Funktionalität „out of the box“ verfügbar ist.  

Kapitel 2: Wie wäre es mit etwas Außergewöhnlichem?

Wir haben versucht, das oben beschriebene Problem mithilfe einer maßgeschneiderten Zugangsanwendung und des Dienstes „ Azure Speech“ zu lösen, der eine einfache Umwandlung von Sprache in Text (Speech-to-Text) und von Text in Sprache (Text-to-Speech) ermöglicht. Zunächst haben wir versucht, die besagte Funktionalität mithilfe einer Canvas-Anwendung mit eingebetteten Steuerelementen zur Audioaufnahme und -wiedergabe zu realisieren.

Leider hat sich die Kommunikation mit dem Dienst, der für die bidirektionale Umwandlung von Text und Sprache über das HTTP-Protokoll zuständig ist, als mit zu großen Verzögerungen behaftet erwiesen. Während sich diese Lösung bei der unidirektionalen Kommunikation durchaus bewähren mag, war bei der bidirektionalen Kommunikation kaum von einem flüssigen Gespräch mit dem Agenten die Rede. Anwendungen dieser Art unterstützen leider nicht nativ die Kommunikation über WebSocket- oder WebRTC-Protokolle, die – im Gegensatz zu einzelnen HTTP-Anfragen – eine ständige, bidirektionale Verbindung aufrechterhalten und das Streamen von Audio in Echtzeit ermöglichen. Natürlich hätten wir dieses Problem leicht mit benutzerdefiniertem Code umgehen können, doch wir gingen davon aus, dass wir, da dieser Code das zentrale und in der Praxis einzige Element der Benutzeroberfläche darstellen sollte, zu diesem Zweck genauso gut eine eigene Anwendung entwickeln könnten.

Kapitel 3: Die Plattform jedoch

Da die im SaaS-Modell verfügbaren Low-Code-Mechanismen in diesem Fall unsere Erwartungen nicht erfüllt haben, haben wir beschlossen, die Einsatzmöglichkeiten der im Rahmen von Microsoft Foundry (bis vor kurzem „ Azure “ AI Foundry) verfügbaren Dienste zu prüfen. Im Rahmen dieses Dienstes wurde ein Agent mit aktivierter Sprachkommunikation (Interaction Mode = Voice) konfiguriert. Zusätzlich wurde ein Webdienst in .NET 10 erstellt, der es ermöglicht, die Details des Agenten vor dem Kunden zu verbergen, und der potenziell die Möglichkeiten zur Zugriffsverwaltung und Konfiguration von Anwendungen oder Geschäftsregeln für einzelne Benutzerkonten erweitert, ohne dass die Ressourcen von Azure „angetastet“ werden müssen. Der Einsatz einer zusätzlichen Vermittlungsschicht in der Kommunikation ermöglicht zudem einen potenziellen Austausch des Agenten in der Zukunft, ohne dass Änderungen an der Konfiguration der Client-Anwendung erforderlich sind.

Als Frontend-Schicht haben wir uns in diesem Fall für die Erstellung eines PCF-Steuerelements (Power Apps Component Framework) entschieden. Diese Technologie ermöglicht die einfache Einbettung des erstellten Codes (ReactJS, Vite) in verschiedene Arten von Power Platform-Anwendungen (Canvas, Model-Driven Apps, Power Pages) oder eine relativ einfache Konvertierung in eine Power Platform Code App.

Darüber hinaus ergaben erste Schätzungen zur Implementierung der besprochenen Funktionalität auf Basis der genannten Dienste potenziell geringere Nutzungskosten als bei einer vergleichbaren Lösung, die auf Low-Code-Komponenten basiert. Und was am wichtigsten ist: Schließlich ist es uns gelungen, das gewünschte Ergebnis zu erzielen, nämlich einen reibungslosen Dialog mit einem benutzerdefinierten Agenten, der das Anlegen von Datensätzen in Microsoft Dataverse direkt aus der mobilen App heraus ermöglicht.

Kapitel 4: Ist das sicher?

Im Hinblick auf die Sicherheit der oben vorgestellten Lösung sind die Authentifizierung der Benutzer und die Autorisierung des Zugriffs auf Daten in Microsoft Dataverse sicherlich wichtige Aspekte. Für die Kommunikation zwischen der Client-Anwendung und dem Backend haben wir eine auf Microsoft Entra ID basierende Authentifizierung sowie die Bibliothek MSAL.js (Microsoft Authentication Library) verwendet, die für die Anmeldung des Benutzers und den Abruf von Zugriffstoken zuständig ist. Dieser Ansatz ermöglicht die Zugriffskontrolle auf Ressourcen über das Cloud-Verzeichnis, verhindert den Zugriff auf die Anwendung durch Benutzer außerhalb der Organisation und gewährleistet zudem die Single-Sign-On-Funktionalität (SSO). Der auf .NET-Technologie basierende Webdienst kommuniziert hingegen mit dem Agenten unter Verwendung einer verwalteten Identität von Azure (Azure Managed Identity). Die Konfiguration des Zugriffs und der Berechtigungen erfolgt in diesem Fall über die Netzwerkressourcen Azure sowie den rollenbasierten Zugriffskontrollmechanismus (Azure , RBAC).  

Ein separates Thema ist der Zugriff des Agenten auf das Dataverse-Repository und die darin enthaltenen Daten. Wir möchten sicherlich vermeiden, dass der Sprachagent Daten weiterer Kunden ausliest, selbst solcher, auf die wir nominell keinen Zugriff haben. In unserem Fall stellte der Agent unter seiner eigenen Identität (wobei erneut der Mechanismus „ Azure Managed Identity“ genutzt wurde) mit eingeschränkten Berechtigungen eine Verbindung zu Dataverse her. Wir können uns jedoch ein Szenario vorstellen, in dem der Zugriff auf Dataverse-Datensätze von den tatsächlichen Berechtigungen des Benutzers abhängt, der die Anwendung ausführt. In diesem Fall ist die Verwendung der Authentifizierung „OAuth Identity Passthrough“ erforderlich sowie die Weitergabe der Identitätsdaten des Benutzers von der Client-Anwendung über das Backend bis hin zum Agenten. Dies ist sicherlich ein weiteres Szenario, das wir im Rahmen der Arbeiten an der besprochenen Lösung prüfen werden.

Zusammenfassung

Die Sprachkommunikation mit einem CRM-System ist keine Zukunftsvision mehr, sondern entwickelt sich zu einer echten Alternative zur herkömmlichen grafischen Benutzeroberfläche. Der „Headless-CRM“-Ansatz, bei dem Microsoft Dataverse als Dienst fungiert, der Daten, Geschäftslogik und ein Sicherheitsmodell bereitstellt, ermöglicht die freie Wahl des Interaktionskanals – einschließlich eines sprachgesteuerten KI-Agenten.

Unsere Erfahrungen zeigen jedoch, dass der Weg zu einer funktionierenden Lösung nicht immer über die naheliegendsten Tools führt. Der in „ Copilot Studio “ erstellte Agent bot in den verfügbaren Veröffentlichungskanälen keine komfortable Sprachkommunikation, und die in den „ Azure Speech“-Dienst integrierte Canvas-Anwendung erwies sich aufgrund von Verzögerungen bei der HTTP-basierten Kommunikation als zu langsam. Letztendlich hat sich die Kombination aus einem Sprachagenten in Microsoft Foundry und maßgeschneiderten Anwendungen, die mit .NET- und JavaScript/PCF-Technologien erstellt wurden, am besten bewährt. Diese Lösung gewährleistete die gewünschte Gesprächsflüssigkeit und Flexibilität bei einem eventuellen Austausch des Agenten und laut vorläufigen Schätzungen auch geringere Betriebskosten als eine Low-Code-Lösung.

Ein ebenso wichtiger Aspekt des Projekts ist die Sicherheit. Die auf Microsoft Entra ID basierende Authentifizierung, die Nutzung von „ Azure “ und „Managed Identity“ sowie die eingeschränkten Berechtigungen des Agenten in Dataverse bilden eine solide Grundlage. Langfristig sollte jedoch in Betracht gezogen werden, die Identität des Benutzers bis zum Agenten weiterzugeben (OAuth Identity Passthrough), damit der Zugriff auf die Daten die tatsächlichen Berechtigungen der Person widerspiegelt, die die Anwendung nutzt. Dies ist ein Ansatz, den wir in den nächsten Arbeitsphasen weiterentwickeln werden.

‍