Power Apps und Power Automate machen Fachbereiche schneller. Ohne klare Steuerung werden daraus aber leicht unbekannte Apps, fehlerhafte Flows, Datenrisiken und unnötige Kosten. Ein Power Platform Center of Excellence schafft Transparenz, Betriebssicherheit und klare Leitplanken.

Was macht Citizen Development mit Power Apps und Power Automate riskant?

Citizen Development ist nicht das Problem. Im Gegenteil: Fachbereiche kennen ihre Abläufe oft besser als jede zentrale IT. Wenn Mitarbeitende kleine Apps oder Automationen selbst bauen, können Prozesse schneller digitalisiert werden.

Riskant wird es, wenn aus einer kleinen Lösung plötzlich ein produktiver Prozess wird. Dann hängen Freigaben, Benachrichtigungen, Datenübertragungen oder interne Prüfungen an einer App oder einem Flow, den niemand offiziell betreibt.

Typische Risiken sind:

  • unbekannte Power Apps und Power-Automate-Flows
  • Flows mit persönlichen Verbindungen
  • Apps ohne fachlichen Owner
  • breite Freigaben ohne Prüfung
  • Konnektoren zu ungeeigneten Diensten
  • fehlende Dokumentation
  • keine Vertretung bei Urlaub, Rollenwechsel oder Austritt
  • unklare Lizenz- und Supportkosten

Das klingt erst einmal unspektakulär. Bis ein Flow für Rechnungsfreigaben abbricht und niemand merkt, dass seit zwei Tagen nichts mehr weiterläuft. Genau dann wird aus „nur schnell automatisiert“ ein Betriebsproblem.

Was ist ein Power Platform Center of Excellence?

Ein Power Platform Center of Excellence ist eine zentrale Funktion für Governance, Transparenz, Betrieb und Befähigung rund um Microsoft Power Platform. Es definiert Regeln, Rollen, technische Leitplanken und Prozesse für Power Apps, Power Automate und verwandte Dienste.

Microsoft beschreibt das CoE Starter Kit als Referenzimplementierung, mit der Governance-, Monitoring- und Adoption-Funktionen auf Basis der Power Platform aufgebaut werden können. Es ist damit ein wichtiger Werkzeugkasten, aber kein fertiges Betriebsmodell.

Ein gutes PPCoE verbindet Technik und Organisation:

  • Inventar über Apps, Flows, Maker und Umgebungen
  • DLP-Regeln und Connector-Governance
  • Rollen und Verantwortlichkeiten
  • Monitoring für kritische Workflows
  • Prozesse für Ownerwechsel und Offboarding
  • Richtlinien für produktive Low-Code-Lösungen
  • Kennzahlen zu Nutzung, Risiko und Kosten

Kurz gesagt: Das PPCoE macht Citizen Development nicht langsamer. Es macht es steuerbar.

Transparenz: Was wird in der Power Platform tatsächlich genutzt?

Ohne Inventar gibt es keine Governance. IT-Leiter müssen wissen, welche Apps und Flows in der Power Platform existieren, wer sie gebaut hat, wer sie nutzt und welche Datenquellen angebunden sind.

Das CoE Starter Kit kann dafür Inventar- und Nutzungsdaten sammeln. Microsoft beschreibt unter anderem Daten zu Umgebungen, Apps, Power-Automate-Flows, Konnektoren, Connection References, Makern und Audit Logs als Bestandteil der CoE-Auswertungen.

Wichtig ist: Ein Dashboard allein entscheidet nichts. Es liefert die Grundlage für Entscheidungen.

Ein PPCoE sollte zum Beispiel sichtbar machen:

  • Welche Apps werden aktiv genutzt?
  • Welche Apps wurden nur getestet?
  • Welche Flows schlagen regelmäßig fehl?
  • Welche Ressourcen sind ownerlos?
  • Welche Apps sind breit geteilt?
  • Welche Flows nutzen Premium-Konnektoren?
  • Welche Lösungen greifen auf sensible Daten zu?
  • Welche Anwendungen sind geschäftskritisch?

Eine Liste mit 300 Apps ist noch keine Erkenntnis. Erst die Einordnung zählt: persönliche Produktivität, Teamlösung, fachbereichskritische Anwendung, geschäftskritische Lösung oder Altlast.

Datenverlust verhindern: Warum DLP und Connector-Governance ins Zentrum gehören

Power Platform arbeitet stark über Konnektoren. Genau das macht sie leistungsfähig. Apps und Flows können SharePoint, Outlook, Teams, Dataverse, ERP-Systeme, CRM-Systeme oder externe Dienste verbinden.

Das ist praktisch. Es ist aber auch der Punkt, an dem Datenrisiken entstehen.

Microsoft beschreibt Data Policies, einschließlich DLP-Richtlinien, als Schutzschienen gegen unbeabsichtigte Datenexposition oder Datenverlust. Sie sollen helfen, die Informationssicherheit im Tenant zu schützen.

DLP ist also kein Misstrauensvotum gegen Maker. Es ist eher der Airbag. Hoffentlich merkt man ihn selten. Wenn etwas schiefgeht, ist man froh, dass er da ist.

Betriebssicherheit: Wann wird aus einer Fachbereichs-App ein IT-Service?

Nicht jede Power App braucht denselben Betriebsstandard wie ein ERP-System. Eine persönliche Aufgabenhilfe ist etwas anderes als ein Flow, der Bestellungen, Rechnungsfreigaben oder Kundenkommunikation steuert.

Ein PPCoE sollte deshalb Kritikalitätsklassen definieren:

  • persönliche Produktivität
  • Teamlösung
  • fachbereichskritische Lösung
  • geschäftskritische Lösung

Je höher die Kritikalität, desto klarer müssen Betrieb, Support und Monitoring geregelt sein.

Für produktive Lösungen braucht es mindestens Antworten auf diese Fragen:

  • Wer ist fachlich verantwortlich?
  • Wer darf Änderungen freigeben?
  • Wer wird bei Fehlern informiert?
  • Wer ist Vertretung des Owners?
  • Gibt es eine Testumgebung?
  • Gibt es Dokumentation?
  • Welche Daten werden verarbeitet?
  • Was passiert bei Ausfall?

Besonders wichtig ist Power-Automate-Monitoring. Kritische Workflows dürfen nicht erst auffallen, wenn der Fachbereich nach drei Tagen fragt, warum nichts passiert ist.

Ein PPCoE sollte fehlgeschlagene Flows regelmäßig auswerten. Bei betriebsrelevanten Automationen braucht es Benachrichtigungen, Eskalationswege und klare Verantwortliche.

Verwaiste Workflows: Was passiert, wenn Maker das Unternehmen verlassen?

Ausscheidende Mitarbeitende sind ein unterschätztes Risiko im Citizen Development. Power Apps, Flows, Verbindungen und Berechtigungen hängen oft an einzelnen Personen.

Solange alles läuft, merkt niemand etwas. Später läuft eine Verbindung ab, ein Konto wird deaktiviert oder niemand hat mehr Rechte, den Flow anzupassen. Dann hängt ein Prozess an einer Person, die nicht mehr im Unternehmen ist.

Ein PPCoE sollte deshalb regelmäßig prüfen:

  • Welche Apps und Flows sind ownerlos?
  • Welche Owner sind inaktiv?
  • Welche Maker verlassen das Unternehmen?
  • Welche produktiven Flows nutzen persönliche Connections?
  • Welche Apps brauchen Co-Owner?
  • Welche Ressourcen müssen übergeben oder stillgelegt werden?

Das gehört ins IT-Offboarding. Nicht als Sonderprüfung kurz vor Feierabend, sondern als fester Prozess.

Bei produktiven Lösungen sollte es keinen Single Point of Failure in Personengestalt geben. Ein Flow, der einen relevanten Geschäftsprozess steuert, braucht mindestens einen fachlichen Owner, einen technischen Ansprechpartner und eine Vertretung.

Best Practices für ein Power Platform CoE im Mittelstand

Ein PPCoE muss nicht als Großprojekt starten. Gerade im Mittelstand hilft ein pragmatischer Einstieg mit klaren Mindeststandards.

1. Default Environment bewusst begrenzen

Die Default Environment sollte nicht zum Sammelbecken produktiver Fachbereichsanwendungen werden. Microsoft weist darauf hin, dass Nutzer in Organisationen mit Power Platform Zugriff auf diese Umgebung haben. Gerade deshalb braucht sie klare Regeln.

Sinnvoll ist eine einfache Vorgabe: persönliche Produktivität ja, geschäftskritische Anwendungen nein.

2. Umgebungskonzept definieren

Trennen Sie Umgebungen nach Zweck. Zum Beispiel:

  • persönliche Produktivität
  • Entwicklung und Test
  • Fachbereichslösungen
  • Produktion
  • CoE-Administration

3. Inventar regelmäßig prüfen

Das Inventar ist kein Einmalprojekt. Apps, Flows, Maker, Konnektoren und Freigaben verändern sich laufend. Regelmäßige Reviews zeigen, wo Risiken wachsen.

4. Kritikalität klassifizieren

Nicht jede App verdient denselben Aufwand. Ordnen Sie relevante Lösungen nach Risiko und Geschäftsrelevanz ein. Danach entscheidet sich, wie viel Governance nötig ist.

5. DLP-Regeln schrittweise einführen

Starten Sie nicht mit blindem Blockieren. Prüfen Sie zuerst, welche Konnektoren tatsächlich genutzt werden. Danach lassen sich Regeln mit weniger Kollateralschaden einführen.

6. Owner- und Vertretungsmodell festlegen

Produktive Apps und Flows brauchen klare Verantwortliche. Dazu gehören fachlicher Owner, technischer Ansprechpartner und Vertretung.

7. Fehlgeschlagene Workflows aktiv monitoren

Kritische Flows sollten bei Fehlern nicht still vor sich hin scheitern. Für betriebsrelevante Automationen braucht es Monitoring, Benachrichtigungen und Eskalation.

8. Offboarding für Maker einführen

Wenn Mitarbeitende austreten oder Rollen wechseln, muss geprüft werden, welche Apps, Flows, Verbindungen und Berechtigungen betroffen sind.

9. ALM leichtgewichtig starten

Für kritische Lösungen reichen oft schon klare Mindeststandards: Entwicklung, Test, Produktion, Dokumentation und ein einfacher Änderungsprozess.

10. Maker befähigen statt nur kontrollieren

Governance ohne Enablement wirkt wie eine Vollbremsung. Besser sind interne Guidelines, Vorlagen, Sprechstunden und klare Kontaktwege.

11. PPCoE-Kennzahlen regelmäßig auswerten

Messen Sie nicht nur Risiken, sondern auch Nutzen. Aktive Apps, Nutzungshäufigkeit, aktive Maker und Flow-Ausführungen zeigen, wo Citizen Development echten Wert liefert.

Kosteneffizienz nachweisen: Welche PPCoE-Kennzahlen wirklich helfen

Kosteneffizienz entsteht nicht dadurch, dass jede Lizenz maximal knapp gehalten wird. Sie entsteht, wenn IT sieht, welche Lösungen tatsächlich genutzt werden und welchen Betriebsaufwand sie erzeugen.

Ein PPCoE kann dafür Kennzahlen liefern, etwa:

  • Anzahl erstellter Apps
  • Anzahl aktiver Apps
  • Nutzungshäufigkeit pro App
  • aktive Maker
  • aktive Flows
  • fehlgeschlagene Flow-Ausführungen
  • Apps und Flows mit Premium-Konnektoren
  • ownerlose Apps und Flows
  • breit geteilte Apps
  • nicht genutzte Apps
  • Apps nach Kritikalitätsklasse

Diese Kennzahlen helfen bei drei Entscheidungen.

Erstens: Welche Lösungen verdienen mehr Support, weil sie stark genutzt oder geschäftskritisch sind?

Zweitens: Welche Apps und Flows sollten archiviert, gelöscht oder konsolidiert werden?

Drittens: Wo lohnt sich weiteres Enablement, weil Fachbereiche gute Lösungen bauen und nur bessere Leitplanken brauchen?

Wichtig ist die gemeinsame Bewertung von Nutzung, Risiko und Aufwand. Eine viel genutzte App mit klarem Prozessnutzen ist anders zu behandeln als zehn Test-Apps, die seit Monaten niemand geöffnet hat.

Rollen und Verantwortlichkeiten: Wer entscheidet, wer betreibt, wer haftet fachlich?

Governance scheitert selten nur an Technik. Meist fehlt Klarheit, wer was entscheiden darf.

Microsoft empfiehlt, Rollen und Verantwortlichkeiten für Power-Platform-Adoption und Governance klar zu definieren und eine RACI-Matrix zu nutzen. Damit wird sichtbar, wer verantwortlich, rechenschaftspflichtig, einzubeziehen oder zu informieren ist.

Für ein PPCoE sind typischerweise diese Rollen relevant:

  • IT-Leitung oder Plattformverantwortung
  • Power Platform Admin
  • Informationssicherheit
  • Datenschutz
  • Fachbereichs-Owner
  • Maker
  • Support
  • Architektur oder Applikationsmanagement

Die zentrale Frage lautet nicht: „Wer hat die App gebaut?“ Die wichtigere Frage lautet: „Wer trägt Verantwortung, wenn sie produktiv genutzt wird?“

Das muss vor dem Ernstfall geklärt sein. Wenn ein Flow ausfällt, sollte die Antwort nicht lauten: „Der Kollege, der das gebaut hat, ist gerade im Urlaub.“

Wie IT-Leiter pragmatisch starten können

Der Einstieg muss nicht perfekt sein. Er muss sichtbar machen, wo Handlungsbedarf besteht.

Ein sinnvoller Start sieht so aus:

  1. Bestand erfassen: Apps, Flows, Umgebungen, Maker und Konnektoren.
  2. Default Environment bewerten und Zweck festlegen.
  3. Kritische Apps und Flows identifizieren.
  4. Ownerlose Ressourcen und persönliche Connections prüfen.
  5. Basis-DLP und Umgebungskonzept definieren.
  6. Monitoring für wichtige Workflows einrichten.
  7. Offboarding-Prozess für Maker ergänzen.
  8. Kennzahlen zu Nutzung, Risiko und Kosten regelmäßig auswerten.

Microsoft beschreibt für das CoE Starter Kit unterschiedliche Wege, Inventar- und Nutzungsdaten zu sammeln, unter anderem Data Export und Cloud Flows. Für den Betrieb sind regelmäßige Updates und Tests wichtig, weil sich Power Platform schnell verändert.

Der wichtigste Punkt: Fangen Sie nicht bei der perfekten Zielarchitektur an. Fangen Sie bei den größten Risiken an.

Das sind meist breit geteilte Apps, sensible Datenflüsse, fehlgeschlagene Flows, ownerlose Ressourcen und produktive Lösungen ohne Supportmodell. Wenn Sie hier Unterstützung in Anspruch nehmen möchten, können wir mit unserer Power Platform Beratung und Umsetzungs-Erfahrung helfen.

Was ein Power Platform CoE nicht leisten kann

Ein PPCoE ist kein magischer Schutzschild. Es verhindert nicht automatisch jede schlechte App und jeden ungünstigen Flow.

Das CoE Starter Kit liefert wichtige technische Grundlagen. Entscheidungen über Risiko, Verantwortlichkeit, Datenklassifizierung, Betrieb und Kosten muss die Organisation trotzdem selbst treffen.

Ein Dashboard ersetzt keine Governance. DLP ersetzt keine Datenstrategie. Maker-Schulungen ersetzen keinen Supportprozess.

Ein PPCoE funktioniert nur, wenn IT, Fachbereiche, Security und Management gemeinsam klare Spielregeln akzeptieren. Sonst entsteht nur ein weiteres Tool mit hübschen Reports. Davon hat Ihre IT vermutlich schon genug.

Fazit

Citizen Development sollte nicht gestoppt werden. Es braucht Leitplanken. Ein Power Platform Center of Excellence hilft IT-Leitern, Nutzung sichtbar zu machen, Datenrisiken zu begrenzen, Workflows betreibbar zu halten und Kosten sachlich zu bewerten.

FAQ

Was ist ein Power Platform Center of Excellence?

Ein Power Platform Center of Excellence ist eine organisatorische Funktion für Governance, Betrieb, Transparenz und Enablement rund um Power Apps, Power Automate und weitere Power-Platform-Dienste. Es definiert Regeln, Rollen, Monitoring, Umgebungskonzepte und Prozesse für kontrolliertes Citizen Development.

Macht mir Citizen Development nicht mehr Arbeit als vorher?

Am Anfang: Ja. Mit der Zeit etabliert sich aber die Hilfe zur Selbsthilfe in den Fachbereichen, wodurch nicht mehr jede kleine Lösung von der IT bereitgestellt werden muss. Das Center of Excellence hilft dabei, den Fokus auf dem Wesentlichen zu halten und die Einhaltung von Compliance und Governance zu unterstützen bzw. zu erzwingen.

Ist das CoE Starter Kit bereits ein vollständiges PPCoE?

Nein. Das CoE Starter Kit liefert Komponenten, Dashboards und technische Grundlagen für Monitoring und Governance. Ein vollständiges PPCoE braucht zusätzlich Verantwortlichkeiten, Prozesse, Kommunikationswege, Betriebsregeln, DLP-Strategie und Management-Rückhalt.

„Das Starter Kit ist die technische Komponente. Zusätzlich benötigt man für den Erfolg aber auch motivierte Citizen Developer, die das Thema mit Begeisterung als Community vorantreiben.“ – Oliver Grahm | Senior Developer bei acoris AG

Wie hilft ein PPCoE gegen Datenverlust?

Ein PPCoE reduziert Datenrisiken durch DLP-Regeln, Connector-Klassifizierung, Umgebungskonzepte, Freigabeprozesse und Transparenz über Datenflüsse. So wird sichtbar, welche Apps und Flows Unternehmensdaten verarbeiten und welche Verbindungen erlaubt, eingeschränkt oder blockiert werden sollten.

Wie erkennt man verwaiste Workflows nach Mitarbeiteraustritt?

Verwaiste Workflows erkennt man über Inventar- und Owner-Analysen: Welche Flows gehören inaktiven oder ausgeschiedenen Nutzern? Welche Verbindungen laufen über persönliche Konten? Welche produktiven Flows haben keinen Co-Owner? Diese Prüfung sollte Teil des IT-Offboardings sein.

Welche PPCoE-Kennzahlen zeigen Kosteneffizienz?

Hilfreich sind aktive Apps, Nutzungshäufigkeit, aktive Maker, aktive Flows, fehlgeschlagene Flow-Ausführungen, Premium-Konnektoren, ownerlose Ressourcen und breit geteilte Apps. Diese Kennzahlen zeigen, welche Lösungen Wert liefern, welche Risiken erzeugen und welche Altlasten bereinigt werden sollten.