Schöne Oberfläche, unsaubere Basis? Wie ich Prozessautomatisierung in Microsoft 365 wirklich denke

Die letzten Tage habe ich nach Feierabend viele Stunden in meine eigene Website gesteckt:
Page Builder raus, eigenes schlankes Child-Theme, Bilder optimiert, Lazy Loading, Cookie- und Consent-Logik neu gedacht, Calendly sauber eingebunden.

Nicht, weil ich Webdesigner wäre, das bin ich nämlich nicht, sondern weil ich seit Jahren in der IT arbeite, u. a. bei einer Versicherung, und dort gelernt habe, wie wichtig eine saubere technische Basis, Dokumentation und Datenschutz sind.

In meinen Projekten unterstütze ich Unternehmen dabei, Prozesse mit Microsoft 365 und der Power Platform (Power Automate, Power Apps, Power BI) zu automatisieren. Und genau da sehe ich tagtäglich das gleiche Muster wie im Web:

Auf den ersten Blick sieht vieles gut aus.
Unter der Haube ist es oft: langsam, fehleranfällig, schlecht dokumentiert und datenschutzrechtlich fragwürdig.

Darum messe ich IT-Dienstleister (und mich selbst) zuerst an ihrer Basis und nicht an Hochglanz-Slides.

1. Warum ich IT-Dienstleister zuerst an ihrer eigenen Basis messe

1.1 Wenn Praxis-Alltag und Datenschutz kollidieren

Im Bekanntenkreis sehe ich immer wieder Situationen, bei denen sich mir, freundlich formuliert, die Nackenhaare aufstellen:

• Praxen, in denen Mitarbeitende Patientendaten über WhatsApp hin- und herschicken.
• Sensible Informationen werden über private E-Mail-Konten oder unverschlüsselte Messenger geteilt.
• Zugänge und Passwörter werden „irgendwie im Team“ geteilt.

Die Menschen dahinter sind oft fachlich sehr gut, aber technisch nicht affin. Sie wissen schlicht nicht, was sie da gerade riskieren (rechtlich und organisatorisch).

Ich bin kein Anwalt und ersetze auch keine Rechtsberatung.
Aber durch meine Arbeit in einem regulierten Umfeld (Versicherung) habe ich ein gutes Gespür dafür, was erkennbar nicht DSGVO-konform ist. Und ich bin bereit, Projekte abzulehnen, bei denen von Anfang an klar ist, dass man sie nicht sauber umsetzen kann.

1.2 Was die eigene Website über einen Dienstleister verrät

Ähnliches sehe ich im IT- und Agentur-Umfeld:

• Websites von „Digitalexperten“, die auf dem Handy auseinanderfallen.
• Schicke WordPress-Seiten mit zehn Plugins zu viel, die ewig laden.
• Cookie-Banner, die nur Deko sind, aber längst getrackt wird.

In Auswertungen großer Datensätze mit Hunderttausenden von Websites zeigt sich, dass nur ungefähr ein Fünftel tatsächlich alle drei Core Web Vitals von Google erfüllt, also bei Ladezeit, Interaktivität und visueller Stabilität wirklich gut abschneidet. Analysen auf Basis realer Nutzerdaten legen nahe, dass rund die Hälfte aller mobilen Besucher abspringt, wenn eine Seite länger als etwa drei Sekunden lädt.

Kurz gesagt:
Die meisten Websites sind spürbar langsamer als sie sein müssten und verlieren dadurch Nutzer und Vertrauen.

Wenn ein Dienstleister seine eigene Website weder performant noch sauber bekommt, ist das für mich ein Signal. Nicht, weil jeder Pixel perfekt sein muss, sondern weil hier sichtbar wird, wie jemand mit Technik, Qualität und Details umgeht.

Und genau diese Haltung spiegelt sich später auch in Automatisierungen, Flows und Apps wieder.

2. Von der schönen Oberfläche zur echten Prozessautomatisierung

2.1 Low Code ist nicht Low Risk

Die Power Platform macht es leicht, schnell Ergebnisse zu zeigen:

• Ein Flow ist „in einer Stunde fertig“.
• Eine Canvas App entsteht per Drag & Drop.
• BI-Dashboards sind mit ein paar Klicks gebaut.

Das ist die Stärke und gleichzeitig die Gefahr von Low Code.

Viele Lösungen wirken im Demo-Termin beeindruckend:

• Die App klickt sich gut.
• Der Flow läuft „ohne Fehler durch“.
• Die Zahlen im Dashboard bewegen sich.

Aber:

Nur weil etwas auf den ersten Blick funktioniert, heißt das noch lange nicht,
dass es technisch sauber, robust und datenschutzkonform ist.

2.2 Typische Fehler in Power-Automate-Flows und Power Apps

Was ich immer wieder sehe:

• Keine Fehlerbehandlung
  Flows, die bei einem kleinen Sonderfall einfach stehen bleiben, ohne Logging oder Benachrichtigung.
• Berechtigungen nur „gefühlt richtig“
  In Power Apps werden Ansichten gefiltert, aber in der dahinterliegenden Datenquelle (z. B. SharePoint, Dataverse) ist der Zugriff viel zu weit geöffnet.
• Unklare Datenflüsse
  Daten werden aus Microsoft 365 raus in Dritttools geschickt, teilweise ohne dass jemand wirklich weiß, welche Personendaten wo landen.
• „Admin-only“-Lösungen
  Eine Person im Unternehmen ist der „Power-User“, der alles zusammengebaut hat. Fällt sie aus oder wechselt das Unternehmen, bleibt eine Blackbox zurück.

Studien und Marktbeobachtungen zeichnen ein klares Bild: Je nach Untersuchung verfehlen grob zwischen der Hälfte und zwei Drittel aller Digitalisierungs- und Automatisierungsprojekte ihre Ziele. Sie werden abgebrochen, liefern zu wenig Mehrwert oder schaffen es nie in einen stabilen Produktivbetrieb.

Das bestätigt das, was man in der Praxis spürt:
Das Problem ist selten das Tool: Es ist fast immer der Ansatz.

2.3 Wenn Automatisierungen zur Blackbox werden

Besonders heikel wird es, wenn:

• niemand mehr genau sagen kann, wo Daten überall hinfließen,
• Abhängigkeiten zwischen Flows und Apps nirgendwo dokumentiert sind,
• und Änderungen aus Zeitdruck „schnell mal“ direkt im Produktivsystem gemacht werden.

Dann entsteht eine Blackbox, die zwar heute funktioniert, aber morgen:

• bei einem Systemwechsel bricht,
• bei einer Prüfung unangenehme Fragen aufwirft,
• oder einfach niemanden mehr findet, der sie versteht.

Für mich gehört zu einer seriösen Automatisierung immer:
die Möglichkeit, sie nachvollziehen, auditieren und im Zweifel sauber abschalten zu können.

3. Saubere Prozessautomatisierung in Microsoft 365: Worauf es wirklich ankommt

3.1 Datenflüsse, DSGVO und Verantwortlichkeiten von Anfang an klären

Viele Datenschutz-Probleme entstehen nicht, weil jemand absichtlich „schlampt“, sondern weil die Fragen zu spät gestellt werden:

• Werden personenbezogene Daten in ein Drittland übertragen?
• Gibt es einen Auftragsverarbeitungsvertrag?
• Muss ein Verzeichnis von Verarbeitungstätigkeiten angepasst werden?
• Wer ist eigentlich fachlich verantwortlich für den Prozess?

Ein Beispiel aus der Web-Welt:
Verschiedene Untersuchungen kommen zu dem Ergebnis, dass ein großer Teil der eingesetzten Cookie-Banner die Anforderungen der DSGVO und der ePrivacy-Richtlinie nicht vollständig erfüllt. Etwa weil schon vor der Einwilligung getrackt wird oder weil Gestaltungen eingesetzt werden, die Nutzer gezielt in eine bestimmte Entscheidung lenken.

Das gleiche Muster gibt es bei Automatisierungen:

• Es wird technisch „irgendwie gelöst“.
• Die Fragen nach Rechtsgrundlage, Speicherfristen und Betroffenenrechten kommen hinterher.

Mein Ansatz:
Diese Themen gehören von Anfang an mit auf den Tisch. Ich ersetze keine Rechtsberatung, aber ich sorge dafür, dass:

• Datenflüsse transparent sind,
• typische Risiken offen angesprochen werden,
• und Entscheidungen dokumentiert sind.

3.2 Architektur, Performance und Betrieb mitdenken

Saubere Automatisierung bedeutet auch:

• Architektur
  Welche Systeme sind beteiligt?
  Welche Trigger und Schnittstellen nutzen wir?
  Wie entkoppeln wir, damit nicht alles an einem Dienst hängt?
• Performance
  Wie viele Vorgänge sollen pro Tag/Woche laufen?
  Ist der Flow dafür ausgelegt oder wird er morgen an seine Grenzen kommen?
• Betrieb
  Gibt es Monitoring, Alerts, Logs?
  Wer schaut regelmäßig drauf?
  Gibt es eine klare Verantwortung?

Dass hier viel schiefgeht, ist kein Randthema:
Auch bei größeren Transformations- und Automatisierungsprogrammen berichten Studien immer wieder von hohen zweistelligen Ausfallquoten, häufig, weil Architektur, Betrieb und Change Management von Beginn an zu wenig Beachtung finden.

3.3 Dokumentation, Logging und Fehlermanagement statt „Hoffnung“

Ein Flow, der „einfach so durchläuft“, ist nett, solange alles perfekt läuft.
Die Realität sieht anders aus:

• eine API ist kurzzeitig nicht erreichbar,
• ein Feld enthält einen unerwarteten Wert,
• oder ein Benutzer wird aus dem System entfernt.

Dann entscheidet sich, ob eine Automatisierung:

• leise hängen bleibt,
• im schlimmsten Fall Daten unvollständig verarbeitet,
• oder sauber reagiert: Fehler loggt, Benachrichtigungen versendet, ggf. Rollbacks ermöglicht.

Darum gehören für mich zu professioneller Automatisierung immer:

• sinnvolle Logik für Fehlerfälle,
• strukturierte Protokollierung (z. B. in Dataverse, SharePoint, Log-Tools),
• und eine Dokumentation, die auch jemand versteht, der das Projekt nicht selbst gebaut hat.

4. Wie ich mit Microsoft 365 & der Power Platform arbeite

4.1 Prozess zuerst, Tool danach

Bevor ich einen Flow anlege oder eine App baue, steht für mich immer die Frage:

• Was ist der konkrete Geschäftsprozess?
  – Wer löst ihn aus?
  – Welche Informationen werden benötigt?
  – Was ist das Ziel?

Erst danach geht es darum, wie wir das mit Power Automate, Power Apps und Co. umsetzen.

4.2 Technische Qualität und Datenschutz im Zusammenspiel

Ich bringe aus meinem Hintergrund (Versicherung, regulierte Umgebung) mit:

• Sensibilität für Dokumentation und Nachvollziehbarkeit,
• Verständnis dafür, wo typische Datenschutz-Fallen lauern,
• und den Anspruch, Dinge nicht „gerade so“ zu bauen.

In der Praxis heißt das:

• Ich spreche offen an, wenn eine gewünschte Lösung offensichtlich riskant ist.
• Ich weise darauf hin, wenn externe Dienste ins Spiel kommen, die datenschutzrechtlich bewertet werden müssen.
• Und ich baue keine „Tricks“, die zwar heute funktionieren, aber morgen bei einer Prüfung Bauchschmerzen bereiten.

4.3 Transparenz statt Abhängigkeit: keine Blackbox-Flows

Ein wichtiger Punkt in meiner Arbeit:

Ich möchte nicht, dass Sie von mir abhängig sind, um jede Kleinigkeit zu ändern.

Darum achte ich darauf, dass:

• Flows und Apps verständlich benannt und strukturiert sind,
• wichtige Funktionen dokumentiert werden,
• Ihr Team, je nach Wunsch, Einblick und Know-how bekommt, um die Lösung zu betreiben und weiterzuentwickeln.

Wenn jemand anderes später übernimmt, soll er oder sie sagen können:
„Ah, ich verstehe, wie das gedacht ist.“

5. Checkliste: Woran Sie seriöse Power-Platform-Dienstleister erkennen

Wenn Sie mit jemandem zur Power Platform oder zu Microsoft-365-Automatisierung arbeiten möchten, können Ihnen diese Fragen helfen.

5.1 Fragen zur technischen Qualität

• Kann der Dienstleister erklären, wie er die Architektur aufbaut (inkl. Triggern, Schnittstellen, Datenquellen)?
• Gibt es ein Konzept für Fehlerbehandlung und Logging?
• Wird auf Performance, Limits und Skalierung eingegangen (z. B. Flow-Runs, API-Limits)?

5.2 Fragen zu Datenschutz & Compliance

• Fragt der Dienstleister aktiv nach Datenarten, Rechtsgrundlagen und Speicherorten?
• Weist er auf mögliche Probleme bei externen Tools oder Drittland-Transfers hin?
• Ist ihm bewusst, dass Low Code nicht bedeutet, dass man DSGVO „ausblenden“ kann?

5.3 Fragen zu Dokumentation & Übergabe

• Bekommen Sie zum Projektende nur „Es läuft“ oder auch eine Dokumentation?
• Gibt es eine Übergabe, bei der Ihr Team die Lösung versteht?
• Sind Anpassungen später möglich, ohne dass alles neu gebaut werden muss?

Wenn jemand auf diese Punkte nur ausweichend reagiert oder alles auf „das machen wir später“ schiebt, wäre ich vorsichtig.

6. Fazit: IT darf schön aussehen, aber sie muss sauber arbeiten

Ob Website oder Prozessautomatisierung in Microsoft 365:

• Die Oberfläche kann täuschen.
• Viele Lösungen sehen gut aus und wirken modern, sind aber technisch, organisatorisch oder rechtlich auf wackligem Fundament.

Mein Anspruch, sowohl für meine eigene Website als auch für Kundenprojekte, ist deshalb:

• sauberer technischer Aufbau,
• transparente Datenflüsse,
• Nachvollziehbarkeit und Wartbarkeit,
• und ein bewusster Blick auf Datenschutz & Compliance.

Ich mache Fehler wie jeder andere auch.
Aber ich habe den Anspruch, sie zu finden, zu verstehen und daraus bessere Lösungen zu bauen.

Wenn Sie mehr Automatisierung mit Microsoft 365 & der Power Platform wollen, aber nicht einfach „irgendwas zusammengeklickt“, sondern saubere, nachvollziehbare und DSGVO-sensible Lösungen, dann lohnt sich ein Gespräch.

Genau dabei unterstütze ich Unternehmen:
Wiederkehrende Aufgaben eliminieren, Prozesse schlanker machen. Ohne Blackbox, dafür mit stabiler Basis.