Helmut Szpott

Microsofts PowerPlatform ermöglicht eine schnelle Erstellung von einfachen App-Oberflächen und einfachen Workflows. Typische Fälle wie Reisekosten-Abrechnung oder Urlaubsanträge sind schnell online. Sobald es aber um anspruchsvolle Logik, Datenaufnahmen oder Integrationen geht, sollten Sie dies wie jedes andere Softwareprojekt behandeln: Anforderungen klären, testen, entwickeln, und schulen.

PowerPlatform

Apps brauchen einen Zweck

PowerApps sind Bestandteil der umfassenderen Power Platform von Microsoft. Die Idee ist, die Benutzeroberflächen (=Apps) von den Workflows (=Flow) und den Schnittstellen zu trennen. Oberflächen allein reichen ja nicht aus, um Softwareanwendungen bereit zu stellen. Die Bezeichnung „No-Code“ oder „Low Code“ bedeutet, dass man mit Designoberflächen die Entwicklungsumgebung „versteckt“ und damit schnell starten kann, funktionsfähige Anwendungen zu bauen.

Aber obwohl PowerApps zwar vorkonfigurierte Oberflächen und Buttons zur Verfügung stellen, enthalten sie keine Logik und somit keinen Use Case. Wie Screens aufeinander folgen und was mit Daten passiert, die eingegeben werden, muss gebaut werden. Und das ist wie bei einem klassischen Softwareprojekt: Use Case durchdenken, Funktionen scripten und testen, schulen, ausrollen, verändern.

Eventmanagement: App statt vielen Excels

So finden Sie gute Use Cases

Schnell und effizient: welche sind die guten Use Cases? Wie nähert man sich also den Microsoft PowerApps – wo bringen sie am meisten (und sind am schnellsten umsetzbar)? Die Antwort ist doch eigentlich einfach. Überall da:

  • wo es Excel-Listen gibt,
  • wo das Papier zu “Medienbrüchen” zwingt (also ausdrucken, abtippen, doppelt eintragen usw.)
  • wo Informationen erfasst, (z.B. mit Fotos von der Handykamera) ergänzt oder mit diesen Daten Workflows (also Freigaben, Benachrichtungen oder Erinnerungen) gestartet werden sollen
  • wo es “alte” (also nicht benutzerfreundliche) oder nicht mobile Anwendungen gibt – hier können PowerApps die neue Oberfläche sein

Wenn man die Oberflächen verändert, sollte man die Benutzer, die damit arbeiten müssen, “mitnehmen”. Das heißt zumindest beim Ausprobieren einbinden und und das Feedback in die Entwicklung und Gestaltung einfließen lassen.

Citizen Developer ist immer noch Techniker

Der Fachanwender (als “Citizen Developer”) baut selbst, stimmt das denn? Ja, aber nur, wenn er der alleinige Nutzer ist. Oder wenn er die gängigen Microsoft PowerPlatform-Schulungen absolviert hat und (manchmal) wie ein Entwickler denken kann. Ohne Scripting wird es bei den PowerApps schwer. Wenn die App etwas können soll, wären schon auch Workflows wichtig (“PowerAutomate” – hießen früher mal “Flow”). Dazu sind Erfahrungen mit dem Design von Workflows sehr hilfreich.

Je früher die meinungsbildenden Benutzer wissen, dass etwas neues kommt und wie sich das verhält, desto einfacher ist das Roll-out. Neue Software einzuführen verhält sich also nicht anders mit PowerApps als jedes andere Softwareeinführungsprojekt. Und daher sollte man die gleichen Standards daran anlegen: Use cases definieren, Kommunizieren und testen, nicht zuletzt schulen  – und auch nachbetreuen. Dann wird es mit ziemlicher Sicherheit auch ein Erfolg bei der produktiven Einführung sein.

Möchten Sie mehr zum Thema wissen oder einfach Ihre Erfahrungen austauschen? Schreiben Sie mir für eine Terminvereinbarung: [email protected] .

Wussten Sie schon: wir haben Webinare zu diesem Thema veranstaltet – Aufzeichnung zur Nachlese davon gibt es hier: https://youtu.be/HvbYcByzVJU