Kann Dynamics 365 Sales oder ein anderes Modul durch Power Apps ersetzt werden? Versteckte Lizenzierungsrisiken, die Sie kennen sollten

Diese Woche haben wir mit einem potenziellen Kunden gesprochen, der nach Möglichkeiten suchte, seine Microsoft-Lizenzkosten zu optimieren. Im Laufe des Gesprächs stellte sich heraus, dass er bereits eine Empfehlung von seinem aktuellen Anbieter erhalten hatte – einem Unternehmen mit langjähriger Markterfahrung. Die Empfehlung lautete, die Standardfunktionalität von Dynamics 365 CRM schrittweise durch eigens entwickelte Power Apps auf Basis von Dataverse und Standardentitäten zu ersetzen. Als Ausgangspunkt wurden die Serviceprozesse vorgeschlagen, die Vertriebsprozesse sollten später folgen.

Ich hörte mit großen Augen zu. Entweder versteht hier jemand die Microsoft-Lizenzregeln nicht vollständig, oder man hat dem Kunden schlicht nicht die ganze Geschichte erzählt.

Aus technischer Sicht ist die Idee durchaus umsetzbar. Power Apps bietet ein hohes Maß an Flexibilität, Dataverse ist eine robuste Plattform, und eine Canvas-App lässt sich so gestalten, dass sie fast wie eine native CRM-Anwendung aussieht und funktioniert. Das Problem beginnt genau an dem Punkt, an dem die Anwendung anfängt, wie Dynamics 365 auszusehen und zu funktionieren – denn Microsoft hat dazu eine sehr klare lizenzrechtliche Position.

Und genau darüber möchte ich schreiben. Nicht um von der Nutzung von Power Apps abzuraten – es ist ein hervorragendes Tool, das wir selbst regelmäßig einsetzen. Vielmehr möchte ich aufzeigen, wo die Kostenoptimierung endet und wo das Risiko beginnt – ein Risiko, das am Ende sehr teuer werden kann.

„Wenn wir unsere eigene Anwendung (CRM) in Power Apps bauen und Dataverse als Datenbank nutzen können – wozu brauchen wir dann eine Dynamics-365-Lizenz?“

Die Frage klingt vernünftig, und ich verstehe, woher sie kommt. Dynamics-365-Lizenzen können einen erheblichen Teil eines Projekts ausmachen und in den Folgejahren einen sichtbaren Posten im IT-Budget der Berichte darstellen. Andererseits lockt die Power Platform mit ihrer Flexibilität und geringeren Kosten und ermöglicht die schnelle Entwicklung von Geschäftsanwendungen. Dataverse bietet eine leistungsfähige Datenschicht, und die Lizenzen sind deutlich günstiger. Auf den ersten Blick erscheint die Idee daher sehr attraktiv: Wir können eine eigene Lösung entwickeln, die exakt auf die Bedürfnisse der Organisation zugeschnitten ist, dabei aber die aus Dynamics bekannten Standardentitäten nutzen. Das Problem ist, dass diese Rechnung in der Hälfte der Fälle nicht aufgeht. Das liegt nicht daran, dass Power Apps ein schlechtes Werkzeug wäre, sondern daran, dass die Microsoft-Lizenzierung nicht so funktioniert, wie die meisten Menschen es intuitiv annehmen.

Woher kommt diese Idee?

Das Muster ist immer ähnlich. Eine Organisation plant, einen oder mehrere Prozesse einzuführen oder anzupassen. Man beginnt mit einer Kostenanalyse, und irgendwann wirft jemand einen Blick auf die Dynamics-365-Preisliste und sagt: „Das ist ein großer Budgetposten.“ Einen Moment später kommt die Idee auf: „Wir haben doch Power Apps, Power Automate, Dataverse und Power BI. Das können wir selbst bauen.“ Und genau hier beginnt das Problem. Denn technisch gesehen – und da stimme ich vollkommen zu – haben sie recht. Das ist keine reine Fantasie. Mit den genannten Werkzeugen lassen sich sehr gute Anwendungen bauen. Die Power Platform ist flexibel genug, um einen Großteil der Funktionalität von Dynamics 365 nachzubilden. Jemand betrachtet das Problem hier ausschließlich durch die technische Brille und lässt dabei die Frage aus, die eigentlich zuerst gestellt werden müsste: Ist dieser Ansatz mit den Microsoft-Lizenzrichtlinien vereinbar? Und diese Frage taucht selten auf, wenn die Idee noch frisch ist und alle von den potenziellen Einsparungen begeistert sind. Sie taucht viel später auf – manchmal erst bei einem Audit.

Technologie und Lizenzierung sind zwei unterschiedliche Welten

Die meisten Menschen gehen davon aus, dass die Lizenzierung davon abhängt, in welcher Anwendung der Benutzer arbeitet. Wenn ich mich nicht in Dynamics 365 einlogge, brauche ich keine Dynamics-365-Lizenz – so klingt es logisch, aber Microsoft sieht das nicht so. Microsoft interessiert sich nicht dafür, welches Fenster der Benutzer sieht. Entscheidend ist, welche Funktionalität tatsächlich genutzt wird und mit welchen Daten interagiert wird. Geht es um die Bearbeitung von Serviceanfragen, das Erstellen von Angeboten, die Verwaltung von Warteschlangen, die Überwachung von SLAs? Wenn ja, bewegt man sich innerhalb von Dynamics 365 – unabhängig davon, ob dies über die native Oberfläche oder eine eigens geschriebene Canvas-App geschieht. Das ist keine Interpretation, sondern ausdrücklich in den Microsoft-Lizenzbedingungen festgehalten.

Was ist „Multiplexing“ in der Microsoft-Lizenzierung?

Microsoft bezeichnet die oben beschriebene Situation als Multiplexing und hat dazu eine sehr klare Position: Sie können die Lizenzierungsanforderungen nicht dadurch reduzieren, dass Sie eine zusätzliche Schicht zwischen Benutzer und Produkt einfügen. Es spielt keine Rolle, ob es sich bei dieser Schicht um ein Webportal, eine mobile App oder eine eigens erstellte Canvas-App in Power Apps handelt. Nutzt ein Benutzer indirekt Dynamics-365-Funktionalität, wird er genauso behandelt wie ein Benutzer, der sich direkt einloggt.

Diese Regel gilt unabhängig von der Absicht. Es kann sein, dass Ihnen gar nicht bewusst ist, dass Sie dagegen verstoßen – oder Sie sind vielleicht sogar überzeugt, einen cleveren Workaround gefunden zu haben. Ein Audit prüft jedoch Fakten, keine Absichten.

Worum geht es beim Multiplexing genau? Um eingeschränkte Tabellen (Restricted Tables).

In Dataverse sind bestimmte Tabellen als auf spezifische Dynamics-365-Lizenzen beschränkt markiert. Im Servicebereich sprechen wir von Tabellen, die das Herzstück jedes Kundenserviceprozesses bilden: Case, Entitlement, SLA und Work Order. Im Vertriebsbereich ist die Liste ebenso konkret: Opportunity, Quote, Order, Invoice, Lead – genau jene Tabellen, auf denen jeder Vertriebsprozess aufbaut. Während ein Benutzer mit einer Power-Apps-Lizenz Daten aus diesen Tabellen lesen darf, erfordert das Erstellen, Aktualisieren oder Löschen von Datensätzen eine entsprechende Dynamics-365-Lizenz. Nicht Power Apps Premium, sondern Dynamics 365.

Und genau hier beginnen viele Projekte in der Phase der Lizenzanalyse zu scheitern. Die Canvas-App ist fertig, sieht großartig aus und funktioniert genau wie erwartet – und dann prüft jemand, welche Tabellen genutzt werden, und stellt fest, dass die ursprüngliche Idee der Lizenzeinsparung nicht mehr tragfähig ist.

Kehren wir zu dem Kunden zurück, mit dem wir diese Woche gesprochen haben. Der Plan bestand darin, Dynamics 365 schrittweise zu ersetzen, beginnend mit den Serviceprozessen und endend beim Vertrieb. In der Praxis bedeutet dies, mit eingeschränkten Tabellen aus beiden Bereichen zu arbeiten. Im Grunde geht es um jede zentrale Tabelle, die in Dynamics 365 geschäftliche Bedeutung hat.

Der Mechanismus ist einfach: Microsoft schaut nicht auf die Oberfläche. Es schaut auf die Daten. Wenn Ihre Anwendung Tabellen liest und beschreibt, die Teil einer lizenzierten Dynamics-365-Lösung sind, befinden Sie sich im Dynamics-365-Bereich – unabhängig davon, wie unterschiedlich Ihre Anwendung im Vergleich zum nativen CRM aussieht.

Bevor also architektonische Entscheidungen getroffen werden, lohnt es sich, eine sehr konkrete Frage zu stellen: Mit welchen Tabellen wird diese Anwendung arbeiten? Lautet die Antwort Case, Entitlement, SLA, Opportunity, Quote oder Order, muss die Lizenzdiskussion geführt werden, bevor die erste Codezeile geschrieben wird.

Wann ist Power Apps eine sichere Wahl?

Um Missverständnisse zu vermeiden: Ich behaupte nicht, dass Power Apps ein schlechter Ansatz ist. Im Gegenteil – wir setzen es regelmäßig ein und sehen, wie viel Mehrwert es bieten kann.

Tausende Organisationen bauen mit Power Apps Lösungen, die überhaupt nichts mit Dynamics 365 zu tun haben – Flottenmanagementsysteme, HR-Anwendungen, Geräteverzeichnisse, Auditprozesse, Compliance-Tools. Und sie tun dies völlig legal, gestützt auf eigene Dataverse-Tabellen, eigene Geschäftslogik und eigene Prozesse. In solchen Fällen reicht eine Power-Apps-Premium-Lizenz völlig aus, und niemand hat etwas dagegen einzuwenden.

Die Grenze ist klar, auch wenn sie auf den ersten Blick nicht immer offensichtlich ist: Berührt die Anwendung keine Dynamics-365-Funktionalität oder -Daten, sind Sie auf der sicheren Seite. Das Problem beginnt, sobald Sie etwas bauen, das funktional einem CRM ähnelt, dessen Tabellen nutzt und dessen Prozesse repliziert – nur in einer anderen Verpackung.

Die Lizenzkosten sind nur ein Teil der Gleichung

Selbst wenn jemand einen Weg findet, die Lizenzfragen zu lösen, und dies vollständig im Einklang mit den Microsoft-Richtlinien tut, gibt es eine weitere Seite der Gleichung, über die deutlich seltener gesprochen wird.

Dynamics 365 ist nicht nur eine Frage der Lizenzierung. Es ist ein Produkt, das Microsoft seit Jahren weiterentwickelt und regelmäßig mit neuen Funktionen, Sicherheitsupdates, Integrationen und KI-Mechanismen ausstattet. Mit dem Kauf einer Lizenz kauft sich eine Organisation auch in diese Weiterentwicklung ein. Entscheidet sie sich, eine eigene Lösung zu bauen, übernimmt sie die volle Verantwortung dafür.

In der Praxis bedeutet dies, dass jeder neue geschäftliche Bedarf ein Entwicklungsprojekt darstellt. Jede Prozessänderung erfordert den Einsatz des eigenen Teams. Jedes Thema rund um Sicherheit, Zugriffskontrolle oder regulatorische Compliance liegt bei der Organisation selbst, nicht beim Anbieter. Und die Funktionen, die in den Updates von Dynamics 365 erscheinen – Copilot, Automatisierung, neue Routing-Mechanismen – müssen in der eigenen Anwendung entworfen, gebaut und gepflegt werden.

Dies ist kein Argument gegen den Bau eigener Lösungen. Es ist ein Argument dafür, die vollen Kosten zu berechnen. Ich habe Projekte gesehen, bei denen die Lizenzeinsparungen zehntausende Złoty pro Jahr erreichten, während die Kosten für die Pflege der eigenen Anwendung diesen Betrag nach zwei Jahren um ein Vielfaches überstiegen. Eine Entscheidung, die auf dem Papier wie eine Optimierung aussah, entpuppte sich in der Praxis als teurer als das, was man eigentlich vermeiden wollte.

Wie geht man das Thema verantwortungsvoll an?

Wenn ein Kunde mit einer solchen Idee zu uns kommt, stellen wir ihm einige Fragen. Nicht um ihn zu entmutigen, sondern um gemeinsam zu verstehen, womit wir es tatsächlich zu tun haben.

Die erste Frage betrifft immer die Prozesse: Was genau wollen wir unterstützen, und sind diese Prozesse tatsächlich einzigartig für diese Organisation, oder ähneln sie schlicht dem Standard-Customer-Service oder Standard-Vertrieb? Diese Frage ist oft aufschlussreich, denn viele Organisationen glauben, ihre Prozesse seien einzigartig, während Dynamics 365 sie in der Praxis von Haus aus unterstützt, ohne eine einzige Zeile Anpassung.

Die zweite Frage betrifft die Daten: Mit welchen Tabellen wird die Anwendung arbeiten? Mit benutzerdefinierten Entitäten oder mit Standard-Dynamics-365-Tabellen? Diese Frage beendet, wie bereits erwähnt, häufig Diskussionen über Lizenzeinsparungen, bevor sie überhaupt begonnen haben.

Die dritte Frage ist die schwierigste, denn sie erfordert etwas Ehrlichkeit: Lösen wir ein echtes geschäftliches Problem, oder versuchen wir vor allem, die Lizenzkosten zu senken? Beides können legitime Ziele sein, doch wenn die Kostenoptimierung wichtiger wird als Architektur und geschäftliche Anforderungen, enden Projekte oft schlecht.

Und schließlich die Frage nach dem Geld – aber ehrlich berechnet. Nicht „wie viel sparen wir bei den Lizenzen“, sondern „wie hoch werden die Gesamtkosten der Lösung in fünf Jahren sein, einschließlich Entwicklung, Wartung, Support und allem anderen, was wir heute von Microsoft erhalten“. Diese Berechnung verändert häufig die Perspektive.

Der letzte Punkt, den wir vor Projektbeginn stets empfehlen: eine formelle Lizenzinterpretation. Nicht die Meinung eines Kollegen aus der Branche, kein LinkedIn-Beitrag, nicht die Annahme, „das wird schon in Ordnung sein“. Sondern eine Verifizierung durch Microsoft oder einen spezialisierten Lizenzierungspartner. Dieser Schritt kostet am wenigsten von allen und wird am häufigsten übersehen.

Zusammenfassung

Kehren wir zu dem Kunden zurück, mit dem dieser Artikel begann.

Wir haben ihm nicht von der Nutzung von Power Apps abgeraten. Wir haben nicht gesagt, die Idee sei schlecht. Wir haben gesagt, dass er vor einer Entscheidung einige konkrete Fragen beantworten muss – zu Prozessen, Tabellen, Gesamtkosten und Lizenzinterpretation. Denn wenn diese Antworten stimmen, kann Power Apps eine großartige Wahl sein. Wenn nicht, ist das Ändern der Oberfläche bei gleichbleibenden Daten und Prozessen keine Optimierung. Es ist ein Risiko, das erst bei einem Audit sichtbar wird.

Kunden zu empfehlen, Dynamics 365 durch eine eigene Canvas-App zu ersetzen, klingt auf einer Folie ansprechend. In der Praxis erfordert es mehr als technische Machbarkeit. Es erfordert eine ehrliche Lizenzanalyse, eine vollständige Kostenberechnung und das Verständnis dafür, dass Microsoft nicht darauf schaut, wie die App aussieht, sondern was sie tut und auf welchen Daten sie läuft.

Eine gute Lösung muss nicht die günstigste im Vorfeld sein. Sie muss ehrlich kalkuliert, konform mit den Richtlinien des Herstellers und in fünf Jahren ohne Überraschungen betriebsbereit sein.

Nützliche Links:

https://www.microsoft.com/licensing/guidance/Multiplexing