Low-Code-Plattform auswählen: Power Apps, SAP Build oder Appian?
Die Frage kommt selten am leeren Blatt. Microsoft 365 ist im Haus, vielleicht auch SAP, irgendjemand hat mit Power Apps eine erste Anwendung gebaut. Jetzt steht die Frage im Raum, ob das trägt oder ob es eine richtige Plattform braucht. Eine Einordnung von jemandem, der alle 3 unterrichtet und keine davon verkauft.
Die kurze Antwort
- Power Apps, wenn die Anwendung im Microsoft-Umfeld lebt, überschaubar bleibt und Fachbereiche selbst bauen sollen.
- SAP Build, wenn der Prozess an SAP hängt und die Daten dort liegen. Die Nähe zum Kernsystem ist das Argument, nicht die Plattform selbst.
- Appian, wenn der Prozess über mehrere Rollen läuft, Fristen und Freigabestufen kennt und Daten aus mehreren Systemen zusammenführt.
- In vielen Fällen sogar keine davon, weil das vorhandene ERP den Prozess bereits kann und ihn nur niemand eingerichtet hat.
| Power Apps | SAP Build | Appian | |
|---|---|---|---|
| Einsatzgebiet | Fachanwendungen im Microsoft-Umfeld | Prozesse rund um SAP | Systemübergreifende Geschäftsprozesse |
| Prozesskomplexität | gering bis mittel, überwiegend lineare Abläufe | mittel, Freigaben und Verzweigungen | hoch, mehrstufig mit Fristen und Vertretung |
| Integration | stark innerhalb Microsoft 365, darüber hinaus über Konnektoren | stark zu SAP, außerhalb durchschnittlich | stark, mehrere Quellsysteme gleichzeitig |
| Citizen Development | hoch, Fachbereiche kommen weit | mittel, Wissen liegt meist beim SAP-Team | gering bis mittel, eher Entwicklerrollen |
| Einführungsaufwand | gering, Umgebung meist schon vorhanden | mittel, Abstimmung mit dem SAP-Team | hoch, eigenes Einführungsprojekt |
Die erste Zeile beschreibt, wofür die Plattform gedacht ist, die übrigen bewerten sie mit einem kurzen Grund. Die Einordnung ist bewusst grob und ersetzt keine Bewertung des konkreten Falls.
Warum der Vergleich schwer zu finden ist
Wer nach einem Plattformvergleich sucht, findet vor allem Material der Hersteller und von deren Implementierungspartnern. Beides ist nicht falsch, aber es hat eine Richtung. Ein Appian-Partner vergleicht anders als ein Microsoft-Partner, beide vergleichen anders als jemand, der nichts davon verkauft.
Ich unterrichte diese Plattformen als Dozent, jede einzeln und in einem herstellerneutralen Überblickskurs dazu. Das heißt nicht, dass ich neutral bin, weil ich besonders tugendhaft wäre — es heißt, dass ich an keiner Lizenz mitverdiene. Die folgenden Einschätzungen sind entsprechend zu lesen.
Die Frage vor der Frage: brauchen Sie überhaupt eine Plattform?
Der häufigste übersehene Fall ist banal: Das ERP kann Freigaben, Genehmigungen und Statusverfolgung bereits, nur wurde das nie eingerichtet. Bevor eine zusätzliche Plattform ins Haus kommt, mit eigener Lizenz, eigenen Berechtigungen und eigenem Betrieb, lohnt diese Prüfung fast immer.
Der zweithäufigste Fall ist ebenso banal: Der Prozess ist fachlich nicht geklärt. Wer einen Ablauf automatisiert, den im Haus niemand vollständig beschreiben kann, gießt die Unklarheit in Software. Das gilt für jede Plattform gleichermaßen und ist der teuerste Fehler in dieser ganzen Kategorie.
Bleibt die Frage nach dem Bauen statt Kaufen: Ob sich eine Plattform überhaupt gegen eine Eigenentwicklung rechnet, ist eine eigene Rechnung — die steht in Low-Code oder Eigenentwicklung? Wann sich Appian rechnet. Dieser Artikel setzt hinter dieser Entscheidung an.
Microsoft Power Apps
Die Stärke ist die Nähe. Wenn Microsoft 365 ohnehin läuft, ist der Einstieg besonders niedrigschwellig: Anmeldung über das vorhandene Verzeichnis, Zugriff auf SharePoint, Teams und Outlook, Automatisierung über die zugehörigen Flows. Für eine Anwendung, die Daten erfasst, eine Liste pflegt oder eine einfache Freigabe abbildet, kommen Fachbereiche erstaunlich weit.
Die Grenze ist die Komplexität. Was klein anfängt, wächst. Power-Apps-Anwendungen altern dabei nicht besonders gnädig. Sobald mehrere Rollen, verzweigte Prozesse, Fristen und Massendaten zusammenkommen, wird aus der schnellen Lösung ein Gebilde, das niemand mehr überblickt und das an einer einzelnen Person hängt. Der typische Wendepunkt ist organisatorisch, nicht technisch: Der Kollege, der es gebaut hat, wechselt die Abteilung.
Der Lizenzpunkt wird ebenfalls oft zu spät gesehen. Vieles wirkt zunächst inklusive, aber sobald Anwendungen die Standardumgebung verlassen oder Premium-Konnektoren brauchen, kommen zusätzliche Lizenzen ins Spiel. Das ist kein Argument dagegen, gehört aber vor die Entscheidung und nicht danach.
SAP Build
Der Vorteil liegt im Kontext. Wenn der Prozess an SAP hängt und die maßgeblichen Daten dort liegen, ist die Nähe zum Kernsystem das eigentliche Argument. Berechtigungen, Stammdaten und Prozesslogik bleiben in derselben Welt, statt über Schnittstellen nachgebaut zu werden.
Eng wird es dort, wo dieser Kontext fehlt. Ohne SAP im Hintergrund verliert die Plattform ihren wichtigsten Vorteil und konkurriert plötzlich als generisches Low-Code-Werkzeug — dann fällt der Vergleich deutlich weniger eindeutig aus. Dazu kommt: Das Wissen liegt typischerweise beim SAP-Team, nicht im Fachbereich. Wer sich davon verspricht, dass Fachabteilungen selbst bauen, sollte das vorher ehrlich prüfen.
Appian
Die Stärke ist der Prozess. Appian kommt aus dem Prozessmanagement. Das merkt man. Aufgabenlisten, Zuständigkeiten, Vertretungen, Fristen, Eskalationen und die vollständige Protokollierung sind Bestandteil der Plattform und nicht etwas, das man in jedem Projekt nachbaut. Für Vorgänge, die durch mehrere Rollen und Freigabestufen laufen, ist das der entscheidende Unterschied.
Dazu kommt die Anbindung bestehender Datenquellen, ohne dass dafür zwangsläufig ein neues führendes Datensystem entstehen muss. Mitarbeitende, Kostenstellen und Lieferanten können dort gepflegt bleiben, wo sie heute liegen. Je nach Konfiguration werden Daten dabei durchaus in der Plattform vorgehalten oder synchronisiert — die Frage, welches System führend bleibt, gehört deshalb ausdrücklich geklärt. In einer Landschaft mit mehreren Systemen ist das oft der Punkt, an dem die Wahl fällt.
Zu groß wird es bei zu kleinem Anlass. Appian ist eine Unternehmensplattform mit entsprechendem Anspruch an Einführung, Betrieb und Können. Für eine einzelne kleine Anwendung ist das überdimensioniert. Der Aufwand rechnet sich, wenn mehrere Prozesse folgen — nicht bei einem einzigen.
Was alle 3 nicht lösen
Unabhängig von der Wahl bleiben 3 Dinge Ihre Aufgabe:
- Der Prozess muss beschrieben sein. Wer entscheidet, wer vertritt, was passiert bei Fristablauf, welche Daten sind maßgeblich. Diese Arbeit fällt bei jedem Werkzeug an und macht den größeren Teil des Aufwands aus.
- Es braucht eine Zuständigkeit im Haus. Low-Code heißt nicht wartungsfrei. Ohne jemanden, der sich verantwortlich fühlt, verwaist jede Plattform.
- Die Daten müssen ein führendes System haben. Sonst entsteht neben der bestehenden Doppelpflege eine weitere.
Plattformentscheidung steht an?
Ich entwickle Prozess-Apps mit Appian und binde vorhandene Systeme über Record Types an. Im Vorgespräch sage ich Ihnen, wenn Ihr Fall dafür zu klein ist oder Ihr ERP ihn längst abdeckt.
→ Appian Entwickler und BeratungEine Entscheidungshilfe, die ohne Marketing auskommt
Statt einer Punktetabelle 4 Fragen, die in der Praxis die Wahl treffen:
- Wo liegen die maßgeblichen Daten? In SAP spricht viel für SAP Build. In Microsoft 365 für Power Apps. Verteilt über mehrere Systeme für eine Plattform mit ordentlicher Anbindung. Dort ist Appian stark.
- Wie viele Rollen berührt der Prozess? Eine einzelne Freigabe spricht für die Bordmittel. Spätestens wenn mehrere Rollen, Vertretungen und Fristen zusammenspielen, wird Prozessfunktionalität wichtiger als reine Formularlogik.
- Folgen weitere Anwendungen? Eine einzelne rechtfertigt keine Plattformeinführung. 5 schon.
- Wer soll bauen? Sollen Fachbereiche selbst arbeiten, führt der Weg eher zu Power Apps. Ist ein Entwicklerteam vorhanden, sind die schwereren Plattformen kein Hindernis mehr.
Häufige Fragen
Ist Power Apps für ernsthafte Anwendungen zu einfach?
Nein, aber es hat eine andere Komfortzone. Für Erfassung, Listen und einfache Freigaben im Microsoft-Umfeld ist es sehr effizient. Für verzweigte Prozesse über mehrere Rollen, mit Fristen, Vertretungen und Massendaten wächst der Aufwand überproportional. Die Frage ist nicht, ob es geht, sondern ob es in 3 Jahren noch wartbar ist.
Lohnt sich SAP Build ohne SAP?
Der Hauptvorteil ist die Nähe zum Kernsystem: Berechtigungen, Stammdaten und Prozesslogik bleiben in derselben Welt. Fehlt dieser Kontext, tritt die Plattform als generisches Low-Code-Werkzeug gegen etablierte Alternativen an. Der Vergleich fällt deutlich weniger klar aus.
Ab wann lohnt sich Appian?
Wenn Prozesse über mehrere Rollen laufen, Fristen und Freigabestufen haben, Daten aus mehreren Systemen brauchen und weitere Anwendungen absehbar sind. Für eine einzelne kleine Anwendung ist der Einführungsaufwand nicht gerechtfertigt.
Können wir mehrere Plattformen parallel betreiben?
In der Praxis passiert das meist ungeplant. Es ist nicht per se falsch, wenn die Zuständigkeiten klar sind: Bordmittel für kleine Fachanwendungen, eine Prozessplattform für die durchgängigen Abläufe. Problematisch wird es, wenn derselbe Prozess in 2 Werkzeugen halb abgebildet ist.
Der ehrliche Schluss
Es gibt keine beste Low-Code-Plattform, es gibt nur die passende zur Datenlage, zur Prozesstiefe und zu den Leuten, die damit arbeiten sollen. Die 3 hier verglichenen Werkzeuge sind alle gut in dem, wofür sie gebaut wurden und mittelmäßig außerhalb davon.
Wer die 4 Fragen oben ehrlich beantwortet, hat die Wahl meist schon getroffen. Wer dabei feststellt, dass das vorhandene ERP den Prozess bereits könnte, hat den besten Ausgang von allen erwischt.