Microsoft Power Platform in der Praxis

1. Management Summary

In einer Zeit, in der Fachbereiche immer schneller digitale Lösungen benötigen, um effizienter zu arbeiten, bietet die Microsoft Power Platform einen flexiblen Werkzeugkasten für die Umsetzung genau solcher Lösungen. Als IT-Consultant erlebe ich oft, dass Abteilungen mit Excel-Listen, Access-Datenbanken oder manuellem E-Mail-Chaos ihre Prozesse irgendwie am Laufen halten. Hier setzt die Power Platform an: Mit Low-Code-Werkzeugen können Sie – auch ohne professionelles Entwicklerteam – geschäftliche Anwendungen, Automatisierungen und Auswertungen erstellen. Die Plattform umfasst Power Apps, Power Automate, Power BI (bzw. das neue Microsoft Fabric), Power Pages und mehr. All diese Komponenten greifen ineinander, um Daten zu verarbeiten, Workflows zu automatisieren und Erkenntnisse zu gewinnen. Und das Beste: Sie benötigen dafür keine umfangreichen Programmierkenntnisse, sondern eher ein gutes Verständnis Ihrer Geschäftsprozesse und etwas Einarbeitung in die intuitiven Designer-Oberflächen.

Warum ist das relevant? Ganz einfach: Die IT-Abteilungen sind häufig überlastet, während die Fachbereiche auf schnelle Lösungen drängen. Die Power Platform ermöglicht es, dass Fachbereiche selbst aktiv werden, ohne dass die IT-Sicherheit oder Governance zu kurz kommt. Richtig eingeführt, können Citizen Developer (also engagierte Mitarbeiter aus den Fachbereichen – keine Sorge, wir meinen natürlich alle Mitarbeiterinnen und Mitarbeiter, verzichten aber auf Gendersterne 😉) eigene Apps und Workflows bauen. Dadurch wird die Innovationskraft im Unternehmen freigesetzt, während die IT-Abteilung einen Rahmen vorgibt, damit alles konform und sicher bleibt.

In diesem Fachartikel zeige ich Ihnen praxisnah, wie Sie die Power Platform sinnvoll einsetzen und was es dabei zu beachten gilt. Wir steigen zunächst in die Komponenten der Plattform ein – also was Power Apps, Power Automate & Co. genau leisten. Anschließend betrachten wir den Nutzen: Warum lohnt sich das für Ihr Unternehmen und Ihre Abteilungen? Ich präsentiere 10 konkrete Anwendungsszenarien aus der Praxis, damit Sie eine Vorstellung bekommen, was andere Unternehmen schon heute damit machen. Natürlich muss man auch über Recht & Compliance sprechen: Themen wie Datenschutz (DSGVO) oder die neue EU-Richtlinie NIS2 sind relevant, ebenso wie unternehmensinterne Richtlinien (DLP, Auditierung). Keine Sorge, wir behandeln das klar und verständlich.

Weiter geht’s mit Best Practices und Architektur: Wie strukturiert man Umgebungen, wie integriert man die Entwicklung in bestehende DevOps-Prozesse, wie stellt man Sicherheit und Qualität sicher? Wir schauen uns Administration & Betrieb an – vom Einrichten von Richtlinien im Tenant bis zum Center of Excellence (CoE) Starter Kit für Governance. Ein oft kniffliges Thema ist die Lizenzierung & Kapazitäten: Ich erkläre alle Lizenzmodelle der einzelnen Komponenten und gebe Rechenbeispiele, damit Sie die Kosten besser einschätzen können. Auch Überwachung, Sicherheit & Qualität kommen zur Sprache – von Telemetriedaten bis zu Security Operations im laufenden Betrieb.

Für technisch Fortgeschrittene beleuchten wir Zusatzfunktionen und die Brücke zur professionellen Entwicklung: Custom Connectors, Plug-Ins, das Power Apps Component Framework (PCF), Process Mining und Azure-Integrationen erweitern die Möglichkeiten der Plattform erheblich. Damit Sie einen roten Faden für die Einführung haben, schlage ich eine Schritt-für-Schritt-Roadmap in drei Phasen vor. Praktische Checklisten für Governance, Sicherheit, ALM und Betrieb helfen Ihnen, nichts Wichtiges zu vergessen. Ein ausführliches Glossar erklärt über 35 Fachbegriffe rund um die Power Platform – falls Ihnen mal ein Begriff wie Dataverse oder Managed Environment über den Weg läuft. Und zum Schluss habe ich häufige Fragen & Antworten (FAQ) aus der Praxis zusammengestellt, die viele meiner Kunden beschäftigen.

Mein Ziel ist es, Sie mit diesem Artikel zu inspirieren und gleichzeitig handfestes Wissen zu vermitteln. Der Ton bleibt bewusst locker und mit einem Augenzwinkern, denn IT darf auch Spaß machen – jedoch immer mit präziser fachlicher Substanz dahinter. Sie sollen am Ende ein klares Bild haben, was die Microsoft Power Platform für Ihr Unternehmen leisten kann, wo die Fallstricke liegen und wie man das Ganze erfolgreich einführt. Als Berater, der solche Projekte persönlich begleitet, teile ich hier meine Erfahrungen aus erster Hand. Legen wir los – die digitale Transformation wartet nicht! 🚀

2. Komponenten der Power Platform

Die Microsoft Power Platform besteht aus mehreren nahtlos integrierten Komponenten. Jede für sich ist schon mächtig – zusammen entfalten sie ihr volles Potenzial. Hier ein Überblick über die wichtigsten Bausteine:

Power Apps

Power Apps ist die Low-Code-Entwicklungsumgebung der Plattform, mit der Sie individuelle Geschäftsanwendungen erstellen können. Es gibt zwei Hauptarten von Apps: Canvas-Apps und modellgesteuerte Apps. Bei Canvas-Apps starten Sie auf einer freien Leinwand – ähnlich wie in PowerPoint ziehen Sie Buttons, Eingabefelder, Formulare etc. per Drag-and-Drop und gestalten die Benutzeroberfläche ganz nach Ihren Bedürfnissen. Datenquellen (z.B. Excel, SharePoint, SQL oder das Dataverse) können einfach angebunden werden. Diese Apps eignen sich perfekt für spezifische Aufgaben, z.B. eine mobile App zur Erfassung von Außendienst-Reports oder ein Formular für Urlaubsanträge. Modellgesteuerte Apps hingegen basieren auf Datenmodellen im Microsoft Dataverse. Hier wird das UI weitgehend automatisch aus Ihren Datenstrukturen erstellt und ist ideal für geschäftliche Anwendungen mit komplexen relationalen Daten, z.B. CRM-ähnliche Anwendungen oder Fallbearbeitungs-Systeme. Power Apps ermöglicht es Menschen ohne klassisches Programmierprofil, mit einer Excel-ähnlichen Formelsprache (Power Fx) und visuellen Tools Anwendungen zu bauen. Gleichzeitig können professionelle Entwickler die Möglichkeiten erweitern – etwa durch Power Apps Component Framework (PCF)-Komponenten für benutzerdefinierte Steuerelemente oder durch Wiederverwenden von HTML/JavaScript in integrierten Seiten. Wichtig: Power Apps laufen auf praktisch allen Geräten – im Browser, auf dem Smartphone oder Tablet (via App). Sie können Ihre Apps unternehmensintern bereitstellen, Berechtigungen vergeben und sogar über Microsoft Teams einbetten. Mit Power Apps lassen sich also schnell maßgeschneiderte Apps für interne Prozesse entwickeln, ohne monatelange klassische Softwareprojekte.

Power Automate

Power Automate ist der Motor für Workflow-Automatisierung und Robotic Process Automation (RPA). Früher unter dem Namen Microsoft Flow bekannt, ermöglicht es Power Automate, wiederkehrende Aufgaben und Geschäftsprozesse zu automatisieren. Es gibt Cloud-Flows (digitale Workflows in der Cloud) und Desktop-Flows (RPA-Bots, die menschliche Klicks und Tastatureingaben auf Windows-Rechnern nachahmen). Ein Cloud-Flow kann zum Beispiel ausgelöst werden, wenn eine E-Mail eintrifft oder ein Datensatz in SharePoint erstellt wird. Daraufhin kann die Automation eine Reihe von Aktionen ausführen – etwa Datensätze im ERP aktualisieren, eine Genehmigungsanfrage per Outlook senden oder eine Teams-Nachricht posten. Die mehr als 700 Konnektoren machen die Integration mit praktisch allen gängigen Systemen sehr einfach (dazu später mehr unter “Connectors”). Power Automate entlastet Ihre Mitarbeiter von stumpfsinnigen Routineaufgaben: Denken Sie z.B. an das monatliche Zusammenkopieren von Excel-Reporten – das kann ein Flow in Minuten erledigen, während Ihr Team sich wichtigeren Aufgaben widmet. Neben diesen Cloud-basierten Flows bietet Power Automate auch RPA-Funktionalität: Mit dem Desktop-Recorder können Sie Klickfolgen in alten Desktop-Anwendungen oder Webportalen aufzeichnen. Der Bot spielt diese dann automatisiert ab, als ob ein virtueller Mitarbeiter am PC sitzt – ideal, um alte Systeme ohne API anzubinden (z.B. eine Preisanpassung in einem alten SAP-GUI, die jeden Monat durchgeführt werden muss). Neu hinzugekommen in 2025 ist die enge Verzahnung mit Process Mining: Power Automate kann Prozessabläufe aus vorhandenen Daten analysieren und visualisieren, um Optimierungspotenziale aufzudecken (dazu gleich mehr). Insgesamt ist Power Automate das Schweizer Taschenmesser für Automatisierung in der Microsoft-Welt – von einfachen Wenn-Dann-Regeln bis hin zu komplexen, mehrstufigen Geschäftsprozessen mit Datenbanken und KI-Integration (z.B. automatisierte Dokumentenverarbeitung) ist alles möglich.

Power BI / Microsoft Fabric

Power BI ist Microsofts Plattform für Datenanalyse und interaktive Dashboards. Viele kennen Power BI vielleicht schon als eigenständiges Produkt – im Rahmen der Power Platform liefert es die Möglichkeit, Daten aus verschiedensten Quellen zusammenzuführen, zu visualisieren und daraus Erkenntnisse zu gewinnen. Ob Vertriebs-Dashboard, Finanzreporting oder Qualitätskennzahlen: Mit Power BI erstellen Sie ansprechende Berichte und interaktive Visualisierungen, die Sie per Browser oder mobil einsehen können. Das Tool ist dabei für Endanwender gedacht – per Self-Service BI können Fachanwender eigene Datenmodelle erstellen, Diagramme gestalten und per Klick filtern und bohren, ohne SQL beherrschen zu müssen. Seit 2023/2024 ist Power BI Teil der größeren Microsoft Fabric-Initiative: Fabric vereint Power BI mit Datenintegration, Data Engineering, Data Science und Data Warehousing in einer einheitlichen Umgebung. Für Sie in der Praxis heißt das, dass Power BI noch leistungsfähiger geworden ist. Beispielsweise können Sie mit Fabric einen Data Warehouse in der Cloud (Lakehouse) aufbauen, Daten mit Pipelines aus verschiedensten Quellen laden und transformieren (ETL/ELT) und das Ergebnis direkt in Power BI auswerten – alles innerhalb einer Plattform. Fabric bringt auch OneLake mit (quasi das „OneDrive für Daten“), das als zentrales Datenspeicher-Layer dient. Wichtig ist: Power BI bleibt das Frontend für Analysen und Berichte. Die Neuerung ist eher auf der Backend-Seite, wo komplexe Datenprojekte nun ebenfalls Teil der Plattform sind. In der Praxis merken Fachanwender davon nur, dass Power BI jetzt noch größere Datenmengen bewältigen kann und eng mit den anderen Fabric-Diensten verzahnt ist. Für Ihr Unternehmen bedeutet Power BI/Fabric: Datengetriebene Entscheidungen werden einfacher. Statt Excel-Auswertungen herumzuschicken, haben Sie ein zentrales, stets aktuelles Dashboard. Dank Echtzeit-Datenanbindung sehen Sie Veränderungen sofort. Und: Mit Power BI können Sie Berichte auch für Kollegen ohne Spezialkenntnisse verfügbar machen – mit einfachen, interaktiven Filtern und sogar in natürlicher Sprache Fragen stellen („Zeige Umsatz nach Region im letzten Quartal“). Kurz gesagt liefert Power BI/Fabric die Transparenz über Ihre Geschäftskennzahlen, die moderne Unternehmen benötigen, und das bei hoher Benutzerfreundlichkeit.

Power Pages

Power Pages (früher bekannt als Power Apps Portals) ist die Komponente der Power Platform, mit der Sie webbasierte Portale und Websites erstellen können – und zwar ebenfalls in Low-Code-Manier. Stellen Sie sich vor, Sie möchten für Ihre externen Partner oder Kunden eine einfache Web-Oberfläche bereitstellen, um Daten einzugeben oder Informationen abzurufen (z.B. ein Kunden-Self-Service-Portal, ein Lieferantenportal oder eine Community-Website). Früher hätte man dafür eine Webagentur beauftragt. Mit Power Pages können solche Sites jetzt von internen Teams erstellt werden, indem man vorgefertigte Vorlagen nutzt und diese in einem visuellen Editor anpasst. Die Seiten können responsive (für Mobilgeräte optimiert) gestaltet werden, ohne eine Zeile HTML/CSS schreiben zu müssen. Ein zentrales Merkmal ist, dass Power Pages nahtlos mit dem Dataverse zusammenarbeitet: Daten, die über ein Portal erfasst werden – etwa eine Registrierung oder ein Formular – landen direkt in Ihrer Dataverse-Datenbank und können von dort aus mit Power BI ausgewertet, per Power Automate weiterverarbeitet oder in einer internen Power App angezeigt werden. Sicherheit ist dabei ein großes Thema: Power Pages bietet ein Rollen- und Berechtigungssystem, um genau zu steuern, welche externen Benutzer welche Daten sehen oder ändern dürfen. Man kann zudem die Anmeldung über verschiedene Methoden ermöglichen, z.B. Azure AD (für externe Partner mit Accounts), Microsoft-Konten oder sogar Sozial-Logins wie Google/Facebook, falls es ein öffentliches Portal sein soll. Auch anonyme Zugriffe sind möglich, falls man Inhalte öffentlich bereitstellen möchte (z.B. eine Wissensseite ohne Login). In der Praxis werden Power Pages gerne eingesetzt, um Lücken zwischen internen Prozessen und externen Nutzern zu schließen: Ein Beispiel wäre ein Support-Portal, wo Kunden Tickets einstellen – intern fließt das ins Dataverse und wird als Case in einer Support-Power-App weiterbearbeitet. Oder ein Messe-Anmeldungsportal, wo Teilnehmer Daten eingeben, die dann intern direkt verarbeitet werden. Das Schöne: Da es Low-Code ist, können die gleichen Personen, die die internen Apps bauen, oft auch das Portal bauen – das spart Abstimmungsaufwand mit externen Web-Entwicklern. Power Pages macht Ihr Unternehmen onlinefähig, ohne dass Sie eine Website bei Null entwickeln müssen.

Microsoft Copilot Studio

Copilot Studio ist die jüngste Ergänzung der Plattform und bringt künstliche Intelligenz (KI) in Form intelligenter Assistenten in Ihre Anwendungen. Dahinter steckt eine Weiterentwicklung von Power Virtual Agents (dem Chatbot-Tool), gepaart mit generativer KI (vergleichbar mit ChatGPT) und Automatisierung. In Copilot Studio können Sie AI-gestützte „Agents“ erstellen – das sind KI-Assistenten, die über Chat mit Nutzern interagieren können und im Hintergrund Aktionen ausführen. Stellen Sie sich zum Beispiel einen Chatbot für den IT-Support vor: Mitarbeiter können ihre Fragen (in natürlicher Sprache) eingeben, der KI-Agent versteht das Anliegen, sucht in den hinterlegten Wissensdaten (z.B. FAQ-Dokumente) nach Antworten und kann bei Bedarf auch gleich Aktionen ausführen (etwa ein Passwort zurücksetzen, einen Trouble Ticket Eintrag erstellen oder eine Software-Zuweisung auslösen) – all das orchestriert durch den Agent. Copilot Studio bietet eine grafische Oberfläche, in der Sie solche KI-Bots und die dazugehörigen Ablaufpläne („Agent Flows“) entwerfen. Man definiert Themengebiete, Wissensquellen (z.B. SharePoint-Dokumente oder interne FAQs), Plugins/Aktionen und trainiert den Bot damit auf das eigene Unternehmen. Die generative KI sorgt dann dafür, dass der Bot auch auf Fragen antworten kann, die nicht 1:1 in den FAQs stehen – er formuliert Antworten mit eigenen Worten auf Basis der gelernten Inhalte. Das ist ein großer Sprung gegenüber klassischen Chatbots, die strikt regelbasiert waren. Copilot Studio nutzt modernste NLP (Natural Language Processing) und kann auch mehrsprachig agieren. Zusätzlich kann der Agent automatisierte Abläufe ausführen: Das sind die erwähnten Agent Flows, im Grunde Power-Automate-Flows, die vom Bot angestoßen werden können. Beispiel: Der Mitarbeiter fragt „Kannst du mir mein Urlaubskontingent sagen?“. Der Copilot-Agent greift auf einen geschützten internen Datentopf zu (über einen Connector), holt die Info und antwortet im Chat: „Sie haben noch 12 Urlaubstage.“. Diese Verzahnung von Chatbot und Aktionen eröffnet völlig neue Möglichkeiten für Service-Automatisierung – intern und extern. Gerade in Kombination mit Microsoft 365 Copilot (das übergreifende KI-Assistenz für Office-Tools bietet) lässt sich Copilot Studio nutzen, um unternehmensspezifische KI-Lösungen zu bauen. Wichtig: Copilot Studio erfordert natürlich einen bewussten Umgang mit Daten (Stichwort: kein vertrauliches Kundenangebot in einen Chatbot kippen, ohne Freigabe…). Aber dazu kommen wir noch im Compliance-Teil. Für jetzt sollten Sie mitnehmen: Copilot Studio = Baukasten für KI-Assistenten, die Sprache verstehen, Antworten generieren und auf Wunsch gleich Taten folgen lassen (Automation). Und das in einer Low-Code-Oberfläche, sodass Ihre Power-Platform-Entwickler damit arbeiten können – ganz ohne ein Data-Science-Team anheuern zu müssen.

Dataverse

Microsoft Dataverse (früher bekannt als Common Data Service) ist die zentrale Datenplattform unter der Haube der Power Platform. Man kann sich Dataverse als eine Cloud-Datenbank vorstellen, die speziell für Business-Anwendungen optimiert ist. Im Gegensatz zu einer klassischen SQL-Datenbank bringt Dataverse von Haus aus vordefinierte Strukturen und Funktionen mit: So gibt es z.B. ein Grundschema mit häufigen Geschäftsobjekten (Accounts, Kontakte, Produkte, Termine etc., bekannt als Common Data Model), das man nach Bedarf erweitern oder anpassen kann. Die Daten in Dataverse werden tabellarisch in sogenannten Tabellen (früher Entitäten genannt) gespeichert, inkl. Unterstützung für Beziehungen, Option-Sets (Auswahllisten), komplexe Datentypen (wie Bilder oder Dateien) und Businesslogik (Geschäftsregeln, Berechnungen, Rollenrechte). Warum Dataverse? Weil es Integration und Sicherheit out-of-the-box bietet: Alle Power-Platform-Komponenten verstehen Dataverse als native Quelle. Eine Power App kann dort direkt darauf zugreifen, ein Power Automate Flow kann Dataverse-Datensätze anlegen, Power BI kann sie auswerten usw., ohne dass Sie erst ODBC-Treiber oder Verbindungsstrings einrichten müssen. Zugleich übernimmt Dataverse das Rechtemanagement – Sie können z.B. definieren, dass Vertriebsmitarbeiter nur Datensätze ihrer eigenen Region sehen dürfen (Row-Level Security) oder dass bestimmte Felder (wie Gehälter) nur für bestimmte Rollen sichtbar sind. Dataverse ist auch die Speichergrundlage für Dynamics 365 (falls Sie CRM/ERP-Module von Microsoft im Einsatz haben, nutzen diese denselben Datenpool, was Integration trivial macht). Technisch läuft Dataverse auf Azure SQL und Azure Storage im Hintergrund, Sie müssen sich aber nicht um Infrastruktur kümmern. Sie als Admin legen lediglich Umgebungen an, bestimmen die Region (in der EU z.B. in Irland oder den Niederlanden), und alles weitere skaliert Microsoft für Sie. Ein paar praktische Vorteile: Dataverse erlaubt modellgetriebene Apps (wie oben erwähnt), man kann Geschäftsprozesse definieren (z.B. Phasen für Leads -> Angebot -> Verkauf), es gibt Audit-Protokollierung (jede Änderung an einem Datensatz kann mitgeschrieben werden) und Transaktionen (Geschäftslogik kann z.B. sagen: Wenn Datensatz A und B angelegt werden, dann oder gar nicht – so etwas hat man bei SharePoint-Listen z.B. nicht). In der Praxis sollten Sie Dataverse als Datenrückgrat nutzen, wenn Ihre Anwendung kritisch oder komplex wird: Anfangs fangen viele mit einem SharePoint-Listchen oder Excel als Datenquelle an – das ist okay für erste Experimente. Aber sobald es professionell wird, fahren Sie mit Dataverse deutlich besser in Sachen Performance, Skalierung und Governance. Natürlich kommt Dataverse (als Premium-Feature) auch mit Lizenzkosten, aber dazu später. Wichtig hier: Dataverse ist das Herzstück, das die Power Platform erst richtig leistungsfähig und „enterprise-ready“ macht.

AI Builder

Während Copilot Studio die große neue KI-Bühne betritt, sollte man AI Builder nicht vergessen – die Komponente, die vorgefertigte KI-Modelle in Ihre Power-Platform-Lösungen bringt. AI Builder gibt es schon seit einigen Jahren und ermöglicht es, künstliche Intelligenz ohne eigene Modelle zu nutzen. Beispiele gefällig? Mit AI Builder können Sie z.B. Formularerkennung machen: Laden Sie ein PDF-Dokument oder ein eingescanntes Formular hoch, und AI Builder liest automatisch die Schlüssel-Werte daraus aus (etwa ein Bestellformular – das Modell extrahiert Bestellnummer, Datum, Positionen, Beträge usw.). Oder Objekterkennung: Laden Sie Fotos (z.B. von defekten Geräten) hoch, und AI Builder erkennt definierte Objekttypen darauf (z.B. verschiedene Bauteile oder ob ein Produkt im Regal fehlt). Es gibt Textklassifizierung (z.B. sortiere eingehende E-Mails nach Kategorien), Stimmungserkennung (Sentiment Analysis auf Kundenfeedback), Vorhersagemodelle (mit eigenen Daten trainierbar, z.B. um auszurechnen, ob ein Kunde abspringt), und mehr. All das ist in Power Apps und Power Automate direkt nutzbar – per Konfigurator oder kleiner KI-Komponente. Sie brauchen also keine Data Scientists, sondern wählen in einer einfachen UI aus, was Sie vorhaben, laden ggf. Beispiel-Daten zum Trainieren hoch und schon stellt Ihnen AI Builder ein fertiges Modell bereit, das Sie per Power Automate Flow oder in einer App verwenden können. Stellen Sie sich vor, Sie haben einen Eingang von Rechnungen als PDFs. Mit AI Builder kann ein Flow jede Rechnung lesen, Beträge und Lieferant erkennen, dann automatisch eintragen und zur Freigabe schicken. Das spart mühsames Abtippen. Oder im Personalwesen: eingehende Bewerbungen könnten automatisch analysiert werden, um sie an den passenden Ansprechpartner weiterzuleiten (z.B. Textklassifizierung nach Jobrolle). AI Builder ist sozusagen das KI-Baukasten-Modul für gängige Geschäftsszenarien. Allerdings hat AI Builder eigene Kapazitätsbegrenzungen – es funktioniert auf Credit-Basis. Man bekommt ein gewisses Kontingent (z.B. im Power Apps Premium-Plan sind ein paar tausend Credits pro Monat inklusive), was für moderate Nutzung reicht. Für intensiven KI-Einsatz (z.B. hunderte Dokumente pro Tag analysieren) muss man zusätzliche AI Builder Kapazität lizenzieren. Die gute Nachricht: Microsoft entwickelt AI Builder ständig weiter und integriert auch neueste generative KI in dieses Modell. In 2025 können wir z.B. in Power Automate direkt GPT-Modelle (Azure OpenAI) nutzen, um Texte zusammenzufassen oder zu übersetzen – auch das läuft dann über AI Builder Credits. Für die Praxis heißt das: Mit AI Builder verleihen Sie Ihren Apps und Flows einen Hauch Magie, indem Sie Aufgaben intelligent erledigen lassen, die früher manuell oder gar nicht möglich waren. Und das alles voll integriert, ohne dass Sie externe KI-Services selbst anbinden müssen.

Connectoren & Gateways

Die wahre Stärke der Power Platform liegt in ihrer Fähigkeit zur Integration – und hier kommen die Connectoren ins Spiel. Ein Connector ist ein vorgefertigter Baustein, der die Verbindung zu einem bestimmten Dienst oder System herstellt. Microsoft hat mittlerweile über 800 Connectoren im Angebot (Tendenz steigend). Beispiele sind: SharePoint, Outlook, Excel, Teams (für alles aus der Microsoft-Welt), aber auch Salesforce, SAP, Oracle DB, Twitter, Adobe Sign, Google Dienste, ServiceNow, Workday – die Liste ist lang und umfasst Cloud-Dienste, Datenbanken, Social-Media, ERP-Systeme, u.v.m. In Power Apps bedeutet ein Connector, dass Sie per einfacher Konfiguration z.B. auf die Tabellen einer SQL-Datenbank zugreifen können oder Daten aus einem Webservice abrufen. In Power Automate bietet jeder Connector vorbereitete Aktionen und Trigger: Beispiel Twitter-Connector: Trigger „Wenn neuer Tweet mit bestimmtem Hashtag“, Aktion „Tweet posten“. So ließe sich ein Bot bauen, der automatisch auf Twitter-Nachrichten reagiert. Für Unternehmen relevanter: SAP-Connector: Trigger „Wenn in SAP ein neuer Datensatz X angelegt“, Aktion „Lies Daten aus SAP aus“ etc. – So kann ein Flow z.B. auf SAP-Buchungen reagieren, ohne dass Sie SAP großartig anpassen müssen. Die Connectoren sind im Hintergrund oft nichts anderes als API-Anbindungen (REST/SOAP), aber Power Platform verpackt es so, dass Sie sich um Authentifizierung, Schnittstellen und Parsing kaum kümmern müssen. Sie hinterlegen einmal die Zugangsdaten (als Verbindung in der Power Platform) und dann nutzen Sie die angebotenen Aktionen/Trigger.

Allerdings gibt es einen wichtigen Unterschied: Standard vs. Premium Connectoren. Standard-Connectoren (z.B. SharePoint, Outlook, Excel – alles was mit Microsoft 365 kommt) können Sie mit den in Office 365 enthaltenen Basisrechten nutzen. Premium-Connectoren (z.B. SQL Server, SAP, Salesforce, uvm.) erfordern eine lizenzierte Power Platform-Nutzung (also Power Apps/Automate Plan). Das ist verständlich, weil damit viele Enterprise-Funktionen verknüpft sind. Auf Premium-Connectoren gehen wir in der Lizenz-Sektion noch genauer ein.

Neben den Cloud-Connectoren gibt es noch die On-Premises Data Gateway-Komponente. Dies ist eine Brücke zwischen der Cloud und Ihrem lokalen Netzwerk. Wenn Ihre Datenquelle innerhalb Ihres Firmennetzwerks liegt (z.B. eine lokale SQL-Datenbank, ein internes Dateisystem, ein proprietäres ERP), dann können Cloud-Dienste da ja nicht ohne weiteres zugreifen (Firewall etc.). Das On-Premises Data Gateway – eine kleine Software, die Sie auf einem Server installieren – stellt die sichere Verbindung her. Es nimmt Anfragen aus der Power Platform entgegen und leitet sie an die internen Quellen weiter (und umgekehrt). Wichtig: Die Daten werden dabei verschlüsselt übertragen, und die Initiative geht immer vom Gateway aus (also keine eingehenden Verbindungen ins Firmennetz nötig, es ist alles outbound über HTTPS). Praktisch bedeutet das, dass Sie auch alte Legacy-Daten in neue Apps/Flows einbinden können, ohne die Daten erst mühsam in die Cloud migrieren zu müssen. Zum Beispiel kann ein Flow per Gateway auf eine lokale Oracle-Datenbank zugreifen und dort Daten abrufen oder schreiben. Oder eine Power BI-Analyse verbindet sich über das Gateway auf den hausinternen SQL-Server, um die Daten täglich zu aktualisieren.

Zusätzlich gibt es die Möglichkeit, Custom Connectoren zu erstellen – das ist quasi Ihr eigenes Verbindungsstück, falls es für einen speziellen Webservice noch keinen fertigen Connector gibt. Mit einem Custom Connector definieren Sie die API-Endpunkte und Authentifizierung und können den dann verwenden, als wäre er nativ dabei (mehr dazu später im Pro-Dev Abschnitt).

Zusammengefasst: Die Connectoren und Gateways sorgen dafür, dass die Power Platform nicht im eigenen Saft schmort, sondern sich nahtlos in Ihre bestehende Systemlandschaft integrieren kann. Sie können quer über Cloud und On-Premises hinweg Daten bewegen, Aktionen ausführen und damit ganz neue Prozesse gestalten, die vorher mangels Schnittstellen vielleicht gar nicht möglich waren.

3. Sinn & Zweck – Nutzenargumentation für Unternehmen und Fachbereiche

Warum sollten Sie und Ihr Unternehmen sich überhaupt mit der Power Platform beschäftigen? Ist das nur wieder ein weiterer IT-Hype, oder steckt handfester Nutzen dahinter? Aus meiner Beratungspraxis kann ich hier ganz klar sagen: Der Nutzen ist real und enorm, wenn man es richtig anpackt. Lassen Sie uns die Argumente aus verschiedenen Blickwinkeln anschauen.

Entlastung der IT & Empowerment der Fachbereiche

Klassischerweise müssen Fachbereiche für jede digitale Lösung bei der IT anklopfen: „Könnt ihr uns eine Anwendung erstellen, um XY zu verfolgen?“ – Die IT hat aber oft monatelange Backlogs, sodass kleine Lösungen für z.B. das Marketing-Team ständig nach hinten priorisiert werden. Ergebnis: Die Fachbereiche helfen sich selbst, notfalls mit Excel-Makros, Access-Datenbanken von anno dazumal oder unsicheren SaaS-Tools, die am IT-Einkauf vorbei geschmuggelt werden (Schatten-IT). Mit der Power Platform gibt man den Fachbereichen ein offizielles Werkzeug an die Hand, um einfachere bis mittelschwere Lösungen eigenständig umzusetzen. Die IT setzt den Rahmen (z.B. was Datenzugriff und Sicherheit angeht), aber muss nicht jeden einzelnen Anwendungswunsch selbst programmieren. Dadurch wird die IT deutlich entlastet und kann sich um ihre Kernprojekte kümmern (etwa die globale SAP-Einführung oder die Netzwerk-Security), während die Fachbereiche ihre Prozesse selbst digitalisieren. Im Endeffekt entsteht eine Win-Win-Situation: Fachabteilungen fühlen sich ermächtigt und ernst genommen, weil sie nicht jahrelang auf ein Tool warten müssen. Die IT behält aber trotzdem die Kontrolle über die Plattform (Lizenzen, Policies, Monitoring), sodass das Wildwuchs-Risiko minimiert wird. Dieses Konzept nennt man gerne „Citizen Development unter Co-Governance“ – Bürgerentwickler und IT arbeiten zusammen. Es ist eine Kulturänderung: Weg von „die IT muss alles machen“ hin zu „der Fachbereich gestaltet aktiv mit“.

Schnellere Lösungen & Business-Agilität

In der heutigen Zeit ändern sich Geschäftsanforderungen rasant. Ob neue Compliance-Vorgaben, verändertes Kundenverhalten oder interne Prozessoptimierungen – oft muss innerhalb weniger Wochen reagiert werden. Low-Code-Entwicklung mit der Power Platform ermöglicht genau das: Eine erste funktionierende Version einer App oder eines Workflows kann oft in Tagen oder wenigen Wochen entstehen, nicht erst nach Monaten klassischer Entwicklung. Das bedeutet, Ihr Unternehmen wird viel anpassungsfähiger. Ein praktisches Beispiel: Angenommen, es tritt ein neues Gesetz in Kraft, dass Sie bestimmte Kundendaten anders erfassen müssen. Statt auf ein nächstes großes Release der Enterprise-Software zu warten, könnte Ihr Team mit Power Apps kurzfristig ein Erfassungsformular bauen, das die Daten sammelt und an vorhandene Systeme andockt – so sind Sie compliant, während der Wettbewerb vielleicht noch rätselt, wie man das schnell umsetzt. Auch Prototyping ist ein wichtiger Aspekt: Mit Power Platform können Ideen schnell ausprobiert werden. Wenn ein Fachbereich die Vision für einen neuen digitalen Service hat, kann man innerhalb kurzer Zeit einen Prototyp in Power Apps klickbar machen und mit echten Nutzern testen. So sehen Sie frühzeitig, was funktioniert und was nicht, ohne große Investitionen. Die frühe Validierung spart langfristig enorm Kosten, weil man nicht am Bedarf vorbeientwickelt.

Digitalisierung von Papierprozessen und Excel-Lösungen

Viele Unternehmen – vielleicht erkennen Sie Ihr eigenes wieder – haben Unmengen an kleinen Helferlein im Einsatz: Excel-Sheets mit Makros, Access-Datenbanken, manuell gepflegte Listen, Formulare in Word, etc. Diese sind oft geschäftskritisch, aber sie sind fehleranfällig und personengebunden (wenn der Ersteller geht, versteht keiner mehr die Makros). Die Power Platform bietet eine hervorragende Möglichkeit, solche Dingen den Schrecken zu nehmen. Statt einer schwer nachvollziehbaren Excel-Matrix kann man eine benutzerfreundliche Power App erstellen, bei der die Logik sauber im Hintergrund im Dataverse läuft und nicht mehr in einer Zelle BX97 versteckt ist. Der Nutzen: Weniger Fehler, höhere Datenqualität, Transparenz. Jeder Berechtigte kann die Daten einsehen, und man kann einfach nachvollziehen, wer wann was erfasst hat (via Audit Logs). Zudem sind solche Apps ortsunabhängig nutzbar – auf dem Tablet im Lager, im Home-Office, überall. Das ersetzt nicht nur Zettelwirtschaft, sondern erhöht die Geschwindigkeit der Prozesse (kein Hin- und Her-Mailen von Files mehr, keine Doppeleingaben). Ich habe Kunden erlebt, die allein durch das Ersetzen eines Uralt-Access-Tools für Prüfberichte durch eine Power App plötzlich 50% Zeitersparnis hatten – weil die neue App Workflows (Power Automate) anstiess, wo früher jemand manuell E-Mails verschicken musste, und weil gleichzeitig die Fehlerquote sank (keine „vergessenen“ Prüfschritte mehr, da App alle Felder vorgibt).

Bessere Entscheidungsgrundlagen durch Daten

Mit Power BI als Teil der Plattform kommt auch ein Riesen-Mehrwert: Datentransparenz. Viele Unternehmen sitzen auf Datenschätzen, die kaum gehoben werden. Oder jeder Bereich hat eigene Auswertungen, die nicht zusammenpassen. Durch die Power Platform können Sie Daten aus verschiedensten Quellen zusammenführen (via Connectoren) und zentral in Power BI analysieren. Das bringt das berühmte „eine Version der Wahrheit“ in Ihre KPIs. Führungskräfte können sich darauf verlassen, dass Kennzahlen für Vertrieb, Finanzen, Produktion etc. aus demselben System stammen und konsistent sind. Echtzeit-Dashboards ermöglichen es, schneller auf negative Trends zu reagieren (z.B. Absatzeinbruch in Region X diesen Monat? – Sie sehen es sofort und nicht erst beim Quartalsmeeting). Und nicht zu unterschätzen: Datenkultur im Unternehmen. Wenn Mitarbeiter durch einfache Tools wie Power BI selbst Analysen erstellen können, steigt das Verständnis für die eigenen Prozesse und wo es hapert. Ich habe erlebt, dass Teams plötzlich miteinander ins Gespräch kamen, weil sie dank eines gemeinsam genutzten Dashboards erkannt haben: „Oh, wenn du deine Daten so eingibst, kann ich sie gar nicht richtig auswerten – lass uns die Schnittstelle verbessern.“ – Solche Gespräche passiert eher, wenn die Daten sichtbar sind, als wenn alles im Verborgenen schlummert.

Reduzierung von Schatten-IT und Erhöhung der Sicherheit

Auf den ersten Blick könnte man denken: „Wenn ich jetzt erlaube, dass jeder Power-Apps baut, dann fördere ich doch Schatten-IT!“ – Genau das Gegenteil ist der Fall, wenn man es mit Konzept einführt. Schatten-IT entsteht ja gerade dort, wo offizielle Lösungen fehlen. Mit der Power Platform schaffen Sie einen offiziellen Rahmen. Und dieser Rahmen ist sicherer als wildwachsende individuelle Tools: Alle Power Platform Apps und Flows laufen in Ihrer kontrollierten Umgebung, Authentifizierung läuft über Azure AD, es gibt Datenverlust-Prävention (DLP)-Richtlinien (dazu später mehr), Audit-Logs, regelmäßige Backups etc. – Kurz: Sie haben viel mehr Kontrolle und Übersicht, als wenn jeder irgendein Cloud-Tool bucht. Anstatt zu versuchen, jede inoffizielle Lösung im Keim zu ersticken (das klappt ohnehin nie zu 100%), kanalisieren Sie die Innovationsfreude in geregelte Bahnen. Die Mitarbeiter dürfen kreativ sein, aber auf einer Plattform, die von IT und Security beaufsichtigt wird. Das ist wie ein Sandkasten mit Zaun drumherum: Drin dürfen sie bauen, aber die Sandburgen bleiben im sicheren Bereich. Dadurch sinkt das Risiko, dass jemand Firmendaten versehentlich auf eine unsichere Plattform lädt, nur weil er eine bestimmte Aufgabe erledigen will. Die IT Governance ist eingebaut – Sie können z.B. zentral steuern, welche externen Dienste angebunden werden dürfen (über Connector Policies). Außerdem bietet Microsoft im Hintergrund ein hohes Maß an Compliance-Zertifizierungen (ISO, SOC, etc.), was viele gängige SaaS-Tools nicht vorweisen können. Also argumentieren Sie intern ruhig offensiv: „Lieber Vorstand, wir führen die Power Platform auch ein, um die Sicherheit zu erhöhen und unkontrollierte Schatten-IT abzulösen.“

Produktivität und Mitarbeiterzufriedenheit

Nicht zu vergessen: Der menschliche Faktor. Mitarbeiter, die immer wieder mit frustrierenden, manuellen Prozessen zu tun haben, sind irgendwann demotiviert. Die kluge Fachkraft von heute erwartet einfach, dass Routine-Prozesse digital und smart laufen. Mit der Power Platform können Ihre Teams lästige Aufgaben automatisieren oder zumindest vereinfachen. Das sorgt für echte Aha-Momente: „Endlich muss ich die Urlaubstage nicht mehr in dreifacher Ausführung in Excel und SAP und Zettel pflegen – das geht jetzt auf Knopfdruck!“. Solche Erlebnisse steigern die Zufriedenheit und binden gute Leute ans Unternehmen. Außerdem fördert das Citizen Development eine Kultur des kontinuierlichen Verbesserns: Mitarbeiter identifizieren Verbesserungsbedarf und setzen ihn selbst um, anstatt zu sagen „Das war schon immer so.“ oder „Da kann man eh nix machen“. Diese Proaktivität ist Gold wert. Zudem lernen die Fachbereiche neue Fähigkeiten (z.B. wie man logisch einen Workflow aufbaut, wie man Daten modelliert) – das sind Soft-Skills in Richtung Digitalisierung, die in Zukunft immer wichtiger werden. Manche Mitarbeiter entdecken gar eine Leidenschaft fürs Entwickeln und wechseln perspektivisch in neue Rollen (z.B. ins CoE-Team oder als Prozessautomationsexperte). Als Unternehmen profitieren Sie von diesen Fähigkeiten, weil Probleme künftig näher an ihrer Entstehung gelöst werden. Statt sturer Arbeit nach Vorschrift entwickeln die Leute ein Ownership-Gefühl für „ihre“ Lösungen.

Kostenersparnis

Natürlich darf das Thema Kosten nicht fehlen. Power Platform kann in verschiedenen Bereichen helfen, Geld zu sparen. Zum einen Entwicklungskosten: Eine klassische Individualsoftware zu beauftragen (intern oder extern) ist teuer – Entwicklerstunden, lange Projekte usw. Mit Low-Code kann vieles günstiger umgesetzt werden, weil es schneller geht und weil möglicherweise teure externe Entwickler gar nicht nötig sind. Zum anderen Lizenzkosten: Viele Firmen haben zig Insellösungen mit separaten Lizenzen im Einsatz – ein Tool fürs Umfragen, eins für Ticketing, eins für Prozessautomation etc. – Wenn Sie viele dieser Anwendungsfälle auf die Power Platform konsolidieren, zahlen Sie im Idealfall nur eine Plattform (bzw. ein Bündel von Lizenzen, dazu später mehr). Beispiel: Anstatt für jeden kleinen Webservice ein SaaS-Tool mit 10€ pro Nutzer im Monat zu abonnieren, können Sie vielleicht drei dieser Anforderungen mit einer Handvoll Power Apps umsetzen, die alle unter einer 19€-Lizenz pro User laufen. Ja, Lizenzen kosten auch hier Geld – aber man muss sehen, was man dafür alles abdeckt. Ein gut gemachtes Power Platform Portfolio kann unter dem Strich günstiger sein als ein Zoo an Einzellösungen. Und dann ist da noch die operative Effizienz: Wenn Routinearbeiten automatisiert werden, sparen Mitarbeiter wertvolle Arbeitszeit. Die gewonnenen Stunden können für wertschöpfendere Aufgaben genutzt werden. Das lässt sich in Euro beziffern: Wenn 50 Mitarbeiter dank einer Reihe von Power Automate-Flows jeweils 1 Stunde pro Woche einsparen, sind das 50h/Woche – multiplizieren Sie das mit dem internen Stundensatz, kommen schnell viele Tausend Euro zusammen, die Sie an Personalkapazität anders einsetzen können.

Abschließend: Sinn & Zweck der Power Platform ist es, die Brücke zu schlagen zwischen den wachsenden Anforderungen der Fachbereiche und der Notwendigkeit von IT-Governance und Sicherheit. Sie ermöglicht rasche Digitalisierung an der Basis und zentralen Durchblick zugleich. Das Resultat sind agilere Geschäftsprozesse, zufriedenere Mitarbeiter, entlastete IT-Abteilungen und letztlich ein wettbewerbsfähigeres Unternehmen. Natürlich passiert das nicht alles automatisch – man muss es klug einführen. Doch dafür sind Sie ja hier und lesen diesen Artikel. 😉

4. Anwendungsszenarien aus der Praxis

Theorie ist schön und gut, aber was kann man denn konkret mit der Power Platform bauen? Hier stelle ich Ihnen 10 realistische Szenarien vor, die in Unternehmen unterschiedlicher Branchen bereits so oder ähnlich umgesetzt wurden. Diese sollen Ihnen Anregungen geben, was auch in Ihrem Umfeld möglich wäre.

1. Urlaubsantrags-App mit Genehmigungsworkflow

Problem: Urlaubsanträge liefen bislang per E-Mail oder gar auf Papierformularen. Das führte zu Unübersichtlichkeit und Verzögerungen, wer wann frei ist.
Lösung mit Power Platform: Eine Power Apps Canvas-App erlaubt es Mitarbeitern, Urlaubstage zu beantragen. Die App ist auf dem Smartphone nutzbar und verbindet sich im Hintergrund mit einer Dataverse-Tabelle oder einer SharePoint-Liste, in der alle Anträge gespeichert werden. Per Power Automate wird automatisch ein Genehmigungsworkflow gestartet: Der Vorgesetzte erhält eine Benachrichtigung (z.B. per Outlook oder in Microsoft Teams) und kann mit einem Klick den Antrag genehmigen oder ablehnen. Die Entscheidung fließt zurück in die App – der Mitarbeiter sieht den Status seines Antrags live. Zusätzlich kann ein Power BI Dashboard die Abwesenheiten im Team-Kalender visualisieren, damit Personalabteilung und Management Überblick haben. Dieses Szenario zeigt schön die Zusammenarbeit der Komponenten: App für Eingabe, Automate für Workflow, BI für Auswertung. Im Ergebnis läuft der Urlaubsprozess transparent, schnell und papierlos. Kein Antrag geht mehr verloren, niemand muss in CC gesetzt werden – alles zentral nachverfolgbar. Übrigens kann man auch Geschäftsregeln einbauen: z.B. automatisches Ablehnen, wenn zu viele Leute parallel Urlaub wollen, oder Info an Vertretungen.

2. Spesenabrechnung und Erstattung

Problem: Mitarbeiter reichen ihre Auslagen/Belege oft noch manuell ein (Excel-Liste mit angeklebten Quittungen), was zu langer Bearbeitungszeit und Fehlern bei der Erstattung führt.
Lösung: Mit Power Apps lässt sich eine Spesen-App erstellen. Mitarbeiter fotografieren unterwegs mit dem Handy ihre Quittungen, wählen in der App Kategorie und Betrag aus. Die App nutzt AI Builder Formularerkennung, um z.B. das Datum und den Betrag aus dem Foto der Quittung automatisch auszulesen (kein Abtippen nötig!). Alle Einreichungen werden ins Dataverse oder in eine SharePoint-Liste gespeichert. Ein Power Automate Flow aggregiert wöchentlich die eingereichten Spesen pro Mitarbeiter und sendet eine Genehmigungsanfrage an den jeweiligen Manager. Nach Freigabe erfolgt automatisch ein Export z.B. als Buchungssatz fürs ERP-System oder es geht eine Zahlungsauslösungsdatei ans Finanzsystem (hier käme ggf. ein Connector zum Einsatz). Die Mitarbeiter bekommen eine Benachrichtigung, sobald die Erstattung freigegeben ist. Durch diese Lösung werden Erstattungen deutlich schneller erledigt, die Buchhaltung spart sich das Eintippen von Papierbelegen und Mitarbeiter sehen in der App jederzeit den Status ihrer Einreichungen. Zudem verhindert das System Doppelabrechnungen (man kann einen Beleg nur einmal erfassen) und stellt sicher, dass alle notwendigen Angaben gemacht wurden (die App kann Plausibilitätsprüfungen machen, etwa dass ein Betrag >0 sein muss etc.). Auch hier greifen wieder mehrere Komponenten ineinander – mit dem angenehmen Nebeneffekt, dass Mitarbeiter die Lösung lieben, weil sie viel einfacher ist als der alte Prozess.

3. Vertriebs-Dashboard und Lead-Management

Problem: Das Vertriebsteam pflegt Kontakte in verschiedenen Excel-Listen und CRM-Tools. Das Management hat Mühe, aktuelle Verkaufschancen und Umsatzzahlen im Blick zu behalten.
Lösung: Power BI wird eingesetzt, um Daten aus dem CRM (z.B. Dynamics 365 Sales oder Salesforce via Connector) und vielleicht einem ERP-System (für aktuelle Umsätze) zusammenzuführen. Das Ergebnis ist ein Vertriebs-Dashboard, das Kennzahlen wie Pipeline-Wert, erzielte Abschlüsse, Performance pro Verkäufer etc. in Echtzeit zeigt. Führungskräfte können filtern nach Region, Produktgruppe usw. – endlich hat man eine einheitliche Sicht auf den Vertriebserfolg. Ergänzend könnte eine Power Apps Modell-getriebene App implementiert werden, die als Lead-Management-Tool dient. Angereicherte Daten (z.B. aus Messekontakten, die per Power Pages Portal eingegeben wurden) landen im Dataverse und werden dort von Vertriebsmitarbeitern qualifiziert (nachverfolgt via App: hat der Kollege schon angerufen? Ist ein Angebot raus?). Über Power Automate werden Follow-Ups sichergestellt: Wenn ein Lead 7 Tage unbeachtet bleibt, bekommt der Vertriebsleiter eine Mail – so geht nichts durch die Lappen. Außerdem schickt ein Flow automatisch wöchentliche E-Mails an die Teammitglieder mit ihren offenen Aufgaben. In Summe sorgt dieses Szenario dafür, dass Vertriebsdaten zentralisiert und transparent sind. Jeder im Team arbeitet mit denselben aktuellen Daten, und das Management kann sich auf aktuelle Zahlen verlassen. Kein mühsames Konsolidieren von Excel-Berichten mehr am Quartalsende – stattdessen tagesaktuelle Visualisierungen. Und dank der App wissen Vertriebsmitarbeiter genau, welche Leads priorisiert zu bearbeiten sind.

4. Kunden-Feedbackanalyse mit KI-Unterstützung

Problem: Das Unternehmen erhält viel Kundenfeedback (z.B. über Umfragen, Support-E-Mails), hat aber Mühe, diese unstrukturierten Daten auszuwerten und Trends zu erkennen.
Lösung: Hier kommt eine Kombination aus Power Automate und AI Builder ins Spiel. Angenommen, es gibt eine allgemeine Mailbox für Kundenanfragen/Feedback. Ein Flow greift jedes eingehende Mail ab (Trigger: „Beim Eintreffen einer E-Mail mit Betreff ‚Feedback'“). Für jede Nachricht nutzt der Flow AI Builder Sentiment Analysis, um die Stimmung zu bewerten (positiv, neutral, negativ) und Key Phrases zu extrahieren (wichtigste Schlagworte). Diese Infos sowie der Text landen im Dataverse. Außerdem kann AI Builder eine Textklassifizierung vornehmen, z.B. nach Themen (vielleicht hat man das Modell trainiert auf Kategorien wie „Produktlob“, „Beschwerde Lieferung“, „Funktionswunsch“ etc.). Nun erstellt ein Power BI Bericht auf Basis der gesammelten Daten eine Trend-Analyse: Wie hat sich das Stimmungsbild der Kunden im letzten Monat entwickelt? Welche häufigen Themen tauchen in den Kommentaren auf (z.B. oft das Wort „Preis“ -> viele finden vielleicht die Preise zu hoch)? Das Dashboard kann in Echtzeit aktualisiert werden, sodass der Kundendienst oder das Produktmanagement frühzeitig Stimmungsumschwünge erkennt. Ergänzend könnte ein Power Automate Bot (via Teams oder Mail) Alarm schlagen, wenn ein sehr negatives Feedback mit bestimmten Schlagworten reinkommt – z.B. „VIP-Kunde unzufrieden“, dann gleich Meldung ans Account Management. Durch diese Lösung wird die Voice of the Customer greifbar: Statt einzelne E-Mails manuell zu lesen und zu hoffen, dass man Trends erkennt, übernimmt KI und Automation die Vorarbeit. So können Maßnahmen (Produktverbesserungen, Serviceänderungen) schneller und datenbasiert ergriffen werden. Und Mitarbeiter müssen nicht hunderte Texte manuell klassifizieren – das erledigt die Power Platform.

5. Wartungs- und Inspektions-App im Feld

Problem: In einem Produktions- oder Versorgungsunternehmen müssen regelmäßig Anlagen vor Ort inspiziert werden. Bisher wurden Checklisten auf Papier ausgefüllt und später abgetippt, Fotos separat verwaltet – ein ineffizienter Prozess mit Medienbrüchen.
Lösung: Eine Canvas Power App für Tablets oder Smartphones, die von den Wartungstechnikern mitgeführt wird. Die App lädt beim Start die Liste der zu prüfenden Anlagen (z.B. aus Dataverse oder SAP via Connector). Vor Ort kann der Techniker die Inspektionspunkte abhaken, Messwerte direkt eintippen und bei Bedarf Fotos aufnehmen, die automatisch an den jeweiligen Datensatz angehängt werden. Wichtig ist hier oft die Offline-Fähigkeit: In entlegenen Werksbereichen gibt es ggf. kein Netz. Power Apps bietet die Möglichkeit, Daten lokal zu cachen und später zu synchronisieren. Der Techniker kann also auch offline alles erfassen, und sobald er wieder Netz hat, überträgt die App die Daten ins Backend. Nach abgeschlossener Wartung unterschreibt der Kunde oder Betreiber vielleicht direkt auf dem Gerät (Unterschrift-Feld in der App). Ein Power Automate Flow sorgt dafür, dass nach der Synchronisation ein PDF-Bericht generiert wird (z.B. mit einer Report-Vorlage, gefüllt mit den eingegebenen Werten und Fotos) und dieser per E-Mail ans Backoffice und den Kunden geschickt wird. Im Dataverse werden die historischen Wartungsdaten gespeichert. Ein Power BI kann daraus z.B. Ausfallrisiken ableiten: Anlage X hatte 5 mal in Folge erhöhten Temperaturwert -> vielleicht proaktiv austauschen. Fazit: Mit dieser Lösung laufen Inspektionen digital, schneller und weniger fehleranfällig. Kein Abtippen handschriftlicher Zettel mehr (was Zeit kostet und Fehler produziert). Alle Daten sind sofort zentral verfügbar. Das erhöht die Qualität der Wartung und die Kundenzufriedenheit (weil Berichte sofort da sind und transparent ist, was gemacht wurde). Zudem kann das Management nun einfach auswerten, wie viele Wartungen pro Tag ein Techniker schafft, wo Engpässe sind etc., was vorher in Papierbergen verborgen war.

6. IT-Helpdesk Ticketing-Lösung in Teams

Problem: Kein formales Helpdesk-System vorhanden; Mitarbeiter melden IT-Probleme per Telefon oder Zuruf, was in Chaos und fehlender Nachverfolgung resultiert.
Lösung: Mit minimalem Aufwand kann in Microsoft Teams mittels Power Platform eine einfache Ticket-Lösung geschaffen werden. Zum Beispiel ein Power Automate Flow, der durch einen Trigger „Bei neuer Chat-Nachricht mit Stichwort #Helpdesk“ ausgelöst wird. Mitarbeiter könnten in einem Teams-Kanal oder via Chat an einen Bot eine Nachricht schicken: „#Helpdesk mein Drucker streikt“. Der Flow liest das aus und erstellt im Hintergrund ein Ticket in Dataverse (oder in einer SharePoint-Liste). Alternativ könnte man auch eine Power Virtual Agents Chatbot (bzw. Copilot Studio Agent) in Teams integrieren: Der Mitarbeiter tippt „Ich habe ein Problem mit dem Drucker“, der Bot fragt automatisch ein paar Details ab („Welcher Standort?“, „Welches Modell?“) und legt dann ein Ticket an. Die IT-Mitarbeiter nutzen eine Power Apps (evtl. modellgesteuert) als Ticket-Queue: Sie sehen alle offenen Tickets, können Status ändern, Lösungen dokumentieren. Der Mitarbeiter wird jeweils per Adaptive Card in Teams informiert, wenn sein Ticket bearbeitet oder gelöst wurde (das erledigt wieder ein Flow bei Statusänderung). Diese Lösung nutzt vor allem bestehende M365-Funktionalität aus – und ist viel kostengünstiger als ein großes ITSM-Tool, wenn man primär die Basics braucht. Der Nutzen: Nichts geht mehr unter, es gibt eine zentrale Nachverfolgung. Gleichzeitig ist die Hemmschwelle für Mitarbeiter gering, ein Ticket zu erstellen (einfach in Teams tippen, statt ein Fremdportal zu öffnen). Die IT kann Reaktionszeiten messen, häufige Problemursachen erkennen (via Power BI: wie oft „Druckerproblem“ pro Woche etc.) und so eventuell präventiv handeln. Insgesamt wird der interne Support durch diese einfache Power-Platform-Lösung strukturierter und transparenter.

7. Vertragsmanagement und Freigabeprozess

Problem: Verträge (mit Kunden, Lieferanten etc.) werden dezentral in Abteilungen verwaltet, Fristen zur Verlängerung/Kündigung werden leicht übersehen. Freigaben neuer Verträge ziehen sich per E-Mail schleppend hin.
Lösung: Einführung einer zentralen Vertragsmanagement-App: In einer Power Apps (Canvas oder modellgesteuert) können berechtigte Mitarbeiter neue Vertragsdokumente hochladen und die Metadaten (Vertragspartner, Betrag, Laufzeit, Kündigungsfrist, Zuständiger etc.) erfassen. Das Dokument selbst kann z.B. in SharePoint gespeichert werden, während die Metadaten im Dataverse stehen (oder ebenfalls in SharePoint als Liste mit Metadaten, je nach Lizenzpräferenz). Sobald ein neuer Vertrag oder eine Änderung erfasst wird, startet ein Power Automate Freigabe-Workflow: je nach Vertragsart müssen z.B. erst der Fachbereichsleiter, dann die Rechtsabteilung, dann der Geschäftsführer freigeben. Das System verschickt die Dokumente in festgelegter Reihenfolge zur Prüfung – entweder als E-Mail mit Approve/Reject Buttons oder wieder als Teams Adaptive Card. Alle Entscheidungen werden geloggt. Man kann auch Bedingungen einbauen („wenn Vertrag > 100k€, zusätzlicher Genehmiger Finance“). Ist am Ende alles genehmigt, bekommt der Ersteller die Info und kann den Vertrag final versenden. Zusätzlich kümmert sich ein geplanter Flow um Fristenmanagement: Für jeden aktiven Vertrag prüft er z.B. monatlich, ob in 60 Tagen eine Kündigungsfrist abläuft. Wenn ja, benachrichtigt er automatisch den zuständigen Mitarbeiter: „Vertrag XY kann bis zum 31.03. gekündigt werden, sonst Verlängerung um ein Jahr.“ Der Mitarbeiter entscheidet dann via Klick (z.B. „Bitte kündigen“ oder „Verlängern“), was wiederum dokumentiert wird. Diese Anwendung stellt sicher, dass keine kritischen Fristen mehr verpasst werden – was sofort ein finanzieller Vorteil sein kann, wenn man z.B. unnötige automatische Verlängerungen verhindert. Außerdem läuft der Freigabeprozess nachvollziehbar und schneller ab: Jeder weiß, bei wem es gerade liegt (kann man im App-Status sehen) und man kann Reminder-Flows schicken, wenn jemand länger nicht reagiert. Das Vertragsarchiv ist digital durchsuchbar (z.B. per Power BI oder einer einfachen Suchmaske in der App), was die Arbeit der Rechts- oder Einkaufsabteilung massiv erleichtert. Kein wühlen in Ordnern mehr, kein Excel „Vertragsliste.xlsx“, das manuell gepflegt werden muss – alles in einer Lösung.

8. Automatisierte Berichterstattung und Alerts

Problem: Jeden Montagmorgen sitzt jemand da und sammelt Zahlen aus verschiedenen Systemen, um einen Wochenbericht für die Geschäftsführung zu erstellen – das kostet viel Zeit und ist fehleranfällig. Außerdem werden kritische Entwicklungen manchmal erst am Montag bemerkt, obwohl sie schon am Freitag problematisch waren.
Lösung: Vollautomatische Berichte mit Power Automate und Power BI. Angenommen, es soll wöchentlich ein Projektstatus-Bericht erstellt werden: Projektleiter pflegen ihre Kennzahlen in einer zentralen Liste oder Dataverse-Tabelle (oder z.B. in Excel auf SharePoint – weniger elegant, geht aber). Ein Power BI Bericht visualisiert diese Kennzahlen pro Projekt (Ampeln, Fortschritte, Budgets etc.). Jeden Montag um 6 Uhr (geplanter Flow-Trigger) wird folgender Ablauf gestartet: Power Automate aktualisiert den Datenbestand (ggf. per Refresh-API das Power BI Dataset aktualisieren, falls Dataflows), generiert dann ein PDF des aktuellen Power BI Berichts (es gibt eine Export-Funktion per Flow für PBI-Berichte) und versendet dieses PDF an den Verteiler der Geschäftsführung. Um 8 Uhr liegt somit automatisch der Wochenreport in den Posteingängen – ohne dass jemand seine Sonntagsabend opfern musste. Zusätzlich kann das System mit Alerts ausgestattet werden: Falls ein KPI einen bestimmten Schwellwert überschreitet (z.B. Projektverzug > 4 Wochen, oder Maschinenstillstand gemeldet), kann ein Flow sofort eine Warnung per E-Mail/SMS/Teams an die Verantwortlichen schicken. Man muss nicht auf den Wochenreport warten. Technisch kann Power Automate z.B. einen Power BI Daten-Alert als Trigger nutzen (PBI ermöglicht ja das Setzen von Alerts in Dashboards) oder man prüft direkt in einem Flow die Datenquelle auf Grenzwert-Überschreitungen. Der Nutzen: Zeitersparnis und höhere Reaktionsfähigkeit. Berichte werden nicht mehr manuell „gebastelt“ – das spart z.B. der PMO-Stelle etliche Stunden pro Woche. Und kritische Situationen werden zeitnah adressiert, nicht erst retrospektiv. So eine Lösung erhöht das Vertrauen ins Reporting („die Zahlen sind immer aktuell und konsistent“) und entlastet Mitarbeiter von stumpfen Datensammel-Aufgaben.

9. Lieferantenportal für Bestell- und Lieferinformationen

Problem: Lieferanten rufen ständig bei Ihrem Einkauf an, um nach dem Status ihrer Bestellung oder Zahlung zu fragen, oder um Adressänderungen mitzuteilen. Für Ihr Team ist das viel manueller Aufwand.
Lösung: Ein Power Pages Portal als Self-Service-Lieferantenportal. Hier können sich Ihre Lieferanten mit einem sicheren Login anmelden. Im Portal sehen sie eine Übersicht ihrer offenen Bestellungen, Lieferpläne, sowie den Status ihrer Rechnungen (bezahlt, in Prüfung, fällig etc.). Diese Daten können aus Ihrem ERP (z.B. SAP) über einen Kontextualisierten Connector oder via Data Export ins Dataverse bereitgestellt werden – quasi eine gesicherte Datenfreigabe. Lieferanten können im Portal auch eigene Daten aktualisieren: etwa ihre Ansprechpartner, Bankverbindungen, Zertifikate hochladen. Änderungen, die im Portal erfasst werden, laufen wiederum per Power Automate zu Ihren internen Systemen: z.B. ein Genehmigungs-Flow „Lieferant X hat seine Bankverbindung geändert – klicke, um ins SAP zu übernehmen“. Somit behalten Sie Kontrolle, aber sparen Tipparbeit. Auch Dokumente können ausgetauscht werden: Der Einkauf stellt etwa Lastenhefte oder Verträge ins Portal ein (nur für den jeweiligen Partner sichtbar), Lieferanten können Angebotsdokumente hochladen. Das Portal dient quasi als Kommunikationsdrehscheibe. Zudem könnten Sie Ankündigungen dort teilen (z.B. „Neue Compliance-Richtlinien für Lieferanten – bitte bis Datum X bestätigen“ -> und ein Flow trackt, wer es bestätigt hat). Der Vorteil: Entlastung der Einkaufsabteilung. Viele Standardfragen beantworten sich die Lieferanten selbst, indem sie ins Portal schauen („Ah, meine Rechnung wird nächsten Mittwoch bezahlt, steht schon zur Zahlung an.“). Gleichzeitig wirkt Ihr Unternehmen professioneller, weil es so eine Plattform anbietet – das stärkt die Partnerbindung. Und das Beste: Sie mussten dafür keine teure Supplier-Portal-Software einführen, sondern haben es mit vorhandenen M365-Ressourcen gebaut. Durch die Dataverse-Integration sind die Daten auch für andere Zwecke nutzbar (z.B. gleich in Power BI Auswertungen über Lieferantenperformance ziehen). Selbstverständlich ist auf so einem Portal Sicherheit das A und O – Zugriffe sind personalisiert, SSL-verschlüsselt etc., aber all das bringt Power Pages ja zum Glück mit.

10. Chatbot für den Kundenservice (24/7 FAQ-Assistent)

Problem: Der Kundenservice wird mit immer gleichen Fragen bombardiert („Wo ist mein Paket?“, „Wie kann ich mein Passwort ändern?“ etc.). Mitarbeiter müssen das ständig manuell beantworten, was teuer und langsam ist. Außerhalb der Geschäftszeiten gibt es gar keine Antwortmöglichkeit.
Lösung: Aufbau eines KI-basierten Chatbots mit Copilot Studio (weiterentwickelter Power Virtual Agents). Dieser Kundenservice-Bot wird auf Ihrer Website oder im Kundenportal eingebunden. Kunden können ihre Fragen in natürlicher Sprache stellen. Der Bot nutzt hinterlegte Wissensquellen (z.B. häufige FAQ-Antworten, Handbuch-Auszüge) und generative KI, um passende Antworten zu formulieren. Zum Beispiel fragt ein Kunde: „Mein Paket mit der Nummer 12345 ist nicht angekommen – was kann ich tun?“. Der Bot kann über einen Connector zu Ihrem Versanddienst (oder Ihrer internen Bestell-Datenbank) den Status der Sendung abfragen (d.h. echte Aktion ausführen!), dem Kunden antworten „Ihr Paket befindet sich derzeit im Logistikzentrum XY, voraussichtliche Zustellung morgen. Möchten Sie einen Nachforschungsauftrag stellen?“ – und ggf. sogar gleich einen Prozess anstoßen: Klickt der Kunde „Ja“, dann wird per Power Automate ein entsprechendes Ticket intern erzeugt. Auch gängige Support-Themen wie Passwort zurücksetzen kann der Bot übernehmen: „Ich habe mein Passwort vergessen“ -> Bot leitet durch die benötigten Schritte oder sendet via Graph API einen Passwortrücksetz-Link an die E-Mail (Datenschutz beachten!). Dieser virtuelle Agent entlastet den First-Level-Support erheblich. Er ist rund um die Uhr verfügbar und kann beliebig viele Kunden gleichzeitig bedienen (kein Warten in der Hotline). Natürlich löst er nicht 100% aller Fälle, aber wenn er z.B. 50% abdeckt, kann sich das menschliche Team auf kniffligere Fälle konzentrieren. Ein weiteres Plus: Über Analytics im Copilot Studio sehen Sie, welche Fragen häufig gestellt werden, wo der Bot vielleicht nicht weiterwusste – diese Insights helfen, Ihr Angebot zu verbessern oder den Bot weiter zu trainieren. Dank KI klingt der Bot weniger „robotisch“ als alte Chatbots und kann auch mal fehlertolerant reagieren (wenn der Kunde Tippfehler drin hat oder umgangssprachlich schreibt). Wichtig ist hier, die richtigen Grenzen zu setzen: Der Bot sollte keine Rechts- oder Gesundheitsberatung geben 😉 und bei Unsicherheit lieber an einen Menschen übergeben. Aber insgesamt steigert dieses Szenario die Servicegeschwindigkeit und Kundenzufriedenheit, während es gleichzeitig Ihre Supportkosten senken kann. Und da es mit der Power Platform gebaut ist, integriert er sich gut mit Ihren bestehenden Daten – ein großer Vorteil gegenüber externen Chatbot-Lösungen, wo die Integration oft mühsam ist.

Dies sind nur zehn von unzähligen möglichen Szenarien. Die Power Platform ist enorm vielseitig – quasi jede manuelle Schnittstelle oder Informationslücke in Ihrem Betrieb ist ein Kandidat, um mit Low-Code gefüllt zu werden. Denken Sie an Qualitätsmanagement (Audit-Apps), Personal-Onboarding, interne Schulungsportale, Facility-Management (Raumbuchung, Schadensmeldungen), Sicherheitsmeldungen (Unfall-Meldesystem inkl. Fotos), uvm. Die Grundprinzipien sind immer ähnlich: Man nehme Daten + Geschäftslogik + Workflow + Oberfläche + Auswertung – mische diese nach Bedarf, und fertig ist eine maßgeschneiderte Lösung. Wichtig ist, immer den geschäftlichen Mehrwert im Blick zu haben: Unsere obigen Beispiele sparen Zeit, Geld, Nerven oder verbessern die Qualität. Suchen Sie in Ihrem Unternehmen nach solchen Hebeln. Die Technik ist mit der Power Platform kein Bremsklotz mehr, sondern kann in Wochen umgesetzt werden, was früher vielleicht utopisch schien.

5. Recht & Compliance im Kontext EU/Deutschland

Bei aller Begeisterung für die neuen Möglichkeiten dürfen wir die Themen Recht und Compliance nicht vernachlässigen. Gerade in Deutschland und der EU sind Datenschutz und IT-Compliance streng geregelt – was auch gut so ist! Die Microsoft Power Platform bietet zwar viele Freiheiten, aber als Unternehmen müssen Sie dafür sorgen, dass diese im rechtlich sicheren Rahmen genutzt werden. Schauen wir uns also die wichtigsten Aspekte an: DSGVO (Datenschutz), NIS2 (neue EU-Richtlinie für Cybersecurity), interne Richtlinien wie DLP (Data Loss Prevention) sowie Auditierung und Nachvollziehbarkeit.

Datenschutz & DSGVO

Die Datenschutz-Grundverordnung (DSGVO) ist in aller Munde – jedes IT-System, das personenbezogene Daten verarbeitet, muss DSGVO-konform sein. Das gilt selbstverständlich auch für Anwendungen, die Sie mit der Power Platform bauen. Was heißt das konkret?

• Datenminimierung & Zweckbindung: Überlegen Sie bei jeder App/Automation: Werden hier personenbezogene Daten verarbeitet? Wenn ja, sind diese erforderlich für den Zweck? Beispiel: Eine Power App für Urlaubsanträge speichert wahrscheinlich Name, Urlaubstage etc. Das ist okay, weil es für den Zweck nötig ist. Aber sollte sie auch das Geburtsdatum speichern? Eher nicht, wenn es dafür keinen zwingenden Grund gibt. Sammeln Sie also nicht unnötig mehr persönliche Daten als gebraucht.
• Transparenz & Einwilligung: Wenn eine App Daten von Kunden oder Mitarbeitern verarbeitet, müssen die Betroffenen grundsätzlich wissen, was mit ihren Daten passiert. Intern kann das oft über Betriebsvereinbarungen oder das allgemeine HR-Datenverzeichnis abgedeckt werden. Falls Sie aber z.B. eine Power Pages bauen, wo Kunden Daten eingeben, brauchen Sie evtl. eine Datenschutzerklärung auf der Website und ggf. eine Einwilligung, insbesondere wenn Daten an Dritte oder außerhalb der EU fließen.
• Datenstandort: Wo liegen die Daten, die die Power Platform verwendet? Microsoft bietet Rechenzentrums-Regionen – wenn Ihr Tenant in der EU angesiedelt ist (in der Regel Dublin/Amsterdam für EU), dann liegen Dataverse-Daten, Flow-Logs etc. auch dort. Das ist schon mal gut für DSGVO, denn es heißt, Daten bleiben innerhalb der EU. Allerdings: Manche Connectoren könnten Daten woanders hinschicken. Z.B. wenn Sie einen Flow bauen, der Personaldaten an einen US-Cloud-Dienst sendet (via Connector XY), dann findet ein Datentransfer in Drittland statt. Dafür brauchen Sie u.U. zusätzliche vertragliche Absicherungen (Standardvertragsklauseln, Prüfung auf angemessenes Datenschutzniveau). Hier hilft es, die DLP-Richtlinien (dazu gleich) so zu gestalten, dass sensible Daten nicht in unkontrollierte Kanäle abfließen können.
• Microsofts Rolle: Microsoft ist für die Power Platform Auftragsverarbeiter nach DSGVO (Sie als Unternehmen sind der Verantwortliche). Das heißt, Microsoft verarbeitet die Daten in Ihrem Auftrag und muss dafür vertraglich zusichern, DSGVO einzuhalten (im Microsoft Online Services DPA). Microsoft hat alle gängigen Zertifizierungen (ISO 27001, EU Model Clauses, C5 etc.), die das Fundament legen. Es gibt auch das Programm der EU Data Boundary – bis Ende 2023/2024 will Microsoft sicherstellen, dass bestimmte Cloud-Dienste (inkl. die Business-Daten) ausschließlich in EU-Rechenzentren verarbeitet werden, inkl. Support etc. – ein wichtiger Punkt, um dem Schrecken des Cloud Acts & Co. zu begegnen. Informieren Sie sich hier aktuell, aber Stand Nov 2025 ist man da auf einem guten Weg.
• Betroffenenrechte: DSGVO gibt Personen Rechte wie Auskunft, Berichtigung, Löschung. Wenn Sie z.B. eine Kunden-Feedback-App betreiben, müssten Sie im Zweifel alle Daten einer Person daraus exportieren/löschen können, falls eine Anfrage kommt. Bauen Sie also Mechanismen, um dem nachkommen zu können (z.B. eine Möglichkeit, per PowerShell oder Admin Center nach Daten zu suchen und diese zu entfernen). Dataverse hat z.B. eine Lösch-Funktion und kommt dem nach, aber Achtung: Falls Daten in Backups oder Audit-Logs sind, muss man auch dort an die Regeln denken (Microsoft löscht standardmäßig Backups nach einer gewissen Zeit automatisch, was hilft). Wenn Sie personalbezogene Daten in Power BI Reports haben, bedenken Sie auch dort, dass bei Löschanfragen entsprechende Datenquellen bereinigt werden.
• Aufbewahrungsfristen: Definieren Sie, wie lange Daten in einer Lösung verbleiben dürfen. DSGVO verlangt ja, dass Daten nicht ewig gespeichert werden ohne Grund. Hat Ihre Anwendung z.B. Bewerberdaten? Dann nach z.B. 6 Monaten sollten abgelehnte Bewerbungen gelöscht werden. Sie können einen Power Automate Planungs-Flow basteln, der regelmäßig alte Datensätze bereinigt. Oder Sie nutzen die Dataverse-Funktion für Löschjobs. Wichtig: Dokumentieren Sie diese Regeln im Datenschutzkonzept.

Insgesamt ist die Power Platform nicht per se ein Datenschutzproblem, man muss nur wie bei jeder Einführung neuer Software die DSGVO-Aspekte mitdenken. Oft ist es hilfreich, den Datenschutzbeauftragten frühzeitig einzubinden. Zeigen Sie auf, welche Daten in welcher Komponente liegen werden. Weil vieles in der Microsoft-Cloud bleibt, hat der DSB oft weniger Bauchschmerzen, als wenn Fachbereiche eigenmächtig irgendeine unsichere App nutzen. Mit vernünftigen Zugriffs- und Löschkonzepten lässt sich DSGVO-konform sehr gut mit Power Platform arbeiten. Achten Sie außerdem auf Telemetrie-Daten: Microsoft sammelt natürlich Nutzungsdaten (für Diagnose, Produktverbesserung). Unternehemn können das über Tenant-Einstellungen teilweise steuern (z.B. „nur notwendige Telemetrie“ statt Volltelemetrie). Hier sollten Sie die internen Richtlinien beachten, ggf. Betriebsrat informieren falls z.B. Mitarbeiteraktivitäten getrackt werden (Stichwort: „Wer hat wann welche App genutzt“ – das kann theoretisch ausgewertet werden, daher Transparenz walten lassen, dass das zum Zweck der Plattformüberwachung passiert, nicht zur Verhaltenskontrolle).

IT-Sicherheit & NIS2

NIS2 ist die zweite Fassung der EU-Richtlinie für Netzwerk- und Informationssicherheit, welche bis 2024/25 von den Mitgliedsstaaten in nationales Recht gegossen wird. Sie richtet sich vor allem an Betreiber kritischer Infrastrukturen und größere Organisationen. NIS2 verlangt verschärfte Maßnahmen in Sachen Cybersecurity: Risiko-Management, Vorfallmeldungen, Lieferketten-Sicherheit etc. Was hat das nun mit der Power Platform zu tun?

Wenn Ihr Unternehmen unter NIS2 fällt (z.B. Energieversorger, Gesundheitswesen, Bankensektor etc.), müssen Sie alle Ihre IT-Systeme auf robuste Sicherheit prüfen – auch die Low-Code-Plattformen. Das heißt zum Beispiel:

• Zugangssicherheit: Stellen Sie sicher, dass die Power Platform in Ihr Identity-Management eingebettet ist. Konkret: Jeder Zugriff läuft über Azure AD, also MFA aktivieren, Single Sign-On, Berechtigungen nur nach Need-to-have. Das ist Standard, aber muss auch durchgesetzt werden (kein „mal schnell externem Berater global Admin geben“ etc.). NIS2 würde hier verlangen, dass man bestmögliche Authentifizierungsverfahren nutzt – MFA ist quasi Pflicht, eventuell Conditional Access Policies (z.B. kein Zugang von unsicheren Geräten oder aus fremden Ländern, je nach Risikoprofil).
• Systemhärtung: Man will keine unnötig offenen Flanken. Die Power Platform hat diverse Admin-Einstellungen, um Sicherheit zu erhöhen. Beispiel: Sie können steuern, ob Benutzer eigene Umgebungen erstellen dürfen. Im Standard kann jeder Nutzer in seinem Power Apps Portal einfach eine „Developer-Umgebung“ anlegen. Für streng regulierte Umfelder möchte man das vielleicht abschalten, damit nicht wild Umgebungen entstehen, die man aus dem Auge verliert. Oder: Standardmäßig ist die Default-Umgebung für alle nutzbar – man sollte regeln, was dort passieren darf (am besten nur Spielwiese, keine produktiven Daten, oder stark eingeschränkte Rechte). NIS2 würde erfordern, dass man solche Policies bewusst setzt.
• Lieferketten-Risiko: Hier geht es darum, dass, wenn Sie Cloud-Services nutzen, Sie sicherstellen müssen, dass diese selbst sicher sind und Ausfälle/Beeinträchtigungen der Lieferanten einkalkuliert werden. Für die Power Platform als Service ist Microsoft der „Lieferant“. Sie sollten also immer im Blick haben, welche Abhängigkeit Sie hier haben (z.B. was passiert, wenn die Power Platform mal einen Ausfall hat? – Kommt zum Glück selten vor, aber möglich). NIS2 fordert, solche Risiken zu adressieren: z.B. Notfallpläne, Offlinedownload wichtiger Daten, Service-Level-Vereinbarungen. Microsoft garantiert SLA für die Dienste (99,9% etwa), aber Sie als Verantwortlicher müssen entscheiden, ob das für Ihren Zweck reicht. Wenn Sie auf Power Platform basierende Prozesse als kritisch klassifizieren, sollten Sie eine Art Notfallprozedur definieren – sei es, dass man temporär auf manuelle Prozesse zurückfällt, oder dass Sie Redundanzen haben (vielleicht ein wöchentliches Backup der Daten, das man im Notfall in Excel nutzen könnte, nur um nicht komplett blind zu sein). Das klingt etwas apokalyptisch, aber im Rahmen von NIS2 will man einfach vorbereitet sein.
• Vorfalls-Meldung: Sollten über die Power Platform sicherheitsrelevante Vorfälle passieren (z.B. Datenpanne, unautorisierter Zugriff), müssten Sie wie bei jedem System die entsprechenden Meldewege einhalten (innerhalb 72h an die Behörde melden bei personenbezogenen Daten). Dafür ist es wichtig, Audit-Logs parat zu haben, um so etwas zu untersuchen.
• Security Monitoring: NIS2 betont, dass man kontinuierlich den Sicherheitsstatus überwachen soll. Das heißt, Sie könnten z.B. SIEM-Integration erwägen: Leiten Sie relevante Logs (z.B. Power Platform Admin Log, Azure AD Logs) in ein zentrales Security Monitoring (wie Microsoft Sentinel oder ein anderes SIEM) weiter, wo Alarme definiert sind. Beispiel: Alarm, wenn plötzlich sehr viele API-Aufrufe von einer einzelnen App ausgehen (könnte Indiz sein, jemand missbraucht eine Connector-Verbindung). Oder Alarm, wenn ein neuer Connector in einer sensiblen Umgebung verwendet wird (z.B. auf einmal macht eine App Verbindungen zu einem unbekannten Drittanbieter).

Zusammengefasst: Mit Blick auf NIS2 und allgemein IT-Security müssen Sie die gleichen Prinzipien anwenden wie anderswo: Least Privilege (nur nötige Rechte vergeben), Defense-in-Depth (mehrschichtige Sicherheitskontrollen – z.B. DLP plus Rollen plus Netzwork-Beschränkungen), Monitoring & Response (im Blick haben, was läuft und vorbereitet sein zu reagieren). Die Power Platform bietet hier Hilfsmittel (z.B. Managed Environments Feature, das zusätzliche Governance-Reports, Limits und einen „Panikknopf“ zum Isolieren einer Umgebung bei Verdacht bereitstellt). Es liegt am IT-Sicherheitsteam, Low-Code nicht als „böse unbekannte Box“ zu sehen, sondern als integrierten Teil der IT-Landschaft, der wie jeder andere Service gehärtet und überwacht werden muss. Aber keine Sorge: Microsoft investiert viel, um die Plattform sicher zu machen – Sie müssen „nur noch“ die Konfiguration passend vornehmen und die Nutzung im Unternehmen steuern.

DLP-Richtlinien (Data Loss Prevention)

Im Power-Platform-Kontext sind DLP-Richtlinien ein zentrales Mittel der Compliance. Diese Richtlinien definieren, welche Datenverbindungen miteinander verwendet werden dürfen. Das Ziel: verhindern, dass sensible Unternehmensdaten in unerwünschte Kanäle abfließen. Konkret teilt man Connectoren in Kategorien ein – typisch sind „Geschäftlich“ (Business), „Eingeschränkt“ (Non-Business) und „Gesperrt“:

• Geschäftliche Connectoren: Das sind Datenquellen, die als vertrauenswürdig gelten und mit vertraulichen Daten arbeiten dürfen. Beispielsweise: SharePoint (internes Intranet), SQL Server (Firmendatenbank), Outlook (Firmen-Mail), SAP, Azure Services usw. Wenn zwei oder mehr Connectors in einer App/Flow verwendet werden, die alle in Business Kategorie sind, ist das okay. Man könnte z.B. aus SAP lesen und in SharePoint schreiben.
• Eingeschränkte/Nicht-geschäftliche Connectoren: Das sind tendenziell öffentlich oder Consumer-orientierte Services, wo Unternehmensdaten besser nicht hingelangen sollten. Beispiele: Twitter, Facebook, Dropbox (wenn das Unternehmen es nicht offiziell nutzt), vielleicht auch private E-Mail Dienste wie Gmail. Standardmäßig packt Microsoft viele Social Media hier rein. Wenn ein Flow oder eine App versucht, einen Business-Connector und einen Non-Business-Connector in einer Lösung zu kombinieren, blockiert die Plattform das. Also z.B. ein Flow „Lese Kundendatenbank (Geschäftlich) und twittere die Inhalte (Nicht-geschäftlich)“ wäre verboten – zum Glück 😉. Nur Non-Business untereinander wäre erlaubt (z.B. Gmail zu Twitter – aber wozu bräuchte man das geschäftlich… egal, wäre technisch erlaubt in einer rein Non-Business Umgebung).
• Gesperrte Connectoren: Das sind solche, die komplett unterbunden werden sollen. Sie können z.B. sagen „Dropbox usage ist bei uns per Policy untersagt“ – dann setzen Sie den Dropbox-Connector auf Blocked. Kein Nutzer, auch nicht in einem Flow, kann dann eine Verbindung mit diesem Connector herstellen. Oder Sie blockieren HTTP generisch, was klug sein kann, denn der HTTP-Connector erlaubt beliebige Web-Calls (damit könnten gewiefte Nutzer jede Ziel-URL ansteuern und Daten hinschicken, was man mit DLP in Business vs Non-Business nicht einfangen würde). Viele Unternehmen blockieren auch SQL-Server (On-Premises) falls sie wollen, dass Daten nur via Azure Dienste gehen, etc. Hier sollten Sie mit Security/Governance-Team überlegen: Welche Dienste wollen wir exlizit ausschließen?

Man kann DLP-Richtlinien auf Environment-Ebene definieren oder tenantweit. Typischerweise macht man zumindest eine Standard-DLP für alle Umgebungen. Evtl. differenziert man: z.B. in einer Entwicklungs- oder Sandbox-Umgebung darf man mehr (um zu testen, z.B. Social-Media-Konnektoren), aber in Produktionsumgebungen strengere Regeln. Über Admin Center lässt sich das pro Environment einstellen.

Für die Compliance in EU/DE bedeutet DLP z.B.: – Sie können definieren, dass Dienste, die Daten in Drittstaaten bringen (USA etc.) nur in Non-Business sind oder sogar gesperrt. Z.B. Connector „Twitter“ – wo landen Tweets? Öffentlich in USA. Den also am besten Non-Business. – Oder „Bing Translate“ (das würde Texte zu einem MS-Dienst schicken, der evtl. Cloud-basiert außerhalb EU ist) – falls Sie das kritisch sehen, dann auch Non-Business. So kann kein Flow z.B. vertrauliche Texte via Bing Translate jagen (wäre Datenübermittlung). – „HTTP“Connector wie erwähnt, sollte meist geblockt sein, außer vielleicht in speziellen IT-Umgebungen, weil der Umgehungen erlauben würde. – „Personal OneDrive“ vs „OneDrive for Business“: Oft trennt man, dass Firmen-Onedrive (Business) erlaubt, aber persönliches OneDrive (das der User privat in seinem MS Account hat) blockiert, damit keine internen Daten ins Privatkonto wandern.

DLP Policies sind zwingend, wenn Sie Bürgerentwickler frei werkeln lassen. Sie schaffen damit Guardrails. Die gute Nachricht: Es ist technisch verankert – sprich, selbst wenn jemand versuchen würde, es zu umgehen, die Plattform setzt es knallhart durch. Allerdings: DLP greift auf App/Flow-Ebene, nicht auf Dateninhalt. Das heißt, es klassifiziert nach Connector, nicht nach dem tatsächlichen Datensatz. Sie können nicht sagen „Personaldaten dürfen nur hierhin, und Kundendaten dorthin“ – so granulare inhaltliche DLP macht Power Platform nicht (dafür bräuchten Sie dann eher Information Protection labels etc., was ein eigenes Thema wäre). Aber immerhin verhindert es grobe Datenabflüsse.

Beachten Sie: Copilot / KI Funktionen sind neu – wo fügen die sich hier ein? Momentan laufen z.B. generative KI-Abfragen (wie GPT) über Azure OpenAI Services, die Stand jetzt oft in USA gehostet sind (auch wenn Rechenzentrum EU, das Modell selbst?). Microsoft arbeitet an EU-Instanzen. Trotzdem, wenn Sie etwa Copilot Studio Agents nutzen, fließen bei offenen Wissensfragen evtl. Daten an das generative Modell. Microsoft sagt, sie nutzen diese Daten nicht für Training etc., aber es ist ein Drittservice. Wahrscheinlich wird es dazu kommen, dass man auch generative KI-Calls als „Connector“ im DLP-sinne betrachtet. Heute könnten Sie aus Vorsicht z.B. sagen: Keine vertraulichen Inhalte in den Copilot eingeben, bis klar ist wo’s verarbeitet wird. Hier muss man Policy und Schulung mit Technik kombinieren.

Als Unternehmen in DE sollten Sie DLP-Policies schriftlich festhalten (quasi als Teil der IT-Richtlinie) und den Anwendern kommunizieren: „Es ist untersagt, Applikationen zu bauen, die Daten der Kategorie A über Systeme der Kategorie B versenden…“, aber gleichzeitig eben technisch enforce, damit niemand unwissentlich Mist baut.

Auditierung & Nachvollziehbarkeit

Gerade in regulierten Branchen (aber auch generell guter Practice) braucht man Nachvollziehbarkeit, wer was in einem System getan hat. Die Power Platform speichert zum Glück vieles automatisch mit:

• Audit Logs (Power Platform Admin Center / M365 Unified Audit): Sie können z.B. im Microsoft 365 Compliance Center Abfragen stellen wie „Show all PowerApp activities“ oder „Show Power Automate activities“. Dort sieht man Ereignisse wie App erstellt, App geändert, Flow ausgeführt, Flow fehlgeschlagen, Connectorkennung erstellt etc. Diese Logs können Sie auch exportieren oder in SIEM integrieren. Zum Zwecke der Auditierung (z.B. interne Revision will wissen: Wer hat diese App wann freigegeben und geändert?) sind diese Logs unerlässlich. Sie sollten daher die Audit-Funktion einschalten (in Dataverse kann man pro Tabelle auch Datenänderungs-Audit aktivieren). Beachten Sie aber, dass Audit-Logs nur eine gewisse Zeit gehalten werden – in E5 Plan z.B. 1 Jahr. Für längere Aufbewahrung müssten Sie ins eigene Archiv kippen.
• Versionierung und Change Management: In einem streng auditierten Kontext (z.B. Pharma, validierungspflichtig) will man vllt. jede Änderung an einer geschäftskritischen App dokumentiert haben. Hier helfen ALM und Source-Control (dazu im nächsten Abschnitt mehr) – wenn Sie z.B. jede Version in Git committen, können Revisoren theoretisch Änderungen nachverfolgen. Für sehr streng geregelte Umgebungen kann man vllt. Tools wie Power Apps Application Lifecyle Management mit Lösungs-Checksum etc. einsetzen. Die Plattform hat aber (noch) kein integriertes „Wer hat den Button hier hinzugefügt“ Log – es gibt im Designer version history pro App, aber nicht super detailliert. Daher: definieren Sie Prozesse, z.B. jede Änderung in Prod muss ein Ticket haben, Code (bzw. Low-Code) Review protokolliert etc., falls es wirklich GxP relevant ist.
• Zugriffsnachvollziehbarkeit: Wer hat wann welche App benutzt? Das wird u.a. in Azure AD Sign-In Logs erfasst (App sign-ins). Wenn es relevant ist (z.B. bei externen Nutzer-Portalen: „Hat sich Partner X unsere sensiblen Dokumente angesehen?“), können Sie über Logging das klären. Dataverse hat zudem Record auditing: d.h. wer hat Datensatz X geändert. So kann man bei Datenmanipulationen nachvollziehen, welcher User das war.
• Compliance-Audit-Funktionen: Microsoft bietet in der Power Platform mittlerweile Tools wie „Self-healing DLP“ oder „Tenant-level analytics„, wo man z.B. erkennen kann, wenn jemand viele Fehler produziert oder unsaubere Patterns (das hat eher QA-Charakter). Für formale Audits kann man vorweisen: Die Plattform ist ISO27001 etc., das deckt vieles ab. Interne Audits werden aber schauen: „Habt ihr Kontrollmechanismen?“ – da können Sie vom CoE Starter Kit Berichte zeigen, DLP Configs, Administrationskonzept (z.B. wer darf Umgebungen anlegen). All das sollte in einer Power Platform Governance Doku stehen, die dem Audit vorgelegt wird.

Schließlich: Lizenz-Audit – es gibt ja auch ein Aspekt, dass MS oder interne Revision checkt, ob Lizenzen richtig genutzt werden (nicht Sharing eines lizenzierten Accounts für 5 user etc. – vermeiden!). Aber das ist vertragsrechtlich, lassen wir mal. Wichtig aus Compliance-Sicht: Halten Sie sich an MS Lizenzbedingungen, z.B. keine Produktivnutzung mit Developer-Lizenz – das wäre ein Auditfinding beim Hersteller-Audit (Lizenzverstoß).

In Deutschland gibt es außerdem besondere Anforderungen branchenweise: z.B. GoBD (Aufbewahrung digitaler Unterlagen) – wenn z.B. mit Power Platform steuerrelevante Daten verarbeitet werden (sagen wir Spesenbelege digital erfasst), muss die Lösung GoBD-konform sein (z.B. Belege unveränderbar archivieren, Änderungen protokollieren). Hier muss man je nach Szenario prüfen: Evtl. muss man so etwas mit externen Systemen kombinieren (z.B. finalen Beleg ins DMS archivieren).

Fazit: Mit der Power Platform können Sie Compliance-Vorgaben sehr wohl erfüllen, aber man darf es nicht laufen lassen. Von Anfang an sollten IT und Compliance-Verantwortliche eng kooperieren: Gemeinsam Richtlinien definieren (DLP, Env Strategien), Schulungen geben („Do’s and Don’ts“ für Maker), und Tools wie das CoE nutzen, um Governance sicherzustellen. Im Zweifelsfall gilt: Lieber etwas restriktiver starten und bei Bedarf Freiheiten erweitern, als umgekehrt. Hat man einmal datenschutzwidrige Apps in freier Wildbahn, ist es schwerer einzugreifen. Also, kommunizieren Sie klar, dass die Power Platform Nutzung kein rechtsfreier Raum ist – jede Lösung muss die gleichen Compliance-Standards erfüllen wie offiziell von IT gebaute Systeme. Der Vorteil ist, dass Sie als IT über die Plattform überhaupt erst die Möglichkeit haben, dies durchzusetzen. Ohne sie würden Fachbereiche wild eigen Tools verwenden, wo Sie gar keine Kontrolle haben. Insofern ist die Power Platform sogar ein Enabler für sichere Digitalisierung unter Ihrer Ägide.

6. Best Practices & Architektur

Nachdem wir die Komponenten, Nutzen und auch Risiken beleuchtet haben, stellt sich die Frage: Wie setzt man die Power Platform vernünftig auf? – Hier geht es um Architektur und Best Practices. Wie bei jeder Technologie kann man auch bei Low-Code viel richtig, aber auch einiges falsch machen. Ich berichte hier aus meinen Erfahrungen, was sich bewährt hat in Bezug auf ALM (Application Lifecycle Management), Environment-Strategie, Einbindung von Source-Code-Systemen (GitHub/Azure DevOps), Sicherheit, Datenmodellierung, Skalierbarkeit, Qualität und Kostenkontrolle. Das klingt nach einer Menge – aber keine Angst, wir gehen Schritt für Schritt durch.

ALM (Application Lifecycle Management)

Auch wenn Citizen Developer oft erstmal „drauflos bauen“, sollte man spätestens für wichtige Anwendungen einen Lifecycle-Prozess etablieren. Was heißt das? ALM sorgt dafür, dass Lösungen kontrolliert von Entwicklung über Test nach Produktion gelangen – und dass Änderungen nachvollziehbar und getestet sind.

Grundprinzip: Nutzen Sie die Lösungen-Funktion der Power Platform. Eine Lösung ist ein Container für eine oder mehrere Apps, Flows, Tabellen, etc., den man als Paket exportieren und importieren kann. Die Idee: Entwickler (sei es IT oder Fachbereich) arbeiten in einer Entwicklungs-Umgebung an einer Unmanaged Lösung. Ist eine Version fertig, wird diese Lösung als Managed Lösung in die Test/QA-Umgebung importiert. Dort testen Key User alles durch. Wenn okay, wandert dieselbe Lösung in die Produktions-Umgebung. Vorteil: Die Prod-Umgebung bleibt sauber (nur Managed, kein wildes Editieren), und Sie können Versionen tracken. Auch Upgrades (von v1 auf v2) laufen kontrolliert.

Um das zu erleichtern, gibt es Tools: Azure DevOps Build Pipelines oder GitHub Actions für Power Platform. Microsoft stellt vorgefertigte Tasks zur Verfügung (z.B. Export Solution, Publish to target env.). Damit können Sie einen CI/CD-Prozess aufsetzen, der ähnlich wie bei Softwareprojekten automatisch Lösungen baut, ins Repo packt (im Klartext, z.B. Canvas-App wird zu YAML/XML-Dateien) und ins nächste Stage deployed. Wenn Sie Programmierer im Team haben oder ambitionierte Maker, lohnt es sich, sich damit zu beschäftigen.

Einfacher gesagt: Mindestens sollten Sie manuelle ALM-Schritte definieren. Also: – Keine Entwicklung direkt in Produktion! – Immer in einer Sandbox zuerst bauen, dort auch direkt vom Anwender testen lassen. – Dann in Prod migrieren (idealerweise als Lösungspaket). – Dokumentieren Sie die Releases (z.B. „App v1.3 am 10.11.25 auf Prod importiert – enthält Feature X“).

Wenn’s Probleme gibt, kann man so auch leichter Rollback (managed Lösungen kann man theoretisch deinstallieren -> alte Version rein). In Praxis: man hat am besten ein Backup der Prod-Umgebung vor dem Import, dann kann man notfalls zurück. Managed Lösungen erlauben auch Side-by-side existenz von alt und neu, aber das führt hier zu weit.

ALM umfasst auch Konfigurationsdaten: Z.B. eine App hat vielleicht andere Einstellungen in Prod (andere Verbindungsstrings). Nutzen Sie hier Environment Variables im Dataverse, um pro Umgebung z.B. andere Parameter zu setzen (z.B. E-Mail von Testsystem vs Livesystem). So vermeiden Sie, dass die App nach dem Import noch manuell angepasst werden muss.

Eine weiterer Punkt: Solution Checker & Code Review. Microsoft bietet einen Solution Checker, der per Klick oder Pipeline eine Lösung auf bekannte Probleme scannt (Performance, Accessibility, Security). Lassen Sie den laufen vor Deploy – das holt einige Quality Issues raus. Ein menschlicher Blick schadet auch nicht: Hat der Maker an alles gedacht? Sind Namenskonventionen eingehalten? etc. – Forcieren Sie das bei geschäftskritischen Lösungen.

Zum ALM gehört auch, wie man mit Versionskontrolle umgeht. Das Schöne: Wenn Sie Lösungen als Files ins Git packen, haben Sie Version History. Aber z.B. Canvas-Apps in der Standardumgebung (ohne in Lösung, oder gar mal schnell erstellte flows) haben diese nicht. Daher lieber alles in Lösungen bauen, auch Canvas-Apps, damit es archiviert werden kann. Fortgeschritten: Es gibt Tools, die Canvas-App diffs lesbar machen, aber das geht jetzt zu tief.

Merksatz: Low-Code ist kein No-Lifecycle. – Bauen Sie früh eine ALM-Philosophie auf, sonst werden Sie mit mehreren Apps/Flows irgendwann den Überblick verlieren und es wird schwer, Änderungen sauber auszurollen.

Environments & Environment-Strategie

Environments (Umgebungen) sind die Container in der Power Platform, die Ressourcen trennen. Standardmäßig hat jeder Tenant eine Standardumgebung (oft „Contoso (default)“ benannt), in der alle User Maker-Rechte haben. Das ist gut für Experimente, aber nicht für kritische Lösungen. Daher: Planen Sie bewusst, wie viele und welche Umgebungen Sie brauchen.

Ein bewährtes Modell: – Prod-Umgebungen: mind. eine für Produktive Lösungen. Oft macht man mehrere: z.B. eine Prod-Umgebung pro Abteilung (Finance Prod, HR Prod, Sales Prod), damit jede Abteilung isoliert ihre Apps hat. Oder man geht nach Projekt/Anwendung: Wenn eine Lösung sehr groß ist, bekommt sie evtl. eigene Prod-Umgebung. Environments kosten nichts extra, außer sie haben Dataverse mit viel Speicher (dazu in Kosten später). Aber isolationstechnisch bringen separate Umgebungen viele Vorteile: Rechte können je Env vergeben werden, DLP kann differenziert sein etc. Wichtig: Prod-Umgebungen sollten nur Admins neue Apps/Flows erstellen dürfen (bzw. streng limitierte Maker). Der Normalnutzer dort ist Konsument. So bleibt es kontrolliert.

• Test/Staging-Umgebungen: Für jede Prod idealerweise eine Entsprechung. Also wenn HR Prod existiert, dann HR Test. Darin landen vorab die neuen Versionen zum Testen. Zugänge: Maker + einige Key-User Tester haben rein, aber normale Anwender nicht.
• Dev/Sandbox-Umgebungen: Hier entwickeln die Macher tatsächlich. Oft teilen sich mehrere Teams eine Dev-Umgebung oder jeder hat seine. Das kann variieren. Für pro Abteilung Setup: HR Dev, Finance Dev etc. ODER man erlaubt einigen „PowerUsern“ Developer-Umgebungen. Microsoft hat ja den Developer Plan, wo jeder sich eine persönliche Dev-Umgebung anlegen kann – das ist kostenlos, aber nur der eine User hat dort Vollzugriff. Ist gut, um zu spielen, aber nicht toll für Teamarbeit. Ich empfehle eher Team-Dev-Umgebungen, damit mehrere zusammen arbeiten können.
• Standard (Default) Environment: Am besten definieren: Das ist unsere „Spielwiese“. Dort darf jeder mal rumprobieren mit z.B. Beispiel-Daten, aber es dürfen keine echten Produktivdaten rein. Und überlegen: Möchte ich default DLP streng (um Datenabfluss aus default – wo alle Zugang haben – zu verhindern)? Manchmal sagt man: In Default sind Non-Business Connectors sogar blockiert, um Leute zu zwingen, in einer richtigen Env zu arbeiten, falls sie was „Echtes“ mit Social Media machen müssen.
• Spezial-Umgebungen:
• Teams-Umgebungen: Wenn jemand eine App in Teams erstellt, erzeugt das im Hintergrund eine „Teams-Environment“ pro Team mit mini-Dataverse. Das ist speziell, Sie können aber diese Option erlauben oder in Tenant-Settings abschalten. Wenn Sie Governance streng wollen, schalten Sie es aus (denn sonst kann jeder in Teams eigen Dataverse anlegen). Wenn Sie es anlassen, behalten Sie Blick via CoE-Kit.
• Managed Environments: Das ist ein Flag, das Sie pro Env setzen können, um zusätzliche Gov-Funktionen zu aktivieren (Makers Welcome Dashboard, Limits an Share-Users definieren, etc.). Überlegen Sie, es für Prod-Umgebungen an zu machen, um z.B. automatische App-Lifecycle (schläfrige Apps markieren/löschen nach X Monaten) zu nutzen.
• High capacity Env: falls Sie z.B. durch Dynamics oder Fabric Integration so genannte „Pay-as-you-go“ oder „Premium capacity“ Umgebungen haben, die z.B. auf dedizierten SQL laufen – das wäre nur wenn extrem gefordert. Normal eher nicht.
• Namenskonvention: Geben Sie Umgebungen klare Namen und am besten Suffixe wie „-DEV“, „-TEST“, „-PROD“. Das sieht man in den URLs / DropDowns, und verhindert Verwechslungen. Nichts schlimmer als aus Versehen in Prod fließen, weil man Fenster verwechselt. Also eine HR Prod könnte „HR-Prod (Prod EU)“ oder so heißen, Test analog.
• Region: Standard wählt oft die tenant region. Falls Sie globales Unternehmen sind, kann es Sinn machen, mehrere Environments in verschiedenen Geographien zu haben (z.B. eine in EU für EU-Teams, eine in US etc.), um Latenz zu verringern und im Zweifel Datenregion zu steuern. Für die EU-DSGVO Thematik belassen Sie EU-Kundendaten in EU-Umgebungen. Microsoft erlaubt Region pro environment.
• Security pro Environment:
• Weisen Sie Security Groups oder Azure AD-Teams zu. Z.B. definieren Sie Gruppen „PowerPlatform_HR_Maker“ -> hat Environment Admin oder Maker in HR Dev,
• „PowerPlatform_HR_User“ -> hat nur User (nutzer) in HR Prod (so er kann Apps ausführen, aber nichts bauen). Machen Sie NICHT „Everyone is maker“ außer in default als sandbox. So behalten Sie Kontrolle wer in Prod Umgebungen rummacht.

Mit so einer Struktur vermeiden Sie den „Alles in einem Topf“-Salat. Es erleichtert auch Support: z.B. wenn Prod kaputt, kann man Test isoliert zum debuggen verwenden. Oder wenn man Migrationen testet, in Dev rumprobieren.

Source Control: GitHub / Azure DevOps

Ich hatte es beim ALM schon angedeutet: Quellcodeverwaltung macht auch bei Low-Code Sinn, zumindest für kritische Anwendungen oder solche, an denen mehrere Leute arbeiten. Sie können ein Git-Repository (GitHub oder Azure DevOps Repos oder Bitbucket etc.) nutzen, um z.B. den ausgepackten Stand einer Lösung zu versionieren. Microsofts Power Platform Build Tools können „Solution Packager“ ausführen: der packt alle Customizations (Apps, Flows, etc.) in Dateien, die in ein Repo commitbar sind. So hat man eine History und kann z.B. einen Pull Request Workflow aufsetzen: d.h. ein Maker macht Änderung, packt Solution, PR, jemand reviewed DIFF im Repo (ja, man kann Canvas-App JSON diffen, man sieht z.B. Formeln geändert). Nach Approval merged es, Pipeline schiebt es in Test etc.

Das ist aber Hardcore-DevOps und noch die Ausnahme in vielen Firmen. Wenn Sie kapazität haben, lohnt es aber mittelfristig, weil es Professionalität reinbringt und vor allem Integration mit pro-code-Projekten erlaubt. (Bsp: Ein Team baut teils in C# in Azure, teils in Power Apps. Im Repo kann man die Pipeline orchestrieren, dass nach dem Azure deploy gleich noch der passende Flow in PP aktualisiert wird etc.).

Für den Einstieg reicht, sich bewusst zu sein: Lösungen exportieren = Backups. Speichern Sie Releases irgendwo sicher (zur Not manuell in SharePoint). Schlimm wäre, wenn ein Maker etwas löscht und Sie keine Kopie haben. Die Platform hat kein globales „Papierkorb“, je nach Objekttyp. (Apps haben Versionen, aber Flows? muss man mühsam reimportieren falls weg).

Sicherheit (Best Practices)

Vieles zur Sicherheit haben wir im Compliance-Teil schon behandelt (DLP, Authentifizierung etc.). Hier noch einige praktische Tipps: – Rollen & Berechtigungen: Nutzen Sie Dataverse-Sicherheitsrollen, falls Sie Dataverse einsetzt. Z.B. definieren Sie eine Rolle „Abteilungs-App Benutzer“, die nur Datensätze der eigenen Abteilung sieht. Weisen Sie diese rollenspezifisch zu. So verhindern Sie, dass z.B. in einer globalen App jemand Daten einer fremden Einheit sieht. – Keine Hartcodierung von Credentials: Nutzen Sie Verbindungen und Connection References statt z.B. in einem Flow HTTP-Header mit API-Keys zu verwenden (wenn möglich). Wenn API Keys sein müssen, speichern Sie sie sicher (evtl. in Azure Key Vault und via connector abrufen). – Service Principals: Wenn Flows automatisch laufen und Systemzugriff brauchen, erwägen Sie den Einsatz eines Dienstkontos / Service Principal statt einer Person. Hintergrund: Flows laufen standardmäßig unter dem Kontext des Erstellers oder eines eingebetteten Connectors. Wenn der Ersteller die Firma verlässt und sein Account gelöscht wird, stehen Flows gern. Besser: richten Sie ein technisches Konto ein (z.B. powerautomate-runner@firma.de) und lassen Sie geschäftskritische Flows über diese Verbindungen laufen. Oder noch besser, nutzen Sie die neuen Managed Identities (in Preview/GA in PA?), wo Flows sich ohne gespeicherte Credentials an Azure AD ausweisen können. – Beschränkung der Maker: Seien Sie nicht zu offen, wer alles produktiv entwickeln darf. Definieren Sie z.B. Citizen Developer pro Fachbereich und schulen Sie diese. Nicht jeder Azubi sollte in Prod-Umgebung basteln dürfen, ohne Guidance. – Audit & Log: Richten Sie Alerts in CoE oder Admin Center ein für verdächtige Aktivitäten (z.B. „App shared with ‚Everyone'“). Solche automatische Flows kann man im CoE-Kit finden. – Conditional Access: Wenn notwendig, setzten Sie Policies wie „Zugriff auf Power Platform Apps nur aus Firmennetz oder mit Compliant Device“. Es gibt App-ID Filter in CA: Man kann speziell Cloud App „PowerApps“ oder „Flow“ regeln. Aber Vorsicht: Das kann tricky sein, weil Flows können eigeninitiierte Cloudcalls machen (die CA hat nur greift wenn User interaktiv). Trotzdem, definieren Sie falls relevant. – Sicherheitsupdates: Microsoft aktualisiert Plattform automatisch. Aber prüfen Sie, falls Sie z.B. On-Premises Gateway im Einsatz haben, dass dieses immer aktuell gehalten wird (die Software updated alle paar Monate; veraltete können Sicherheitslücken haben). – Least Privilege: Geben Sie Administratorrechte nur wenigen. Setzen Sie lieber granular: z.B. Environment Admin reicht, muss nicht gleich global Admin sein. Und an Maker nur die benötigte Berechtigung (Umgebung Maker, nicht global). – Datenverschlüsselung: Dataverse verschlüsselt at-rest ohnehin. Falls super sensitive: Es gibt Customer Managed Key Option (dann können Sie eigenen Schlüssel verwenden). Ist eher heavy, nur falls Compliance es erfordert. – Labeling: Wenn Sie M365 Information Protection Labeling nutzen, schauen Sie, dass auch in Power BI und co entsprechende Sensitivity Labels auf Reports gesetzt werden – das geht ja, dann wird es beim Export z.B. als vertraulich markiert. In PowerApps gibts so was noch nicht nativ.

Kurzum: Denken Sie an Low-Code wie an High-Code in Sachen Security. Was dort gilt (Zugriffskontrolle, Input-Validation etc.), gilt auch hier – nur dass oft vieles schon vom Service gehändelt wird. Z.B. brauchen Sie sich um SQL-Injection kaum sorgen, weil Parameter eh via API sanitized fließen. Aber Sie sollten trotzdem prüfen: Validate user input in Apps (z.B. jemand könnte versehentlich Sonderzeichen eingeben, die Query sprengen, also am besten Dropdowns statt Freitext wo möglich usw.).

Datenmodellierung

Low-Code hin oder her: Ein schlechtes Datenmodell rächt sich auch hier. Zeit also für die inneren Werte Ihrer Apps: Wie gestalten Sie Tabellen, Beziehungen und Co.?

• Wahl der Datenquelle: Überlegen Sie strategisch: Soll die App-Datenhaltung in Dataverse liegen oder in einer anderen Quelle? Dataverse ist ideal, wenn:
• Sie relational komplexere Daten haben,
• Sie Business-Rules, Workflows auf Datenebene brauchen,
• Oder wenn Daten von mehreren Apps geteilt werden sollen (z.B. eine zentrale Kundentabelle für viele Apps).
• Und natürlich, wenn Sie Premium-licensing ohnehin haben. Falls aber Ihre Daten schon in z.B. SharePoint gut aufgehoben sind (eher flache Listen bis 100k Einträge), kann man eine Canvas-App auch auf SharePoint-Liste bauen. Das hat Null Extra-Kosten (SharePoint ist in M365 drin) – viele Firmen starten so (z.B. Ideensammlung App, etc. via Lists). Aber wenn es skaliert, stößt man an Grenzen (z.B. 5000er Schwelle, Delegation, Performance). Für strukturierte, unternehmenskritische Daten empfiehlt sich Dataverse. Für prototypische oder Content-lastige Sachen (z.B. Event-Anmeldungsliste mit <2000 entries) geht SP/Liste. Excel als Datenquelle: bitte nur zu Demo-Zwecken, niemals für echte Multiuser-App – wird schnell Chaos, weil Excel concurrency etc. begrenzt. SQL-Azure: Option, falls Sie bereits ein Azure SQL haben und Teams/Apps drauf zugreifen sollen. Das ist Premium-Connector (Lizenz nötig). Aber vllt. will man es wegen vorhandener procs. Ist okay, aber dann müssen Sie die Security in SQL managen etc. Der Vorteil Dataverse: out-of-box security layer.
• Tabellenstruktur: In Dataverse Modellieren ist ähnlich wie in einem Datenbank-ER-Modell. Überlegen Sie Entities (Tabellen) pro „Objekt“. Vermeiden Sie Redundanzen (lieber Lookups/Beziehungen). Nutzen Sie Choice-Felder (Picklists) statt Strings für vorhersehbare Werte (für Konsistenz). Bei SharePoint: da ist man limitiert (One-to-Many relations sind mühsamer), aber kann mit Lookup-Spalten arbeiten. Achten Sie auf Naming: Name der Tabelle und Spalten nach Unternehmenskonvention (Dataverse hat Display Name vs SchemaName – Schema besser nicht ändern nach Erstellen). Legen Sie Schlüssel und benötigte Felder sinnvoll fest (Dataverse hat required attribute Option).
• Datenvolumen: Schätzen Sie, wieviel Daten pro Zeiteinheit kommen. Dataverse verkraftet viele Millionen Datensätze technisch, aber Ihr Speicher-Lizenz vielleicht nicht (teuer). SharePoint Listen würde ich < 30k empfehlen, jenseits wird’s lahm im Abfragen. Wenn es um Big Data (hundert Millionen) geht, ist Power Platform nicht das primäre Storage (dann lieber Azure DataLake / Synapse – man kann aber z.B. per Synapse Link Dataverse <-> Data Lake synchronisieren, best of both worlds: operational data in DV, analysis in lake).
• Performance & Delegation: In Canvas-Apps ein wichtiges Konzept: Delegation. Heißt, dass Filter/Abfrage-Operationen möglichst an die Datenquelle delegiert werden. Standarddelegation in Dataverse, SQL, SP: ca. 2000 Zeilen Limit, wenn Filter nicht delegierbar, dann App zieht nur die ersten 500/2000 records und filtert client-side (Gefahr falscher Ergebnisse). Also: Versuchen Sie, Formeln in Canvas so zu bauen, dass sie delegierbar sind (Verwendung von Filter-Funktionen mit straightforward conditions, vermeiden von AllRecords-Auslese). Wenn das nicht geht und Daten viel, muss man Workaround (z.B. Aufteilung in Batches). By designing your data well (viele Spalten filterbar indexiert, etc.) helfen Sie der Performance.
• Option Sets vs separate Tables: Dataverse hat global Option Sets (Choices) – nutzen, wenn z.B. „Status“ mit fixen Werten. Wenn Werte aber vom Fachbereich änderbar sein sollen (z.B. eine Liste von Projekttypen die man mal ergänzen will), dann lieber in eine separate Konfigurationstabelle packen, die man via App pflegen kann. Das sind architektonische Entscheidungen.
• Datenintegration: Überlegen Sie, ob Daten synchron/fließen müssen zwischen Systemen. Z.B. pflegt man Kundendaten in CRM (Dynamics), will sie aber auch in einer Power App. Dann besser live per Connector lesen statt Dublette in DV anlegen. Weniger Kopien = gut. Wo Kopien nötig (z.B. nightly import), kann Power Automate oder Dataflows (Power Query integrated in PP) genutzt werden. Dataflows sind toll, um z.B. aus SQL nach Dataverse Table periodisch zu laden (transform inkl. mapping). Diese laufen serverseitig und sind effizienter als manuell Flow record-by-record.
• Datenqualität: Legen Sie Business-Regeln an, wo möglich: In Dataverse kann man z.B. eine Regel definieren „Wenn Feld X = ‚Ja‘, dann mache Feld Y Pflicht oder setze Wert Z.“ Solche Logik kann Verarbeitungsfehler vermeiden. Überlegen Sie Code-Komplettheit Checks: Flows können vor Insert prüfen, ob z.B. E-Mail Format okay (gibt auch vordefinierte Funktionen). Der Vorteil von Dataverse: Hier kann man auch serverseitig Plugins oder Real-Time Workflows definieren (im Pro Dev Teil mehr) – z.B. „Beim Erstellen eines Datensatzes immer Duplikat-Check machen“. Also, Mechanismen nutzen, um Mist in der DB zu vermeiden. Das erspart später Bereinigung.
• Skalierung / Partitionierung: Falls Sie sehr viele Daten haben, überlegen Sie Partitionierung. Dataverse speichert in SQL mit Partition keys (glaube orgId je env, intern). Sie haben nicht viel Einfluss, aber Sie können z.B. Archive-Mechanismen vorsehen: Ältere Daten in separate table archivieren (Lightning, table per year?). Oder In Power BI: je nach Modell, dimension table outsourcen etc. Das sind advanced topics, für die meisten < millionen Datensätze muss man nicht sofort daran. Achja: Attachment handling: Dataverse Standard file store 2GB pro user license, kann aber große attachments (max 128MB per file). Wenn Sie massig attachments (Fotos, PDFs) erwarten,
• a) Planen Sie den File Storage (kann man add-ons kaufen),
• b) evtl. hybride Lösung: speicher Files in SharePoint (billiger Speicher) und nur Link in Dataverse. Das Spart DV space und Kosten. Man kann das via Flow machen: On file add in DV -> copy to SP -> remove or link. Kommt auf Use-case an; recht oft mixen Firmen: Dataverse für Strukturdaten, SharePoint for heavy files.

Zusammengefasst: Low-Code verzeiht manches beim Start, aber nicht im Dauerbetrieb. Ein durchdachtes Datenmodell ist das Gerüst, auf das sich Ihre Apps stützen. Nimmt man es auf die leichte Schulter, hat man später Performanceprobleme, Datensilos oder ein Refactoring-Drama. Also investieren Sie ruhig am Anfang ein paar Stunden in die Modellplanung (vielleicht mit einem Datenarchitekten zusammen, falls vorhanden) – das zahlt sich aus.

Skalierung

Ich habe einige Skalierungsthemen schon angerissen, aber betrachten wir es systematischer:

• Anzahl Benutzer:
• Power Apps: Canvas-Apps laufen clientside (im Gerät), holen Daten via connectors. 100 gleichzeitige Benutzer, die je 100 Datensätze abrufen, sind in Summe 10k calls, was okay ist, aber man muss auf Limits (API calls pro user) achten. Pro User Plan hat ~40k calls/24h – 100 user = 4 Mio calls theoretisch. Das müsste man verteilen. Bis zu einigen Tausend Nutzer habe ich schon Canvas-Apps gut funktionieren sehen. Für >10k daily user skaliert man besser mit multiple Apps oder re-think (vielleicht ein Portal (Power Pages) oder D365).
• Model-Driven (Dataverse) Apps sind serverrendered, skalieren tendenziell besser mit vielen Nutzer, da Query heavy lifting am Server.
• Testen Sie, falls Sie Hunderte User erwarten: Es gibt Tools wie Power Apps Load Test (Community), um Simulated load to app.
• Power Automate:
• Cloud flows: Standard Flow concurrency = 1 (d.h. ein Flow Instanz pro Trigger in sequence, es sei denn, man aktiv. erhöht concurrency). Also wenn z.B. ein Trigger „on create record“ bei 100 gleichzeitigen creates, die Flowjobs landen in queue. Ggf. concurrency auf 5 oder 50 hochsetzen, aber Achtung: Kann Last auf System erhöhen.
• Also mechanisch: Flows for mass processing -> Partition tasks in parallel flows oder use Logic Apps (skaliert dynamic).
• Throughput Limits: Flow runs per 5 Minuten: Each license type hat limit (Power Automate per user ca. 20 Flows/5min?). Aber man hat so entkoppelt, dass normal business flows nicht an Decke stoßen. Wenn doch (z.B. IoT scenario?), dann vllt. Alternativen (Azure Functions or Logic app).
• RPA bots: Skalieren durch parallele Bots. Also 1 Bot = 1 VM per license. Für Last = kaufen mehr Bot licenses.
• Power BI:
• Im Pro License Modell, jeder Nutzer Query hat 1 GB Memory Limit etc. Das reicht oft, aber wenn DataSet sehr groß (Import >1GB), braucht Premium (Kapazität oder PPU).
• Premium Kapazitäten kann man höhere Memory, größere dataset (bis 400GB etc.). Und man kann User concurrency besser managen (Max cores etc.).
• Also falls Dutzende gleichz. das selbe Dashboard kicken, Premium Abo recommended.
• Fabric allows autoscaling to some degree ($ etc. on azure, optional).
• Dataverse:
• Hat API-rate limits pro user und per environment (~80k/5min per env?). In normal usage selten erreicht. Aber Bulk integrations sollten besser mit Data Import Service oder Dataflows gelöst werden als via Flow, um Limits zu umgehen (diese Tools nutzen behind scenes Service user with high quotas).
• Wenn Daten/Transaktionen extrem, kann man an ein Dedicated capacity (was D365 uses behind scenes) denken, aber Standard reicht meist.
• Performance Tuning:
• For Apps: Use Collections to cache data that is static (like reference lists) rather than repeatedly query.
• Use delegation and indexing in data source for quicker filter.
• If working with large sets, consider using Virtual Entities (Dataverse feature where data remains in external store but surfaced in DV as if internal).
• For flows: shorten steps, avoid unnecessary loop (some novices do endless loops, meltdown engine). Provide good trigger filters (so flows not triggered unnötig).
• Possibly break complex flows into multiple smaller flows (modular, triggered by others) to reuse and also easier scaling by distributing load.
• Quality & Governance interplay: A well-architected solution rarely hat scaling surprise. Ungeplante scaling issues sind oft Indikator, dass man was unsauber gebaut hat (z.B. Flow schleife 1000x pro record vs BulkOperation).
• Always ask: Is there a built-in better way? Eg. want to update 100 records -> use Dataverse „Relational action“ vs flow loop.

Qualitätssicherung

Qualität bei Low-Code ist tricky, weil es schnell was „funktioniert“ zusammengeklickt ist. Aber um Professionalität zu erreichen: – Naming Conventions: Legen Sie Konventionen fest: z.B. Prefix für elemente (in Canvas: lbl_Name for label, txt_Input for text input etc., in flows: good descriptive names for actions, not just „Initialize variable 3“). Das hilft, dass jeder sich zurechtfindet. Tools wie CoE-Kit bieten ein Canvas App Code Review Tool (Canvas App Checker) der checkt Nomenklatur. – Kommentare & Doku: Encourage Maker to comment formulas (gibt in Power Fx Möglichkeit mit / comment /). In flows kann man Scope Container nutzen und Labeln, das macht es lesbarer. – Testing: – Für Canvas Apps: Es gibt eine „Test Studio“ feature, wo man Test Cases definieren kann (Record user actions, expected outputs). Das wenige machen, aber existiert. Kann man für mission critical app einsetzen (so eine art UI test). – Für flows: Kein direct test harness, aber man kann flows debug-run und check outputs. Wenn Sie dev/test env haben, das dort tun, in Prod dann if else avoid needed? You might simulate input triggers. – UAT: Machen Sie Abnahme-Tests mit Endanwendern, dokumentieren Sie die. – Performance-Tests: Mach mal Lasttest, wie reagiert App mit X Data. – Peer Review: Etablieren Sie vllt. ein Gremium (Power Platform Board), wo jemand vom CoE oder erfahrener dev dem Citizen Dev über die Schulter schaut bevor go-live. Das als Mentoring verstehen, nicht Polizei. So lernt Maker und Fehler werden vor Prod korrigiert. – Solution Checker: Schon erwähnt, pflicht vor Release. Findet z.B. in flows: „Loop could cause performance issues if >5000 items“, or „Canvas control not accessible“. Fix die findings, oder begründen wieso Ignorieren. – Accessibility: A quick note – eine qualitativ gute App sollte barrierefrei sein (gerade im öffentlichen Sektor oft gefordert). Canvas Apps: PowerApps ermöglicht Screen Reader labels etc., Solution Checker flagged missing accessible names. Nehmen Sie das ernst, das zeugt von Qualität, auch wenn man interne apps macht – kann mal Kollege mit Seheinschränkung da sein. Power BI: hat auch Accessibility features (Focus mode, Alt Text on charts). – User Training & Feedback: Ach, oft vernachlässigt: Selbst beste App hat no value wenn user es nicht verstehen. Machen Sie kurzes Manual oder in-App Hilfetexte (Tooltips). Holen Sie nach Launch Feedback (CoE hat Feedback Collector app). Dann iterieren Sie v2 mit den Verbesserungen. Low-Code’s advantage: schnell adaptieren.

• Monitor in Power Apps: There’s a tool „Monitor“ that allows you to see events and network calls of an app live. If user complains „App slow when I click X“, you can run Monitor while replicating scenario, it might show e.g. „non-delegable query, returned partial data“ or „call took 5s“, thus pinpointing cause. Use this as debugging tool for quality improvements.
• Automatisierte Governance-Checks: CoE Starter Kit hat flows, die z.B. neuen Apps scannen auf bestimmte Patterns (like connection to forbidden source? or usage of service account?). Implement or augment those to keep an eye on quality.
• Continuous Improvement: Im CoE definieren: Apps sollen mind alle X Monate reviewt werden: Brauchen wir noch? laufen sie gut? Hat sich Business Prozess geändert, App muss mit? So bleibts qualitativ up-to-date, nicht abhelfert.

Kostenkontrolle

Über Lizenzen reden wir im nächsten Abschnitt, aber aus Best-Practice-Sicht: – Lizenz-Zuordnung: Führen Sie ein Verzeichnis, wer welche PP Lizenz hat (CoE Starter Kit erfasst das). Rein aus Kostensicht: Wenn jemand das Unternehmen verlässt oder App nicht mehr nutzt, entziehen Sie die Lizenz, um Geld zu sparen. Mit CoE Report erkennt man z.B. „User X hat Premium license, aber hat in 90 Tagen keine App geöffnet“ -> kann man hinterfragen, evtl. entziehen oder fragen ob noch braucht. – Pay-as-you-go: Evaluieren Sie, ob für sporadische oder unbekannte Nutzung sich Payg via Azure lohnt. Vorteile: Bis Freed-tier Azure Sponsors? Eher fürs Protpying gut. If usage stable and heavy, fixe Lizenzen oft günstiger. CoE kann (in preview 2025?) auch tracken Azure billing for flows and apps. Also, wer’s nutzt, monatlich sichten: passt es? oder switch to Prepaid license? – Kostenstellen: Es ist sinnvoll, die Kosten transparent auf die Verursacher umzulegen (Showback/Chargeback). Weisen Sie Lizenzen oder Azure-Konten einer Abteilung zu. Wenn IT budget knapp, aber Fachbereichslust groß, sagen Sie: „Kein Problem, HR zahlt die 10 extra Lizenzen aus ihrem Budget.“ – Das motiviert auch, dass Fachbereiche schauen, effizient einzusetzen. Im CoE Kit kann man Richtig Kennzahlen pro Dept. muster, KPIs etc. – Komplexe Queries = Kosten?: Bisher MS hat usage-limits aber keine „cost per run“ (außer payg). Jedoch, achten Sie auf Power Automate API Calls: Connectors like HTTP to external might incur separate costs (z.B. calling Azure OpenAI in flow -> das wird azure usage cost, nicht PP license). Also, wenn Flows auf externe Dienste zugreifen, trackt das dort evtl. Kosten (z.B. Azure cognitive service). Ebenso, Power BI fabric usage beyond capacity auto-scale will do Azure consumption charges. So know your architecture if any such events cause extra charges, and monitor via Azure cost mgmt. – Entwickler vs Prod Lizensen: Developer Plan ist free, aber not for prod. Also nicht in Versuchung, Prod-Solution in Dev Plan environment zu belassen, um Lizenz zu sparen -> Verletzung Terms und risk (Plattform isn’t backed up as robust in dev plan, I think). Besser: Real Prod environment with proper licensing. Spart euch Ärger mit MS Audit.

• SKU Optimierung: Sichten Sie regelmäßig, ob es neue Lizenzangebote gibt, die günstiger für Ihr usage pattern sind. Microsoft ändert gerne. (Z.B. promotions, capacity offers). 2025 gibt es „Power Apps Premium mit 2000 seats minimum“ für 11,20€ anstatt 18,70€. Falls Sie so viele user haben, go for it. Oder „Power Automate Process“ vs „Per User“ abwägen, je nachdem wie viele Flows vs. user man hat. Später mehr, aber der Tipp: Bleiben Sie up-to-date, um nicht unnötig zu viel zu zahlen.
• Kostenüberwachung: Ein heikler Punkt: „Citizen Dev bastelt Flow, ruft 1000x am Tag einen externen Webservice an, was pro Call was kostet.“ Der Citizen ist sich Kosten implikationen evtl. nicht bewusst. Daher:
• Machen Sie Sensibilisierung: „Achtung, wenn ihr Flow E-Mails verschickt via MailChimp, kostet uns das im MailChimp plan“ etc.
• Setzen Sie Limits: Z.B. in Managed Environment kann man „Max flow runs per day“ togglen. Also falls jmd. aus Versehen Endlosschleife baut, wird es begrenzt.
• Im CoE Monitor „Top 10 flows by action count“ – check if legitimate or runaway.
• Trial vs Prod: Users can get Trial licenses easily (Power Apps 30 day trial) – an Admin should decide, ob man das zulässt. Standard: Trials allowed, but convert to paid needed after 30 days or ext. If uncontrolled, a dept might rely on trial and stuck when expiry. You as Admin see in PPAC who has Trial. CoE can alert on nearing expiry, to either buy license or stop usage.

Im Kern: Transparenz & Governance sind die Mittel gegen böse Überraschungen in der Kostenstelle. Die Power Platform kann viel, aber sie ist kein Freemium-Selbstläufer – es gibt real costs. Mit den richtigen Kontrollen bleibt das jedoch im Rahmen und vor allem vorhersehbar planbar, statt hinterher „böses Erwachen“.

7. Administration & Betrieb

Sie haben nun fleißig geplant, entwickelt und vielleicht erste Lösungen live – aber wer verwaltet und betreibt das Ganze nun? Gute Frage! Die Administration der Power Platform und der Betrieb (im Sinne von Support, Wartung, Weiterentwicklung) sind wesentliche Komponenten des Gesamtbilds. Hier ein Überblick, wie Sie Ihren Tenant konfigurieren, welche Tools (z.B. CoE Starter Kit) Ihnen helfen, wie Sie Vorlagen/Standards definieren, wie der Lifecycle im Betrieb gemanagt wird und wie ein Supportmodell aussehen kann.

Tenant-Einstellungen und Governance im Admin Center

Als Tenant-Admin (meistens jemand aus der IT, M365-Admin etc.) sollten Sie zunächst im Power Platform Admin Center alle relevanten Einstellungen prüfen. Hier einige wichtige:

• Umgebungs-Einstellungen: Pro Environment können Sie Dinge regeln, z.B. ob Copr-* (noch mal) COPILOT??? War unten. -> Hier ging’s um Tenant Settings:
• Creation of Trial/Dev Environments: Standardmäßig kann jeder User eine Developer-Umgebung erstellen (via Developer Plan) und Trial-Umgebungen (die 30 Tage halten) anlegen. Wollen Sie das? Wenn Sie streng sind, schalten Sie es ab bzw. erlauben es nur bestimmten. Es gibt toggles: „Everyone or only admins can create new environments“. Evtl. setzen Sie „only admins“ – dann haben Sie Ruhe, aber Fachbereiche müssen anfragen wenn neue env brauchen, was ja ok für Prod usage. Developer Plan Umgebungen sind von dieser Setting ausgenommen, aber man kann Developer Plan sign-up tenantweit deaktivieren, falls gewünscht.
• Datenschutz-Notizen: Im Tenant kann man definieren, ob Nutzer die AI-Features (wie Copilot) nutzen dürfen. In 2025 hat Microsoft extra Schalter: „Allow use of Copilot (Yes/No)“. Wenn man Bedenken hat (Daten an AI), kann man es bis Klärung Off lassen.
• Sharing-Einschränkungen: Standard: Ein Maker kann eine App mit „allen authentifizierten Benutzern“ teilen (quasi Org-weit). Will man das zulassen? Kann gut sein (z.B. News-App für alle). Aber es kann auch Chaos geben (plötzlich hat jeder zig Apps im All Apps Katalog). In Managed Environments kann man das granular regeln: „Maximale Anzahl Empfänger pro App Share = X“ oder „Nur bestimmte Security Groups als Publikum“. Überlegen Sie Richtlinien: Evtl. soll nicht jede Bastel-App global gehen. Man kann jedoch organisch sehen: CoE-Kit listet Apps, die Org-wide shared sind – kann man dann reviewen. Tenant Setting „Block Everyone as share“ existiert glaub ich nicht global, aber per env kann man restriktiv Rechte setzen (z.B. in Prod env nur Admin darf sharen).
• Templates & Features: Microsoft bietet in Power Apps Portal viele Template-Apps zum Installieren, und auch die Integration in Teams (Apps in Teams adden) etc. Es gibt Tenant toggles „Allow users to download Template apps“ – kann man Off machen, falls man will, dass nur eigen dev apps.
• Integration-Einstellungen: Z.B. „Allow Power Apps to use dynamic content with Teams messages“ etc., lauter so Kleinigkeiten. Durchsehen und nach Bedarf togglen.
• Data Policies (DLP): Wie im Compliance-Teil, definieren Sie im Admin Center DLP policies. Das ist das Governance-Werkzeug. Legen Sie initial mind. eine policy an, die heikle connectors in „non-business“ oder „blocked“ packt. Und weisen Sie alle (oder bestimmte) Umgebungen zu. Sie können auch z.B. unterschiedliche Policies: Prod Umgebungen sehr streng, Dev Umgebungen liberaler. Planen Sie das gut, es ist wichtig und später änderbar, aber wenn 100 flows schon combos nutzen, die dann verboten werden, meckern die. (Man muss dann flows anpassen).
• User Licenses: Im M365 Admin Portal verwalten Sie Lizenzen, aber hier Admin Center können Sie z.B. Analytics sehen, welche Lizenzen wie genutzt werden. Halten Sie auch die „Capacity“ im Blick (Menü: Resources -> Capacity), dort sieht man Dataverse Storage belegt, limit und wie viel zugekauft/ included. Rote Balken drohen? Dann aufräumen oder zubuchen.
• Updates & Wave Settings: Falls Sie Dynamics 365 im Boot, kennen Sie Release Waves (halbjährlich). Im PP Admin Center kann man pro Environment festlegen, ob auf nächste Wave schon updaten (Early) oder Standard Zeit (General Availability). Wählen Sie „Standard“ für Prod, „Early“ für Dev to test new features early. Das Planen ist v.a. relevant falls ein Breaking Change kommen würde (selten). Schauen Sie Release Plan notes, test in dev, wenn ok, then in Prod auto (man hat eh Deadlines).
• Region & Multi-Geo: Wenn Sie Multi-Geo Tenant (z.B. Exchange in EU + US), PP admin center hat multi region capacity stuff – falls relevant, hier entscheiden wo environment residiert. For EU companies, likely all in EU region anyway.
• Azure AD & Permissions:
• Legen Sie Gruppen an für env Admins etc. Spart Einzel-Zuweisung.
• Machen Sie eventuell Privileged Access for environment admin via Privileged Identity Management (PIM). Z.B. Prod CoE Admin nur via JIT Elevation falls needed, so Minimierung ständige Admins.
• Service Principals: Create SPNs for using in DevOps pipelines or in flows (some connectors allow SPN auth e.g. Graph API calls etc.). Manage their secrets in Key Vault.

Center of Excellence (CoE) Starter Kit

Ich erwähnte es zig Mal: Das CoE Starter Kit ist ein von Microsoft bereitgestelltes Toolkit für Governance und Admin. Es ist im Prinzip eine Sammlung von Power Apps, Flows, Power BI Reports und Dataverse-Tabellen, die zusammen ein „Cockpit“ ergeben, um die Power Platform im Unternehmen zu verwalten.

Wesentliche Bestandteile: – CoE – Core Components: Flows, die regelmäßig den Tenant scannen: Welche Environments gibt es? Welche Apps, Flows, Connectors, Benutzer, Lizenzen etc.? Diese schreiben die Infos in Dataverse Tabellen (in einer dedizierten „CoE“ Umgebung). So hat man eine inventarisierte Übersicht. – CoE – Governance Components: Flows, die z.B. automatisch E-Mails verschicken: „Hallo Maker, deine App X wurde 90 Tage nicht genutzt – bitte entscheide ob weiter behalten oder wir archivieren.“ Oder „Neuer Connector Y in Environment Z wurde erstellt – Admin wird informiert“. Also Mechanismen, um Compliance quasi zu enforcen und Nutzer einzubinden. – CoE – Nurture Components: Kulturelle Seite: Power Apps „Ideen“ App, „Challenges“ (Hackathon mgmt), Newsletter generierung für PP Community etc. Hilft, eine Maker-Community aufzubauen intern (Tipps, Awards etc.). – CoE – Theming & Templates: Da gibts ne theming App wo man corporatedesign theme definieren kann, Maker können abrufen. Und eine „App Template Gallery“ wo man BestPractice-Sample apps (z.B. Urlaubsantrag) intern als Vorlage bereitstellt. – CoE Dashboard: Schickes Power BI mit Kennzahlen: #Apps per Dept, Growth over time, Top Makers by AppCount, etc. Perfekt für mgmt-reporting „unser Citizen Dev adoption soared by 20%“.

Die Einrichtung vom CoE Kit ist etwas Arbeit, aber lohnt sich. Typisch richtet man eine dedizierte CoE-Environment ein (mit Dataverse), installiert dort die managed Solution vom CoE (download via MS), passt in einigen Flows Parameter (Tenant ID etc.), und schaltet Flows an. Das CoE Team (vielleicht 2-3 Leute die PP admin sind plus ein paar Enthusiasten) nutzt dann die CoE App.

Praxisnutzen: – Sie sehen alle Apps/Flows und ihre Owner. So können Sie z.B. eine Orphan App ermitteln: Maker hat Firma verlassen? CoE listet als „Orphaned“ (Eigentümer = disabled account). Dann können Sie neu zuweisen oder stilllegen. – Sie kriegen Usage stats: Wichtiger Indikator, um Erfolge zu zeigen und Ressourcen zu planen. Bsp: 500 Apps insgesamt, davon 100 in aktivem Gebrauch (>=1x pro Monat). Are others candidates to clean up? – DLP-Compliance: CoE zeigt, ob irgendeine App gegen DLP anläuft (im error fall sieht man es). – Lizenzen: Man sieht wer Trials nutzt, wer Premium hat. Evtl. Aufforderung an Trial-User „Dein Trial läuft aus, melde dich bei IT für Prod-Lizenz“.

• Support: CoE Tools kann Ticket-IDs in App Liste erfassen, man kann Änderungen dokumentieren (gibt fields „ComplianceApprovalGiven“ etc. falls man Formulare pflegt).
• Es fosters faktenbasierte Entscheidungen: Z.B. Abteilung XY will 50 neue Lizenzen. Im CoE Dashboard sieht man aber, die haben nur 5 Apps im Einsatz, wovon 3 selten genutzt – dann kann man nachfragen: wofür 50? Vllt. Wollen sie aber neu ausrollen was, dann ok, aber man hat Daten um nachzuhaken.

CoE Team: – Muss die Tools pflegen (Update CoE Kit alle paar Monate, MS liefert Updates). – Muss Flows überwachen (ob z.B. Admin-FLows laufen daily, error notifications?). – Daraus Policies anstoßen: z.B. CoE erkennt: „Viele Apps nutzen environment Default, vielleicht höchste Zeit Depts Prod environment zu geben und migraten“. – Running Nurture: Viell. CoE Team schreibt interne Blog „App of the Month“ etc., um Kultur.

Tipp: Legen Sie CoE Kit ideal auf eine separate Service-Account (oder use an SPN with flow if possible) -> reason: Minimiert Abhängigkeit von Person. Meistens aber es muss ein User context sein, also nutzt man so eine generisches CoE Admin user.

Vorlagen & Standards

Best Practices sollten nicht nur im Kopf des CoE Teams sein, sondern in greifbarer Form für Maker. – Erstellen Sie Vorlagen für typische Anwendungsfälle. Z.B. eine Canvas-App Template mit Company-Branding und Navigation-Gerüst. So haben Maker einen Ausgangspunkt und alles sieht einheitlicher aus. Diese kann man in dem CoE Template Catalog bereitstellen oder einfach als .msapp File zum Download im Intranet. – Ebenso Flow-Vorlagen: Evtl. ein Standard genehmigungs-Flow mit Company-Textbausteinen etc. Könnte man in Teams posten als „Starter for your own“. – Konfigurations-Vorlagen: Falls jmd. Environment neu anlegt (in konzern), definieren Sie „Environment Setup Checklist“ (z.B. DLP applied, support contact assigned, …). Vllt. via CoE request form: „Ich brauche neue Environment“ -> CoE genehmigt, Admin erstellt nach Standard (Naming, DLP linking etc.). – Coding-Standards: Machen Sie ein kurzes Dokument mit Namenskonventionen, was use/don’t use. Bsp: „Use variables sparingly, prefer using Dataverse directly in formulas for concurrency, ALWAYS comment complex formulas, ALWAYS set OnError handler globally to catch runtime errors in app etc.“ Ok, Maker lesen Manuals ungern 😅, aber man kann es in Schulungen oder BrownBags thematisieren.

• UI-Standards: Haben Sie Corporate Design? Dann definieren Sie im Theme JSON (Power Apps hat Hidden theming possib., CoE Themer helps customizing). So Buttons/Colors sind fix. Bzw. geben Sie Farbcodes & Logo mit. Machen Sie evtl. einen Control Template (in Canvas kann man group controls as custom component) for e.g. a header bar with Company Name, which reuse.
• ALM Standards: Legen Sie fest z.B. „Alle Apps ab Impact X müssen in Dev->Test->Prod Pipeline, code in Repo.“ So Maker wissen, wann sie IT um Hilfe bitten sollten dafür. Kleine 5 Nutzer-Apps kann man notfalls in place machen, aber definieren Sie den Schwellenwert (z.B. Ab 50+ User or critical data – formal ALM route). Dann hat man Standard, den man dem Management auch so kommunizieren kann „Kritische Apps gehen durch Qualitätsschleife“.
• Templates für Documentation: Hilft, wenn Maker auch kleine Doku erstellen. Vllt. ein OneNote Template „App Name, Owner, Purpose, Data Sources, etc.“ – minimal. CoE kit hat so was in den tables (Felder Description, risk etc.), encourage filling.

Die Idee hinter Vorlagen: Zeit sparen & Einheitlichkeit fördern. Gerade Wenig-Entwickler schätzen es, wenn sie was in die Hand bekommen. Und CoE hat weniger Nacharbeit, weil der Grundaufbau schon stimmt.

Lifecycle & Updates im Betrieb

Wenn eine App einmal produktiv ist, endet die Geschichte nicht – Lebenszyklus geht weiter: – Änderungsanforderungen: Wie fangen Sie neue Anforderungen oder Bugfixes ein? Evtl. definieren Sie, dass Fachbereiche für ihre Apps ein kleines Backlog pflegen (kann einfach eine Liste sein). Wenn CoE/IT involviert war, vllt. nutzen die Azure DevOps Boards oder Planner tasks. Wichtig: es sollte klar sein, wer verantwortlich ist: – „Citizen Dev A betreut App X, Änderungen bitte an ihn“ – diese Info z.B. ins App Katalog und an Helpdesk, damit Leute wissen, an wen wenden. – Legen Sie in App eine Impressum-Seite an („App Owner: Name, Kontakt“). – Regelmäßige Wartung: Power Platform ist Cloud, ergo Microsoft kann Änderungen ausrollen. Mal taucht neuer Feature auf, mal etwas wird deprecated. Da Maker oft nicht daily News checken, sollte CoE – die MS Release Plan lesen (Focus on „Canvas apps“, „Power Automate updates“ etc.), – prüfen, ob eine Änderung Apps beeinträchtigen könnte. Z.B. 2022 gab es die Abschaltung des alten Approvals-Portal, flows mussten angepasst werden etc. CoE muss das auf Schirm haben und Maker warnen & unterstützen. Also Plan: „Alle halbe Jahr Review, ob technische Updates notwendig“. – Backup/Restore: Microsoft hat sog. Environment Backup (wenn Dataverse). Täglich if on Managed env optionally, oder manual on demand. Sie können Prod Umgebungen Snapshots manuell vor größerer Änderung machen (Backup Env, dann import Solution). Wenn was schief, kann man environment restore (Achtung: environment restore erfordert new environment replacement, also heavy, kann man aber in out-of-biz hours). Für einzelne App restore: im Maker portal kann man „Restore previous version“ (bis zu letzten 50 version). For flows: gibts versioning (ja, flows have minimal version history now, one can revert I recall). It’s advisable, CoE holds latest managed solution exports in a safe place as well. Test Wiederherstellung mal, dass Team weiß wie und wie lang es dauert.

• Monitoring in Betrieb:
• Flow-Failures: Wollen Sie, dass wenn Flow fehlschlägt, einer alarm kriegt? Standard schickt MS oft dem Owner ne Mail „Failed“. Aber Owner vllt. nicht im Blick, oder weg. CoE: Besser, definieren „Critical flows“ -> monitor via Admin-API. Kann Flow (Flow management connector) track failures > X times, then send to central support? Ja, mit dem „CoE – Error Report“ Flow: Der checkt entgangene Flows and summarises to admin daily.
• App usage Monitoring: Set KPIs, e.g. if usage drops auf 0, vllt. App obsolet -> nachfragen.
• Connectors Monitoring: Possibly see if new connectors appear (someone adding unapproved stuff).
• Capacity Monitoring: Wöchentlich Capacity Tab check (Memory, Database if near limit).
• Support Model: Je nachdem, wie Sie die Verantwortung verteilt haben, sollte es klar definierte Supportlevel geben:
• Level 1 (Helpdesk): Die normalen IT-Helpdesk-Mitarbeiter sollten grundlegend geschult sein, was die Power Platform ist. Nicht dass bei jedem Anruf „Was ist Power Automate?“ kommt. Sie müssen Basics wissen: „App geht nicht -> oft Browser-Cache, oder frag Owner“. Geben Sie dem Helpdesk eine Liste: App Name -> Owner/Supporter. So kann Level1 entweder direkt an Level2 (Owner) weiterleiten oder dem User helfen mit Standardtipps (Login/Permission Issues etc.).
• Level 2 (App Owner / Maker): Der/diejenige, die die Lösung gebaut hat, ist meist auch der Beste, um kleinere Probleme oder Datenkorrekturen zu machen. Diese Person sollte offiziell Zeit dafür haben. Heißt, das Management muss dem Citizen Dev anerkennen, dass er X% seiner Zeit als Support einplant. Sonst droht Frust (Abteilung erwartet, dass er Support nebenher macht, aber Chef sagt „wo bleibt Tagesgeschäft?“). Also bei wichtiger App: Chef der Abteilung einbinden, dass Maintainer-Pflichten existieren.
• Level 3 (CoE/IT): Wenn Owner nicht weiter weiß (z.B. komplexer Fehler oder Plattform-Bug), kommt CoE Team ins Spiel. Die haben tiefere Kenntnisse und eventuell Kontakt zu Microsoft Support. Sie können technisch ein Problem debuggen oder Workaround empfehlen. Oder z.B. Integrationsthemen (Flow kann nicht auf SAP zugreifen -> eventuell ist Gateway down, das checkt IT).
• Microsoft Support: Not daily, aber Option. IT (global admin oder so) kann Ticket bei MS aufmachen, falls wirklich ein Servicefehler vorliegt. Mit Premium Support (falls Ihr Unternehmen hat) geht’s schneller. Aber als fallback gut.
• Externes Consulting: Manche Firmen vereinbaren mit Partnern (auch so einer wie mir 😜) Support-Verträge, falls intern Knowhow fehlt. Kann für Startphase gut sein. Ziel aber meist, intern selbsttragend.

Wichtig: Kommunikation des Supportweges. – Machen Sie klar: Endnutzer sollen NICHT bei MS anrufen (die wissen eh nicht wer ruft), sondern internen Weg. – Pflegen Sie vllt. in Ihrem ITSM-System (ServiceNow/Jira etc.) ein Ticketkategorie „Power Platform/Low-Code“, sodass Tickets getrackt werden. – Das CoE Team sollte quartalsweise Ticket-Auswertung machen: Was für Probleme häufig? Evtl. Schulungsbedarf oder Systemanpassung? – Achja, definieren Sie SLA falls notwendig: Wenn z.B. eine App super kritisch (vlt. Produktionsanlage stopp, wenn App ausfällt) – dann brauch man 24/7 Bereitschaft? Besser aber, solch kritische dinge redundant haben. Aber falls, dann CoE muss schichten. – Weniger kritische: Normale Office times support.

Lifecycle- und Release-Management im Betrieb

Wir hatten unter ALM und Lifecycle Einiges. Hier noch mal emphasise: – Roadmap definieren: Jedes größere PP Projekt kann Roadmap Phase 2,3 etc. haben. Machen Sie es ähnlich wie Software. So bleibt Thematik auf Agenda und iterative improvements passieren. – Decomissioning: Planen Sie auch mal das Abschalten: * Hat ein UseCase sich erledigt (neues ERP modul ersetzt die PowerApp)? Dann App/Flow abschalten, Daten archivieren, User informieren. * CoE kit hat „Clean Up“ flows: fragt Owner, ob App noch needed, if no, disable und nach x Tagen delete. * Halten Sie Prod Umgebungen sauber: keine Leichen, das spart auch Storage und potentielle Sicherheitslücken (alte flows ungewartet). – Scale up Team: Anfangs war CoE klein, aber mit Hunderten Apps, überlegen Sie, ob Sie eine dedizierte Low-Code Platform Admin/Engineer Rolle schaffen. Viele Unternehmen tun das. Jmd. der 100% den Platform Betrieb managt (vergleichbar O365 Admin). Und vllt. pro Abteilung „Local Power Platform Champion“, die 20% dafür abgestellt sind. Das Netzwerk ist wertvoll: Austauschtreffen organisieren (Power User Roundtable). – Betriebskosten: Im Betrieb merkt man, welche hidden costs kommen: e.g. CoE maintenance, Infra. Rechnen Sie im Budget ein.

Zusammengefasst: Der Betrieb der Power Platform erfordert ähnlich viel Organisation wie der Betrieb anderer wichtiger Plattformen (ERP etc.), auch wenn vieles Cloud-managed ist. Mit Tenant Settings, dem CoE als Schweizer Taschenmesser, klaren Prozessen und Verantwortlichkeiten halten Sie den Laden stabil und die Benutzer glücklich. Vor allem gilt: Proaktiv sein! – Wenn Sie alles erst ad-hoc machen, wenn Probleme auftreten, laufen Sie nur hinterher. Lieber von Anfang an definieren, wer Admin ist, wie Support läuft, welche Tools (CoE) eingesetzt werden, dann entwickeln sich erst gar nicht unkontrollierte Zustände.

8. Lizenzierung & Kapazitäten

Jetzt wird’s einmal richtig trocken, aber sehr wichtig: Lizenzierung. Keine Angst, ich versuche es so anschaulich wie möglich zu machen. 😊 Die Microsoft Power Platform hat verschiedene Komponenten, und jede hat eigene Lizenzmodelle. Außerdem gibt es Quotas und Kapazitäten (z.B. Speicherplatz, API-Aufrufe), die mit Lizenzen einhergehen. Hier entwirren wir den Dschungel: Welche Lizenzoptionen gibt es pro Komponente? Was kosten diese ungefähr (Stand Ende 2025)? Wie rechnet man aus, was man für ein bestimmtes Szenario braucht? Und wie behält man die Kapazitäten im Blick?

Lizenzmodelle der Power Platform im Überblick

Die Power Platform-Lizenzen sind modular. Grundsätzlich kann man zwei Hauptarten unterscheiden: pro Benutzer (User) und pro Nutzung/Einheit. Und manche Dinge sind bereits in anderen Lizenzen (z.B. Office 365, Dynamics 365) enthalten.

Schauen wir uns für jede Hauptkomponente die Optionen an:

Power Apps: – Power Apps Premium (pro Benutzer): Dies ist die Flatrate für einen Nutzer. Für aktuell ca. 18,70 € pro Benutzer/Monat (bei jährlicher Abrechnung, zzgl. MwSt) erhält der Nutzer das Recht, unbegrenzt viele Apps zu nutzen und auch zu erstellen (solange er in entsprechenden Environments die Rechte hat). Früher hieß das „Per User Plan“. Alle Premium-Funktionen sind damit abgedeckt: Zugriff auf Dataverse, auf alle Premium-Connectoren, und sogar Power Pages-Nutzung ist enthalten (d.h. wenn der Nutzer auch auf ein internes Portal zugreifen soll). Außerdem sind 500 AI Builder Credits pro Monat und Nutzer dabei – ein netter Bonus, um z.B. mal Form Processing zu nutzen (falls mehr nötig, muss man AI Credits separat kaufen). Dieser Plan eignet sich, wenn ein User mehrere Apps benötigt oder generell viel mit Power Apps arbeitet. – Power Apps per App (pro App pro Benutzer): Hier lizenziert man einzelne Apps günstiger. Pro aktive App-Berechtigung und Nutzer zahlen Sie etwa 4,70 € pro Monat (5 $). Beispiel: Wenn ein Mitarbeiter nur eine einzige Power App nutzt (z.B. eine Urlaubsantrag-App), wäre es kosteneffizienter, ihm 1x diese „App-Pass“ zu geben statt gleich die volle Flatrate. Mit einem App-Pass kann ein Nutzer genau eine App (bzw. ein Portal) nutzen, inkl. aller Premiumfeatures darin. Falls er zwei Apps braucht, bräuchte er zwei App-Pässe (also ~9,40 €). Man merkt: ab 4 oder 5 Apps wird es teurer als die Flatrate, deshalb sagt man als Daumenregel: bis ~3 Apps pro Nutzer lohnt per-App, darüber eher der Premium-Plan. – Wichtig: App-Pässe werden oft über Azure Pay-as-you-go abgerechnet oder als Prepaid-Pool im Tenant gekauft (z.B. 100 App-Pässe). Man muss sie nicht namentlich zuweisen; das System zieht sich die benötigten, wenn ein Nutzer eine App startet, die so lizenziert ist. – Power Apps Developer Plan: Das ist kostenlos, aber nur für Entwicklung/Test. Jeder Mitarbeiter kann sich auf der MS-Website so einen Developer-Plan holen, dann bekommt er eine eigene kleine Dataverse-Umgebung mit Premium-Fähigkeiten – aber diese Umgebung ist nur für ihn zugänglich und darf nicht produktiv genutzt werden. Sie dient Trainings und Experimente. Datenvolumen und Flow-Runs sind begrenzt (z.B. 750 Flow-Runs/Monat). – Office 365 enthaltende Rechte: Haben Sie z.B. Office 365 E3/E5 Lizenzen, dann dürfen User Power Apps mit „Standard“-Connectors nutzen ohne zusätzliche Lizenz. Das bedeutet: Sie können einfache Canvas-Apps bauen, solange diese nur auf SharePoint, Excel, Outlook, Teams etc. (alles Standard) zugreifen. Diese O365-Lizenz erlaubt aber kein Dataverse oder andere Premium-Connectoren. Für sehr grundlegende Apps kann das reichen. Beispiel: Eine kleine Umfrage-App, die Daten in eine SharePoint-Liste schreibt – jeder mit O365 darf die nutzen. Microsoft positioniert das als „Power Apps for Office“ bzw. manche nennen es „Seeded license“. In Plänen wie Microsoft 365 F3 oder Office E1/E3/E5 ist das drin. Aber sobald man z.B. einen SQL-Server anbinden will, braucht der Nutzer doch eine Power Apps Premium-Lizenz. – Power Apps Pay-as-you-go: Alternativ zur festen Lizenz kann man über ein Azure-Abonnement nach Verbrauch zahlen. Hier werden die gleichen Kosten angesetzt (also ~5€ per App/Month oder ~19€ per user/Month), aber eben nur für tatsächlich genutzte Apps/Nutzer. Vorteil: Für Prototypen oder unklare Nutzerkreise muss man nicht vorab Lizenzen kaufen, sondern sieht am Monatsende im Azure-Abrechnung, was angefallen ist. Beispiel: 100 Leute hätten Zugriff, aber nur 10 haben die App im Oktober wirklich gestartet – dann zahlen Sie 104,70€ = 47€. Wenn nächsten Monat 50 Leute nutzen, dann eben 504,70 = 235€. So skaliert es flexibel. Gerade bei schwankender Nutzung oder externen Benutzergruppen ist PayG interessant. Allerdings braucht man ein hinterlegtes Azure Subscription und gutes Kostenmonitoring, sonst kann’s überraschend werden.

Power Automate: – Power Automate Premium (pro Benutzer): Für rund 13–15 € pro User/Monat (15 $) bekommt ein Nutzer die Möglichkeit, unbegrenzt viele Flows auszuführen (Cloud-Flows) und auch Attended RPA (Desktop flows) auf seinem Rechner zu starten. Dieser Plan deckt zudem Process Mining (Prozessberater) in kleinem Umfang ab – meist ~50 MB Daten, d.h. zum Reinschnuppern in die Process-Mining-Funktion. Jeder lizenzierte User erhält auch hier um ~250 MB Dataverse-DB und 2 GB File Kapazität (wie bei Power Apps). Dieser Plan ist gut, wenn bestimmte Power-User viele eigene Automatisierungen nutzen. – Power Automate Process (Unattended RPA Bot): Hier lizenziert man einen digitalen Bot, der unbeaufsichtigt auf einem VM/PC laufen kann. Kostenpunkt: ca. 135–150 € pro Bot/Monat (150 $). Mit so einer Lizenz kann man z.B. einen VM einrichten, auf dem RPA-Flows (Desktop flows) ohne menschliche Hilfe laufen (z.B. jede Nacht 100 Datensätze im Altsystem abarbeiten). Enthalten sind auch normale Cloud-Flows, aber primär kauft man das für RPA-Szenarien, wo kein User aktiv sein muss. Pro Bot-Lizenz kann immer ein Desktop-Flow gleichzeitig laufen – für Parallelität braucht man mehrere Bots (= mehrere Lizenzen). – Power Automate Hosted RPA: Noch einen Schritt weiter: Microsoft stellt den Bot gleich als gehosteten Cloud-VM. Kostet ca. 200–215 € pro Bot/Monat (215 $). Hier brauchen Sie keine eigene VM on-prem, Microsoft startet eine VM in Azure on demand, führt den RPA aus und schaltet sie wieder ab. Ist komfortabler, aber teurer. – Power Automate im Office 365 inkl.: Ähnlich wie bei Power Apps haben O365-Lizenzen eine „seeded“ Nutzung: Jeder O365-User darf Standard-Workflows erstellen, z.B. sich selbst eine Outlook-Regel per Flow, oder einen SharePoint-zu-Teams-Notifier. Diese Office-Flows dürfen jedoch keine Premium-Connectoren nutzen. Außerdem fehlen diesen Basis-Flows Features wie HTTP oder Custom Connectors. Also, interne E-Mail-Benachrichtigung bei neuem Listeneintrag – geht ohne extra Lizenz. Aber sobald man was wie „Wenn neu in Salesforce, dann schicke Teams Message“ tun will – Salesforce ist Premium -> erfordert Power Automate Plan. – Power Automate Per Flow (Team flows): Früher gab es den „Per Flow Plan“: für ~420 € bekam man 5 Flows lizenziert, egal wie viele User sie nutzen. 2025 hat MS das umbenannt: Im Grunde entspricht das den RPA-Bot-Lizenzen, nur ohne RPA? Tatsächlich wurde „Per Flow“ größtenteils durch die Unattended-Bot-Lizenz (die ja Cloud und Desktop Flows kann) ersetzt. Wer nur Cloud flows team-basiert lizensieren will, könnte theoretisch 1 Bot-Lizenz kaufen und auf dem Service-Konto laufen lassen – ist aber Overkill. Allerdings gab es auch Power Automate für Teams (kostenlos begrenzt auf innerhalb Teams), doch das Konzept hat MS zurückgefahren. Heutzutage lizenziert man i.d.R. entweder pro User oder pro Bot. – Process Mining Add-On: Wenn Sie richtig Process Mining betreiben wollen (große Logs analysieren etc.), gibt es ein Add-on: ~ 5.000 € pro Tenant/Monat (100 GB Data, 1 TB File entitlements für Logs). Das ist eher was für Konzerne, die intensives Process Mining über mehrere Prozesse machen. Ansonsten reicht oft das, was im pro User Plan minimal drin ist, um mal einen Process Advisor Durchlauf zu probieren. – Pay-as-you-go für Power Automate: Gibt es ebenfalls – hier zahlt man pro Flow-Ausführung. Z.B. ein automatisierter Cloud-Flow kostet 0,00004€ pro Ausführung (Beispielwert), ein Desktop-Flow-Lauf vielleicht 0,002€ pro Minute Laufzeit – die Preise sind eher „versteckt“ in Dokus, aber Azure kann es nach Nutzung berechnen. Dies lohnt, wenn man wenige Flows hat, die selten laufen. Wenn ein Flow jedoch z.B. 1000x am Tag läuft, rechnet es sich bald mehr, fix zu lizenzieren. Auch RPA-Bots kann man mit Azure meter bezahlen (gehostete RPA-Bot runtime stundenbasiert etc.).

Power BI / Microsoft Fabric: – Power BI Pro (User): Jeder User, der Berichte erstellen oder in einem Workspace freigegebene Berichte anschauen will, braucht i.d.R. entweder eine Pro-Lizenz oder der Bericht liegt auf einer Premium-Kapazität. Power BI Pro kostet rund 8–10 € pro User/Monat. In vielen Microsoft 365 E5 Plänen ist Pro schon enthalten. Damit kann man an der Power BI-Welt voll teilnehmen, Berichte veröffentlichen, teilen, Teams-Integration, alles. Grenzen: Daten-Modell bis 1 GB, Refresh 8x am Tag. – Power BI Premium pro User (PPU): Für ~16–20 € pro User/Monat bekommt man Premium-Funktionen „light“. Dazu zählen größere DataSets (bis 100 GB), AI-Features (autom. Bericht-Gen, Paginated Reports), und man kann Berichte in Sharing ohne Pro-Empfänger nur begrenzt nutzen (nur PPU zu PPU können Inhalte austauschen; PPU ist eher dafür, heavy-power user extra Funktion zu geben). PPU wird nicht so breit eingesetzt, außer man hat keinen Kapazitätsbedarf, will aber Premium-Features für eine kleine Gruppe. – Power BI Premium Kapazität (Fabric-Kapazität): Das ist eine dedizierte Rechenleistung in Microsoft Fabric, auf der man beliebig viele Nutzer (auch ohne Pro-Lizenz) Berichte anschauen lassen kann. Es wird nach Kapazitätsgröße bezahlt (Recheneinheiten). Früher hieß es P1, P2 Nodes (~4.200 €/Monat aufwärts). Mit Fabric gibt’s granularere SKUs (F2, F4, F8…). Beispiel: F4 Kapazität ~ 1.700 € pro Monat (fiktiver Wert, da es neu ist und modulare). Für echte große Deployments rechnet man mit so einer Kapazität ab. Vorteil: Unbegrenzte Verteilung, bessere Leistung, ab 500+ User meist günstiger als jedem Pro zu geben. – Microsoft Fabric Integration: Wer Premium-Kapazität hat, kann nun nicht nur Power BI, sondern auch Data Factory, Synapse, Spark, DataScience in der selben Kapazität nutzen (sofern in Kauf). Das ist aber advanced. Kostentechnisch bleibt es ähnlich dem alten P-Kapazität Modell, nur flexibler. – Free License: Power BI Desktop ist kostenlos, und im Service kann man eigene Reports anschauen mit Free, aber kein Sharing. Interne Nutzer ohne Pro können Reports nur sehen, wenn der Workspace auf einer Premium-Kapazität liegt. Externe können Bericht per Public link (unsicher, eher nicht in Business), sonst ebenfalls Pro oder Premium required. – Zusätzliche Info: Wenn Ihre Firma E5 lizenziert ist, nutzen Sie das – d.h. viele haben Pro inkl. Muss man nicht extra kaufen. Premium (Kapazität) lohnt z.B. wenn man Berichte an externe Kunden geben will (diese haben kein Login oder keine Pro-Lizenz; mit Premium kann man sogenannte „PUs“ Public user). – Kostentabelle: Kommt unten – mache wohl separate Spalte.

Power Pages (vormals Portals): – Authenticated Users: Das sind externe Benutzer, die sich am Portal anmelden (z.B. mit Firmen-Account oder via Azure AD B2C, Social, etc.). Microsoft verkauft Packs von 100 authentifizierten Users pro Website für ca. 187,20 € pro Monat (200 $). Dabei gilt „User“ grob definiert als unique monthly user. Das Plan “1 pack = bis 100 aktive Nutzer mtl.”. Braucht man mehr, kauft man mehr Packs. Rechnet sich: ~1,87€ pro User/Monat. Das ist im B2B-Portal-Umfeld okay, aber wenn Sie 10.000 externe Kunden haben, addiert es sich. Hier kann man vlt. mit volum discount verhandeln. – Anonymous page views: Für öffentliche Websites rechnet MS nach Seitenaufrufen. Pack: 500.000 Page-Views pro Monat ~ Preis unbekannt hier, früher ~75€? Müsste ich checken. (War mal $100). Das deckt anonyme Besucher im genannten Kontingent. Für heavy-traffic Seiten skaliert linear. – Internen Nutzung: Interne Benutzer, die schon Power Apps lizenzieren, können i.d.R. ohne extra was auch interne Pages nutzen, weil Power Apps Premium deckt „unlimited Power Pages for assigned user“ ab (siehe Pricing: Power Apps Premium hat „Unlimited Power Pages for user“). Das ist neu und praktisch: Wenn z.B. 500 Mitarbeiter ein internes Portal nutzen sollen, braucht man nicht pro se Portal-Lizenz, die haben ja PApps (sofern Premium lizenziert). – Kapazität: Jede 100er Auth-Pack bringt 2GB DB + 16GB File extra Storage speziell fürs Portal (das in einem speziellen Dataverse-Backend liegt). Das entlastet Ihr generelles Storage-Konto. – Hinweis: Ein „User“ auf dem Portal ist mit E-Mail/Azure AD ID distinct, egal wie oft er kommt, zählt als 1. Wenn im Monat 120 User kamen, brauchen 2 Packs (200 capacity). Spart man nicht durch halben pack – müssen aufrunden.

Copilot Studio / AI Credits: – Microsoft Copilot Studio: Der Dienst, um KI-Agents zu bauen, hat (neben dem, was in M365 Lizenzen drin sein mag) ein eigenens usage-Meter: Für 200 $ (ca. 187 €) bekommen Sie 25.000 Chat-Nachrichten pro Monat. Das nennt man „Messages“. Jede Nutzerfrage oder KI-Antwort zählt als 1. Das ist in etwa vergleichbar mit ChatGPT API-Pricing. Wenn man mehr braucht, kauft man mehrere 25k-Pakete. – Rechenbeispiel: Ihr Kundenservice-Bot beantwortet im Monat 10.000 Anfragen, die meist 3 Dialogschritte haben -> 30.000 Messages, also ~1,2 Pakete -> man bräuchte 2 Pakete = 50k ($400). Also KI ist nicht gratis, aber je nach Nutzen günstig verglichen mit menschlicher Arbeitszeit. – AI Builder Credits: Hier kosten 1 Mio Credits (das ist z.B. ~1000 Seiten OCR oder 5000 Textklassifizierungen) ca. 460–470 € pro Monat (468 € gelistet). Man kann kleinere Pakete nicht, es ist fix pro 1Mio pro Monat. Aber wie gesagt, viele Lizenzen bringen freebies: Power Apps Premium User -> 500 Credits, Power Apps 2000er Volumen -> 500 Credits/User, Und es gab mal Tenant Startguthaben 5000 Credits. Das reicht für moderate KI. Für intensives (z.B. 10k Dokumente pro Monat scannen) wird man 1-2 Add-Ons brauchen. – Dataverse Storage Add-Ons: – DB (transaktionaler Speicher) kostet ca. 37,40 € pro GB/Monat zusätzlich. – File (Anhänge, Bilder) günstiger, ~ 7,50 € pro 1 GB/Monat (als Schätzung, war früher $2 per 1GB, aber in EU-Preisliste steht 37,40 for DB und ca. 7,50 for file). – Log (Audit-Log Storage) noch mal anders, glaub ~€18 pro GB. Allerdings: Jedes Prod-Lizenz-Paket gibt schon was: Power Apps Premium user -> 250MB DB, 2GB File each. Power Automate per user -> 50MB DB, 200MB File each. In Summe z.B. 10 Premium User = 10250MB = 2.5GB DB plus baseline 10GB default = 12.5GB. File 102 + def ~? Der Tenant bekommt initial 10GB DB + 20?GB File default. – Kurz: die meiste Storage hat man für moderate apps, aber wenn Sie das als mini-ERP betreiben mit million records, Speicher zukaufen einplanen. – Power Platform Requests (API-Calls): Standard je User/P2 Plan = 40.000 pro 24h, pro Flow Bot = 500k/24h. Man kann Add-On für 10k mehr/day pro User kaufen, falls jemand Limits reißt. Das ist selten nötig, aber gut zu wissen, dass es existiert (Preis war mal ~42€ pro 10k pack). – Richtiges Lizensierungs-Guidance: Der fairen Ordnung halber: – Internal Users: lizenziert pro head (User, App-Pass, or put content on capacity in BI). – External Users: – Power Pages/Portal-User: via authent/anon packs. – Power BI externe: require Premium capacity (embedding or B2B). – Externe via Teams or App-Sharing: streng genommen muss externer ein Guest in tenant mit lizenz oder embed. – Multiplexing: A tricky concept: Auch wenn externe über Portal was tun, Sie dürfen NICHT einfach ein Portal als Proxy für unlizensierte interne. Z.B. ein interner hat keine PApps-Lizenz, darf nicht durchs Portal seine App „billig“ nutzen. Das fällt unter „Multiplexing rules“ – MS will, dass interne regelkonform lizenziert sind. Ebenso, ein Shared Service Account der Flows im Auftrag von 10 Leuten ausführt -> die 10 bräuchten eigen Lizenz theoretisch. Aber bei Flows Team-szenario ist es unklar; MS duldet, wenn Flow triggers auf System events reagiert. Jedoch, wenn Flow manuell per unlizensiert user trigger, dann gilt’s als circumvent. – Im Zweifel: lieben Sie Ihre Microsoft Account Manager, sie helfen natürlich gerne beim Kauf 😉, aber seriös: Lassen Sie sich zweifelhafte Konstrukte schriftlich freigeben, falls unsicher (um Audits abzusichern).

So, genug generelles. Schauen wir das gelernte in Tabellenform und mit Rechenbeispielen an, damit es greifbarer wird:

Lizenzoptionen und Kosten je Komponente (Überblick):

Komponente	Lizenz-Option	Kosten (Netto/Monat)	Leistungsumfang
Power Apps	Premium Plan (pro User)	~18,70 € / Benutzer	Unbegrenzte Apps & Power Pages, Premium Connectors, 500 AI Credits, Dataverse inkl.
	Per App Plan (App-Pass)	~4,70 € / Benutzer/App	1 App oder 1 Portal pro Nutzer, Premium-Funktionen inklusive (kostenlos in M365-Teams-Umgebung auf 1 App beschränkt)
	Pay-as-you-go (Azure)	~5 € / Benutzer/App genutzt	Verbrauchsabrechnung, praktisch bei schwankender Nutzung
	Office 365 integriert	inkl. in E1/E3/E5	Nur Standard-Connectors, keine Premium-Datenquellen
	Developer Plan (Entwicklung)	kostenlos	Nur zu Test/Dev, keine Prod-Nutzung (eigene Sandbox-Env)
Power Automate	Premium (pro User)	~13–15 € / Benutzer	Unbegr. Cloud-Flows für User, Attended RPA inklusive, Standard Process Mining, Premium Connectors
	Unattended RPA Bot (pro Bot)	~135 € / Bot	1 unbeaufsichtigter Bot (Desktop-Flow) + Cloud-Flow Rights, kein User nötig
	Hosted RPA Bot (Cloud VM)	~195 € / Bot	Unatt. Bot inkl. MS-gehosteter VM (Azure), kein eigener Rechner nötig
	Office 365 integriert	inkl. in O365	Standard-Connector-Flows, keine Premium-Aktionen
	Pay-as-you-go (Azure)	z.B. ~0,000x € / Flow-Run	Verbrauch nach Anzahl Runs/Bot-Stunden (für sporadische Workflows)
Power BI / Fabric	Pro (User)	~9 € / Benutzer	Erstellen/Ansehen von Berichten in geteilten Workspaces (bis 1GB Dataset)
	Premium per User (PPU)	~18 € / Benutzer	Premium-Funktionen (bis 100GB, Paginated Reports, AI), Sharing aber nur mit PPU-Benutzern
	Premium Kapazität (Fabric F SKU)	z.B. ~1.700 € / Monat (F4)	Dedizierte Kapazität für alle Nutzer. Z.B. F4 (~8 CPU) oder P1 (entspricht ~8 CPU, ~4200€). Unbegrenzt Viewers, große Datasets, 48x/d Refresh etc.
	Embedded (Azure A SKU)	z.B. A4 ~4€/h (Dev/Test)	Azure-stündlich buchbare Kapazität für Embedding (z.B. in eigene App)
	Free (einzeln)	0 €	Nur persönliche Nutzung, kein Sharing ohne Premium-Kapazität
Power Pages	Authentifizierte Nutzer-Paket	~187 € / 100 Nutzer	Externe Authentifizierte Benutzer, pro Portal-Website. Mehrfach buchbar (200 Nutzer ~374€)
	Anonyme Zugriffe-Paket	~75–100 € / 500k Pageviews	Öffentlich verfügbare Seiten-Aufrufe pro Monat. Skalierbar je 0,5 Mio.
	Intern durch Power Apps lizenziert	0 € (inkl.)	Interne Mitarbeiter mit Premium-Lizenz können auf internen Power Pages ohne extra Kosten zugreifen
Copilot Studio	KI-Message Pack	~187 € / 25.000 Messages	KI-Chat/Agent Gespräche, z.B. in PVA/Copilot. Mehr Packs buchbar je nach Interaktionen.
AI Builder	Add-On 1 Mio Credits	~468 € / Monat	KI-Verarbeitungen (z.B. ~1000 Dokumente scannen). 500 Credits pro Premium-User bereits inklusive.
Dataverse Storage	DB-Kapazität 1 GB	~37 € / Monat	Zusatz-Datenbank-Speicher. Tenant hat Basis (10 GB + pro Lizenz Zuteilung).
	File Storage 1 GB	~7–8 € / Monat	Zusatz-Dateispeicher (Anhänge). Basis inkl. (20 GB + pro Lizenz).
	Log Storage 1 GB	~18 € / Monat	Zusatz Protokollspeicher (Audit-Logs). Logs werden 30 Tage Standard gehalten, länger erfordert Speicher.
Zus. Kapazität & Limits	Power Platform Requests Add-On	~42 € / +10k Calls/Tag	Erhöht API-Request Limit um 10.000 pro 24h für einen Benutzer. Meist nicht nötig außer bei Extrembelastung.
	Process Mining Add-On	~5.000 € / Tenant/Monat	100 GB Prozessdaten + 1 TB Speicher, für umfangreiches Process Mining in Power Automate.

(Preise in Euro sind ungefähre Werte aus Dollar, Stand Nov. 2025, zzgl. MwSt. Tatsächliche Konditionen können je nach Region/Rabatt variieren.)

Man sieht, die Lizenzierung ist nicht gerade trivial. Daher empfehle ich immer, Szenarien durchzurechnen. Machen wir mal zwei typische Beispiele:

Beispiel 1: Abteilungs-App für 50 Nutzer
Die Personalabteilung möchte eine Onboarding-App bauen. Es werden ca. 50 Mitarbeiter (Führungskräfte und HR-Team) diese App nutzen, jeder nur diese eine App.

• Option A: Pro Benutzer-Lizenz: 50 * 18,70 € = 935 € pro Monat. Damit könnten die 50 aber auch noch andere Apps nutzen, falls später vorhanden.
• Option B: Per App-Lizenz: 50 Benutzer * 4,70 € = 235 € pro Monat (für die App). Günstiger, solange wirklich nur diese eine App genutzt wird. Sollte eine zweite App in HR hinzukommen (z.B. Urlaubsanträge), müsste man für die ggf. erneut App-Pässe lizenzieren: dann 50 * 4,70 € = weitere 235 €. Zusammen wäre man bei ~470 €. Immer noch <935.
• Haken beachten: Wenn in der App Premium-Funktionen genutzt werden (z.B. Dataverse), müssen wir diese App-Pässe auch tatsächlich kaufen.
• Ergebnis: Für eine Abteilungs-Einzellösung ist die Per App-Variante (Option B) hier deutlich kostengünstiger. Wir würden also 50 App-Pässe erwerben. Praktisch läuft es so, dass man ein Paket (z.B. 50er) im Admin Center bucht und den entsprechenden Environment der App zuweist. Abrechnung erfolgt dann fix oder nach tatsächlicher Nutzung (je nach Modell, App-Pass kann beides).

Beispiel 2: Unternehmensweites Ideenmanagement für 300 Nutzer
Man will eine Ideenmanagement-App einführen, wo alle Mitarbeiter Ideen eingeben können, plus eine Power BI Auswertung dazu.

• Alle 300 Mitarbeiter sollen Zugang haben. Hier haben wir zwei Komponenten: Power App + Power BI.
• Power Apps Lizenzierung:
• Option A: 300 * 18,70€ = 5610 €/Monat.
• Option B: 300 * 4,70€ = 1410 €/Monat (da pro Nutzer nur diese App).
• Offensichtlich ist B hier viel attraktiver, da die meisten wohl sonst keine andere App nutzen. Wir nehmen also App-Pässe, 300 Stück.
• Power BI Lizenzierung:
• Wenn nur wenige Mitarbeiter Reports wirklich interaktiv ansehen müssen, könnte man sagen „Wir geben z.B. 20 Managern eine Pro-Lizenz (209€=180€) und verteilen statische PDF-Berichte an den Rest.“ – das wäre eine Minimal-Lösung. Aber sagen wir, das Ideen-Dashboard soll allen zugänglich sein, damit jeder Fortschritt sieht.
• 300 Pro-Lizenzen wären 2700 €/Monat. Das ist recht viel.
• Eine Premium Kapazität P1 kostet ~4200 €/Monat, was für 300 Overkill und teurer wäre. Aber es gibt nun Fabric F2 oder F4, vielleicht F2 (~730€/Monat) reicht vom Leistungsprofil für 300 Nutzer mit moderatem Report. Wenn ja, dann F2 ist deutlich günstiger als 300 Pro einzeln. Allerdings muss man dem Setup die Erstellung von Reports abdecken: die Ersteller (vielleicht 2 BI-Leute) brauchen trotzdem mindestens Pro oder PPU um ins Premium deployen zu können (im Premium-Workspace).
• Alternativ PPU (Premium pro User): Wenn man Reports mit Premium-Funktionen will. Aber hier wollen wir nur allen Zugriff. PPU an 300 ist unsinnig (teurer als Pro).
• Also, man könnte ein Power BI Embedded A SKU in Azure nehmen (A4 z.B. ~2,5€/h = ~1800€/Monat 24/7). Auch das ist Option. Aber am Ende, ich würde hier pragmatisch: Falls die 300 bereits alle O365 E5 hätten (dann alle Pro-Lizenz inkl. => 0€ extra). Realistisch aber E3. Dann günstigste Weg:
  • Entweder 300 Pro = 2700 € oder
  • 1 Kapazität F2 ~ 730€ und 2-3 Pro-Lizenzen für Entwickler ~27€ -> ~757 €. Das ginge nur, wenn F2 genug Performance hat. F2 entspricht 2 „Capacity Units“ (d.h. 1/4 P1?), das sollte 300 Light-Report-User packen.
• Wir entscheiden uns also für Fabric F2 Kapazität.
• Kosten total: Power Apps ~1410€ + Power BI ~757 € = ~2167 € pro Monat (zzgl. MwSt).
• Pro Kopf ~7,22 €/Monat – das klingt fair für eine enterprise-weite Lösung.
• Ach ja: Wenn die 300 nur sporadisch gucken, hätte man theoretisch mit Power BI Embedded auch „pro View“ rechnen können, aber Microsoft lizenziert offiz. nicht pro click.
• (Nebenrechnung: Wenn man stur Pro-lizenziert hätte: 1410+2700=4110 €/Monat – also rund doppelt so teuer).

Beispiel 3: RPA-Bot vs. manuelle Arbeit
Ein Prozess in der Buchhaltung erfordert täglich 300 Eingaben in ein altes System. Mitarbeiter brauchen dafür ~3 Stunden pro Tag. Idee: Ein RPA-Bot könnte das rund um die Uhr übernehmen.

• Lizenzierung: Wir brauchen 1 Unattended Bot. Das kostet ~135 € im Monat.
• Zusätzlich einen Windows-Rechner (virtuell oder physisch), den wir dafür betreiben. Falls wir Azure-VM nutzen: ~50€ im Monat (schätzungsweise für Standard VM).
• Der Bot kann 24/7 ackern. 300 Aktionen pro Tag sind nichts, er schafft deutlich mehr. Also Kapazität kein Problem.
• Kosten Bot-Betrieb ~185 €/Monat.
• Ersparnis: Der Mitarbeiter spart 3h * 22 Tage = 66 Stunden/Monat. Bei einem kalkulatorischen Stundensatz von z.B. 50 € wären das 3300 € „Wertschöpfung“, die anderweitig genutzt werden kann.
• ROI also riesig positiv. Selbst wenn man Overhead rechnet (Bot-Einrichtung, Wartung), hat sich das schnell gelohnt.
• Hier sieht man: RPA-Lizenzen sind teuer im Vergleich zu einzelnen Cloud-Lizenzen, aber im Verhältnis zur ersetzten manuellen Arbeit oft ein Schnäppchen.

Beispiel 4: Externes Kundenportal
Ein mittelständisches Unternehmen will ein Portal für ~1000 Kunden einrichten, damit diese Service-Tickets einstellen können und Auftragsstatus prüfen.

• Power Pages Authentifizierte Nutzer: 1000 Kunden/Monat. Pro 100 kosten 187€, also 10 Packs *187 = 1870 €/Monat. Evtl. mit etwas Rabatt bei 10 pack Bulk.
• Alternativ: Wäre eine Custom-Entwicklung eines Webportals inkl. Hosting fällig, was zigtausende EUR Entwicklung + laufende Cloud-Kosten machen würde. In dem Lichte sind <2000€ monatlich gar nicht schlimm.
• Der Wert: Weniger Hotline-Anrufe, besserer Kundenservice.
• Intern: Mitarbeiter, die Tickets bearbeiten, haben eh ihre Dynamics/Dataverse Lizenzen, also kein Zusatz.
• Also Pricing plausibel: ~2€ pro Kunde/Mon, wenn’s gut genutzt wird.
• Hier könnte man argumentieren: Was, wenn nicht alle 1000 jeden Monat kommen? PayG gibts da nicht, man muss Kapazitätspacks für Page ampeak dimensionieren.
• Positiv: Wenn im Januar mal 1200 unique logins kommen, bräuchte man 12 packs (1200 capacity). man kann monatlich anpassen, aber i.d.R. man würde oversubscribe leicht um Puffer zu haben.
• Ach so, es gibtAlternativen: Man hätte auch auf Azure B2C plus eigen dev Portal setzen können. Kostet vllt. 0,20€ pro Auth user + dev. Aber der Entwicklungsaufwand vs. Power Pages Low-Code Abwägen. Für die ersten 1000 kann PP gesamt billiger sein.

Zusammenfassend: – Pro Benutzer-Lizenzen lohnen, wenn ein einzelner Mitarbeiter viel Nutzen aus vielen Apps/Flows zieht (breite Nutzung). – Per App/Paket-Lizenzen sind top, um große Nutzerkreise für begrenzte Lösungen kostengünstig abzudecken. – Für Flows, überlege ob du pro User oder pro Prozess lizensieren willst. Oft ist pro User gut, wenn einzelne Leute sich Automationen basteln. Aber für team-automatisierungen, wo Flow im Hintergrund läuft, hat man ja oft Service-Account, dann reicht ggf. 1-2 pro user lizenzen (z.B. 1 service user mit PA Premium = drölf Flows as him). Offiziell benötigt allerdings jeder Auslöser einer manuellen Team-Flow auch lizenz, aber z.B. Recurrence flows, triggered by events, stört es die 1 license approach nicht. Das ist eine Grauzone, da muss man auf Multiplexing achten: MS sagt idR „wenn Flow im Auftrag von N usern was macht, sollten N Lizenzen vorhanden.“ In vielen Fällen geht es aber technisch mit weniger und MS hat da bisher nicht streng kontrolliert. – Pay-as-you-go ist super flexibel, aber man muss diszipliniert cost monitoren. Vorteil: Keine Vorkasse, austesten, schnell Projekte aufsetzen. Nachteil: Azure Rechnung kann unpredictably hoch, wenn usage boomed. CoE kit kann Reports generieren (Cost analysis) aber man muss dranbleiben.

• Dynamics 365: Noch notiert, falls jemand D365 CRM/ERP Lizenzen hat, die beinhalten oft Power Platform Kapazitäten und Rechte. Z.B. Dynamics Sales user kann bis 15 custom Power Apps im selben env nutzen ohne extra. Oder Team Member license hat kleine Canvas usage. Das ist ein Kapitel für sich; moral: Check, ob bestehende D365 Lizenzen vielleicht Euer Szenario abdecken (dann 0€ extra). Gerade Großfirmen mit EAs: Oft ist klug, PP Lizenzen im großen Microsoft-Vertrag zu verhandeln (Rabatte etc.). Und Government/Edu hat auch abweichende Pläne zum Teil (Academic ~40% discount etc.).

Damit haben wir das vermeintlich Komplexeste auch geschafft. Letztlich ist es wie im Restaurant: Man hat à la carte (einzelne Lizenzen) oder Buffet (Flatrate pro User). Je nach Hunger und Personenzahl wählt man das Günstigere. 😉 Wichtig ist: Planen Sie das Thema frühzeitig ein und rechen Sie – nichts ist unangenehmer, als am Ende ein super technisches Konzept zu haben und dann festzustellen „Ups, das kostet ja 50k im Jahr, das hatte keiner bedacht“. Holen Sie am besten Ihren Lizenz-Betreuer oder Partner mit ins Boot, die kennen oft Kniffe, wie man es optimal gestaltet. Und behalten Sie im Betrieb (via CoE) immer die Lizenznutzung im Blick, um nachsteuern zu können.

9. Überwachung, Sicherheit & Qualität

Hat man die Power Platform im Einsatz, will man natürlich wissen: Läuft alles rund? Sind unsere Daten sicher? Werden die Qualitätsziele erreicht? In diesem Abschnitt geht es um Monitoring, Security Operations und Qualitätskennzahlen (KPIs). Wir beleuchten, wie Sie Telemetriedaten sammeln, welche Protokolle zur Verfügung stehen, wie man im Fall der Fälle reagiert (Security Operations), und welche Kennzahlen sinnvoll sind, um den Erfolg und die Gesundheit der Plattform-Nutzung zu messen.

Telemetrie und Protokollierung

Telemetrie bedeutet: das Sammeln von Nutzungs- und Systemdaten, um Einblicke zu gewinnen. In der Power Platform gibt es verschiedene Ebenen: – Power Platform Admin Analytics: Im Power Platform Admin Center finden Sie unter „Analytics“ Dashboards für Power Apps, Power Automate, etc. Diese zeigen z.B.: – Anzahl aktiver Apps/Flows im Zeitverlauf, – Top Apps (mit meisten Aufrufen), – Fehlerquoten von Flows, – Nutzerzahlen pro Environment. Das sind gute Einstiegsmetriken. Allerdings sind sie teils aggregiert und nicht sehr fein einstellbar. – Office 365 Unified Audit Log: Wie zuvor erwähnt, protokolliert M365 jede Menge Events. Darunter: – App erstellt/ gelöscht / geteilt, – Flow erstellt/ geändert, – Connectors verwendet, – User X hat App Y aufgerufen (begrenzt), – Admin hat DLP Policy geändert etc. Diese Logs können Sie gezielt abfragen. Für Audits ideal, aber auch für Monitoring: Sie könnten z.B. eine Überwachung einrichten, die das Audit Log scannt und Alarm schlägt, wenn jemand plötzlich eine gesperrte Aktion versucht. Tipp: Sie können Audit-Logs auch dauerhaft an ein SIEM (Security Information & Event Management) weiterleiten via Office365-Management-API, falls Sie z.B. Splunk oder Microsoft Sentinel haben. So fließen PP-Events in Ihren allgemeinen Security-Monitor. – Power Apps Monitor (Debug): Für Performance- oder Fehleranalyse einer bestimmten Canvas-App gibt es das Monitor-Tool. Ein Entwickler kann seine App mit dem Monitor laufen lassen (auch remote mit einem Nutzer verbinden) und sieht live alle Ereignisse: welche Datenabfragen, wie lang sie dauerten, wo Fehler in Formeln passieren, etc. Das ist super, um im Detail Engpässe zu finden (z.B. „Diese Abfrage hat 5 Sekunden gedauert, delegiert nicht, daher langsam“). Allerdings ist es manuell und fallweise. Für generelle Überwachung eignet es sich nicht, aber als Qualitätswerkzeug ja. – Power Automate Run-History: Jeder Flow speichert 28 Tage (Standard) seine Run-History: wann gelaufen, erfolgreich/fehler, Dauer. Ein Admin (mit Environment-Rechten) kann diese einsehen. Für kritische Flows lohnt es, regelmäßige Checks zu machen. CoE Starter Kit hat z.B. „Flow Runs Power BI Report“ – da kann man über mehrere Flows aggregiert sehen, wie viele Durchläufe, wie viele Fehler. Telemetrie-Maße: z.B. „Fehlerquote 7-Tage-Ø = 2% der Runs“ – könnte man definieren als KPI. – Custom Logging innerhalb Apps/Flows: Man kann selbst Telemetriedaten erfassen. Beispiel: In einer App könnte man bestimmte Nutzungsdaten in eine Log-Tabelle schreiben („User klickte auf Button X“). Oder ein Flow könnte bei jedem Durchlauf einen Dataverse-Datensatz „FlowRun“ erzeugen mit Infos. Das sollte man sparsam tun (nicht dass Logging das System belastet), aber für wirklich unternehmenskritische Prozesse ist ein custom Audit sinnvoll: z.B. jeden genehmigten Vertrag loggen: wer genehmigt wann – sowas kann man explizit protokollieren (auch wenn Flow’s default Approvals das auch trackt). – Integration mit Application Insights: Es gibt (noch experimentell) Möglichkeiten, Power Apps mit Azure Application Insights zu koppeln. Das würde umfassende Telemetrie (User Sessions, Screens, Crashreports) ermöglichen. Das erfordert etwas Azure-Setup (Instrumentation Key in App einbinden etc.). In 2025 war das aber kein Standard out-of-box, mehr ein Code-Component Trick. Für klassische Web-Apps ist AppInsights top, bei Low-Code noch neuartig. Microsoft hat aber für Power Pages nun Integration in Azure Monitor for telemetry.

Für Protokollierung gilt: – Dataverse hat eigene Audit-Funktion: Wenn aktiviert, schreibt es bei jeder Änderung (Create/Update/Delete) einen Logeintrag mit altem/neuem Wert, User, Zeit. Das kann granular eingestellt werden (z.B. „auditiere Änderungen an Tabelle Kunde, aber nicht an Tabelle Log“). Diese Audit-Logs sind in Dataverse selbst (werden auf separate Storage-Kategorie Log gezählt). Sie können über das Power Platform Admin Center exportiert werden oder per API abgerufen. Nützlich, wenn Sie z.B. nachschauen müssen: „Wer hat diesen Datensatz letzte Woche gelöscht?“ Dann in Audit nachschauen. Für DSGVO und interne Kontrollen ist das Gold wert. Nachteil: storage-intensiv, sollte man nur für wichtige Felder anmachen, sonst frisst es Platz. – Flow-Approvals Logging: Flows, die Approvals nutzen (Genehmigungsaktionen), loggen diese in einem zentralen „Approvals Center“ (im Flow-Portal und Teams-App). Das ist gut, um den Status einer bestimmten Anforderung nachzuvollziehen. Man kann das aber auch prozessspezifisch in Daten schreiben. Je nach Compliance (z.B. signifikante Freigaben) würde ich immer Flow-seitig in einer eigenen Tabelle festhalten: „Vorgang X genehmigt am Y durch Z“. So hat man System-of-record unabhängig vom Flow-Engine. – Power BI Logging: Für Power BI gibt es auch Telemetrie: – Activity Log: wer hat welchen Bericht wann aufgerufen/exportiert. Per PowerShell oder API abrufbar (und ans SIEM leitbar). – Performance Logging: Im Premium Kapazität Monitor sieht man CPU-Auslastung, Query-Dauer, etc. Auf Pro-niveau aber begrenzt (dort nur End-User refresh logs). – Error log: man kann im Admin Portal sehen, ob DataSet refresh fehlgeschlagen (und Grund). Ein engagiertes Team würde für BI-Dashboards, die viele Zuschauer haben, ein Monitoring einrichten: z.B. „Refresh hat länger als 1h gedauert => Alarm“, oder „Nutzerabfrage überlastet ständige CPU => vllt. Model optimieren“.

Zusammenfassend: Telemetrie ist reichlich vorhanden – die Kunst ist, die richtigen Daten auch wirklich anzuschauen. Daher…

Security Operations (SecOps) in der Power Platform

Hier geht es darum, wie man sicherheitsrelevante Vorkommnisse erkennt, reagiert und vorbeugt: – DLP Policy Verstöße: Normalerweise blockt die Plattform ja gleich, aber SecOps sollte Reports bekommen, wenn z.B. jemand versucht etwas Verbotenes zu tun. Im CoE-Kit gibt’s einen Flow „Log DLP block events“. So können Sie z.B. sehen: „User X wollte Twitter-Connector nutzen, wurde geblockt“. Daraus kann SecOps beurteilen: war das ein fahrlässiger Versuch (User schert sich nicht um Policy) – dann Schulung; oder hatte der User einen legitimen Grund? – dann evtl. Policy überdenken oder Ausnahme. – Ungewöhnliche Aktivitäten: Das Security-Team möchte vielleicht wissen, wenn z.B. – plötzlich sehr viele Apps auf einen externen Connector zugreifen (evtl. Mass-Exfiltration?), – oder wenn ein Admin-User zu ungewöhnlichen Zeiten Environment-Einstellungen ändert (Kompromittierung?). Diese Dinge kann man via Audit-Log oder Azure AD Logs aufspüren. Ex: Create ein Alert „wenn ein zweiter Globaler Admin sich selbst Power Platform Admin gibt“ – selten, aber falls Team compromised. – Incident Response: Was tun, wenn eine App Sicherheitsproblem hat? – Sie haben z.B. festgestellt, eine App ist freigegeben für Leute, die eigentlich keine Daten sehen dürften (Verstoß gegen Berechtigung). Sofortmaßnahme: Admin kann im Admin Center die App deaktivieren (sofort steht „disabled“ dran, niemand kann öffnen). Dann mit dem Owner klären, fixen, neu teilen. – Wenn ein Flow Amok läuft (z.B. endlose Schleife spamt E-Mails): Admin kann Flow abschalten (in Portal off setzen) oder einfach Owner-Konto disabled (stoppt alle Flows von dem). Besser: Notfall-Berechtigung ans CoE Team, damit die in jeweiliger Env Flows off schalten dürfen. – Wenn Datenpanne (versehentlich Kundendaten extern geschickt): SecOps muss bekannte Verfahren greifen lassen (Meldung an DSB, Forensik: was, wann, wer). Hier sind Logs zum Glück da, um Impact festzustellen (Flow-Lauf Log: „Sende Email an…“). Gut, wenn man im Nachhinein auch aus Telemetrie sieht, welche Datensätze betroffen. => Planen Sie im Incident-Response-Handbuch Power Platform als mögliches System mit ein. – Patching & Updates: – Security Operations sollte auch sicherstellen, dass z.B. On-Premises Data Gateway stets aktuell gepatcht ist, weil ein veralteter Gateway potenziell Angriffsfläche (Lücke) bieten könnte. Gateways sendet man ergo in den Patch-Zyklus der Firma (man sieht im Admin Center, welche Versionen und ob up-to-date). – Auch, wenn Microsoft mal kritische Patches in Platform rollt (z.B. in 2024 gab’s einen OData Feed bug), dann CoE Team muss schnell informieren: „Bitte updaten eure Power BI Desktop, da old version unsicher“ etc. – User Management & Access Reviews: – SecOps/Governance sollte regelmäßige Access Reviews machen: wer hat alles Environment Admin Rechte? Wer hat wichtige Apps geteilt? Über Zeit kann es sein, dass Leute Rollen gewechselt haben, aber noch CoE-Admin sind. Also pflegen. – Azure AD Conditional Access Policies pflegen (z.B. wenn neue risk factors, wie block older IP ranges). – Multi-Faktor Auth: Check, ob alle sign-ins auf PP from known location etc. (In Azure AD risk policies). – Backup & Recovery Tests: – SecOps interessiert: „Können wir im Fall X Systeme wiederherstellen?“ CoE Team sollte mal testweise ein Environment restore proben – z.B. in Sandbox mal Crash simulieren, restore from backup. So weiss man, wie lang es dauert (~Umgebung mit 5GB DB evtl. 30-60 min). – For disaster: Besser noch: definieren, welche Apps so kritisch, dass Disaster Recovery Plan notwenig. Evtl. vorhalten, in anderer Region eine Standby environment mit Kopie? (Power Platform hat nicht multi-region failover in Basic plan – teure D365 maybe). Aber in Bank/Utility might need fallback arrangement. Not trivial, weil PP stateful DB etc. Minimallösung: täglich Export critical solution + Data to blob – worst case kann man es in neuen Tenant importieren. Halte ich aber in Praxis i.d.R. für Overkill. Platform ist 99.9% verfügbar – Ausfall war vllt. 2h mal in Region – not worth 100k backup environment invest. – Information Protection & Compliance: – Wenn Firma MIP (Information Protection Labels) einsetzt, SecOps könnte schauen: Flows mit Emails – setzen die die korrekten Labels? Oder z.B. Integration: ein Document with Sensitivity Label „Confidential“ wird von AI Builder extrahiert und in Datenbank gespeichert – hat es noch Label? Heikel, da PP nicht nativ Label carry-forward. Kann man bei ingestion an DLP guidelines mit anpacken (z.B. „Dick markierte Dokumente nicht in ungeschützte DB packen“). – Außerdem: falls ein User datensensitiv, kann man eDiscovery an O365 eDiscovery-Tool machen – geht aber nur bedingt, PP Entities tauchen dort (Dataverse might, if if integrated into M365 search). – Responsable AI Oversight: – Mit Copilots & generativer KI neu: SecOps/Compliance-Teams sollten hinschauen, was mit KI gebaut wird (verhindern, dass z.B. KI vertrauliche Infos ausplaudert oder biased decisions). Microsoft fordert „Responsible AI“ usage. In Copilot Studio gibts Telemetrie: welche Agents sind gebaut, wie oft genutzt, und man kann Chat transcripts loggen (um nachzuvollziehen, ob z.B. falsche Antworten gibt). – Möglicherweise sollte ein Gremium KI-Sachen vor Live-Gang absegnen, v.a. im Kundeneinsatz, um Reputationsrisiken zu managen.

Generell merke ich: Security-Operation für Power Platform ist ein gemeinsames Spielfeld von klassischer IT-Security und dem CoE Team. Die Sec-Leute bringen das Knowhow über Threats & compliance, die CoE-Leute wissen, wo in PP man was einstellt und abliest. Zusammen sollte man definieren, was „normales Verhalten“ ist und wo Alarme Sinn machen.

KPIs (Key Performance Indicators) für Power Platform Erfolg und Qualität

Um zu beurteilen, ob Ihre Power Platform-Initiative erfolgreich ist und wo Optimierungspotenzial liegt, helfen Kennzahlen. Diese KPIs können sowohl technische Aspekte als auch Nutzung & Nutzen abbilden:

Einige sinnvolle KPIs: – Anzahl aktiver Apps/Flows: – Definition: Apps/Flows, die z.B. im letzten Monat mindestens 1x genutzt wurden. – Ziel: Soll natürlich mit der Zeit steigen (bei steigender Adoption). – Damit sehen Sie, ob nach dem Start irgendwann Stagnation eintritt (dann neue Use Cases identifizieren). – Monatlich aktive Benutzer (MAU): – Definition: Anzahl unterschiedlicher Nutzer, die im Monat Power Platform Lösungen verwendet haben (egal ob App oder Portal etc.). – Ziel: Je nach Zielgruppe (z.B. alle 3000 Mitarbeiter) soll ein gewisser Prozentsatz PP nutzen. – Ist der Wert sehr klein, nutzt evtl. nur IT, aber noch nicht die Breite – dann Fokus auf Nurturing. – Durchschnittliche Zufriedenheitsbewertung: – Falls Sie Feedback-Mechanismen haben (CoE Starter Kit erlaubt per App „Feedback geben“ mit Sternebewertung z.B.), messen Sie die User-Zufriedenheit mit den Apps. – Ziel: >X Sterne im Durchschnitt. – Ist es niedriger, schauen woran: Performance? UI? Schulungslücke? – Automatisierungsgrad / Zeitersparnis: – Schwerer KPI, aber sehr wirkungsvoll: Schätzen (oder messen) Sie, wie viele Arbeitsstunden pro Monat durch Power Automate-Flows & Co eingespart werden. – Bsp: Summe (Durchläufe Flow A * 10min Ersparnis + Flow B * 30min + …). – Ziel: eine steigende Kurve, die man monetär bewerten kann. – So belegen Sie ROI. – Z.B. „Im Quartal Q4 haben wir 500 Arbeitsstunden an manueller Tätigkeit durch Automatisierung gespart (~ 25k € Wert).“ – Fehlerquote / Zuverlässigkeit: – Z.B. „Anteil fehlgeschlagener Flow-Runs“ oder „App Absturzrate“ (schwerer, da no crash log, aber ggf. user feedback). – Ziel: unter z.B. 1%. – Wenn drüber: zielgerichtet qualitätsverbessern. – Durchschnittliche Performance: – Z.B. „Durchschnittliche Ladezeit einer App-Seite“ oder „Durchschnittliche Laufzeit eines Flows“. – Messen Sie in repräsentativen Apps. – Ziel: definieren, z.B. App Start < 5s, Flow Bearbeitungszeit < 1 min. – Monitoring Tools helfen (App Monitor, Flow run durations via CoE). – Adoptions-Engagement: – Bsp: „Anteil Citizen Developer pro Abteilung“ (wie viele Leute haben selber was gebaut). – Oder „Anzahl Trainings teilgenommen“. – Ziel: Citizen Dev Programm ausweiten. – z.B. 10% Mitarbeiter sollen ein PP Training besucht haben innerhalb Jahr 1. – Kosteneffizienz pro App: – Rechnen Sie: Was kostet uns eine App pro Monat (Lizenzen, Dev-Aufwand) vs. Nutzen. – Das kann man als KPI tracken, um Low-ROI Apps zu identifizieren. – Etwa: „App X = 100€ Kosten/Monat, aber nur 2 User nutzen, je also 50€ p.P – ist das okay?“ – Für interne Tools manchmal egal, aber kann anregen, ungenutztes stillzulegen zugunsten anderes. – Governance KPIs: – Bsp: „% Apps mit zugewiesenem Owner“ (Ziel 100%). – „% Flows mit Service-Konto statt pers. Account“ (Ziel >90% für Prod). – „Anzahl DLP-Verstöße“ (Ziel 0). – „Anzahl offene kritische Wartungsaufgaben“ (Ziel <5). – Support KPIs: – „Anzahl Support-Tickets zu Power Platform pro Monat“. – Ziel: mittelfristig eher sinkend (wenn Systeme stabiler) oder zumindest < X pro 100 Nutzer. – „Durchschnittliche Lösungszeit Ticket“. – Falls sehr hoch: evtl. Support besser schulen oder Komplexität reduzieren. – Security KPIs: – „Anzahl Sicherheitsvorfälle (z.B. DLP Blocks, unautorisierte Zugriffsversuche)“. – Hier will man minimal. – „Audit-Funde bei Prüfung“ – ideal 0.

Um die KPIs anschaulich zu machen, stellen wir sie am besten in Tabellenform dar, wie gewünscht:

Beispiele für KPIs und Zielvorgaben:

KPI	Definition/Messung	Zielwert
Aktive Apps (monatlich)	Anzahl Apps, die mind. 1× pro Monat genutzt wurden (alle Environments)	Steigerung um +10% pro Quartal im ersten Jahr; danach konstant wachsend
Monatlich aktive Nutzer (MAU)	Anzahl eindeutiger Benutzer, die pro Monat Power Platform Apps/Flows aktiv genutzt haben	>20% der Mitarbeiter bis Q4; langfristig >50% im Unternehmen
Durchschnittliche Flow-Fehlerquote	Anteil fehlschlagender Flow-Runs an allen Runs, gemittelt über alle produktiven Flows	<2% Fehlschläge (nach initialer Stabilisierungsphase)
App Performance (Ladezeit)	Ø Ladezeit/Hauptbildschirm einer repräsentativen Kern-App (in Sekunden, gemessen mit Monitor)	<5 Sekunden Ladezeit im Durchschnitt
Automatisierungs-Ersparnis	Geschätzte Zeit, die durch Power Automate pro Monat eingespart wird (Summe aus Standardzeiten * Anzahl Flow-Durchläufe)	>500 Stunden/Monat nach Jahr 1 (entspricht ~3 Vollzeitkräften); jährlich +20% Steigerung
Nutzerzufriedenheit	Durchschnittliche Bewertung (1–5) der Power Platform-Lösungen durch Endanwender (Feedback-Umfrage oder App-intern)	>4 von 5 Sternen Zufriedenheit
Support-Tickets pro 100 Nutzer	Anzahl eingehender Helpdesk-Tickets bezogen auf 100 aktive Nutzer pro Monat	<5 Tickets/100 Nutzer; Tendenz fallend durch bessere Schulung
Durchschnittliche Ticket-Lösungszeit	Zeit vom Öffnen bis Schließen eines Power Platform Supporttickets (in Stunden)	<24h bei Normal-Priorität; <4h bei hoher Priorität (während Geschäftszeiten)
DLP-Policy Verstöße (monatlich)	Anzahl der blockierten Aktionen/Flows aufgrund der Data Loss Prevention Richtlinien pro Monat	0 (Zero-Tolerance-Ziel; bei Auftreten Analyse & Schulung)
Apps ohne zugewiesenen Owner	Anteil der produktiven Apps, die keinen definierten Verantwortlichen (Owner) mehr haben (z.B. wegen MA-Austritt)	0% (jedes System hat klaren Verantwortlichen)
Einhaltung Release-Prozess	Anteil der Änderungen, die via definiertem ALM-Prozess (Dev->Test->Prod) erfolgen, statt direkt in Produktion	100% bei geschäftskritischen Apps; >=90% insgesamt
Schulungsteilnehmer Citizen Dev	Anzahl Mitarbeiter, die an mind. einer Power Platform-Schulung oder -Community-Veranstaltung teilgenommen haben	>100 Teilnehmer im ersten Jahr; danach stetige Zunahme (Community wächst)
ROI / Kosten-Nutzen	Verhältnis aus geschätztem Nutzen (Zeit/Geld) zu Kosten der Plattform (Lizenzen, Betrieb) – z.B. 2:1 bedeutet doppelter Nutzen vs. Kosten	>1,5 : 1 im Jahr 1 (50% mehr Nutzen als Kosten); >3 : 1 in Jahr 3 (Investition trägt sich mehrfach)

Natürlich müssen die konkreten Zahlen an Ihr Unternehmen und Reifegrad angepasst werden. Aber KPIs wie diese geben Ihnen und dem Management ein Steuerungsinstrument. Man sieht z.B., ob nach initialem Hype vielleicht die Nutzung stagniert – dann müsste man nachsteuern (neue Abteilungen onboarden, Erfolgsgeschichten teilen). Oder wenn die Fehlerquote hochgeht – dann liegt es evtl. an zunehmender Komplexität, also mehr Testen und Guidelines nötig.

Wichtig: KPIs sollen nicht dazu dienen, Citizen Developer unter Druck zu setzen oder „Big Brother“ zu spielen. Sie dienen dem Überblick und der kontinuierlichen Verbesserung. Teilen Sie diese Kennzahlen ruhig mit allen Beteiligten („Schaut her, wir haben schon 1000h Arbeit automatisiert – super! Wo finden wir die nächsten 1000?“). Das motiviert und zeigt den Sinn der ganzen Aktion.

Zum Thema Qualität haben wir übrigens einige Aspekte in Best Practices (z.B. Code Review, Testing) und KPIs abgedeckt. Qualitätssicherung soll integraler Bestandteil sein, aber am Ende zählt, was der Nutzer empfindet. Und dafür sind KPIs wie Zufriedenheit und Performance die Messlatten.

Fazit dieses Abschnitts: Überwachen Sie Ihre Power Platform instanzen genauso sorgfältig wie traditionelle IT-Systeme. Nutzen Sie die vorhandenen Tools (Admin Analytics, CoE-Dashboards, Audit-Logs), um Probleme früh zu erkennen – sei es Performance-Engpässe oder Sicherheitsvorfälle. Gleichzeitig definieren Sie Erfolgskennzahlen, um intern den Mehrwert zu belegen und Schwachstellen anzugehen. Dann bleibt Ihre Power Platform nicht nur sicher und robust, sondern wird auch stetig besser und wertvoller für Ihr Unternehmen.

10. Zusatzfunktionen & Pro-Dev-Brücke

Auch wenn die Power Platform eine Low-Code/No-Code-Welt ist, so endet ihre Reise nicht dort. Es gibt zahlreiche Zusatzfunktionen und Möglichkeiten, wie professionelle Entwickler (Pro-Devs) tiefer eingreifen oder die Plattform erweitern können. Gerade wenn man an Grenzen stößt, kann man mit diesen Erweiterungen die Brücke zur klassischen Softwareentwicklung schlagen. Schauen wir uns einige dieser Optionen an: Custom Connectors, Plug-ins, PCF (Power Apps Component Framework), Process Mining sowie die Integration mit Azure-Diensten.

Custom Connectors

Die Power Platform bietet wie gesagt Hunderte eingebaute Connectoren. Aber was, wenn Ihr Unternehmen ein sehr spezielles System hat, für das es (noch) keinen vorgefertigten Connector gibt? Oder ein interner Microservice mit eigener API? Hier kommen Custom Connectors ins Spiel.

Ein Custom Connector ist im Grunde eine von Ihnen definierte Schnittstelle, die Sie der Power Platform hinzufügen. Man beschreibt dem Connector: – Basis-URL des API-Endpunkts (z.B. https://api.meinefirma.de/v1/), – die Authentifizierungsmethode (z.B. API-Key, OAuth2, etc.), – und die verfügbaren Aktionen/Trigger (HTTP-Methoden, Pfade, Parameter, Response-Schema).

Technisch basiert das oft auf einer OpenAPI (Swagger) Definition. Sie können also, falls Ihre Entwickler eine Swagger-Datei Ihrer API haben, diese quasi importieren, und der Custom Connector ist fast fertig. Alternativ füllen Sie ein Formular im Connector-Designer aus, um einzelne Calls zu definieren.

Beispiele: – Ihr Unternehmen hat ein eigenes Projektmanagement-Tool mit Web-API. Sie definieren einen Custom Connector „AcmeProjectAPI“ mit z.B. Aktion „GetProjectStatus (ProjectID)“ die GET /projects/{id}/status macht, und „UpdateTask (TaskID, Fields)“ die ein PUT sendet. – Oder Sie haben einen alten SOAP Webservice – auch den kann man (etwas aufwändiger) einbinden; bei SOAP helfen ggf. bereitgestellte Postman-Collections oder Wrapper.

Sicherheit: Da Sie hier eigene Verbindungen herstellen, sollten Sie auf sichere Authentifizierung setzen – idealerweise OAuth2 (mit Azure AD Auth). Das bedeutet: Man registriert das Zielsystem als Azure AD App und der Connector nutzt dann dieses Token, sodass Azure AD die Auth übernimmt. So haben Sie zentrales Identity-Management. Wenn das nicht geht, gehen auch API Keys – aber die liegen dann verschlüsselt im Connector (nur Admins sehen sie). Besser als in Klartext in einem Flow-HTTP-Schritt.

Verteilung: Custom Connectors sind im Prinzip Environment-spezifisch. Wenn Sie einen Connector erstellt haben, können alle in der Environment ihn nutzen (sofern DLP nicht blockt). Man kann Connectors auch im Org-Ressourcen Katalog veröffentlichen, dann sind sie global verfügbar. Aber das sollte die CoE/IT steuern, um Chaos zu vermeiden.

Governance: Prüfen Sie die Custom Connectors, bevor Sie sie freigeben – quasi Code-Review, ob sie nicht ungewollt Daten rausgeben. Setzen Sie DLP Policy: Standardmäßig fallen Custom Connectors in „Nicht kategorisiert“. Besser: Schieben Sie interne Custom Connectors in „Business“ Kategorie (denn die sind vertrauenswürdig intern). Alle fremden (von Marketplace importiert) ggf. in Non-Business.

ProDev-Anteil: Meist erstellen Pro-Dev-Entwickler diese Connectoren, da sie am besten die API kennen. Für Citizen Devs ist das definieren eines JSON-Swagger mit Auth-Flow evtl. zu viel. Aber einmal erstellt, können Citizen Devs es wie jeden Standard Connector nutzen – toll, so wird aus schwer konsumierbarer API ein einfaches Lego-Teil.

Wartung: Wenn sich die API ändert (neue Parameter), muss der Connector angepasst werden. Planen Sie, wer das pflegt (wahrscheinlich das Entwicklungsteam des API-Services).

Plug-ins (für Dataverse)

Plug-ins sind Stücke C#-Code, die auf dem Dataverse-Server laufen, ausgelöst durch Datenereignisse. Das ist High-End-Erweiterung, v.a. im Dynamics 365 Umfeld bekannt. Warum? Weil man damit Dinge erreichen kann, die mit Bordmitteln nicht gehen, z.B.: – Komplexe Datenvalidierungen oder Berechnungen während ein Datensatz gespeichert wird (im Transaction Scope). – Cross-System Integrationen oder Batching direkt im Dataverse statt erst per Flow asynchron.

Beispiel: Immer wenn ein Datensatz „Bestellung“ erstellt wird, soll automatisch der Status berechnet und evtl. ein Rabatt hinterlegt werden, ABER nur, wenn die Summe > X und Kunde VIP und Lagerbestand geprüft. Sowas könnte man zwar mit Flows (Workflows) auch machen, aber Flow ist asynchron (nach Speichern). Ein Plug-in könnte vor dem Speichern eingreifen und z.B. das Feld „Genehmigung erforderlich“ setzen, falls bestimmte Kriterien. Das ließe sich in Plug-in in einigen Zeilen C# tun und garantiert, dass es transaktional erfolgt (sprich, wenn das Plugin einen Fehler wirft, wird der ganze Schreibvorgang abgeblasen – das kann man nutzen, um „invalid“ Saves zu verhindern mit Fehlermeldung an Nutzer).

Plug-ins werden als .NET Assemblies erstellt (man referenziert die Dataverse SDK, schreibt eine Klasse implementiert IPlugin, registriert sie mit Tooling auf Events wie Pre-Operation Create von Entity X). Das ist was nur Pro-Devs tun (man braucht Visual Studio etc.).

Wenn man aber Dynamics 365 Produkte hat, hat man meist solche Plug-ins eh (z.B. die Business Logic in CRM oft als Plugin implementiert). Dieselbe Infrastruktur steht auch in „rein Power Platform“ Umgebungen zur Verfügung.

Einschränkungen: – Plug-ins dürfen nicht ewig laufen (Time-out ~2 Min). Und sie laufen in Sandbox (keine direkten externen Aufrufe ohne spezielle Möglichkeiten). – Sie belasten die Performance, wenn zu viele/häufig getriggert – also nur einsetzen, wenn unbedingt nötig. – Sie sind schwerer zu debuggen (aber es gibt Trace-Logging). – Deployment geht via Solutions (so ALM-fähig).

Typische Einsatzfälle: – Komplexe Geschäftsregeln: z.B. Generiere automatisch eine Seriennummer nach bestimmtem Muster, wenn Datensatz erstellt (kann man teils mit „Business Rules“ machen, aber die sind limitiert). – Integration bei Datenänderung: z.B. Duplikatprüfung: Wenn neuer Kontakt erstellt, durchsuche DB auf ähnliche – geht als Plugin synchron netter (gibt es sogar Out-of-box Duplicate check as plugin). – Benutzerdefinierte Aktionen: Man kann in Dataverse sog. „Custom Actions“ definieren (im Solution custom process), und diese mit Plugin-Logik hinterlegen. Dann kann ein Flow oder App diese Aktion aufrufen wie einen API-Call (z.B. „GenehmigeRechnung“ custom message – ruft Plugin, das checkt Budget etc. und ändert Status). – Also, es ist like server side scripting in traditional DB.

Wichtig: Jedes mal, wenn wir Plugins einsetzen, steigert sich die Komplexität. Daher, best practice: Erst schauen, ob es mit Flow oder Business Rule geht. Nur wenn Performance oder Transaktionsbedingung es erfordert -> Plugin. Sonst Low-Code first. Und wenn Plugin, immer quellcode-versionieren und dokumentieren, weil Citizen Devs sehen davon nix – es passiert auf Server, „magisch“.

Power Apps Component Framework (PCF)

Canvas- und Model-Driven-Apps haben viele Standardsteuerelemente (Textfelder, Dropdowns, Datentabellen…). Aber manchmal will man etwas individuelles: – Ein schicker Graph, der so nicht standardmäßig vorhanden ist (klar, in Canvas gibts eine Standard-Chart, aber begrenzt). – Eine Eingabemaske mit spezieller UI-Logik (z.B. ein farbiges Rating-Sternefeld). – Oder Integration eines JavaScript-Widgets (z.B. eine besondere Kalender- oder Diagrammbibliothek). Hier kommt das Power Apps Component Framework (PCF) ins Spiel.

PCF erlaubt es, eigene Steuerelemente für Power Apps zu entwickeln (für Canvas Apps und Model-Driven Forms gleichermaßen). Das ist was Pro-Devs in TypeScript programmieren: – Man richtet das PCF-Projekt (yeoman template etc.), definiert Eigenschaften (z.B. es bindet an ein Datenfeld oder mehrere), – Im Code schreibt man mit HTML/CSS/JS, was in dem Div passieren soll. – Z.B. ruft man im init eine Charting-Library auf, um aus dem übergebenen Datensatz ein Tachometer anzuzeigen. – Oder man reagiert auf User-Input (Click events etc.), callt event an die Power App.

Beispiel: Eine PCF-Komponente „SignaturePad“ – sie zeigt ein Canvas, worauf man mit dem Finger unterschreiben kann. Das Ergebnis (Bild/Base64) wird ans Datenfeld gebunden (z.B. an ein „Unterschrift“-Attribut). Sowas kann man nicht mit Standard-Elems. PCF macht’s möglich.

Die PCF Controls werden in Solutions verpackt und können wie Standard-Controls genutzt werden: – In Canvas Apps taucht es z.B. links unter „Code components“ auf; man zieht es rein und setzt Properties im Advanced Panel. – In Model-Driven sagt man: Feld X soll statt Standardtext ein PCF-Control „RatingStars“ nutzen.

Aufwand: Einfache PCF kann man in ein paar Tagen dev erstellen, aber aufwändigere wie komplette DataGrids mit Inline-Edit z.B. gab’s Community-Controls, die sehr elaboriert sind.

Beispiele: – Microsoft selbst hat viele offizielle PCFs gebaut (z.B. Auto-Complete Dropdown, Calendar View etc.), einige sind so gut, dass MS sie ins Standard übernommen hat. – Die Community teilt PCFs auf pcf.gallery – da gibt’s coole gratis Sachen (Progress bar, Google Maps viewer etc.). – Auch Firmen wie Map Controls, kanban, etc. existieren als Solutions (teils kostenpflichtig).

Wartung: PCFs müssen evtl. upgedated werden, wenn Platform sich ändert oder Browser updates kommen. Also versionieren Sie, und überwachen (die Solutions kann man updaten wie Plugins eben via ALM). DLP: Code in PCF kann theoretisch externecalls machen -> leider (oder zum Glück) laufen PCFs im context of user’s browser, so Netzwerkrufe sind aus user context. Da kann DLP nicht intervenieren – sprich, ein PCF könnte Daten rausschicken. Also nur vertrauenswürdige PCFs einsetzen, Code review wenn von Drittquelle.

Process Mining (Prozessanalyse)

Wir hatten es schon angerissen: „Process Mining“ in der Power Platform meint die Funktion „Prozessberater“ in Power Automate. Microsoft hat durch Zukäufe (Minit) diese Technologie integriert.

Was ist das? Process Mining analysiert vorhandene Prozessdaten (z.B. Event-Logs aus Systemen) und visualisiert den tatsächlichen Ablauf von Prozessen. Es zeigt z.B.: „In 80% der Fälle läuft der Prozess A->B->C, in 15% A->C (Sprung), in 5% A->B->B‘ (Rework) etc.“ Und es berechnet Durchlaufzeiten, Engpässe (z.B. durchschnittlich 2 Tage Verzögerung bei Schritt B in Abteilung X).

In Power Automate kann man im Prozessberater: – Ein Projekt anlegen und Event-Daten hochladen (z.B. CSV mit Spalten CaseID, ActivityName, Timestamp, optional User etc.). – Das Tool generiert ein Prozessmodell und Diagramme: Sie sehen alle Pfade, Häufigkeiten als flussähnliche Diagramme. – Es liefert Metriken: z.B. „Case dauerte Ø 5 Tage, Variation 2-10 Tage, Bottleneck bei Genehmigung (3 Tage Wartezeit)“. – Und es gibt Empfehlungen: „Aktivität X kommt oft vor -> möglicherweise automatisierbar“ (ja, MS ist schlau und schlägt „Mach doch nen Flow dafür“ vor). – Mit der Version in 2025 kann man auch Task Mining: PC aufnehmen wie ein Nutzer klickt, dann Auswertung wie Variation. Aber das ist noch im Kommen.

Process Mining-Projekte in PA sind eine Prima Sache, um Business Prozesse zu verstehen bevor man sie digitalisiert. SecOps hat auch was: es deckt z.B. Abweichungen auf, die vllt. Non-Compliance sind (hey, wieso hat Schritt D 5 Schleifen? Das war so nie vorgesehen).

Lizenzthema: Kleines Mining ist im normalem PA Plan drin (bis 50MB Data = sehr klein). Für echte Logs (100GB) bräuchte man das teure Add-on. Evtl. kann man es mal als POC nutzen und dann Dedizierte Tools / Approvals aus Prozessmining ableiten.

Brücke zu Low-Code: Der Clou ist, nach dem Mining, können Sie identifizierte Schwachstellen gleich mit Power Platform fixen – z.B. „Genehmigung dauert ewig, okay wir bauen ’n Flow zur Erinnerung nach 2 Tagen“. Oder man sieht manuelle Zwischenschritte -> „Oh, das können wir mit RPA automatisieren“. So schließt sich der Kreislauf: Process Mining findet Automatisierungspotenzial, und Power Platform liefert es.

Azure-Integration

Die Power Platform ist eng mit Azure verbandelt unter der Hood (Dataverse -> Azure SQL, Functions etc.), aber auch „extern“ gibt es zig Integrationsmöglichkeiten: – Azure Functions / Web APIs: – Über Connectoren (z.B. HTTP oder Custom Connector) können Sie aus einem Flow oder Canvas-App eine Azure Function aufrufen. Z.B. Sie haben eine hochkomplexe Berechnung, die man nicht im Flow machen will (zu langsam), packt das in C# Function, ruft an mit Param, kriegt Ergebnis. Perfekt, wenn Low-Code Logiklimit erreicht. – Andersrum: Azure Functions kann auch via Service Bus oder so triggered by Dataverse change (Dataverse->Azure plugin via ServiceBus endpoint). Etwas advanced, aber trivialer: Bauen Sie in Azure Logic App if needed (Logic Apps sind „Zwillingsservice“ von Power Automate im Azure Portal, aber teilen Connectors). – Azure Logic Apps vs. Power Automate: – Logic Apps sind quasi „Power Automate für Devs“: im Azure-Portal, mit JSON definitions. Der Vorteil: Sie können Source Code mgmt, supportet echte CI/CD via ARM templates. Und es hat Integration Service Environment Option (dedicated infra, VNet integration). – Ein gängiges Pattern: Power Automate für personal/department flows, Logic Apps für enterprise integration flows (B2B EDI, high volume pipeline). Und: Ein Power App kann auch indirekt eine Logic App triggern (via HTTP call). So hat man heavy-lifting in Azure, UI in PP. – Azure API Management (APIM): – Wenn Sie viele interne APIs haben, packen Sie die doch in APIM. Dieses Gateway kann dann für jede API automatisch einen Custom Connector-Definition exportieren! (gibt’s Integration: „Export to Power Platform“). – So wird ein im APIM registrierter Service schnell in PP nutzbar. – Und Sie centralisieren Security (APIM übernimmt Auth, Logging). – Azure DevOps/GitHub: – Hatten wir in ALM: CI/CD pipelines, Repo mgmt. – Also PP hooking in AzDO is crucial for professional dev cycles. – Azure Repos/GitHub host code (Plug-ins, PCF) aber auch the unpacked solutions. So ProDevs und CitizenDevs kollaborieren (Citizen dev macht Canvas, pro dev review code in repo). – Azure Data Services: – Synapse Link für Dataverse: mit einem Klick können Sie Dataverse-Tabellen in Echtzeit in Azure Synapse Analytics bzw. Data Lake spiegeln (Azure Data Lake Gen2). Das ist super, um Big Data Analytics oder AI mit den Dataverse Daten zu machen, ohne die PP zu belasten. – Umgekehrt, Sie können mit Power BI dataflows aus dem Data Lake oder Warehouse Daten ins Dataverse pumpen, falls nötig (z.B. ML Score zurück ins App). – Azure AI Services: – AI Builder deckt viel, aber es kann Szenarien geben, da wollen Sie den Azure Cognitive Service direkt ansteuern (z.B. spezielle Form Recognizer Modell in Ai). – Klar, es gibt Connector „Azure Form Recognizer“, „Azure Text Analytics“. – Oder Sie rufen per HTTP die Azure OpenAI mit eigenem Modell (wenn MS PP noch nicht bietet). – So nutzen Sie neueste AI im Flow, blechen aber auf Azure Bill. – Oft streitet man: Azure AI vs AI Builder – Faust: AI Builder für Low-mid scale, out-of-box. Azure AI für heavy scale oder custom train with full control, Pro Dev macht’s. – On-Premises via Azure: – Der OnPremises Data Gateway selbst ist ja quasi „Azure Data Factory Self hosted IR“ modul. Man kann in Azure Services (Power BI, PP, etc.) Connect to onPrem through it. – Also Azure Hybrid is encompassed by that gateway piece. – Bsp: Flow uses Gateway to talk to OnPrem SQL; Azure Logic App kann das ebenso (via OnPrem connector). – Power Platform in Azure Solutions: – Man kann Whole PP Solutions as part of azure architecture treaten: z.B. Cloud solution: Web front-end for customers in Azure WebApp, interner Backoffice via Power App hooking on same DB or via connectors. Oder IoT scenario: IoT Hub events trigger Logic App, that uses PP connector to create a case in Dataverse (why not). PP become just another piece orchestrated by Azure. – Und umgekehrt, aus PP Seie: „extremely large calculation needed -> drop data to Azure HPC cluster via connector, get result.“

Konkretes Beispiel Azure Integration: Ein Automobilhersteller nutzt Power Apps für ein Werkstatt-Tool. Wenn ein Wagen im Service ist, gibt Mechaniker VIN ein, kriegt alle Details. Die Daten liegen aber in SAP und im IoT-Data-Lake (Telemetrie). – Über Custom Connectors & APIM ruft die Power App im Hintergrund Azure Functions auf: Function 1 holt SAP-Daten (über SAP .NET Connector, was man in Function easier hostet), Function 2 holt IoT Data aus Cosmos DB, beides wird zack ans App UI gegeben. So merkt Mechaniker nur „app reagiert fix, hat alle Infos“. Ohne Azure-Integration wäre es schwer, direkt SAP & IoT in PP Fluss zu kriegen.

Fazit zu Pro-Dev-Integration: Die Power Platform ist kein geschlossenes System – im Gegenteil, Microsoft positioniert es als „Glue“ zwischen Ihren Datenquellen und Prozessen. Pro-Entwickler können – neue Datenanbindungen schaffen (Custom connectors), – tiefergehende Logik implementieren (Plug-ins), – tolles UI beisteuern (PCF), – oder das rundherum IT-Ökosystem (Azure) einspannen, um das Beste aus beiden Welten zu kombinieren.

Wichtig ist, dass Citizen Developer und professionelle Entwickler Hand in Hand arbeiten, wenn diese Extensions nötig werden. Dafür hat man idealerweise Fusion Teams: gemischte Teams, wo die einen die Prozessexpertise haben und die anderen die technische Tiefe. Wenn diese gut kommunizieren, erreichen Sie mit der Power Platform praktisch die gleiche Mächtigkeit wie Full-Code-Entwicklung, aber behalten das meiste als Low-Code wartbar.

Im Alltag heißt das: Scheuen Sie nicht, bei Bedarf mal einen Entwickler mit ins Boot zu holen, wenn es die Lösung deutlich verbessert. Genauso sollten Entwickler respektieren, dass sie nicht alles neu coden müssen, sondern mit den Low-Code Grundgerüsten viel schneller vorankommen. Diese Brücke macht die Power Platform erst richtig spannend, weil Sie damit weder auf Geschwindigkeit noch auf Individualität verzichten müssen.

11. Schritt-für-Schritt-Einführung: Roadmap mit drei Phasen

Die Einführung der Power Platform in einem Unternehmen ist selbst ein kleines Projekt – oder besser gesagt eine Reise. Es empfiehlt sich, phasenweise vorzugehen, damit man weder überstürzt Chaos riskiert noch zu zögerlich an den Nutzen kommt. Hier skizziere ich eine Roadmap in drei Phasen: Von den ersten Gehversuchen bis zum etablierten Unternehmensstandard.

Phase 1: Grundlagen schaffen und Pilotprojekte (0–3 Monate)

Ziel dieser Phase: Die Plattform vorbereiten, erste Erfahrungen sammeln und Quick Wins demonstrieren.

Schritte: 1. Sponsor & Kernteam etablieren: Zunächst braucht es einen internen Sponsor (z.B. IT-Leiter oder CDO), der den Einsatz der Power Platform unterstützt. Stellen Sie ein kleines Kernteam zusammen – vielleicht 1–2 IT-Experten (können am Anfang auch „nur“ M365-Admins sein) und 2–3 Fachbereichs-Ansprechpartner, die Lust haben, Pionier zu sein. Dieses Team wird später das CoE bilden. 2. Tenant-Einrichtung & Governance-Basics: Aktivieren Sie die Power Platform Dienste im Tenant (sind meist eh schon aktiv mit O365). Richten Sie erste Environments ein: z.B. eine „Sandbox“ für Experimente und eine dedizierte „Pilot Prod“ Umgebung. Konfigurieren Sie wichtige Tenant-Einstellungen: z.B. schalten Sie ggf. Trial-Umgebungen auf „nur Admins“, definieren Sie eine erste DLP-Policy (z.B. alle Social Media = nicht-geschäftlich, interne Standardservices = geschäftlich). Noch nichts Komplexes, aber grobe Leitplanken. 3. Schulung & Inspiration: Schulen Sie das Kernteam und einige interessierte Mitarbeiter (Citizen Dev-Kandidaten) in den Grundlagen: 1–2-tägige Workshops „Einführung Power Apps/Automate“. Zeigen Sie Beispiele (vielleicht aus dieser Doku 😉), um die Fantasie anzuregen. Wichtig, dass alle verstehen: Das ist kein Hexenwerk, man kann schnell was bauen. 4. Pilotprojekte auswählen: Identifizieren Sie mindestens zwei gut abgegrenzte Pilotanwendungen – idealerweise aus unterschiedlichen Bereichen, um breiter zu lernen. Kriterien: kleiner bis mittlerer Umfang (2–6 Wochen Umsetzungszeit), klarer Nutzen (Zeitersparnis oder Schmerzpunkt beseitigen), überschaubare Nutzerzahl. Bsp: Eine Urlaubsantrags-App in HR, oder ein Vertriebs-Dashboard mit Lead-Erfassungs-App. Wichtig: Wählen Sie etwas, das tatsächlich genutzt wird (kein rein theoretischer Fall), damit echtes Feedback kommt. 5. Umsetzung der Piloten: Jetzt Hands-On: Das Kernteam gemeinsam mit den Fachbereichen entwickelt die Pilotlösungen. Hier lernt man by doing: – Einrichten Dataverse/Verbindungen, – Canvas-App bauen, Flow dazu etc., – Nutzer testen lassen und schleifen. Setzen Sie bewusste kurze Sprints (z.B. Wöchentlich Demo der Zwischenstände), um alle mitzunehmen. Das CoE-Team kann hier erste ALM-Schritte üben, aber übertreiben Sie es in Phase 1 nicht – notfalls wird direkt in Prod-Pilot gebaut, falls das pragmatischer ist (man kann sich Tools und Formalismus in Phase 2 aneignen). 6. Erfolgsmessung & Feedback: Nach Go-Live der Pilot(e) (Ende Phase 1) sammeln Sie aktiv Feedback: Hat es den erhofften Nutzen gebracht? Gibt es Kinderkrankheiten? Messen Sie kleine KPIs: z.B. „X Anträge digital gestellt im ersten Monat, geschätzte Bearbeitungszeit halbiert“ oder „10 Vertriebsleute nutzen das neue Dashboard täglich“. Dieses Greifbare ist wichtig für die nächsten Phasen – Erfolge kommunizieren! 7. Grundstein CoE legen: Noch in Phase 1 kann man bereits mit dem CoE Starter Kit experimentieren. Vielleicht installieren Sie es in der Sandbox, um zu sehen welche Daten es liefert. Das Kernteam kann anfangen, eine Governance-Doku zu erstellen (erstes Draft: Ziel der Platform, wer macht was). Außerdem, definieren Sie naming conventions und erste Spielregeln (z.B. „In Pilot Prod Umgebung nur genehmigte Apps“).

Ergebnis von Phase 1: Es gibt konkrete, funktionierende Beispiele im Unternehmen. Die Mitarbeiter sehen „Oh, sowas kann man in ein paar Wochen bauen!“. Das Fundament (Tenant config, Team, DLP) steht, auch wenn noch einfach. Und die wichtigsten Learnings (was lief gut, wo hapert’s?) sind gesammelt, um in Phase 2 breiter zu gehen.

Phase 2: Ausbau und Governance (3–12 Monate)

In Phase 2 geht es darum, aus den Piloten einen skalierbaren Standard zu machen. Man rollt in mehr Bereiche aus, etabliert Governance-Strukturen und integriert die Plattform richtig in die Organisation.

Schritte: 1. Center of Excellence formalisieren: Aus dem Kernteam wird jetzt offiziell ein kleines CoE. Definieren Sie Rollen: z.B. Power Platform Product Owner (overall verantwortlich, meist aus IT), Citizen Dev Lead (kümmert sich um Community), Platform Admin (technische Betreuung). Wenn möglich, geben Sie diesen Rollen auch entsprechende zeitliche Ressourcen (z.B. 1 Person 50% dafür abstellen). Jetzt ist auch ein guter Zeitpunkt, falls nötig, externen Beratungs-Support für ein paar Monate hinzuzuholen, um Best Practices reinzuholen oder Lastspitzen zu decken. 2. Governance & Richtlinien ausarbeiten: Das CoE erstellt eine Governance-Dokumentation. Inhalte z.B.: – Environment-Strategie: z.B. „Pro Abteilung einen Dev und einen Prod Environment“, plus „Default nur für Pers. Tests“. – Security-Rollen: „Abteilungsadmins können in ihrem Prod selber Maker bestimmen, globale Admin genehmigt Environment-Schaffung“. – DLP-Policies verfeinern: Evtl. segmentieren nach Umgebungen (Produktion streng, Dev lockerer). – ALM-Prozess: Ab wann soll ein Projekt den Dev->Test->Prod Weg gehen? – Naming-Konvention (für Umgebungen, Lösungen, Flows). – Support-Prozess grob skizzieren (wer meldet an wen, falls App down?). – Checklisten (siehe später Phase 3 / Checklisten-Abschnitt) – manche kann man jetzt schon definieren. Diese Doku muss nicht perfekt sein, aber es sollte ein offizielles Papier existieren, um Willkür zu vermeiden. 3. Tooling & ALM einführen: Installieren und konfigurieren Sie jetzt das CoE Starter Kit produktiv (in einer CoE-Umgebung). Schalten Sie die wichtigsten Flows an (Inventar, Governance E-Mails). Bauen Sie eine ALM-Pipeline (Azure DevOps oder GitHub) für mindestens einen repräsentativen Entwicklungsfluss auf. Testen Sie das mit einer neuen App: Dev-Umgebung -> in Repo einchecken -> in Test pushen -> Prod. Schulen Sie Maker, wie Solutions und Source-Control funktionieren. Ziel: In Phase 2 sollen alle kritischeren Projekte diesen Weg nutzen. 4. Weitere Anwendungsfälle identifizieren und umsetzen: Jetzt öffnen Sie die Plattform für mehr Bereiche. Laden Sie Fachbereiche ein, Ideen zu pitchen. Das CoE hilft zu priorisieren: Wählen Sie z.B. 5–10 neue Anwendungsfälle über Phase 2 verteilt. Vielleicht eine Mischung aus „Low Hanging Fruits“ (schnell umsetzbar) und „wichtigen Herausforderungen“ (die signifikanten Business Impact haben). Mögliche Bereiche: Finanzen (z.B. Spesen-App), Produktion (Audit-Checklisten), Vertrieb (Mobil-App fürs CRM-Feld), etc. Für jedes Vorhaben: Stellen Sie Fusion Teams zusammen – jeweilige Fachanwender + IT/CoE Unterstützung. Hier zahlt es sich aus, in Phase 1 das Wissen aufgebaut zu haben: Einige Pilot-Mitarbeiter sind nun Botschafter in ihren Abteilungen. Umsetzung am besten in iterativen Zyklen (Agil vorgehen, alle 2-3 Wochen was vorzeigen). Tipp: Zu Beginn der Phase 2 sind manche Teams noch zurückhaltend – vielleicht muss man aktiv auf sie zugehen und „Power Platform Awareness“ schaffen. Evtl. interne Roadshow: das CoE zeigt in Abteilungsmeetings, was bisher gemacht wurde und fragt nach Prozessen, die man verbessern könnte. 5. Parallel: Schulung und Community ausweiten: In Phase 2 bauen Sie eine Citizen Developer Community auf. – Veranstalten Sie regelmäßige Brown-Bag-Meetings oder Sprechstunden („Power Hour“), wo Maker Fragen stellen und Tipps bekommen. – Richten Sie einen Teams-Channel oder Yammer-Gruppe als Austauschforum ein. CoE beantwortet dort Fragen, aber ermuntert auch die Maker, sich gegenseitig zu helfen. – Organisieren Sie ggf. einen Hackathon oder Ideenwettbewerb: z.B. ein 2-Tage-Event, wo Teams an einer Challenge eine App/Flow bauen – das fördert Fähigkeiten und liefert vllt. gleich eine neue Lösung. – Stellen Sie Lernressourcen bereit: MS Learn Pfade, interne Quickstart-Guides, diese Governance-Doku etc. Vielleicht auch eLearning-Lizenzen, falls vorhanden. 6. Integration in IT-Landschaft: Bis Ende Phase 2 sollten Sie die PP auch in die IT-Prozesse eingebettet haben: – Nehmen Sie Power Platform in die IT-Strategie auf (z.B. als offizielles Tool für „Business-Lösungen in Eigenentwicklung“). – Passen Sie ggf. das Service Management an: IT Helpdesk weiß nun wie mit PP-Tickets umgehen, vllt. gibt’s nen Ticketkatalogeintrag. – Denken Sie an Lizenzmanagement: Etablieren Sie, wer Lizenzen nachkauft, wie das verrechnet wird. Evtl. best practice: zentrale Purchase, aber Umlegung auf Fachbereich-Budgets, damit Wertschätzung da ist. – Azure Integration: Falls relevant, in Phase 2 könnten Sie auch die ersten Azure Dev Resourcen anbinden – z.B. bestehende APIs via Custom Connector verfügbar machen. – Datenstrategie: Legen Sie Standards fest, wo Daten der Apps liegen sollen. Vielleicht entscheiden Sie: „Primär Dataverse, außer begründete Ausnahmen“, oder „Für kleine Teams bis 1000 Einträge darf SharePoint Liste genutzt werden, dann migrieren“. 7. Erfolge messen und kommunizieren: Jetzt, da etliche Lösungen live gehen, ist es wichtig das Top-Management auf dem Laufenden zu halten. Erstellen Sie am Ende von Phase 2 einen Power Platform Statusbericht: – Anzahl implementierter Apps/Flows, – Beispiel-Erfolge (mit Aussage der Fachbereichsleiter „Wir sparen 30% Zeit in Prozess XY dank der App“), – Kennzahlen (evtl. ROI Rechnung). – Nennen Sie auch noch offene Herausforderungen (z.B. „Fachbereich Z zögert noch mitzuziehen, hier planen wir Workshop“). Das Ganze dient dazu, breitere Unterstützung und ggf. Budget für Phase 3 zu sichern. Vielleicht zeigen Sie das auf Vorstandsebene kurz vor Jahresultimo, um dort Rückendeckung zu erhalten.

Ergebnis von Phase 2: Die Power Platform ist nun keine Spielerei mehr, sondern als fester Baustein anerkannt. Es gibt definierte Strukturen: CoE, Governance-Regeln, einen wachsenden Nutzerkreis. Mehrere Abteilungen haben funktionierende Apps/Automationen im täglichen Einsatz. Natürlich tauchen auch neue Anforderungen auf (man stellt fest „Oh, wir brauchen doch mehr Kapazität hier“ oder „Jenens Problem ist noch ungelöst“) – aber das ist normal. Wichtig ist: Die Kultur hat sich gewandelt – Fachleute haben erfahren, dass sie selbst Digitalisierung gestalten können.

Phase 3: Skalierung und Etablierung (12–24 Monate und fortlaufend)

Phase 3 geht über ins normale Programm: Hier skalieren Sie die Nutzung über das ganze Unternehmen und optimieren fortlaufend, um langfristig den Nutzen zu maximieren und Risiken zu minimieren. Im Grunde wird die Power Platform jetzt Teil des „Business as Usual“.

Schritte: 1. Unternehmensweite Ausrollung: Machen Sie einen Plan, um alle relevanten Geschäftsbereiche zu erreichen. Eventuell priorisieren: Wo liegen die größten Potenziale? – Große Abteilungen ohne eigene IT kriegen jetzt verstärkt Aufmerksamkeit (z.B. Operations, Logistik). – Möglicher Ansatz: „Citizen Development Program Batch 2“ – eine neue Kohorte an Citizen Devs ausbilden, vielleicht 1-2 pro Abteilung, die dann vor Ort Lösungen treiben. – Spätestens jetzt sollte auch der Betriebsrat einbezogen sein, falls noch nicht geschehen, da Endanwender-Software und Automationen in breitem Umfang eingesetzt werden (Stichwort Mitbestimmung bei Tools, Qualifikation der Mitarbeiter etc.). Ideal: Der BR ist wohlwollend, weil Sie ihnen transparent den Zweck (Entlastung der MA von Routine) erläutern. 2. Fortgeschrittene Governance & Compliance: – In Phase 3 verfeinern Sie alle Governance-Aspekte. – Führen Sie regelmäßige Audits durch: z.B. vierteljährlich prüft CoE stichprobenartig Lösungen auf Konformität (Namenskonvention, Sicherheitsrollen, keine sensiblen Hardcodings etc.). – Aktualisieren Sie die DLP-Policy nach Bedarf (neue Connectors? Evtl. strengere Regeln, wenn mehr Leute Zugriff haben). – Managed Environments-Feature aktivieren: Dieses bietet z.B. Bulk-App-User-Removals, Insights-Dashboards etc., was nun bei großer Skala sinnvoll ist. – Richten Sie Backup-Pläne ein: z.B. regelmäßige Backups der Produktivumgebungen (Power Platform kann das automatisieren lassen), und definieren Sie Notfallübungen (z.B. einmal eine Env Recovery testen). – Kostenkontrolle: In Phase 3 hat man signifikante Lizenzen im Einsatz. Etablieren Sie einen Rhythmus (monatlich/ quartalsweise), bei dem CoE und Controlling die Nutzung vs. Kosten prüfen. Nicht um Leute zu gängeln, sondern um Effizienz sicherzustellen (z.B. „Wir zahlen 100 Flows, aber nutzen nur 50 – lizenzen anpassen? Oder in 6 Monaten wird’s mehr?“). – Compliance Reviews: Binden Sie interne Revision und Datenschutz ein, um die Lösungen (insb. solche mit personenbezogenen Daten) abzunehmen. Zeigen Sie, dass audit-Logs da sind, Löschkonzepte umgesetzt etc. Phase 3 ist wichtig, um externen Prüfern zu beweisen, dass die Citizen-Lösungen denselben Standards genügen wie klassische IT-Lösungen. 3. Technische Optimierung & DevOps: – Hier werden Sie vlt. in fortgeschrittene Gefilde gehen: – ALM-Deployment voll automatisieren: z.B. Pull Request im Git, der eine App-Änderung durchspielt bis Prod, one-click. – Quality Gates: Use Solution Checker in pipeline mit Fail if issues > threshold, sodass Code qualitativ stabiler ist. – Performance Tuning: Das CoE sollte aus Metrics lernen: identifiziert langsame Apps und hilft, diese zu tunen (vielleicht anstatt SharePoint auf Dataverse migrieren, Indexe setzen etc.). – Pro-Dev Integration voll ausnutzen: Bis Phase 3 haben Sie sicher auch Fälle, wo Pro-Dev was zugebaut hat (Custom Connector, PCF). Machen Sie das zum Standardrepertoire. Bsp: Wenn in mehreren Apps derselbe „Custom Download PDF“ PCF sinnvoll wäre – einmal entwickeln, wiederverwenden. – Upgrades & Updates: Etablieren Sie, wer MS Release Notes trackt und Funktionsupdates steuert. In Phase 3 hat man evtl. den „2026 Release Wave 1“ vor sich – plant man Features aktiv ein? – Denkbar auch: Ab Phase 3 Bindung an Tools wie „Application Lifecycle Insights“ (coming?), das anzeigt, welche Apps alt sind / neu deployed etc. 4. Wartung & Lebenszyklus: – Phase 3 ist viel Wartung: Alte Apps ablösen, neue Versionen einführen. Bauen Sie Versionierungskonzepte aus. Z.B. „major apps haben SemVer Version, und Release Notes werden kommuniziert an Nutzer via Portal“. – Machen Sie regelmäßige Housekeeping-Aktionen: z.B. Halbjährlich „Aufräumtag“ wo CoE mit Abteilungen ungenutzte Sachen löscht (um Wildwuchs zu begrenzen). – Monitor Kapazitäten: i.e. Storage. Phase 3 vllt. >80% DB capacity belegt -> Plan add-ons oder archivieren alte data (vllt. move to Azure). 5. Kultur verankern: – Nach ~2 Jahren sollte Citizen Development im Mindset verankert sein. Das heißt aber nicht, dass CoE aufhören kann. – Machen Sie das kontinuierlich attraktiv: Belohnen Sie erfolgreiche Lösungen (z.B. interner „Digitalisierungspreis“ für beste App des Jahres). – Halten Sie die Community-Events bei, oder sogar institutionalisiert (z.B. ein monatliches „App & Pizza“ Treffen). – Bauen Sie Power Platform ins Onboarding neuer MA ein („Wir haben übrigens internes App-Store, gern nutzen oder erweitern“). – Achten Sie aber auch, die Balance zu halten: Nicht jeder muss Citizen Dev sein – es wird immer Leute geben, die einfach ihre Standardtools nutzen. Das ist okay. Zwingen Sie niemanden, aber bieten Sie allen die Chance. 6. Strategische Nutzung & Großprojekte: – In Phase 3 könnten auch größere Digitalisierungsinitiativen die Power Platform als Teil einplanen. Z.B. Sie entscheiden, ein altes Access-basiertes QM-System wird komplett in Power Platform neu gebaut statt teurer Fremdsoftware. Solche „Product“-Apps (mit hunderten Usern) können nun realisiert werden, weil das Vertrauen da ist. Diese benötigen dann vlt. dedizierte Projektteams, Pro-Dev Integration etc. Im Grunde verschwimmt die Grenze: es wird „normale Softwareentwicklung mit Low-Code-Ansatz“. – Auch externe Integration: Möglicherweise öffnen Sie Teile der Platform für Partner oder Kunden (via Power Pages oder B2B). Phase 3 heißt ja, reif genug um über die Unternehmensgrenzen zu schauen. 7. Stetige Verbesserung: – Etablieren Sie den Plan-Do-Check-Act Zyklus: CoE sammelt Feedback, passt Governance an, schult nach, misst wieder. – Halten Sie ein Ohr an Microsoft: Neue Features? Vielleicht ein Azure service, der PP ablöst? (eher wird PP ja ausgebaut, aber z.B. vllt. neu „Workflows in Teams“ etc. – bewerten ob relevant). – Bleiben Sie an der Community dran (externe: Microsoft Power Users Forum, etc.), da lernt man viel, was man intern wieder gut einsetzen kann.

Ergebnis Phase 3: Die Power Platform ist fest etabliert. Man hat eine skalierte, geregelte und effektive Low-Code-Plattform. Das Unternehmen profitiert von mehr und mehr digitalisierten Prozessen, schnell realisiert. Die IT hat vom „Gatekeeper“ zum „Enabler“ gewandelt: Anstatt alles selbst bauen zu müssen, stellt sie nun die Bühne und Leitplanken, auf der die Fachbereiche selber Innovation treiben – und springt nur bei Bedarf unterstützend ein. Das Entlastet alle: Fachbereiche fühlen sich unabhängiger und schneller, IT kann sich auf komplexere Sachen konzentrieren ohne hunderte Kleinanfragen.

Natürlich endet Phase 3 nicht wirklich – sie geht in einen fortlaufenden Betriebsmodus über, wie es eben auch bei etablierten Systemen ist. Wichtig ist, dass man die Anfangseuphorie nicht einfach verpuffen lässt, sondern in nachhaltige Strukturen gegossen hat. Dann bleibt die Power Platform ein langfristiger Baustein der digitalen DNA des Unternehmens.

Vielleicht noch als kleine Metapher: Phase 1 war das zarte Pflänzchen säen, Phase 2 das Pflegen und Umtopfen in einen größeren Topf, und Phase 3 das Aussetzen ins freie Feld, wo es zum starken Baum heranwachsen kann. Mit der richtigen Pflege wird dieser Baum viele Früchte (sprich Lösungen) tragen. 🌳😊

12. Checklisten: Governance, Sicherheit, ALM, Betrieb (kompakt und praxisnah)

Checklisten helfen dabei, nichts Wichtiges zu übersehen. Hier habe ich pro Themenbereich praxisnahe Checklisten zusammengestellt, die Sie nutzen können, um Ihren Power-Platform-Einsatz zu überprüfen und abzusichern. Diese Listen können als Vorlage dienen, die Sie an Ihr Unternehmen anpassen.

✅ Governance-Checkliste

• [ ] Rollen & Verantwortlichkeiten festgelegt: Es ist klar definiert, wer die Plattform administriert (CoE, Admins) und wer im Fachbereich für welche App verantwortlich ist (Product Owner je App).
• [ ] Umgebungsstrategie dokumentiert: Anzahl und Zweck der Environments ist festgelegt (z.B. pro Abteilung Dev/Test/Prod, Standard-Env nur für Spielwiese).
• [ ] DLP-Policies eingerichtet: Data Loss Prevention Regeln sind erstellt und anwenden. Sensible Connectoren als „gesperrt/nicht-geschäftlich“ markiert, Business-Daten bleiben in sicheren Bahnen.
• [ ] Namenskonvention vereinbart: Einheitliche Benennungen für Umgebungen, Apps, Flows, Variablen etc. (z.B. Prefix Dept-Abkürzung, sprechende Namen) sind definiert und kommuniziert.
• [ ] Richtlinien für App-Freigaben: Es gibt Vorgaben, wer Apps teilen darf und mit welchem Personenkreis (z.B. Org-weite Freigabe nur nach CoE-Freigabe).
• [ ] Metriken/KPIs definiert: Erfolgskriterien (Nutzerzahlen, Zeitersparnis, Zufriedenheit) sind festgelegt und werden regelmäßig erhoben.
• [ ] Onboarding-Prozess für Citizen Devs: Neue „Macher“ erhalten Schulung/Leitfaden, inklusive Governance-Regeln. Sie wissen, wo sie Hilfe bekommen (Community/CoE).
• [ ] Betriebsrat/Compliance informiert: Relevante interne Gremien (Datenschutz, Mitbestimmung) sind in Governance einbezogen; es gibt keine ungeklärten Bedenken.

🔒 Sicherheits-Checkliste

• [ ] Multi-Faktor-Authentifizierung (MFA) aktiviert: Alle Nutzer (insb. Admins) nutzen MFA fürs M365-Konto, somit auch für Power Platform. Keine schwachen Authentifizierungen offen.
• [ ] Zugriffsrechte geprüft: Prinzip der minimalen Rechte umgesetzt. Nur berechtigte Personen sind Environment-Admin oder Co-Owner von Apps/Flows. Alte Zugriffe (z.B. von Ex-Mitarbeitern) wurden entzogen.
• [ ] Conditional Access Policies anwendet: Falls erforderlich, Zugriffe auf die Power Platform an Bedingungen geknüpft (z.B. nur mit Firmengerät oder aus bestimmten Ländern).
• [ ] On-Premises Data Gateway aktuell: Installierte Gateways sind auf neuester Version, Zugang beschränkt (mind. WindowsAuth + ggf. nur Dienstkonto). Monitoring für Gateway-Status aktiv.
• [ ] Überwachung für Anomalien: Mechanismen aktiv, um ungewöhnliche Aktivitäten zu erkennen (z.B. M365 Security Alerts bei MassenDownloads, viele Fehlversuche etc.). CoE/ SecOps prüft regelmäßig Audit-Logs.
• [ ] Dataverse Security Roles genutzt: In Dataverse-Apps feingranulare Tabellen- und Feldebenen-Rechte vergeben wo nötig (z.B. HR-Daten nur für HR-Rolle). Keine sensiblen Daten „offen für alle“ in Tabellen.
• [ ] Kein Hardcoding sensibler Daten: Keine Passwörter, API-Keys etc. in Klartext in Apps oder Flows hinterlegt. Nutzung von sicheren Verbindungen (Secure Inputs/Outputs in Flows aktiviert).
• [ ] Backup & Restore getestet: Notfall-Wiederherstellung von kritischen Umgebungen/Apps wurde exemplarisch geübt. Backups werden planmäßig erstellt (und sicher aufbewahrt).
• [ ] Aktuelle Updates/Patches: Plattform-Updates von MS werden verfolgt; lokale Komponenten (Gateway, plugin assemblies) up-to-date. Keine veralteten Versionen im Einsatz, die Sicherheitslücken haben könnten.
• [ ] Compliance sichergestellt: Umgang mit personenbezogenen Daten geprüft (DSGVO-Konformität: Einwilligungen, Auskunft/Löschkonzepte vorhanden). Ggf. sind Audit-Trails aktiviert, Verschlüsselung genutzt.

🔄 ALM (Application Lifecycle Management) Checkliste

• [ ] Entwicklungs-, Test-, Prod-Umgebungen vorhanden: Es gibt getrennte Umgebungen für die verschiedenen Phasen. Niemand entwickelt direkt in Produktion ohne Freigabeprozess.
• [ ] Solutions genutzt: Alle Apps/Flows/Bots, die über die Pilot-Spielerei hinausgehen, sind in Solutions organisiert. Namensschema und Publisher (Firma/CoE) korrekt gesetzt.
• [ ] Source-Code-Versionierung aktiv: Lösungen werden regelmäßig als Unmanaged exportiert und in einem Git-Repository versioniert. PCF/Code-Komponenten ohnehin in Repo. Änderungen damit nachvollziehbar.
• [ ] Build-/Deploy-Pipeline eingerichtet: Ein CI/CD-Prozess (Azure DevOps Pipeline oder GitHub Actions) existiert, um Lösungen von Dev nach Test/Prod zu migrieren, idealerweise automatisiert (inkl. Solution Packager).
• [ ] Konfigurationsdaten getrennt: Environment-spezifische Werte (URLs, Keys, Parameter) sind als Environment Variables oder in separaten Config-Entities gepflegt und nicht hart in App/Flow eingebaut.
• [ ] Change Management Prozess definiert: Es gibt Absprachen, wie Änderungen an bestehenden Apps erfolgen (z.B. Ticket -> Dev -> UAT -> Prod Deploy). Die Fachseite wird in Tests einbezogen und Abnahmen dokumentiert.
• [ ] Solution Checker vor Release OK: Der Lösungs-Qualitätscheck von MS wurde ausgeführt, kritische Befunde behoben. Code-Komponenten geprüft (Linting bei PCF/Plugins).
• [ ] Rollback-Plan vorhanden: Für größere Releases/Updates liegt ein Plan vor, wie man zurück zur vorherigen Version käme, falls Probleme auftreten (z.B. letzte funktionierende Solution-Version bereit, Backups).
• [ ] Dokumentation der Lösungen erstellt: Für jede größere Anwendung existiert ein kurzes Dokument (oder Wiki-Eintrag) mit Beschreibung, Verantwortlichen, Versionshistorie, bekannten Abhängigkeiten.
• [ ] Training/Übergabe an Betrieb: Bevor eine Lösung „produktiv frei“ gegeben wird, sind Support und Nutzer geschult. Für Business-kritische Apps hat der Betrieb (Support-Team) Einblick in Funktionsweise und Wartungshinweise.

⚙️ Betriebs-Checkliste

• [ ] Monitoring-Dashboard im Einsatz: CoE/ Admins nutzen regelmäßig eine Übersicht (z.B. CoE Power BI Dashboard) mit Kennzahlen zu allen Apps/Flows (Nutzung, Fehler, Performance-Hinweise).
• [ ] Regelmäßige Bereinigung: Unbenutzte oder veraltete Apps/Flows werden mindestens quartalsweise identifiziert und entweder archiviert (via Export) oder gelöscht, um Wildwuchs zu vermeiden.
• [ ] Supportorganisation geklärt: Helpdesk-Mitarbeiter wissen, wie mit Power Platform Anfragen umzugehen (es gibt einen internen 2nd-Level via CoE). Antwortvorlagen für gängige Probleme (z.B. „App aktualisieren (F5)“).
• [ ] SLAs definiert: Für wichtige Anwendungen sind Service-Level-Agreements definiert (z.B. „Critical App Wiederherstellung innerhalb 4h“). CoE hat Bereitschaft/Alarmierung eingerichtet, falls so eine App ausfällt.
• [ ] Kapazitätsmanagement aktiv: Speicher-Auslastung (Dataverse) wird überwacht. Geplante Zukäufe rechtzeitig eingesteuert (keine überraschenden Kapazitätsstopps). Ebenso Lizenznutzung vs. -bedarf regelmäßig abgeglichen.
• [ ] Incident-Handling getestet: Es gab mindestens eine Übung oder realen Fall, wo ein Power Platform Incident gemanagt wurde (z.B. Ausfall eines Flows) – Lessons Learned daraus umgesetzt (z.B. verbesserte Alarmierung oder Dokumentation).
• [ ] Kontinuierliche Verbesserung: CoE trifft sich periodisch (z.B. monatlich) mit wichtigen Stakeholdern, um Feedback aus dem Betrieb zu sammeln: Was läuft gut, wo müssen wir nachjustieren (Performance, Usability, etc.)?
• [ ] Neue Features Bewertung: Es gibt einen Prozess, neue Microsoft-Features (z.B. Release Waves) zu prüfen. Falls sinnvoll, werden sie geplant aktiviert und an Nutzer kommuniziert (z.B. „Ab nächstem Monat: Power Apps Offline-Funktion im Einsatz“).
• [ ] Integrationen gepflegt: Schnittstellen zu anderen Systemen laufen stabil. Monitoring für z.B. Fehlschläge bei Schnittstellenflows vorhanden (und Fehler-E-Mails gehen an zuständige Personen, nicht ins Leere).
• [ ] Kostenüberwachung & Optimierung: Die monatlichen Kosten (Lizenzen, Azure Payg) werden vom CoE oder FinOps erfasst. Unnötige Ausgaben identifiziert (z.B. nicht genutzte Trials -> entfernen oder Umwandeln in Prod Lizenz falls doch genutzt). Wenn Sparpotenziale (z.B. Umstieg auf Kapazität statt Pro-User) erkennbar, werden diese verfolgt.

Diese Checklisten sind natürlich nur Anhaltspunkte. Man sollte sie an die eigene Organisation anpassen und lebendig halten – also regelmäßig durchgehen: „Haben wir an alles gedacht?“ Gerade wenn das Programm wächst, hilft so ein kompakter Überblick, um den Zustand der Plattform-Nutzung zu bewerten.

Man kann diese Listen auch als Assessment-Tool nutzen: z.B. einmal pro Quartal abhaken, was erfüllt ist und wo Lücken sind, und dann gezielt die Lücken schließen. So stellen Sie sicher, dass Ihre Power Platform nicht aus dem Ruder läuft, sondern stets auf soliden, geprüften Beinen steht.

13. Tabellen zu Lizenzen, Environments, DLP, RACI, KPIs, Risiken

Klar strukturierte Tabellen fassen die wichtigsten Informationen übersichtlich zusammen. Hier sind geforderte Tabellen zu verschiedenen Governance-Aspekten erstellt. Die Struktur ist so gewählt, dass man sie direkt auf die eigene Organisation übertragen kann.

Lizenzierungsübersicht

Diese Tabelle zeigt die wichtigsten Lizenztypen der Power Platform mit Kosten und typischen Einsatzszenarien:

Lizenztyp	Kosten (ca.)	Enthaltene Leistungen	Wann geeignet?
Power Apps Premium (pro User)	18,70 €/Benutzer/Monat	Unbegrenzt Apps & Power Pages, Premium Connectors, 250 MB Dataverse-Speicher, 500 AI Credits	– Nutzer braucht mehrere Apps <br/>- Volle Flexibilität pro Person
Power Apps Per App	4,70 € pro Benutzer/App/Monat	1 App oder 1 Portal pro Lizenz, Premium Connectoren, Dataverse-Zugriff	– Gezielte einzelne Anwendungen <br/>- Große Nutzerzahl mit wenigen Apps
Power Automate pro User	12,50–15 € /Benutzer/Monat	Unbegrenzte Cloud-Flows, Attended RPA auf User-PC, 5.000 API-Aufrufe/Tag inkl.	– Einzelne Mitarbeiter automatisieren viel <br/>- Dezentrales Automatisieren (Office-Integration)
Power Automate Unattended Bot	~135 € / Bot/Monat	1 unbeaufsichtigter RPA-Bot (läuft 24/7 auf VM), inkl. Cloud-Flows <br/>(+ VM-Kosten falls selbst gehostet)	– Automatisierung ohne User-Eingriff <br/>- Nachts/off-hours Batchjobs <br/>- „virtueller Mitarbeiter“ für Legacy-Systeme
Power BI Pro	~9 € /Benutzer/Monat	Berichte/Dashboards teilen und anzeigen, bis 1 GB Dataset, 8x täglich Refresh	– < 500 interne Nutzer mit BI-Bedarf <br/>- Self-Service BI in Teams/Abteilungen
Power BI Premium Kapazität	ab ~730 € /Monat (F2) bis 4.200 € (P1)	Dedizierte Rechenkapazität, unbegrenzt View-Nutzer, große Datasets (bis 400GB), bis 48x Refresh, AI, Paginated Reports	– Breiter Bericht-Zugriff (auch externe) <br/>- Hohe Datenvolumen & Performance-Anforderungen <br/>- > 500 Nutzer oder unternehmenskritische BI
Power Pages Authenticated	187,20 € / 100 Nutzer/Monat	Authentifizierte externe Portal-Nutzer, 2 GB Dataverse-DB inkl. pro Pack	– Extranet/Portal für Partner, Kunden mit Login <br/>- Community, Self-Service-Seiten
Power Pages Anonymous	~75 € / 500k Seitenaufrufe	Öffentliche (anonyme) Website-Pageviews, skalierbar	– Öffentlich zugängliche Infoseiten oder Formulare (ohne Login)
AI Builder 1 Mio Credits	468 € /Monat	Zusatz-KI-Kontingent für AI Builder (z.B. ~1000 Dokumente auslesen)	– Hohes Dokumentenaufkommen <br/>- Intensive KI-Nutzung über Inklusivvolumen hinaus
Copilot Studio 25k Messages	~187 € /Monat	25.000 KI-Chat-Nachrichten (Generative AI) für eigene Copilots/Power Virtual Agents	– Einsatz von eigenen KI-Bots/Assistants mit hohem Gesprächsvolumen
Dataverse Speicher 1GB (DB)	37,40 € /Monat	Zusatz-Datenbank-Speicher im Dataverse-Pool	– Zusätzliches Datenvolumen nötig (über inkludiertes hinaus, z.B. bei vielen Datensätzen oder Audit-Logs)

Hinweise: Preise zzgl. MwSt, Stand Nov. 2025, können je nach Region/Rabatten variieren. Office 365 beinhaltet bereits Basisrechte für Standard-Apps/Flows (keine Premium-Funktionen). Pay-as-you-go-Modelle über Azure sind alternativ für variable Nutzung (Abrechnung nach tatsächlichem Verbrauch).

Environment-Übersicht

Diese Tabelle zeigt empfohlene Umgebungstypen und deren Zweck in der Governance:

Environment-Typ	Verwendungszweck	Besonderheiten / Richtlinien
Sandbox / Dev-Umgebung	Entwicklung und Ausprobieren durch Maker <br/>(pro Team oder zentral für CoE)	– Volle Maker-Rechte für Citizen Devs <br/>- DLP gelockerter (zu Testzwecken dürfen mehr Connectoren) <br/>- Keine produktiven Daten (Testdatensätze verwenden)
Test / QA-Umgebung	Qualitätssicherung, Abnahmetests <br/>(eine pro wichtigem Projekt oder pro Abteilung)	– Nur CoE/Maker & ausgewählte Tester haben Zugriff <br/>- Enthält Anonymisierte Kopien produktiver Daten (falls nötig fürs Testen) <br/>- Stabile Versionsstände werden hier geprüft, keine Ad-hoc-Entwicklung
Produktiv-Umgebung	Live-Betrieb der Apps/Flows für Endnutzer <br/>(Abteilungs- oder lösungsweise getrennt)	– Strikte DLP (keine riskanten Connectoren) <br/>- Nur CoE-Admin kann neue Ressourcen direkt erstellen (Änderungen kommen via ALM aus Test) <br/>- Enthält echte Daten, regelmäßige Backups aktiv
Default Environment	Persönliche Apps/Flows, Pilotierung kleiner Ideen <br/>(Tenant-weit standardmäßig vorhanden)	– Offen für alle lizenzierten Nutzer zur Notnutzung <br/>- Kein kritisches System hier hosten (unzureichende Kontrolle) <br/>- CoE überwacht und bereinigt periodisch (Aufräumen von „Waisen“-Flows)
Center of Excellence Env	Verwaltung der Plattform (CoE-Kit Dataverse, Admin-Apps)	– Enthält CoE-Steuerungsdaten (Inventar aller Apps etc.) <br/>- Nur CoE-Team hat Zugriff <br/>- Produktionsnahes Logging und Monitoring, ggf. Verbindung zu SIEM
Teams-Umgebung (optional)	Automatisch erstellt bei Nutzung von „Power Apps in Teams“ für ein Team	– Reduziert auf Dataverse for Teams (limitiert in Kapazität/Funktionen) <br/>- Eignet sich für sehr einfache Lösungen im kleinen Teamrahmen <br/>- Governance: tenantweit aktivieren oder deaktivieren je Strategie, CoE sollte Überblick behalten (Inventar via Graph API)
Spezial-Umgebung (optional)	Separate Envs für z.B. ISV-Lösungen, isolierte Projekte oder aufgrund Datenresidenz (Geo)	– Z.B. Environment „RegulatoryCompliance“ mit strengem Zugriff <br/>- Oder Environment in EU vs. US für Datenregion-Trennung <br/>- Einsatz nach Bedarf; sollten dokumentiert und begrenzt werden um Wildwuchs zu vermeiden

Erläuterung: In einem typischen Deployment hat man z.B. pro Abteilung 3 Umgebungen (Dev, Test, Prod). Kleinere Firmen evtl. nur einen gemeinsamen Test und Prod. Wichtig ist, Prod vom Rest zu trennen und Default nicht für kritisches zu nutzen. Naming wie „HR-Dev“, „HR-Test“, „HR-Prod“ ist hilfreich.

DLP-Policy-Kategorien (Beispiel)

Eine beispielhafte Einteilung von Connectoren in einer Data Loss Prevention Richtlinie:

Kategorie	Typische zugewiesene Connectoren	Regeln
Geschäftlich (Business)	– Microsoft 365: SharePoint, Outlook, Teams, Excel <br/>- Datenbanken intern: SQL Server (On-Prem via Gateway), Azure SQL, Dataverse <br/>- Business Apps: SAP, Dynamics 365, SalesForce (sofern genutzt) <br/>- Sonstige vertrauenswürdige: Azure Blob, File System (via GW)	Dürfen miteinander in einem Flow/App kombiniert werden. <br/>Business-Connectoren sollen ausschließlich für dienstliche Daten verwendet werden. Wird standardmäßig erwartet für interne Prozesse.
Eingeschränkt (Non-Business)	– Soziale Netze: Twitter, Facebook, LinkedIn <br/>- Öffentliche Dienste: Dropbox, Gmail, Google Sheets, Reddit <br/>- Sonstige Consumer: SMS, Wunderlist, Weather, RSS	Dürfen nicht gemeinsam mit Business-Connectoren in einem Flow/App auftreten. <br/>D.h. kein Misch-Datenfluss von internen Systemen zu externen Consumer-Diensten. <br/>Zulässig ist Kombi Non-Business unter sich (z.B. Twitter -> Gmail), aber solche Lösungen sollten kritisch geprüft werden.
Gesperrt	– Unsichere/Unkontrollierte: HTTP generisch, SMTP, SQL (direkt übers Internet, ohne Gateway) <br/>- Duplikate von Tools: z.B. Personal OneDrive, Personal Outlook (um private Accounts abzugrenzen) <br/>- Nicht benötigte externe: Alle unbekannten oder Hochrisiko-Connectoren (z.B. Bitcoin-Preis, Spiele-APIs etc.)	Diese Connectoren können gar nicht erst verwendet werden. <br/>Flows oder Apps, die versuchen sie einzusetzen, werden vom System blockiert. <br/>Ziel: Datenabfluss über Kanäle, die IT nicht überwachen kann, komplett verhindern. <br/>Auch Pro-Dev: Eigener HTTP-Aufruf muss via genehmigten Custom Connector erfolgen, direkter HTTP ist blockiert.

Anmerkungen: – Die konkrete Einstufung muss ans jeweilige Unternehmen angepasst werden. Obiges ist ein konservatives Beispiel: Alles Öffentliche in Non-Business, gemischte Nutzung untersagt. – Mindestens sollte HTTP immer blockiert sein, sonst könnten clevere User jede beliebige URL ansteuern. – Die DLP-Policy greift tenantweit oder pro Environment. Evtl. hat man 2 Stufen: z.B. „Dev DLP“ (etwas relaxter, damit man z.B. Tests gegen externe API machen kann) und „Prod DLP“ (sehr strikt). – Wichtig zu kommunizieren: DLP verhindert z.B. dass in einem Flow Daten von SharePoint nach Twitter gehen – diese Flows lassen sich gar nicht speichern. So schützt die Plattform proaktiv.

RACI-Matrix (Verantwortlichkeiten)

Eine RACI-Tabelle (Responsible, Accountable, Consulted, Informed) für das Power Platform Betriebsmodell:

Aufgabe / Prozess	CoE Team (IT)	Citizen Developer (Fachbereich)	IT-Security/ Compliance	Management
Governance-Richtlinien definieren	R (erstellt Vorschlag) <br/>A (verabschiedet)	C (gibt Praxis-Feedback)	C (prüft auf Regeltreue)	I (genehmigt strategisch)
Neue Apps/Flows entwickeln	C (coacht/unterstützt)	R (entwickelt) <br/>A (Fachvorgesetzter genehmigt inhaltlich)	– (nicht direkt beteiligt, außer bei heiklen Daten)	I (bei größeren Projekten über Status informiert)
Qualitätssicherung & Testing	C (stellt Tools & Guidelines)	R (testet fachlich, Datenvalidität)	–	I (bei kritischen Systemen Abnahme-Info)
Deployment (Dev -> Prod)	R (führt Deployment durch oder automatisiert es)	C (prüft in UAT, gibt „Go“ fachlich)	–	I (Release neuer wichtiger Apps wird gemeldet)
Betrieb/Überwachung laufender Lösungen	R (monitoring, first technical response)	– (nutzt, meldet Probleme)	C (definiert Monitoring-Anforderungen für Security-Aspekte)	I (bei gravierenden Störungen informiert)
Support (User-Anfragen)	R (2nd-Level Support bei technischen Problemen)	C (1st-Level fachlicher Support für Endanwender ihrer App)	–	I (wenn Ausfall/Auswirkung groß)
Lizenzen & Kapazitäten verwalten	R (verfolgt Nutzung, kauft nach, ordnet zu)	–	C (prüft Compliance z.B. keine unerlaubte Nutzung von Trial etc.)	A (stellt Budget bereit)
Security & Compliance überwachen	C (implementiert DLP, Audit Logs) <br/> I (bekommt Findings von Sec)	–	R (führt Audits durch, meldet Verstöße) <br/>A (setzt Anforderungen durch)	I (bei schweren Verstößen eingebunden)
Schulung & Community fördern	R (organisiert Trainings, Community Calls)	R (teilt Wissen, evtl. Mentorenrolle zu Junior-Makern)	–	A (fördert Kultur, ermutigt Teilnahme)
Strategie/Weiterentwicklung der Plattform	R (macht Vorschläge neue Features zu nutzen, Roadmap)	C (bringt Ideen/Bedarfe ein)	C (bringt Anforderungen für Sicherheit)	A (entscheidet strategische Weichen, z.B. Investitionen, Freigabe neuer Bereiche)

Legende: – R = Responsible (durchführend verantwortlich), – A = Accountable (endgültig rechenschaftspflichtig / Entscheidung), – C = Consulted (wird einbezogen, mitgestaltend), – I = Informed (wird auf dem Laufenden gehalten).

Man sieht: Das CoE (IT) ist oft R für technische Dinge, Citizen Devs R für inhaltliche Entwicklung. Management ist selten operativ, aber A bei Strategie und Budget. Security springt punktuell als R bei Audits ein, sonst beratend.

Diese Matrix sollte natürlich mit konkreten Rollen im Unternehmen benannt werden (z.B. „Max, IT-Leiter“ als A für Governance etc.). Sie hilft Missverständnisse zu vermeiden („Ich dachte, du kümmerst dich um das Monitoring?!“).

KPI-Übersicht (Kennzahlen & Verantwortliche)

KPI	Definition	Zielwert	Verantwortlich (Tracking)	Maßnahmen bei Abweichung
Anzahl aktive Apps	# Apps mit >0 Nutzungen im Monat	z.B. +5%/Quartal Wachstum im 1. Jahr	CoE (Reporting via CoE Dashboard)	– Ursachenanalyse bei Stagnation <br/>- Erfolgsgeschichten teilen, neue Use Cases identifizieren
Monatlich aktive Nutzer (MAU)	# eindeutige User, die PP genutzt haben	z.B. 200 (nach 6 Mon.), 500 (nach 12 Mon.)	CoE (Admin Analytics)	– Info-Kampagne falls gering <br/>- Abteilungen gezielt ansprechen, Schulungen intensivieren
Durchschn. Flow-Fehlerquote	Fehlgeschlagene Runs / Gesamt Runs (% pro Monat)	Unter 5%	CoE (CoE Log, BI Report)	– Problem-Flows identifizieren & fixen <br/>- Gegebenenfalls Kapazität erhöhen oder Neuversuch-Logik einbauen
Nutzerzufriedenheit (App-Feedback)	Durchschnittsfeedback (1-5 Skala)	>4	CoE (Feedback-App Auswertung)	– Gezielt Feedback analysieren <br/>- Nachbessern (Usability, Performance) bei kritisierten Apps <br/>- User-Schulungen falls Bedienprobleme
Automatisierte Stunden/Monat	Summe geschätzte Zeitersparnis durch Flows/Apps	Soll-Steigerung z.B. +50h/Monat pro Quartal	CoE + Fachbereiche (Schätzung)	– Priorisierung neuer Automationen mit hohem Impact <br/>- Prozessevaluierung: noch manuelle Schritte eliminieren?
Support-Tickets (PP-bezogen)	# Helpdesk-Tickets pro Monat zu PP-Lösungen	Abnehmend (nach Hochlaufphase < 10/Monat)	Helpdesk-Leitung (Ticket-System)	– Häufige Probleme identifizieren und dokumentieren (FAQ) <br/>- Gezielte Nachschulung der Benutzer/Maker
Durchschn. Lösungszeit Ticket	Schnitt Zeit zw. Eröffnung & Schließen (PP-Tickets)	< 2 Arbeitstage	Helpdesk / CoE (Ticket-Report)	– Engpässe im Support prüfen (mehr Ressource nötig?) <br/>- Wissensbasis verbessern, damit 1st-Level mehr selbst löst
DLP-Verstöße	# blockierter Flows/Apps wegen Policy p.M.	0 (oder sehr selten)	Security Officer (Audit Logs)	– Falls >0: mit Ersteller sprechen (Schulung/Bewusstsein) <br/>- Policy ggf. präzisieren <br/>- Eskalation bei vorsätzlichen Verstößen
Budgeteinhaltung (Lizenzen)	Ist-Kosten vs. geplantem Budget (Quartal)	<= 100% (keine Überschreitung)	IT-Controlling + CoE	– Bei Überlauf: Usage prüfen, unnötige Lizenzen stilllegen <br/>- Nachbudget beantragen mit Begründung (ggf. ROI aufzeigen)
Projektdurchlaufzeit (Idee->GoLive)	Schnitt Dauer (in Wochen) für Umsetzung einer neuen App von Freigabe bis Produktiv	z.B. < 8 Wochen bei kleinen Apps	CoE (Projektliste)	– Engpässe identifizieren (Genehmigungsprozesse? Technik?) <br/>- Bei längerer Dauer: Prozess straffen, mehr Ressourcen zuteilen für Dev oder Test
Schulungsquote	Anteil der Zielgruppe (z.B. Business-Analysten), der an PP-Trainings teilnahm	> 60% nach Jahr 1	CoE (Teilnehmerlisten)	– Weitere Trainings anbieten <br/>- Management anhalten, Mitarbeiter zu entsenden <br/>- E-Learning bereitstellen für Selbstlernende

Diese KPIs werden idealerweise in einem Management-Dashboard zusammengeführt, das z.B. quartalsweise dem Lenkungsausschuss oder CIO vorgelegt wird. Verantwortliche im CoE bzw. Fachbereich sorgen für Datenerhebung und -interpretation. Bei Abweichungen sollten konkrete Maßnahmen vereinbart werden. So bleibt das Programm zielgerichtet und transparent.

Risikomatrix (Power Platform bezogene Risiken & Gegenmaßnahmen)

Risiko	Auswirkung	Eintritts-wahrscheinlichkeit	Gegenmaßnahmen / Kontrollen
Unkontrollierter Wildwuchs <br/>(zu viele Apps ohne Übersicht)	– Doppelarbeit durch redundante Lösungen <br/>- Qualitätsprobleme, wenn jeder „bastelt“ <br/>- Wartungsaufwand steigt exponentiell	Mittel (wenn Plattform populär)	– Strikte Governance (DLP, Env-Strategie, Freigabeprozesse) <br/>- CoE-Inventar & regelmäßige Reviews <br/>- Katalogisierung: zentrales App-Register, interne „AppStore“ Übersicht
Schattendaten / Compliance-Verstöße <br/>(Apps verarbeiten personenbezogene Daten ohne Beachtung von DSGVO)	– Datenschutzverletzungen, rechtliche Folgen <br/>- Reputationsschaden bei Datenlecks <br/>- Mögliche Geldstrafen (DSGVO)	Mittel (bei Unwissen der Maker)	– Datenschutz-Schulungen für Citizen Devs <br/>- Frühzeitige Einbindung DSB in relevante Apps <br/>- Aktiviertes Audit-Logging, Sensible Daten kennzeichnen <br/>- Regelmäßige Compliance-Audits auf Apps/Flows
Wissens- / Personalabhängigkeit <br/>(Wichtige Apps wurden von Einzelperson gebaut, keine Vertretung)	– Gefahr bei Mitarbeiterwechsel (Know-how-Verlust) <br/>- Betriebsunterbrechung, wenn niemand Problem beheben kann <br/>- Schwierigkeit, App weiterzuentwickeln	Hoch (wenn viele Einzel-Projekte)	– „Fusion Teams“ fördern: mind. 2 Leute kennen jede kritische Lösung <br/>- Code/ Konfig in Repo, Doku erstellen erzwingen vor Prod <br/>- Schlüsselpersonen identifizieren und binden (Karrierepfade für Citizen Devs) <br/>- CoE als Backup: CoE-Mitarbeiter haben Grundverständnis aller Kern-Apps
Performance-/Skalierungsprobleme <br/>(Apps werden mit mehr Nutzern/Daten langsam oder stoßen an Limits)	– Frustrierte Anwender, sinkende Akzeptanz <br/>- Möglicher Prozessstau, wenn Flows zu langsam laufen <br/>- Intransparente Fehler (Timeouts etc.)	Mittel (steigt mit Nutzerzahl & Datenwachstum)	– Frühzeitig Architektur prüfen (Dataverse vs. SharePoint etc.) <br/>- Lasttests für Apps mit großer Zielgruppe <br/>- Monitoring von Laufzeiten (langsame Flows identifizieren) <br/>- Bei Bedarf: Aufstocken von Kapazitäten (Premium Capacity, zusätzliche Bots etc.) <br/>- Notfalls: Aufteilung auf mehrere Apps/Instanzen, oder kritische Teile in Azure auslagern
Lizenzkosten außer Kontrolle <br/>(unerwartet hohe Gebühren durch viele einzeln lizenzierte Nutzer oder Pay-as-you-go)	– Budgetüberschreitung, ggf. Projektstopp <br/>- Negative Wahrnehmung („Low-Code ist zu teuer“) <br/>- Druck, Apps wieder abzuschalten aus Kostengründen	Mittel (wenn Adoption steigt ohne Kostenkontrolle)	– Zentralisiertes Lizenzmanagement (CoE + Einkauf überwachen laufend) <br/>- Kostenstellen zuordnen: Bewusstsein in Fachbereichen („jede App kostet x/Monat“) <br/>- Quartalsweise Lizenz-Review: ungenutzte entfernen, optimales Modell wählen (z.B. Wechsel auf Kapazität oder Volumenrabatte nutzen) <br/>- Transparentes Reporting ans Management (Kosten vs Nutzen gegenüberstellen, ROI nachweisen)
Technische Störung / Ausfall <br/>(Microsoft-Dienst down, Gateway offline, kritischer Flow hängen geblieben)	– Unterbrechung wichtiger Geschäftsprozesse (z.B. Genehmigungen, Datenflüsse) <br/>- Arbeitsstillstand in betroffenen Bereichen <br/>- Improvisierte Workarounds (Fehleranfällig)	Niedrig (Microsoft Cloud sehr stabil) aber möglich	– Notfallpläne für Kernprozesse: Wer kann ggf. manuell überbrücken? <br/>- Wichtige Daten regelmäßig exportieren (zur Not offline verfügbar) <br/>- Backup-Gateway bereit halten <br/>- Premium Support Vertrag mit MS für schnelle Reaktion <br/>- Kommunikationplan: sofort Betroffene informieren mit Workaround-Anweisungen
Akzeptanzprobleme bei Mitarbeitern <br/>(Nutzer lehnen neue Apps ab, nutzen weiter alte inoffizielle Wege)	– Erhoffter Effizienzgewinn bleibt aus <br/>- Parallelstrukturen: Aufwand verdoppelt sich <br/>- Investition in neue Lösung verpufft	Mittel (typischer Wandel-Widerstand)	– End User früh einbeziehen (Co-Creation, Pilotnutzer-Feedback) <br/>- Nutzen klar kommunizieren („Was habe ich davon?“) <br/>- Simplen Umstieg gestalten: Schulungen, Hilfestellungen <br/>- Management-Support: Vorgesetzte sollen Nutzung einfordern/fördern (wenn sinnvoll) <br/>- ggf. temporär alten Weg abschalten, um Wechsel zu forcieren (mit Vorsicht, nur wenn neue Lösung wirklich bereit)
Know-how-Lücken / Qualitätsmängel <br/>(Citizen Devs stoßen an Grenzen ihres technischen Wissens, bauen suboptimale Lösungen)	– Apps mit schlechten Praktiken (Sicherheit/Performance) gelangen in Produktion <br/>- Erhöhter Wartungsaufwand hinterher <br/>- Risiko von Fehlern/Pannen durch versteckte Bugs	Hoch (Citizen Dev sind keine Profis, Lernkurve)	– Intensive Trainingsprogramm & Coaching (Learning by doing mit CoE im Rücken) <br/>- Code Review Pflicht für kritische Apps (CoE prüft vor GoLive) <br/>- Standards/Template bereitstellen, damit von Anfang an Strukturen stimmen <br/>- Community-Support: schnelle Hilfe bei Fragen bietet, damit Probleme gar nicht „krumm“ gelöst werden müssen
Überlastung CoE/IT <br/>(zu viele Anfragen nach Support, Governancereviews etc., Team kommt nicht hinterher)	– Wartezeiten bei Deployments oder Hilfestellungen <br/>- Frustration in Fachbereichen („IT bremst uns aus“) <br/>- CoE-Team Burnout-Gefahr	Mittel (abhängig von Teamgröße vs. Nachfrage)	– Aufgaben priorisieren (Kritisches zuerst, kleine Anliegen bündeln) <br/>- Citizen Dev Community befähigen, sich gegenseitig zu helfen (Entlastung CoE) <br/>- ggfs. CoE-Team aufstocken oder Paten in Abteilungen benennen (dezentrale CoE-Satelliten) <br/>- Prozesse schlanker machen, Automatisierung nutzen (z.B. Self-Service-Bereitstellung via Scripts)

Die Risikomatrix zeigt: viele Risiken lassen sich durch proaktive Maßnahmen und gute Kommunikation verringern. Wichtig ist, sie nicht zu ignorieren – lieber offen ansprechen („ja, uns ist bewusst, Lizenzkosten können ein Thema werden, deshalb machen wir X und Y“) als später überrascht zu werden.

Diese Tabelle kann man auch in einem Risk-Workshop mit Stakeholdern durchgehen, um sicherzustellen, dass alle auf dem selben Stand sind und die vorgeschlagenen Gegenmaßnahmen tragen.

14. Glossar der Power Platform Fachbegriffe

Zum Schluss ein umfangreiches Glossar mit den wichtigsten Begriffen rund um die Power Platform, inklusive kurzer Erklärung in deutschem Klartext:

• Power Platform: Überbegriff für Microsofts Low-Code-Plattform bestehend aus Power Apps, Power Automate, Power BI, Power Pages, Power Virtual Agents (Copilot Studio) und verwandten Diensten. Dient zur Entwicklung von Apps, Workflows, Analysen ohne (viel) Code.
• Power Apps: Dienst zur Erstellung von individuellen Geschäftsanwendungen via Low-Code. Ermöglicht Formulareingaben, Geschäftslogik und Verknüpfung mit Datenquellen. Unterteilt in Canvas Apps und modellgesteuerte Apps.
• Canvas App: Eine Art von Power App, bei der man auf einer „freien Leinwand“ die Benutzeroberfläche mittels Drag&Drop gestaltet (ähnlich PowerPoint). Sehr flexibel im Design, Logik wird mit Excel-ähnlichen Formeln (Power Fx) implementiert.
• Modellgesteuerte App: Power App, deren UI weitgehend automatisch aus dem Datenmodell (Dataverse) generiert wird. Eignet sich für komplexe daten-zentrierte Anwendungen (CRM-ähnliche Anwendungen). Man definiert hauptsächlich Datenstrukturen, Ansichten und Formulare, nicht Pixel-genaues Design.
• Power Automate: Cloud-Dienst zur Automatisierung von Workflows und Prozessen. Früher „Microsoft Flow“. Verbindet verschiedene Dienste (über Connectoren), um Auslöser-Ereignisse und anschließende Aktionen zu definieren („Wenn dies, dann das“). Enthält auch RPA-Funktionen (Robotic Process Automation) für Desktop-Abläufe.
• Flow: Konkrete Workflow-Definition in Power Automate. Besteht aus einem Trigger (Ereignis, Zeitplan oder manuell) und einer Abfolge von Aktionen/Schritten, die automatisch ausgeführt werden. Beispiel: „Wenn neue E-Mail ankommt, speichere Anhang in SharePoint und sende Benachrichtigung“.
• Desktop-Flow: Ein Power Automate Flow, der auf einem Windows-PC Aktionen ausführt (RPA). Kann Maus/Tastatur steuern, um z.B. alte Desktop-Anwendungen zu bedienen. Wird mit dem Power Automate Desktop Tool aufgezeichnet und erstellt.
• Power BI: Business-Intelligence-Dienst zum Erstellen interaktiver Berichte und Dashboards. Ermöglicht Datenvisualisierung, -analyse und das Teilen von Reports im Web oder in Teams. Besteht aus Power BI Desktop (Autoren-Tool) und dem Power BI Service (Cloud zum Hosten/Teilen).
• Microsoft Fabric: Cloud-Datenplattform (eingeführt 2023), welche Power BI mit Datenintegration, Data Engineering, Data Warehouse und Data Science in einer einheitlichen Umgebung vereint. Die Power Platform-Komponente Power BI ist nun Teil von Fabric, was erweiterte Möglichkeiten z.B. in Richtung Big Data bietet.
• Power Pages: Dienst zum Erstellen von Low-Code-Websites (ehem. Power Apps Portals). Ermöglicht externe Webseiten, auf denen z.B. Kunden oder Partner Daten erfassen oder anzeigen können, die im Dataverse gespeichert sind. Bietet Web-Content-Design per Editor, Sicherheit (Login, Rollen) und responsive Templates.
• Power Virtual Agents (PVA): Komponente für Chatbots (in neuester Version als Teil von Copilot Studio). Ermöglicht den Entwurf von Chatbots, die per natürlicher Sprache mit Nutzern interagieren, Fragen beantworten oder Abläufe anstoßen können. Integriert KI/NLP, um Benutzer-Eingaben zu verstehen.
• Copilot Studio: Neues Tool in 2025 für die Erstellung von KI-gestützten „Copiloten“ bzw. intelligenten Agenten. Hiermit kann man komplexere Chatbots und autonome Agenten bauen, die LLMs (Large Language Models) nutzen, Plugins (ähnlich PVA) und sogar Power Automate Flows (Agent Flows) triggern. Quasi die Weiterentwicklung von Power Virtual Agents mit generativer KI.
• Dataverse: Zentrale Datenplattform der Power Platform (früher Common Data Service). Eine Cloud-Datenbank, relational aufgebaut, mit vorkonfigurierten Standardschemata (Common Data Model). Bietet robuste Funktionen: Geschäftsregeln, Modellierung von 1:N-Beziehungen, rollenbasierte Sicherheit, Trigger (für Plugins/Workflows) etc. Daten in Dataverse können von allen PP-Komponenten genutzt werden.
• Common Data Model (CDM): Eine standardisierte Sammlung von Entitäten und Attributen für typische Geschäftsobjekte (z.B. Kunde, Auftrag, Produkt), die Microsoft bereitstellt. Dataverse implementiert den CDM. Er soll Integration erleichtern, da verschiedene Apps auf gemeinsame Schemata zurückgreifen.
• Environment (Umgebung): Logische Instanz in der Power Platform, die Daten, Apps, Flows etc. enthält und isoliert von anderen Environments ist. Wird typischerweise genutzt, um z.B. Entwicklung, Test, Produktion zu trennen oder verschiedene Abteilungen. Jedes Environment hat eigene Konfiguration (DLP-Regeln, Datenbank etc.).
• Default Environment: Die standardmäßig vorhandene Umgebung in jedem Tenant („[TenantName] (default)“). Alle Nutzer können darin grundsätzlich arbeiten. Gedacht primär für persönliche oder erste Experimente. Sollte nicht für geschäftskritische Lösungen genutzt werden, da sie sehr offen ist.
• Managed Environment: Feature von Microsoft zur verbesserten Governance. Wenn man ein Environment als „Managed“ markiert, erhält man zusätzliche Tools: z.B. Limits für App-Sharing, automatische Nutzungs-Benachrichtigungen (an Maker), und einen analytischen Überblick im Admin-Center. Dient dazu, Umgebungen mit wenig Aufwand sicherer zu administrieren.
• Solution (Lösung): Ein Packaging-Mechanismus in der Power Platform (vor allem Dataverse-Umgebungen) zur Bündelung von Komponenten (Apps, Flows, Tabellen, Plugins etc.). Ermöglicht Application Lifecycle Management (Export/Import zwischen Umgebungen) und Versionsverwaltung. Es gibt unmanaged Solutions (zur Entwicklung) und managed Solutions (für Distribution in Prod, Quellcode verborgen).
• Connector: Vorgefertigte Schnittstelle, die Power Platform mit einem externen Dienst oder System verbindet. Stellt Trigger und Actions bereit, ohne dass man niedrig-level API Code schreiben muss. Über 800 Connectoren existieren (z.B. für SharePoint, SQL, Twitter, ServiceNow etc.). Unterteilt in Standard-Connectoren (frei nutzbar mit O365-Lizenz) und Premium-Connectoren (erfordern PP-Lizenz).
• Custom Connector: Selbst erstellter Connector, um einen eigenen Webservice oder ein nicht standardmäßig verfügbares System anzubinden. Man definiert in einer OpenAPI/SWAGGER-Spezifikation oder im GUI die Endpunkte, Parameter und Authentifizierung. Nach Bereitstellung verhält sich ein Custom Connector wie ein nativer Connector und kann in Flows/Apps genutzt werden.
• On-Premises Data Gateway: Brückensoftware (Client) von Microsoft, die lokal installiert wird (auf Server oder PC), um Cloud-Dienste mit On-Premises-Datenquellen zu verbinden. Z.B. kann ein Cloud-Flow über das Gateway auf eine interne SQL-Datenbank oder einen lokalen Fileserver zugreifen. Das Gateway leitet Anfragen verschlüsselt vom Cloud-Service ins interne Netz weiter, ohne dass Ports geöffnet werden müssen.
• AI Builder: Sammlung von KI-Funktionen in der Power Platform, die ohne Coding genutzt werden können. Bietet z.B. vorgefertigte KI-Modelle für Texterkennung (OCR), Vorhersagen (Prediction), Bilderkennung, Kategorie-Zuordnung oder Sentiment-Analyse. Integration in Power Apps (als Steuerelement) und Power Automate (als Actions). Benötigt AI Credits je nach Nutzung.
• RPA (Robotic Process Automation): Technologie, um Benutzeraktionen auf der GUI-Ebene zu automatisieren. In Power Automate als Desktop Flows umgesetzt. Ein „Software-Roboter“ kann so z.B. alte Windows-Anwendungen oder Webseiten bedienen, wo keine API existiert. Attended RPA = vom Benutzer gestartet und beobachtet, Unattended RPA = vollständig automatisiert im Hintergrund.
• Power Fx: Die Formelsprache von Canvas-Apps (auch in Teilen in Model-driven Commanding). An Excel angelehnt (z.B. Sum(Formel); If-Bedingungen etc.). Z.B. OnSelect eines Buttons kann man Navigate(Screen2) programmieren oder If(Dropdown1.Selected.Value=“Ja“, Patch(…), Notify(„Nein“)). Power Fx wird auch in z.B. Dataverse-Formeln (Berechnete Spalten) und neu in Flows als Expressions verwendet.
• Fusion Team: Ein Entwicklungsteam, das aus Mitarbeitern verschiedener Disziplinen besteht, z.B. Fachbereichsexperten (Citizen Developer) und professionellen Entwicklern/ITlern. Ziel ist, Business Know-how und IT-Know-how zu vereinen, um bestmögliche Lösungen zu bauen. In Kontext Power Platform oft die empfohlene Zusammensetzung für wichtige Projekte.
• Citizen Developer: Ein Mitarbeiter ohne klassischen IT-Entwickler-Hintergrund, der mit Low-Code-Tools eigene Lösungen erstellt. Kommt meist aus dem Fachbereich (z.B. Finance-Analyst, der eine App für Budgettracking baut). Power Platform richtet sich besonders an Citizen Devs, muss aber im Unternehmensumfeld durch Governance begleitet werden.
• Center of Excellence (CoE): Ein zentrales Team (oder virtuelles Team), das die Nutzung der Power Platform im Unternehmen fördert und steuert. Aufgaben z.B.: Governance definieren, Best Practices vermitteln, Plattform administrieren, Support leisten, Erfolge messen. Microsoft stellt das „CoE Starter Kit“ zur Verfügung mit Tools, um Inventar und Governance technisch zu unterstützen.
• CoE Starter Kit: Ein von Microsoft bereitgestelltes Set an Power BI Dashboards, Power Apps und Power Automate Flows, das einem CoE-Team hilft, die Plattform zu verwalten. Liefert z.B. Übersichten aller Apps, Flows, Nutzer; Flows die bei Nichteinhaltung Governance Mails senden (z.B. „Deine App wurde 90 Tage nicht genutzt, bitte aufräumen“); Tools für Lizenz-Insights, Verbindungs-Review, etc.
• Data Loss Prevention (DLP) Policy: Governance-Einstellung, mit der Admins festlegen, welche Connectoren in Apps/Flows kombiniert werden dürfen. Drei Kategorien: „geschäftlich erlaubt“, „nicht-geschäftlich“ und „gesperrt“. So kann verhindert werden, dass z.B. ein Flow vertrauliche Firmendaten auf Twitter postet (Business + Non-Business in einem Flow wird geblockt) oder dass komplett unerwünschte Dienste genutzt werden.
• Managed Identity: Ein Azure AD-Objekt, das Diensten (z.B. Power Automate Flows) erlaubt, sich selbst gegenüber Azure Diensten zu authentifizieren, ohne manuelle Credentials. In Preview kann Power Automate z.B. mit einer eigenen Managed Identity auf geschützte Azure Ressourcen zugreifen. Erleichtert Authentifizierung, weil kein festes Passwort/Client Secret benötigt wird.
• Adaptive Card: Ein kleines Info- und Interaktions-Panel, das z.B. in Teams Nachrichten oder Outlook Mails eingebettet werden kann. Power Automate nutzt Adaptive Cards, um z.B. Approvals darzustellen (Annehmen/Ablehnen Buttons). Sie sind JSON-definiert und passen sich adaptiv an das Rendering in verschiedenen Clients an.
• Approval (Genehmigung): Standardprozess in Power Automate, um Freigaben einzuholen. Man kann in einem Flow eine „Genehmigung“ Aktion nutzen, die dem angegebenen Approver (Person) eine Adaptive Card schickt (in Teams/Outlook oder in Power Automate Zentrum). Der Status (Approved/Rejected + Kommentare) wird zurück an den Flow gegeben. Häufig genutzt für Urlaubsanträge, Bestellfreigaben etc.
• Solution Checker: Ein Analysetool von Microsoft (im Power Apps Maker Portal oder via Power Platform Tools), das eine Lösung auf bekannte Probleme scannt. Überprüft z.B. Canvas-App Performance-Bed issues, Flow-Einstellungen, ungenutzte Variables, Plugin Code Qualität etc. Ergebnis ist ein Bericht mit empfohlenen Korrekturen (z.B. „Vermeide Schleife mit 1000 Iterationen“ oder „Diese Formel ist nicht delegierbar“).
• Managed / Unmanaged: Bezogen auf Solutions. Unmanaged = Roh-Entwicklungsversion, alles editierbar. Managed = fertig gepackte Version, eingesetzt in Ziel-Umgebung, Quellcode/Struktur teils verborgen, man kann sie nicht direkt ändern (nur via import neuer Version). In Prod nutzt man i.d.R. Managed Solutions, um versehentliches Anpassen zu verhindern und sauber up-/downgradebar zu bleiben.
• API-Limits (Request Limits): Microsoft begrenzt die Anzahl an Aufrufen/Transaktionen pro Benutzer und Tag, um eine faire Nutzung sicherzustellen. Z.B. ein Premium-lizenzierter User darf 40.000 API-Anfragen pro 24h an Dataverse/Connectors stellen. Das ist normalerweise sehr hoch, aber extreme Flows könnten es erreichen. Es gibt Add-ons, um Limits zu erhöhen. Für einen Bot (Flow mit Service-Account) gelten separate höhere Limits. Wichtig im Blick zu haben bei hochvolumigen Szenarien.
• DevOps (CI/CD) für Power Platform: Der Ansatz, auch für Low-Code Anwendungen eine professionelle kontinuierliche Bereitstellung umzusetzen. Inklusive Source-Control (z.B. via Azure DevOps oder GitHub), automatisches Bauen (Solution exportieren, ins Repo committen) und Release-Pipelines (Import in Test/Prod Umgebungen). Microsoft bietet dafür „Power Platform Build Tools“ (Azure DevOps Erweiterung) und vorgefertigte GitHub Actions.
• Plug-in: Serverseitige Erweiterung für Dataverse (C# Code), die bei bestimmten Triggern (z.B. vor/nach dem Erstellen eines Datensatzes) ausgeführt wird. Kann Geschäftslogik oder Integration im Hintergrund ausführen. Müssen in Solutions als Assembly registriert werden. Eher in komplexen Szenarien oder bei Dynamics 365 Implementierungen genutzt, wo Low-Code-Ausdrucksmöglichkeiten nicht ausreichen.
• Power Apps Component Framework (PCF): Möglichkeit, eigene UI-Komponenten für Power Apps zu entwickeln (mit Code, TypeScript/React). Damit können Entwickler spezielle Steuerelemente bauen (z.B. eine visuelle Karte, einen Slider, einen farbigen Kalender etc.), die im Canvas oder Model-Driven App eingebunden werden können. PCFs erweitern die Standard-Komponentenbibliothek um firmenspezifische oder besonders ausgefeilte Controls.
• Process Mining (Prozessanalyse): Funktion in Power Automate (Process Advisor), die anhand von Log-Daten reale Prozessabläufe visualisiert und Engpässe erkennt. Man lädt Ereignisdaten (z.B. aus ERP-Logs) und erhält ein Prozessdiagramm mit Verzweigungen, Häufigkeiten, Durchlaufzeiten. Hilft, Optimierungspotential aufzudecken (z.B. um zu entscheiden, was zu automatisieren ist). Volle Funktion erfordert entsprechendes Lizenz-Add-on.
• AI-Modelle trainieren: In AI Builder kann man eigene KI-Modelle anhand eigener Daten trainieren. Z.B. ein Klassifikationsmodell, um Support-Tickets Kategorien zuzuweisen, oder ein Objekterkennungsmodell für spezifische Produkte auf Bildern. Dazu lädt man Trainingsdaten ins AI Builder Studio, labelt ggf. und lässt das System ein Modell erzeugen. Dieses kann dann in Flows/Apps genutzt werden. (Zu verwechseln mit „Co-Creator Models“ in PVA/Copilot Studio, was eher Orchestrierung von LLMs ist).
• Managed Identity / Service Principal: Statt Benutzerkonten kann man in PP zunehmend Azure Service Principals verwenden (z.B. ein Flow läuft unter SPN-Kontext, nicht an Personengebunden). Das erleichtert Verwaltung, v.a. wenn Personen das Unternehmen verlassen (der Flow bricht nicht, weil ein generisches Konto genutzt wird). Aktuell noch begrenzt einsetzbar, aber perspektivisch wichtig.
• Teams Integration: Viele Power Platform-Elemente lassen sich in Microsoft Teams einbetten. Z.B. eine Canvas-App direkt als Teams-Tab veröffentlichen, Power BI Reports in Teams-Kanälen, oder PVA-Bots in Teams-Chats. Außerdem gibt es „Power Apps (für Teams)“ – ein abgespecktes, aber lizenzkostenfreies Modell um Apps innerhalb eines Teams-Workspaces zu bauen (mit „Dataverse for Teams“, begrenztem Storage). Dies ist gut für kleine Teamlösungen ohne zusätzliche Lizenzen, aber limitiert in Funktionen.
• Telemetrie: Sammelbegriff für Nutzungsdaten und Logs, die die Plattform erzeugt. Dazu zählen z.B. die Analytics im Admin Center (Nutzungszahlen, Laufzeiten) und die Unified Audit Logs (jede Aktion wie „User X hat App Y gestartet“). Telemetrie wird genutzt, um Monitoring zu betreiben und KPIs abzuleiten. Man kann Telemetrie auch erweitern (z.B. eigene Logs in Apps/Flows einbauen, oder Azure App Insights an Power Apps anbinden) um noch genaueres Bild vom System zu haben.
• Unified Audit Log: Zentraler Protokollierungsdienst in Microsoft 365, der auch Ereignisse aus Power Apps/Power Automate erfasst. Admins können hier z.B. abfragen: „Wer hat letzte Woche eine Verbindung angelegt?“, „Wer hat App X freigegeben und wann?“. Sehr nützlich für Forensik und Compliance. Man muss es ggf. im Security&Compliance Center aktivieren (bei E5 standardmäßig 1 Jahr Aufbewahrung, bei E3 90 Tage, etc.).
• Lifecycle (Lebenszyklus): Bezieht sich auf die Phasen einer Anwendung/Workflow: von der Idee über Entwicklung, Test, Betrieb bis zur Ablösung. Power Platform Lifecycle Management umfasst, dass Änderungen kontrolliert in Prod kommen (ALM), aber auch, dass man End-of-Life einer Lösung einplant (z.B. Archivierung, Nachfolgelösung, Abschaltung alter Version). Oft regelt das CoE den Lifecycle (z.B. via CoE-Flows: „App ungenutzt? -> abschalten“).
• Entitlement: In Lizenzsprache der Umfang/Nutzrechte. Z.B. „Power Apps Per User entitles user to 250MB Dataverse storage und 2GB File“. Oder „Office E3 hat Flow usage entitlement für Standard Connectors“. Wichtig bei Compliance: zu wissen, welcher Nutzer hat welche Entitlements (Übernutzung wäre Lizenzverstoß, Unterauslastung vllt. Optimierungspotenzial).
• Shadow IT: Inoffizielle IT-Lösungen, die außerhalb der Kontrolle der IT-Abteilung entwickelt/eingesetzt werden. Die Power Platform kann Shadow IT entweder erhöhen (wenn unkontrolliert jeder bastelt) oder reduzieren (wenn man damit eine offizielle, aber niedrigschwellige Alternative bietet). Governance zielt darauf ab, „Citizen Development“ innerhalb offizieller Bahnen zu halten, damit es nicht zu chaotischer Shadow IT wird.
• CI/CD (Continuous Integration/Continuous Deployment): Ansatz aus DevOps, regelmäßige, automatische Build- und Release-Prozesse zu haben. In Power Platform wird das durch Solutions + Build Tools realisiert. Continuous Integration: z.B. jede Änderung am Canvas App Code im Repo wird validiert (Solution Checker), Continuous Deployment: z.B. nightly wird Dev-Stand in Test aktualisiert sofern keine Fehler. Erhöht Qualität und Konsistenz der Auslieferung von PowerPlatform-Lösungen.
• AI Copilot (in Power Platform): Im Kontext November 2025: Microsoft hat in viele Bereiche „Copilot“-Funktionen integriert, d.h. KI-Assistenten im Werkzeug selbst. Beispielsweise „Power Apps Copilot“ im Studio, wo man per Sprache eine App beschreiben kann und er generiert einen Entwurf. Oder „Power Automate Copilot“, der helfen kann, Flows zu erstellen („Erstelle einen Flow, der…“). Diese Funktionen nutzen GPT-Modelle, um Nutzer zu unterstützen. Zu unterscheiden von „Copilot Studio“, wo man eigene KI-Bots baut.
• Multiplexing: Lizenzbegriff: Es ist unzulässig, die PP so vorzuschalten, dass viele Nutzer eigentlich die Plattform nutzen, aber nur ein technischer Nutzer lizenziert ist. Z.B. wenn 50 Leute über ein Portal (Power Pages, 1 Auth User Service-Account) Daten ins Dataverse schreiben -> nach MS-Regeln benötigen alle 50 jeweils eine entsprechende Lizenz (oder Auth-Page-Lizenz zählt pro Person). Multiplexing soll verhindern, dass man mit technischen Tricks Lizenzen spart. In Praxis muss man also drauf achten, dass pro realem User die richtigen Lizenzen vorhanden sind, auch wenn sie z.B. indirekt über ein gemeinsames Konto zugreifen.

Das Glossar könnte noch länger sein, aber diese ~40 Begriffe decken die häufigsten und wichtigsten ab, die in Diskussionen und Dokumentationen zur Power Platform auftauchen. Gerade wenn man das Dokument an Entscheider oder neue Teammitglieder gibt, hilft das Glossar enorm, um Fachjargon nachzuschlagen und ein gemeinsames Verständnis zu sichern.

15. FAQ – Häufige Fragen aus der Praxis

Zum Abschluss noch ein FAQ mit häufig gestellten Fragen (und Antworten), die erfahrungsgemäß im Zusammenhang mit der Einführung und Nutzung der Power Platform auftauchen:

Frage 1: „Eignet sich die Power Platform wirklich für unternehmenskritische Anwendungen, oder nur für ‚kleine Spielereien‘? Was ist mit Performance und Skalierbarkeit?“
Antwort: Die Power Platform hat sich längst über „Spielerei“ hinaus entwickelt. Microsoft selbst nutzt sie für teils kritische interne Prozesse. Mit dem richtigen Architektur- und Governance-Ansatz kann man auch wichtige Anwendungen darauf betreiben. Dataverse als Datenplattform skaliert auf Millionen Datensätze, und mit Premium-Kapazitäten in Power BI oder zusätzlichen RPA-Bots in Power Automate kann man Leistung gezielt erhöhen. Wichtig ist, die Grenzen zu kennen: z.B. eine Canvas-App ist client-basiert – für 10.000 gleichzeitige Nutzer würde man eventuell eine andere Strategie (Portal/Fabric) wählen. Aber für viele mittlere Szenarien (einige hundert Nutzer, moderate Datenmengen) ist die Power Platform hervorragend geeignet. Performance sollte man testen – oft lässt sich mit Optimierungen wie Delegation oder dem Einsatz von Dataverse statt Excel viel rausholen. Also ja: bei guter Planung können auch kritische Prozesse auf der Power Platform laufen. Für absolute Hochlast oder 100% Verfügbarkeit sollte man im Einzelfall schauen (z.B. eventuelle Fallback-Lösungen), aber im Normalfall ist der Service sehr robust (99,9% SLA) und performant.

Frage 2: „Wie stellen wir sicher, dass sensible Daten geschützt bleiben? Können Power Apps & Flows DSGVO-konform eingesetzt werden?“
Antwort: Datenschutz ist zentral. Grundsätzlich ist Microsoft als Auftragsverarbeiter DSGVO-konform zertifiziert (inkl. EU-Rechenzentrumsstandorten, Standardvertragsklauseln etc.). Wichtig ist der verantwortungsvolle Umgang intern: Wir haben DLP-Policen eingerichtet, damit niemand sensible Daten versehentlich an unautorisierte Dienste sendet (z.B. Kundenliste -> Twitter ist blockiert). Wir achten darauf, dass persönliche Daten nur dort erfasst werden, wo nötig (Datenminimierung). Jede App/Flow sollte im Konzept haben, welche Daten verarbeitet werden und mit welchem Zweck. Zudem sind Audit-Logs aktiv – wir können nachvollziehen, wer z.B. Datensätze geändert hat (wichtig für Rechenschaft). Betroffenenrechte (Auskunft, Löschung) lassen sich erfüllen: z.B. könnte man auf Anfrage die Dataverse-Daten einer Person herausfiltern und löschen. Hierzu erstellen wir Prozesse, damit das im Ernstfall schnell geht. Alle Mitarbeiter, die Apps bauen, werden für Datenschutz sensibilisiert (z.B. keine Personaldaten in private OneDrive speichern, sondern in zentral kontrollierte Systeme). Fazit: Ja, wir können DSGVO-konform mit der Power Platform arbeiten, solange wir die selben Regeln anwenden wie bei jeder anderen Software – mit dem Vorteil, dass wir durch die Platform-Tools (DLP, Security-Rollen) das sogar technisch gut unterstützen können.

Frage 3: „Unsere IT-Security macht sich Sorgen: Öffnen wir mit Citizen Development nicht Tür und Tor für neue Schatten-IT und unsichere Lösungen?“
Antwort: Im Gegenteil – wenn wir es richtig angehen, reduzieren wir Schatten-IT. Bisher sind die Fachbereiche ja gezwungen, Workarounds zu basteln (Excel-Makros, Access-Datenbanken, fremde Cloud-Tools), weil offizielle Lösungen oft zu langsam oder teuer kommen. Mit der Power Platform bieten wir ihnen eine offizielle, zentral verwaltete Spielwiese. Alles was dort passiert, können wir als IT einsehen (wir haben Inventar aller Apps/Flows), wir setzen Policies (z.B. DLP), und wir schulen die Leute. Natürlich gibt es ein Risiko, dass anfangs nicht alles perfekt gemacht wird – aber da fangen wir als CoE auf. Wir haben Review-Prozesse und definierte Freigaben. Lieber holen wir diese „IT“ in unseren Verantwortungsbereich, als dass im Verborgenen etwas Wildes läuft. Bislang hat die Security ja gar keine Sicht auf z.B. manuell geteilte Excel mit Kundendaten – künftig läuft das über unser Dataverse mit vernünftigen Berechtigungen. Also: Bei gutem Governance-Setup (das wir implementiert haben) erhöht sich unterm Strich die Sicherheit. Und falls doch jemand Mist baut, merken wir es dank Logging eher und können reagieren. Wichtig ist, dass Fachbereiche und IT hier eng zusammenarbeiten – das ist ja der Plan mit dem CoE und hat die Unterstützung des Managements.

Frage 4: „Wie vergleichen sich Power Automate und Azure Logic Apps? Wann sollte man was nutzen?“
Antwort: Technisch sind Power Automate und Azure Logic Apps sehr ähnlich – sie teilen sogar viele Connectoren. Der Hauptunterschied liegt im Zielpublikum und Umfeld: Power Automate ist in die Office/Power Platform integriert, mit freundlicherer UI für Nicht-Programmierer und Lizenzierung pro User/Bot. Logic Apps ist ein Azure Service, mehr auf Entwickler und Integrations-Szenarien ausgerichtet, Abrechnung nach Verbrauch. Wann Power Automate? Wenn der Prozess eher von Fachanwendern aufgesetzt werden soll, in M365-Kontext (z.B. „bei E-Mail eingang tu das“). Auch für RPA ist Power Automate die Wahl (Logic Apps können kein Desktop-RPA). Wann Logic Apps? Wenn es um reine Backend-Integration geht, hoher Durchsatz oder DevOps-Anforderungen: z.B. ein B2B-Datenhub, der 10.000 Nachrichten pro Stunde verarbeitet – das baut man eher als Logic App, weil man da voll ins Azure Monitoring und CI/CD integriert ist. Oft ist es kein Entweder-Oder: wir können beides kombinieren. Beispiel: Ein Power Automate Flow löst durch einen Webhook eine Logic App aus, die dann komplexe Transformationen macht und Resultate zurückgibt. Unser Ansatz: Standardprozesse und Abteilungs-Workflows -> Power Automate; Hardcore-Systemintegration -> Logic Apps. Und natürlich beachten wir die Lizenz: Mit unserer PP-Lizenz haben wir Power Automate quasi „drin“, während Logic Apps separat auf Azure Budget läuft – das nutzen wir gezielt, wo es Sinn ergibt.

Frage 5: „Was, wenn der Mitarbeiter, der eine wichtige App entwickelt hat, das Unternehmen verlässt? Stehen wir dann ohne Wissen da?“
Antwort: Das Risiko sogenannter Key Person Dependencies sehen wir und steuern dagegen: Erstens sind alle Apps/Flows nicht an das persönliche Konto gebunden – wir haben sie in der Organisation verankert (Eigentümerrollen, Notfall-Admin). Wenn jemand geht, kann der Admin die App auf jemand anderen übertragen, die App läuft weiter. Zweitens legen wir Wert auf Dokumentation und Teamarbeit: Wichtige Anwendungen werden nicht von nur einer Person alleine betreut. Das CoE-Team hat Einblick in die Strukturen (auch durch das Center of Excellence Kit). Schon während der Erstellung versuchen wir, mindestens zwei Leute einzubinden (z.B. jemand aus IT unterstützt den Fachbereichsmacher). Im Fall der Fälle können wir zudem auf Versionskontrolle und das Repository zurückgreifen – der „Code“ (bzw. Definition) der App ist nicht weg, wir haben ihn exportiert. Und schlussendlich: Wir bauen intern eine Community auf, die Wissen teilt. Sollte Person X ausscheiden, haben wir vermutlich Person Y, die an ähnlichen Apps gearbeitet hat und einspringen kann. Worst case könnten wir auch auf einen Partner oder Microsoft Support zurückgreifen, da alles auf Standard-Technik basiert, nicht auf unbekannter Eigenentwicklung. Also, ideal ist natürlich, Wissen zu übertragen bevor jemand geht (dazu gibt’s interne Prozesse). Aber selbst wenn überraschend – nein, wir stehen nicht vollkommen im Regen, wir haben vorgesorgt mit Eigentumswechsel und zentraler Sicht auf die Lösungen.

Frage 6: „Wie behalten wir die Kosten im Griff, wenn immer mehr Fachbereiche damit arbeiten? Könnte das ausufern?“
Antwort: Kostenkontrolle ist uns sehr wichtig. Wir haben einige Mechanismen etabliert: – Erstens, Transparenz: Das CoE verfolgt genau, wie viele Lizenzen wir haben, wer Trials nutzt, wieviel Dataverse-Speicher verbraucht wird etc. Wir haben dazu Berichte eingerichtet. – Zweitens, Richtlinien: z.B. dass pro Anwendung und Benutzergruppe das kosteneffizienteste Lizenzmodell gewählt wird (wir rechnen im Vorfeld durch: Per-App vs. per-User). – Wir vermeiden unnötige Premium-Verbräuche – z.B. wenn eine Aufgabe mit Standard-Connector geht, nutzen wir den. – Drittens, Budgetzuordnung: Die Kosten werden auf die Fachbereiche umgelegt, soweit möglich („Verursacherprinzip“). Dadurch haben die Abteilungen selbst ein Interesse, nur sinnvolle Apps in Betrieb zu halten. Und das Management sieht pro Bereich, was die Plattform bringt vs. kostet – mit unserem ROI-Reporting wollen wir zeigen, dass der Nutzen deutlich höher ist. – Viertens, Skaleneffekte nutzen: Sollten wir z.B. absehen, dass wir sehr viele Einzellizenzen einsetzen, werden wir mit Microsoft sicherlich Rabatte verhandeln oder auf Kapazitätspläne umsteigen (z.B. Power BI Kapazität statt 1000 Pro-User). – Und laufend: Cleanup: Wir bereinigen z.B. nicht genutzte Flows/Apps (damit keine unnötigen Hintergrundläufe passieren) und ziehen ungenutzte Lizenzen ein. Also, ja, wir achten streng darauf. Bisher liegen wir voll im genehmigten Budget. Und wenn ein Fachbereich eine größere Investition will (z.B. 100 extra Portalnutzer), muss er das wie bei anderer Software auch begründen und budgetieren. Es gibt zudem die Möglichkeit von Pay-as-you-go via Azure, was wir anfangs für Piloten nutzen – damit sehen wir echte Nutzungskosten, bevor wir fixe Lizenzen kaufen. Unterm Strich hat Low-Code auch Kostenvorteile (schnellere Entwicklung, weniger externe Dienstleister). Bisher haben wir – auch dank Support des Managements – das gut im Griff.

Frage 7: „Können wir unsere bestehenden Systeme (z.B. SAP, Oracle, eigene APIs) wirklich anbinden? Gibt es da Performanceprobleme oder Sicherheitsrisiken?“
Antwort: Ja, wir können praktisch alle gängigen Systeme einbinden. Microsoft stellt out-of-the-box Connectoren bereit z.B. für SAP (ECC und S/4 via Gateway), für Oracle DBs etc. – die haben wir in Tests geprüft. Sie nutzen idR. die Standard-Schnittstellen der Systeme, also Performance ist vergleichbar, als würde man direkt vom System abfragen. Sicherheit: Wir verwenden den On-Premises Data Gateway, d.h. der Zugriff erfolgt verschlüsselt und kontrolliert, keine Ports werden nach außen geöffnet. Unsere SAP-Admins können genau sehen, welcher User über die API zugreift (wir nutzen einen Service-Account dafür mit beschränkten Rechten). Für eigene APIs nutzen wir Custom Connectors – quasi definierte Schnittstellen mit OAuth2-Auth. Das ist in etwa so sicher, als würde ein .NET-Programm unsere API aufrufen (es steckt ja letztlich Dieselbe Tech dahinter). Performance hängt natürlich vom System selbst ab: Wenn SAP 5 Sekunden für einen BAPI-Call braucht, dann dauert es in Power Apps auch 5 Sekunden. Aber wir werden keine signifikanten Overheads hinzufügen. Caching können wir auch machen (z.B. Laden der Stammdaten in App-Start und dann lokal filtern). Bisher haben unsere Pilot-Integrationen (u.a. eine SAP-Bestellanlage per Flow) gut funktioniert, ohne merkliche Performanceprobleme. Und wir loggen alle API-Zugriffe – bei Auffälligkeiten (z.B. viele Calls in kurzer Zeit) können wir reagieren (z.B. Limit setzen, Flows entsprechend gestalten). Also: Integration klappt und ist eingeplant. Wir halten auch Rücksprache mit den jeweiligen Systemverantwortlichen, damit die Bescheid wissen, dass z.B. einige Last jetzt über die API von der Power Platform kommt. Durch das CoE sind solche Aktivitäten koordiniert.

Frage 8: „Braucht man Programmierkenntnisse, um die Power Platform zu nutzen? Unsere Fachbereiche haben doch kaum IT-Entwickler…“
Antwort: Das Schöne an der Power Platform ist gerade, dass man keine klassischen Programmierkenntnisse benötigt. Die Fachanwender sollten natürlich ein bisschen technisches Verständnis mitbringen (vergleichbar mit fortgeschrittenen Excel-Kenntnissen). Aber man muss keine Hochsprachen wie C# oder Java können. Die Oberflächen sind visuell, und die Logik wird mit einfacher Sprache oder Formeln beschrieben. Viele unserer Citizen Developer hatten anfangs auch Berührungsängste, aber nach ein, zwei Schulungen konnten sie bereits eigenständig kleine Lösungen bauen. Und sie wissen: Für die komplexeren Dinge haben sie Unterstützung vom CoE/IT. Tatsächlich haben z.B. unsere Kollegen aus dem Controlling großes Gefallen daran gefunden – sie sagen, es sei wie damals mit Excel-Makros, nur moderner und effizienter. Also ja, es ist bewusst für Nicht-Programmierer konzipiert. Und wenn doch mal Code nötig wird (z.B. ein fortgeschrittenes Szenario mit eigenem Connector), dann springt eben ein Entwickler aus IT ein. Wir erwarten aber nicht, dass plötzlich alle Fachanwender „programmieren lernen“ müssen. Sie lernen ein neues Tool, vergleichbar mit „damals SharePoint nutzen“ oder ähnlich. Und wer nicht entwickeln möchte, muss das auch nicht – der kann dann einfach die fertigen Apps nutzen, die seine Kollegen gebaut haben. Insgesamt beobachten wir, dass bei den Fachbereichen teils verborgenes Talent ans Licht kommt: Manchen macht es richtig Spaß und sie bringen super Ideen rein, obwohl sie vormals keinen IT-Hintergrund hatten.

Frage 9: „Wie sieht es mit dem Betrieb und Support aus? Muss nun unsere IT jede App der Fachbereiche supporten, als wäre es eine selbst entwickelte Software?“
Antwort: Wir etablieren ein Supportmodell mit mehreren Stufen: Zuerst einmal soll der Fachbereich, der eine Lösung erstellt hat, auch den 1st-Level Support für die inhaltlichen Fragen übernehmen (wer den Prozess kennt, kann Anwenderfragen besser beantworten). Die IT (CoE) unterstützt 2nd-Level bei technischen Problemen. Viele kleine Apps brauchen kaum Support – wenn gut gebaut, treten selten Fehler auf (und falls doch, fängt ein Flow sie ab oder wir können es rasch fixen). Man darf es sich nicht so vorstellen, dass wir jetzt Hunderte Mini-Anwendungen einzeln babysitten müssen. Durch unser Governance (Monitoring etc.) sehen wir zentral, wenn irgendwo ein Fehler häufig auftritt, und können proaktiv eingreifen. Der Service Desk wird geschult, einfache Lösungen sofort zu geben (z.B. „Cache leeren, App neu laden“ oder „Berechtigungsanfrage an CoE weiterleiten“). Also: Die Fachbereiche tragen mehr Eigenverantwortung, was gut ist, aber natürlich lassen wir sie nicht allein. Im IT-Team bedeutet es, wir verlagern unsere Rolle: Weniger selbst Entwickeln, mehr Koordinieren und Plattform betreiben. Da wir das mit dem CoE strukturiert haben, verteilt es sich auf mehrere Schultern. Unser Monitoring (CoE Kit) hilft sehr – so erkennt man schnell, wo evtl. Handlungsbedarf ist. Bisher hatten wir in den Pilotprojekten kaum Supportaufwand, weil die Endnutzer die Apps gut angenommen haben (die sind ja oft einfacher und klarer als alte Lösungen wie Excel-Makros). Und wenn in einem Fachbereich der Entwickler wechselt, plant das CoE eine geordnete Übergabe, sodass auch hier der Betrieb weiterläuft. Fazit: Der zusätzliche Support-Aufwand für IT hält sich in Grenzen, weil die Verantwortung geteilt wird. Und durch Standards (Checklisten, App-Dokumentation) stellen wir sicher, dass im Notfall jeder ITler sich zurechtfinden kann, auch ohne monatelang eingearbeitet zu sein. Falls das Programm massiv wächst, werden wir Kapazitäten anpassen (ggf. Citizen Dev „Champions“ ausbilden, die als lokale Supporter fungieren). Also, wir haben das im Blick und bisher gut in den Griff bekommen.

Frage 10: „Was tun wir, wenn eine Fachbereichs-App plötzlich sehr beliebt wird oder unternehmensweit nützlich wäre? Können wir die dann ‚professionalisieren‘?“
Antwort: Das ist ein toller „Luxusproblem“-Fall – eine App geht viral intern. Ja, dann sollten wir sie auf die nächste Stufe heben. Dank unseres ALM Prozesses können wir die App schnell in eine kontrollierte Umgebung überführen, Tests erweitern und ggf. Performance optimieren (z.B. Datenbank auf Premium hochstufen, Mechanismen anpassen). Wenn es unternehmensweit wird, schauen wir auf die Lizenz: ggf. wechseln von Einzellizenzen auf einen kapazitätsbasierten Plan (z.B. Power Apps Premium für alle oder ein Portal statt vieler Einzellogins). Das CoE würde vermutlich ein Projekt daraus machen: „Aus Abteilungs-App X wird Company-App“. Dazu gehören dann: UI/UX-Feinschliff, Security-Review (passen die Berechtigungskonzepte noch?), Skalierung testen. Wir haben ja auch die Option, Code-Komponenten hinzuzufügen, falls nötig – z.B. wenn die App dann irgendwas sehr Spezielles können muss, könnten Entwickler ein PCF-Control beisteuern. Im Grunde ist das der gewünschte Weg: klein anfangen, validieren, dann ausbauen. Und die Plattform ist flexibel genug – notfalls gliedert man Teile aus, z.B. in ein Azure Backend. Aber das Grundgerüst (Dataverse, das Canvas UI) kann weiterverwendet werden. Manche Organisationen migrieren sehr erfolgreiche Apps später sogar in richtiges custom Development – bisher sehen wir aber, dass man mit Polieren der Low-Code-Lösung sehr weit kommt, ohne neu bauen zu müssen. Also, sollte uns so ein „Hit“ gelingen, sind wir vorbereitet: Wir ziehen es wie ein internes IT-Projekt hoch, mit allen Standards, und stellen so sicher, dass es als Unternehmenslösung robust läuft. Das Business Case dafür wäre leicht, wenn es schon bewiesenermaßen beliebt ist.

Frage 11: „Wie gehen wir mit Änderungen oder Versionsupgrades einer App um? Gibt es sowas wie Versionsverwaltung und Testumgebungen?“
Antwort: Ja, das ist Teil unseres ALM (Application Lifecycle Management) Konzepts. Für jede wichtige App gibt es eine Entwicklungs-/Testumgebung. Änderungen werden nicht direkt in der produktiven Version gemacht, sondern zunächst in der Dev-Umgebung oder einer Kopie der App. Dort kann man neue Funktionen hinzufügen, das Team testet intern. Wenn es soweit ist, nutzen wir die Solutions-Funktion, um die neue Version in die Test-Umgebung und später nach Prod zu transportieren. Dadurch bleibt Prod unberührt, bis wir sicher sind. Wir haben auch eine Art Versionierung: beispielsweise versehen wir bedeutende Releases mit Nummern (1.0, 1.1 usw.) und führen Release-Notes. Falls mal etwas schiefgeht, können wir theoretisch auch wieder die alte Solution importieren (Rollback). Praktisch haben wir in Pilotphase schon mal eine Änderung zurückgenommen, weil Feedback negativ war – ging problemlos, weil die alte Version ja im System noch vorhanden war. Zudem nutzen wir Quellcodeverwaltung (die App-Definition kann als Datei exportiert in GitHub liegen), sodass wir Änderungen nachverfolgen können. Also, ähnlich wie bei „richtiger“ Software-Entwicklung, nur dass der Deploy bei Power Apps oft schneller geht (Minuten statt Stunden). Wichtig ist, dass wir die Anwender informieren, wenn sich etwas ändert – wir machen z.B. kurze Info-Mails „Neue Version ab Montag, mit folgenden Verbesserungen…“. Und kritische Änderungen werden vorher mit Key-Usern getestet. Fazit: Wir haben einen geordneten Update-Prozess, um Qualität sicherzustellen und Überraschungen zu vermeiden. Das haben wir in unserer Governance festgeschrieben und mit Leben gefüllt (Testpläne etc.). Bisher klappt es gut, die Fachbereiche sind ja froh, dass sie überhaupt schnell Änderungen bekommen – das bisschen formale Vorgehen ist da willkommen, weil es Vertrauen schafft.

Frage 12: „Was sind die größten Stolpersteine, auf die wir achten müssen, wenn wir Citizen Development einführen?“
Antwort: Typischerweise gibt es drei Bereiche: Kultur/Mensch, Governance, Technik: – Auf der menschlichen Seite: Manche Mitarbeiter haben Berührungsängste („Ich bin doch kein Entwickler!“) oder Resistenz gegen Neues („Warum jetzt anders, läuft doch auch so“). Hier hilft viel Kommunikation und Erfolgsbeispiele. Ein Stolperstein wäre, Fachbereiche ohne ausreichende Schulung losrennen zu lassen – dann könnten Fehler passieren oder Frust entstehen. Daher investieren wir am Anfang in Training und in „Quick Wins“ zeigen, damit Akzeptanz entsteht. – Bei Governance: Zu lax – dann droht Chaos, zu strikt – dann erstickt man die Initiative. Es ist eine Gratwanderung. Ein Stolperstein wäre, DLP und Rechte nicht früh genug richtig zu setzen, so dass evtl. etwas passiert (z.B. jemand teilt App mit Daten zu offen) und dann die Alarmglocken schrillen. Das verhindern wir proaktiv mit den getroffenen Maßnahmen. Umgekehrt dürfen wir Maker nicht mit Bürokratie überfordern. Wir versuchen, Governance schlank zu halten (Checklisten, Templates, damit sie wissen was tun, aber nicht 100 Genehmigungen). – Technisch muss man auf Daten & Lizenzen achten: Ein bekanntes Problem ist, wenn Leute zu lange auf z.B. einer SharePoint-Liste entwickeln und plötzlich ist Delegationslimit erreicht – die App wird langsam – dann heißt es vielleicht „Power Apps taugt nix“, obwohl es nur die falsche Datenquelle war. Daher unser CoE-Consulting: wir schauen früh auf solche Dinge und leiten um (z.B. „nimm lieber Dataverse“). Auch Lizenz-Überraschungen („Oh, dieser Connector war Premium!“) sollten wir gleich klären – deshalb haben wir die Info-Kampagne wer was braucht. – Ein weiterer Stolperstein: Vergleich mit Profi-Software. Manche könnten erwarten, dass eine Power App alles kann, was eine individuell entwickelte App kann. In 90% der Fälle geht es auch, aber vielleicht 10% muss man Kompromiss (z.B. UI nicht ganz so fancy). Wichtig ist, die Erwartung richtig zu managen: „Done is better than perfect.“ Lieber eine 95%-Lösung in 1 Monat, als eine 100%-Lösung in 1 Jahr. Das Verständnis müssen alle haben, sonst sucht man den Haar in der Suppe. – Last not least: Resilienz bei Fehlern – Es wird Fehlerchen geben (vielleicht rechnet mal ein Flow falsch, weil anfangs falsch konzipiert). Wenn das passiert, darf nicht gleich das ganze Programm verurteilt werden. Wir müssen daraus lernen und verbessern. Stolperstein wäre hier, wenn Management bei erstem Problem ruft „Abschalten!“. Durch transparente Risikoabschätzung (die wir ja mit den Maßnahmen in der Matrix getan haben) hoffen wir, dass Vertrauen da ist, gemeinsam zu optimieren statt gleich die Reißleine zu ziehen. Summa summarum: Achten müssen wir vor allem auf gute Betreuung der Fachanwender, kontinuierliche Kontrolle der Einhaltung und rechtzeitiges Nachjustieren. Dann stolpern wir nicht, sondern marschieren relativ sicher.

Frage 13: „Wie unterscheidet sich eine Power Platform Anwendung von einer klassischen individuell entwickelten Anwendung (z.B. in .NET oder Java) – hinsichtlich Wartung, Upgrades etc.?“
Antwort: Im Kern erfüllt sie denselben Zweck (eine Geschäftsanforderung digital abbilden), aber die Erstellungs- und Wartungsmethodik ist anders: – Bei einer .NET-App schreibt man Code, hat vielleicht tausende Zeilen, die nur ein Entwickler versteht; bei einer Power App klickt man vieles zusammen, und auch Nicht-ITler können die Logik nachvollziehen (Formeln in natürlicher Sprache etc.). – Upgrades der Plattform (z.B. neue Features) kommen automatisch via Microsoft-Cloud – der Vorteil: wir haben keine großen Versionsmigrationsprojekte wie bei eigenentwickelter Software. Allerdings müssen wir uns auf laufende Änderungen einstellen (deshalb schauen wir die Release Waves an, aber die bringen idR. neue Optionen, selten Breaking Changes). – Wartung: bei Code muss man bei OS-Updates/Library-Updates selber Hand anlegen und neu kompilieren. Bei Power Platform entfällt das – Microsoft hält die Laufzeit aktuell. Unser Wartungsfokus verlagert sich auf die Inhaltspflege der Anwendung (Daten aktualisieren, Regeln anpassen wenn sich Business ändert). Das geht in Power Platform agiler, weil man vieles im Editor fixen kann und sofort ausrollt, statt erst Build/Deploy-Pipeline zu bemühen – wir haben aber trotzdem ALM, damit es kontrolliert bleibt. – Dokumentation: Für eigen Code hat man evtl. WIKI, aber man muss tief tauchen, um Logik zu verstehen. In Power Apps ist vieles selbsterklärender (Namen der Felder etc.), plus Maker sollten kommentieren. Und es existiert das CoE-Inventar, was z.B. Verbindungen auflistet (so weiß man „diese App nutzt System X“). – Abhängigkeiten: Low-Code nutzt viele Standard-Dienste – der Vorteil, wir kriegen im Standard z.B. Authentifizierung, Responsiveness, Mobile-Support out-of-the-box. Bei Custom dev muss man das alles einbauen. Weniger Custom Code = weniger potentielle Fehlerquellen. Nachteil: wir sind natürlich im Rahmen der Plattform-Fähigkeiten (können nicht jedes Pixel so customizen wie im Code; aber über PCF notfalls doch). – Fazit: Wartung von Power Platform Apps ist im Allgemeinen einfacher und kostengünstiger – weil wir uns um Infrastruktur und Basistechnik nicht kümmern. Dafür müssen wir die Plattform-Administration* machen (Governance, Rechte), was bei einer einzelnen Custom-App entfallen würde, aber die hat dann wieder zig overhead in DevOps. So oder so, wir behandeln PP-Lösungen mit derselben Professionalität (ALM, Tests), aber kommen dank Low-Code mit weniger personellem Aufwand aus. Das hat sich in Studien gezeigt: TCO (Total Cost of Ownership) einer Low-Code Lösung ist oft deutlich geringer.

Frage 14: „Können wir die Power Platform auch für externe Nutzer einsetzen, z.B. ein Portal für Kunden? Oder ist das nur intern gedacht?“
Antwort: Absolut, das geht – dafür ist speziell Power Pages da (vormals Power Apps Portals). Wir können Websites erstellen, die Kunden/Partner entweder anonym aufrufen können oder sich registrieren/einloggen. Dataverse fungiert im Hintergrund als Datenbank. Typische Anwendung: Kundenservice-Portal, Partner-Informationsportal, Event-Registrierung etc. Wir haben das in unserer Roadmap (für z.B. Lieferanten-Self-Service). Die Plattform übernimmt dabei vieles: Authentifizierung (auch mit Google/Facebook oder Firmenaccounts via Azure B2C), Zugriffssteuerung (welcher angemeldete Benutzer darf was sehen) und sogar Styling-Vorlagen. Wir müssen also kein Web-Entwicklungsprojekt von Grund auf machen, sondern konfigurieren das meiste. Auch Chatbots (PVA) können wir auf so einer Seite einbinden, um 24/7 FAQ-Service zu bieten. Natürlich gibt es Skalierungskonzepte: man kauft Pageview- oder Nutzer-Kapazität, je nach dem. Für ein paar tausend externe User ist das erprobt. Für Millionen-Nutzer-Portale würde man es vielleicht nicht nehmen – da würde man eher eine speziell optimierte Weblösung bauen. Aber der Sweet Spot sind eben Szenarien, wo es bisher kein Portal gab, weil es zu aufwändig schien – jetzt können wir es mit vergleichsweise geringem Aufwand realisieren. Sicherheit ist gegeben: Die Daten bleiben in Dataverse (auch DSGVO-konform), wir definieren genau, welche Tabellen extern sichtbar sind. Also ja, externe Nutzung ist möglich und geplant. Zusätzlich: Power BI kann Berichte auch für externe teilen (mit Premium oder per Embed in eigene Web-App). Und man kann z.B. Flows bereitstellen, die via Forms oder E-Mail mit externen interagieren. Die Plattform schlägt also auch Brücken nach draußen. Wir müssen nur entsprechend Lizenzen dafür einplanen (Portal User-Packs etc.). Wir sehen darin eine Chance, z.B. uns als moderner Servicepartner zu präsentieren, indem wir schnelle digitale Touchpoints für Kunden/Partner bereitstellen – ohne monatelanges Web-Projekt. Und jederzeit anpassbar, falls sich Anforderungen ändern.

Frage 15: „Welche Grenzen hat die Power Platform? Wann stoßen wir an Punkte, wo wir doch klassische Entwickler oder andere Tools brauchen?“
Antwort: Einige Grenzen habe ich indirekt erwähnt, hier zusammengefasst: – Hochlast/Bulk Processing: Wenn wir z.B. in Echtzeit 100.000 Ereignisse pro Minute verarbeiten müssten – das sprengt Power Automate (dort eher ~hundert pro Minute je Flow). Da würde man auf Azure Event Hub + Funktionen ausweichen. – Ultrakomplexe UI-Logik: Wenn ein Frontend extrem individuelle Anforderungen hat (z.B. eine CAD-ähnliche Oberfläche oder komplexes Drag&Drop mit Spezialeffekten), kommt man mit Canvas-PCF irgendwann an Aufwand, der Custom Code nahekäme. Dann evtl. separate Web-App entwickeln und via API ans Dataverse koppeln. – Spiele/3D: Dafür ist Power Apps nicht gemacht. – Mobile Offlinenutzung mit Gerätetechnik: Zwar gibt’s begrenzte Offline-Fähigkeit und Kamera/GPS Zugriff, aber wenn man hochoptimierte mobile Apps (z.B. mit AR, native Device Functions) braucht, wäre Xamarin/Flutter nativer besser. – Langlaufende Workflows > 30 Tage: Power Automate hat Limit ~30 Tage per Flow-run. Prozesse, die monatelang pendeln, sollte man in Etappen aufteilen oder via anderes BPM-Tool, sonst droht Timeout. – Datenbank-Transaktionen quer über Systeme: In PP-Flow lassen sich nicht mehrere Systeme transaktional koppeln (kein distributed Transaction). Braucht man das (kommt selten vor), muss man an Middleware oder synchron mit Code ran. – Lizenzkosten vs Nutzen: In manchen Fälle kann es günstiger sein, eine kleine dedizierte App zu bauen: Z.B. 2 simple Usecases für 10.000 Mitarbeiter – da wäre evtl. eine simple Webanwendung günstiger als 10k P1 Lizenzen. Hier muss man rechnen. – Geheimhaltung Quellcode: Low-Code ist tendenziell offen (Admins etc. können Konfiguration sehen). Wenn wir etwas haben, was super geheim Algorithmen hat, könnte man überlegen, es lieber in ein Azure Function (kompiliert Code) zu packen. Aber intern ist das selten ein Problem. – Fremd-Integration: Wenn wir ein Stück Software verkaufen wollten, ist PP nicht so geeignet, da es eher auf internen Gebrauch abzielt (man kann Solutions exportieren, aber Endkundenszenarien sind eher Sache von pro dev). – Abseits davon sind Nischenbedürfnisse evtl. besser in Spezialtools aufgehoben: z.B. komplexe Echtzeit IoT-Steuerung -> eher IoT Platform, auch wenn man PP zur Visualisierung nehmen könnte. Oder hochvolumiges E-Commerce Shop -> dafür gibt’s Webshops. Die PP kann aber „drumherum“ viel (z.B. interne Bestellabwicklung für Shop-Bestellungen).

Wir bewerten also Case-by-Case. Bisher in dem, was unsere Fachbereiche wollen (optimierte Abläufe, einfache Datenerfassung, Auswertungen) liegen wir voll im Stärkenbereich der Platform. Die Grenze verschwimmt zudem: Notfalls, wie oft betont, können wir Code in Form von Azure Services oder PCF/Plugins einbetten, sodass viele Grenzen verschoben werden. Sollten wir auf ein absolutes No-Go stoßen, ist es ja kein Beinbruch auch mal eine klassische Lösung zu erwägen – aber wir erwarten das eher selten, da die PP-Fähigkeiten stetig wachsen.

Im Zweifel haben wir mit der Kombination aus Power Platform + Azure-Integration ein sehr breites Werkzeugset, das 90-95% aller internen Anforderungen abdeckt. Für die restlichen 5-10% findet sich dann auch ein Weg, zur Not outside of PP – wobei wir diese Spezialfälle dann sinnvoll vom Rest entkoppeln, damit unser Gesamtkonstrukt sauber bleibt.

16. Beratungsangebot – Ulrich B. Boddenberg IT-Consultancy

Gerne unterstütze ich Sie und Ihr Unternehmen auch ganz persönlich bei der erfolgreichen Einführung und Optimierung der Microsoft Power Platform. Als unabhängiger Berater mit viel Praxis-Erfahrung biete ich folgende Service-Pakete an, die auf Ihren Bedarf zugeschnitten sind:

• Paket 1: Power Platform Starter-Workshop
  Dauer: 2 Tage vor Ort
  Inhalt: In diesem Intensiv-Workshop lege ich gemeinsam mit Ihnen den Grundstein. Am ersten Tag vermittle ich Ihrem Kernteam alle wichtigen Grundlagen – von den Möglichkeiten der Komponenten bis zu Governance-Empfehlungen. Am zweiten Tag erarbeiten wir konkret Ihre Use Cases und erstellen eine erste grobe Roadmap. Wir identifizieren ein Pilotprojekt und stellen die Weichen für dessen Umsetzung (inkl. Einrichtung der Umgebung und DLP-Policy). Der Workshop ist interaktiv und auf Ihr Unternehmen zugeschnitten. Am Ende haben Sie ein klares Bild der nächsten Schritte und ein motiviertes Team, das direkt loslegen kann.
  Preis: 2 Tage x 1.500 € = 3.000 € (zzgl. MwSt.) – inkl. Workshop-Unterlagen und Nachbereitungsempfehlung.
• Paket 2: Pilotbegleitung & Governance-Aufbau
  Dauer: ca. 5 Beratertage (flexibel verteilbar, vor Ort und remote)
  Inhalt: Ich begleite Ihr erstes Power-Platform-Projekt von der Idee bis zum Go-Live und stelle sicher, dass es ein Erfolg wird. Wir starten mit einer Tiefenanalyse des Pilot-Prozesses und gestalten zusammen die Lösung (Tag 1-2). Während Ihre Mitarbeiter entwickeln, stehe ich mit Coaching und Best Practices zur Seite (Tag 3-4, remote Q&A-Sessions). Parallel entwickeln wir Ihr Governance-Grundgerüst: gemeinsam definieren wir DLP-Regeln, Rollen, einen Supportplan – alles was ein Center of Excellence braucht. Vor dem Go-Live (Tag 5) führen wir einen Qualitätssicherung-Check durch und richten Monitoring (CoE Starter Kit) ein. Ergebnis: Ihr Pilot ist produktiv im Einsatz und Sie verfügen über ein grundlegendes Governance-Setup, um sicher weiter zu skalieren.
  Preis: 5 Tage x 1.500 € = 7.500 € (zzgl. MwSt.) – Terminverteilung nach Ihrem Tempo.
• Paket 3: Power Platform Enterprise-Rollout
  Dauer: 15 Tage Beratungsleistung (über mehrere Monate nach Bedarf)
  Inhalt: Dieses Rundum-sorglos-Paket richtet sich an Unternehmen, die die Power Platform flächendeckend einführen wollen. Ich agiere quasi als externer CoE-Leiter auf Zeit. In Phase 1 analysiere ich Ihre Prozesse und identifiziere mit den Fachbereichen mindestens 5 lohnende Anwendungsfälle (Discovery-Workshops). In Phase 2 unterstütze ich parallel mehrere Teams bei der Umsetzung dieser Lösungen – als Architekt, Troubleshooter und Sparringspartner für Ihre Citizen Developer. Wir etablieren eine langfristige Governance-Struktur: Richtlinien, DevOps-Prozesse, Betriebskonzepte – maßgeschneidert und dokumentiert. Zusätzlich schule ich Ihre IT- und Power-User in fortgeschrittenen Themen (Sicherheit, ALM, Pro-Dev-Integration). Das Paket ist zeitlich flexibel – z.B. 3 Tage Kickoff im ersten Monat, danach 1-2 Tage pro Monat begleitend über ein halbes Jahr. Ziel: Nach Abschluss haben Sie mehrere produktive Apps/Flows mit messbarem Nutzen UND ein internes Center of Excellence, das ohne externe Hilfe weitermachen kann.
  Preis: 15 Tage x 1.500 € = 22.500 € (zzgl. MwSt.) – inkl. aller vorbereitenden Analysen, Templates und Beratung. Termine und Phasenplanung nach gemeinsamer Absprache.

Durchführung: Alle Pakete werden ausschließlich persönlich von mir, Ulrich Boddenberg, durchgeführt – keine Juniorberater, kein Remote-Callcenter. Ich lege großen Wert darauf, mit den Menschen zu arbeiten, weil ich glaube, dass gerade im Low-Code-Umfeld das gemeinsame Erarbeiten von Lösungen der Schlüssel ist. Selbstverständlich stehe ich auch zwischen den geplanten Workshops für dringende Fragen per Telefon/Teams zur Verfügung – Sie bekommen meinen direkten Draht.

Über mich: Mit über 30 Jahren Erfahrung als IT-Consultant kenne ich sowohl die klassischen Entwicklungsprojekte als auch die neuesten Ansätze wie Citizen Development. Ich habe zahlreiche Kunden in die Welt von Office 365, Power BI und nun auch Power Platform eingeführt. Meine Stärke ist, Brücken zwischen IT und Fachbereichen zu bauen – technisch fundiert, aber immer praxisorientiert und mit einer Prise Humor, die die Zusammenarbeit erleichtert.

Wenn Sie Interesse an einem der Pakete haben (oder ein individuelles Anliegen rund um die Power Platform besprechen möchten), zögern Sie nicht, mich zu kontaktieren. Mein Motto: „Gemeinsam Digitalisierung anpacken – pragmatisch, sicher und mit Begeisterung.“ Genau das möchte ich auch in Ihrem Haus erreichen.

Hinweis: Alle genannten Preise verstehen sich zuzüglich gesetzlicher Mehrwertsteuer.

 

Weitere Beiträge zum Thema Power Automate