Die passende Plattform hängt stark von der vorhandenen Systemlandschaft ab. Microsoft Power Platform liegt nahe, wenn Microsoft 365, Teams, SharePoint oder Dataverse den Arbeitsalltag prägen. Google AppSheet passt eher zu Organisationen, die Daten und Zusammenarbeit in einer Google-orientierten Umgebung abbilden. Mendix und OutSystems zielen stärker auf umfangreiche Unternehmensanwendungen. ServiceNow App Engine ist vor allem dort interessant, wo Prozesse bereits auf der ServiceNow-Plattform laufen. Die Produktnamen allein entscheiden jedoch nicht: Lizenzen, verfügbare Konnektoren, Identitätsverwaltung und Governance bestimmen, was tatsächlich ohne Entwickler möglich ist.
Diese Aufgaben eignen sich besonders für Low-Code
Am einfachsten lassen sich Abläufe übertragen, die heute über E-Mail, Tabellen, Formulare und manuelle Wiedervorlagen organisiert werden. Ein digitaler Ablauf nimmt Daten entgegen, prüft festgelegte Bedingungen, weist eine Aufgabe zu und dokumentiert das Ergebnis. Der Nutzen entsteht weniger durch eine aufwendige Benutzeroberfläche als durch verlässliche Übergaben zwischen Personen und Systemen.
Freigaben und Genehmigungen
Urlaubsanträge, Bestellanforderungen, Reisekosten, Zugriffsanfragen oder die Freigabe eines Dokuments folgen häufig einem überschaubaren Regelwerk. Ein Formular erfasst die Angaben, der Workflow ermittelt die zuständige Person und versendet eine Aufgabe. Nach der Entscheidung werden Status, Zeitpunkt und Kommentar gespeichert.
Ohne Entwickler bleibt ein solcher Ablauf beherrschbar, wenn die Freigabekette wenige stabile Stufen hat. Regeln wie „Kostenstelle auswählen, Vorgesetzten benachrichtigen und bei Ablehnung an den Antragsteller zurückgeben“ lassen sich visuell modellieren. Schwieriger wird es bei zahlreichen Vertretungsregeln, dynamischen Betragsgrenzen, parallelen Freigaben und revisionspflichtiger Archivierung. Dann müssen Fachbereich, IT und gegebenenfalls Compliance gemeinsam festlegen, wie Berechtigungen und Nachweise funktionieren.
Datenerfassung statt Excel-Dateien per E-Mail
Low-Code-Apps können eine zentrale Eingabemaske für Inventar, Prüfprotokolle, Kundenbesuche, Schadensmeldungen oder Qualitätsabweichungen bereitstellen. Pflichtfelder, Auswahllisten und einfache Plausibilitätsregeln erhöhen die Datenqualität. Die Informationen landen direkt in einer freigegebenen Datenquelle, statt in mehreren Dateiversionen verteilt zu werden.
Eine Excel-Tabelle lässt sich jedoch nicht in jedem Fall unverändert zum dauerhaften Backend einer Firmen-App machen. Gleichzeitige Zugriffe, Beziehungen zwischen Datensätzen, fein abgestufte Rechte und große Datenmengen sprechen für eine geeignete Datenbank oder den Datendienst der jeweiligen Plattform. Der Fachbereich kann die Oberfläche oft selbst bauen; die Wahl und Absicherung der Datenhaltung gehört bei einer produktiven Lösung in die IT-Verantwortung.
Benachrichtigungen, Fristen und Aufgabenverteilung
Ein Ablauf kann auf einen neuen oder geänderten Datensatz reagieren und eine Nachricht, Aufgabe oder Eskalation auslösen. Typische Fälle sind auslaufende Zertifikate, unbearbeitete Anfragen, fällige Wartungen und fehlende Pflichtangaben. Der Auslöser muss zuverlässig maschinenlesbar sein. Ein Datum in einer strukturierten Liste eignet sich besser als eine Frist, die nur im Text eines eingescannten Dokuments steht.
Die Automatisierung sollte nicht bloß zusätzliche E-Mails produzieren. Sinnvoller ist eine zentrale Statusquelle, aus der hervorgeht, wer zuständig ist und wann der Vorgang bearbeitet wurde. Andernfalls wird lediglich ein manueller Posteingang durch einen automatisierten Posteingang ersetzt.
Dokumente aus strukturierten Daten erzeugen
Angebotsentwürfe, Übergabeprotokolle, Bestätigungen oder interne Berichte können aus geprüften Formularwerten erstellt und zur weiteren Bearbeitung abgelegt werden. Solche Abläufe eignen sich, wenn eine feste Vorlage und klar bezeichnete Felder vorhanden sind. Auch die Benennung und Ablage in einer vorgegebenen Ordner- oder Bibliotheksstruktur lässt sich einbeziehen.
Unterschriften, Aufbewahrungsanforderungen und rechtlich relevante Dokumentversionen benötigen eine gesonderte Prüfung. Eine automatisch erzeugte Datei ist nicht allein durch ihre Erstellung ordnungsgemäß freigegeben oder revisionssicher archiviert.
Einfache interne Apps und Self-Service-Angebote
Für Geräteausgabe, Raumprüfung, Besucherverwaltung, Onboarding-Aufgaben oder interne Bestellungen kann eine Low-Code-App Formulare, Listen und Rollen in einer Oberfläche bündeln. Diese Lösungen sind besonders geeignet, wenn der Nutzerkreis bekannt ist und sich über das vorhandene Unternehmenskonto anmelden kann.
Öffentliche Kundenportale, Anwendungen mit sehr vielen gleichzeitigen Nutzern oder Software mit ungewöhnlichen Bedienanforderungen stellen deutlich höhere Ansprüche. Hier werden Architektur, Lastverhalten, Barrierefreiheit, Datenschutz und Schutz gegen missbräuchliche Eingaben zu Entwicklungsaufgaben, auch wenn Teile der Oberfläche weiterhin mit Low-Code entstehen.
Ein schneller Eignungstest für den ersten Prozess
Ein Fachbereich sollte nicht mit dem sichtbar größten Problem beginnen, sondern mit einem begrenzten Ablauf, dessen Regeln bereits verstanden sind. Die folgende Reihenfolge trennt einen guten Einstieg von einem Projekt, das früh technische Unterstützung benötigt:
- Auslöser bestimmen: Beginnt der Ablauf durch ein Formular, einen neuen Datensatz, eine Statusänderung oder einen festen Termin? Ist der Auslöser nicht eindeutig, muss der Prozess zuerst fachlich geklärt werden.
- Regeln aufschreiben: Lassen sich alle Entscheidungen als nachvollziehbare Wenn-dann-Regeln ausdrücken, ist Low-Code gut geeignet. Beruht die Entscheidung überwiegend auf Erfahrung oder freier Auslegung, darf sie nicht blind automatisiert werden.
- Datenquellen zählen: Eine freigegebene Standardquelle ist ein günstiger Ausgangspunkt. Mehrere Altsysteme, lokale Dateien und nicht dokumentierte Datenbanken erhöhen den Integrationsaufwand.
- Ausnahmen erfassen: Wenige bekannte Sonderfälle können als eigene Zweige abgebildet werden. Zahlreiche unklare Ausnahmen weisen darauf hin, dass der bestehende Prozess noch nicht standardisiert ist.
- Schadensfolge bewerten: Eine verspätete interne Erinnerung ist leichter beherrschbar als eine falsche Zahlung, Kontosperre oder Löschung. Je größer die mögliche Auswirkung, desto früher muss die IT einbezogen werden.
- Erfolg messbar machen: Bearbeitungszeit, Zahl manueller Übergaben, Fehlerquote oder offene Vorgänge eignen sich als Vergleichswerte. Ohne Ausgangswert bleibt unklar, ob der neue Ablauf wirklich besser arbeitet.
Fällt die Prüfung bei Auslöser, Regeln und Datenquellen positiv aus und ist die Schadensfolge überschaubar, kann ein Fachbereich einen Prototyp erstellen. Eine produktive Freigabe ist davon zu trennen. Sie setzt geklärte Eigentümerschaft, Berechtigungen, Betrieb und Support voraus.
Fünf Plattformansätze im gleichen Entscheidungsraster
Die folgenden Lösungen decken nicht exakt dieselbe Produktklasse ab. Sie lassen sich dennoch anhand derselben Fragen einordnen: Welche bestehende Umgebung wird angebunden, wie leicht gelingt ein erster Ablauf, wie weit trägt die Plattform bei größeren Anwendungen, wie wird sie verwaltet und an welcher Stelle entsteht Entwicklungsbedarf? Funktionsumfang und Lizenzbedingungen können sich ändern; vor einer Auswahl sind deshalb die offizielle Produktdokumentation, die Konnektorenübersicht und die Lizenzinformationen des jeweiligen Herstellers zu prüfen.
Microsoft Power Platform
Microsoft Power Platform verbindet unter anderem Power Apps für Anwendungen, Power Automate für Abläufe, Dataverse für strukturierte Geschäftsdaten und Power BI für Auswertungen. Der Ansatz ist besonders naheliegend, wenn Benutzerkonten, Dateien und Zusammenarbeit bereits über Microsoft-Dienste organisiert sind. Formulare, Genehmigungen und interne Apps können dann an vorhandene Identitäten und Dienste anknüpfen.
Der Einstieg in einfache Abläufe ist vergleichsweise niedrigschwellig. Mit wachsender Lösung werden jedoch Umgebungsstrategie, Datenmodell, Rollen, Lösungsverwaltung und Lizenzierung wichtig. Nicht jeder Konnektor und nicht jede Ausführungsart ist automatisch durch eine bereits vorhandene Microsoft-365-Lizenz abgedeckt. Unternehmen sollten im Power Platform Admin Center sowie in der offiziellen Lizenzdokumentation prüfen, welche Umgebungen, Richtlinien und Nutzungsrechte gelten.
Google AppSheet
AppSheet ermöglicht datenorientierte Apps und Automatisierungen auf Basis angebundener Quellen. Das passt zu mobilen Erfassungsaufgaben, Prüfungen, Listen und einfachen Freigabeprozessen, insbesondere in einer Google-geprägten Arbeitsumgebung. Eine App kann schnell aus einer strukturierten Tabelle oder einer anderen unterstützten Quelle entstehen.
Die Grenze liegt dort, wo ein komplexes Datenmodell, stark individualisierte Oberflächen oder anspruchsvolle Transaktionen erforderlich sind. Auch hier muss geprüft werden, welche Datenquelle für den produktiven Mehrbenutzerbetrieb geeignet ist. Für die Auswahl sind die offiziellen Angaben zu unterstützten Datenquellen, Sicherheitsfiltern, Benutzerlizenzen und Automatisierungsschritten maßgeblich.
Mendix
Mendix ist auf die modellbasierte Entwicklung umfangreicher Anwendungen ausgerichtet. Fachliche Prozesskenntnis kann in visuelle Modelle einfließen, während professionelle Entwickler Erweiterungen und Integrationen übernehmen. Die Plattform kommt eher infrage, wenn aus einem Prototyp eine längerfristig betriebene Unternehmensanwendung mit mehreren Rollen und Systemanbindungen werden soll.
Für einen einzelnen Erinnerungsworkflow wäre dieser Ansatz häufig größer als nötig. Seine Stärke liegt in gemeinsamen Projekten von Fachbereich und IT, nicht darin, jede Entwicklungsleistung vollständig zu vermeiden. Vor einer Entscheidung sind Bereitstellungsmodell, Identitätsanbindung, Erweiterbarkeit, Betriebsverantwortung und Lizenzmodell gemeinsam zu bewerten.
OutSystems
OutSystems zielt ebenfalls auf umfangreiche Web- und mobile Anwendungen mit visueller Entwicklung, wiederverwendbaren Komponenten und Integrationsmöglichkeiten. Es eignet sich eher für zentral gesteuerte Anwendungsentwicklung als für beliebig verteilte Einzelautomatisierungen in Fachabteilungen. Einfache Oberflächen können visuell entstehen, während Architektur und komplexe Logik weiterhin technische Erfahrung verlangen.
Die Plattform ist vor allem dann ein Kandidat, wenn Unternehmen mehrere Anwendungen nach gemeinsamen Standards entwickeln und betreiben möchten. Für die Prüfung zählen nicht nur die Bauoberfläche, sondern auch Bereitstellung, Überwachung, Versionsverwaltung, Skalierung und die Einbindung bestehender Systeme.
ServiceNow App Engine
ServiceNow App Engine kann Prozesse und Anwendungen auf der ServiceNow-Plattform abbilden. Der Ansatz ist besonders schlüssig, wenn Service-, Anfrage- oder Fallprozesse bereits dort verwaltet werden. Neue Workflows nutzen dann vorhandene Benutzer, Rollen, Datensätze und Plattformmechanismen, statt eine weitere isolierte Lösung einzuführen.
Für Unternehmen ohne bestehende ServiceNow-Landschaft ist App Engine nicht automatisch der einfachste Einstieg. Die Stärke entsteht vor allem aus der Einbettung in die Plattform. Zu prüfen sind der vorhandene Vertrag, erlaubte Benutzergruppen, Anwendungsumfang, Integrationen und die administrativen Vorgaben der eigenen Instanz.
Welche Wahl zu welcher Ausgangslage passt
- Microsoft-zentrierter Arbeitsplatz: Power Platform ist häufig der naheliegende Prüfpunkt, weil Identitäten und Arbeitsdaten bereits in derselben Umgebung liegen können. Lizenz- und Datenrichtlinien müssen dennoch vor dem Bau geklärt werden.
- Google-orientierte, datenbasierte Arbeitsabläufe: AppSheet kann für Erfassungs- und Status-Apps einen kurzen Weg bieten. Die Datenquelle darf dabei nicht nur nach Bequemlichkeit gewählt werden.
- Größere, langlebige Geschäftsanwendung: Mendix oder OutSystems sind eher als gemeinsame Entwicklungsplattform von IT und Fachbereich zu betrachten. Für einen isolierten Kleinworkflow können sie unverhältnismäßig sein.
- Prozesse innerhalb einer bestehenden ServiceNow-Umgebung: App Engine kann Medienbrüche vermeiden und vorhandene Plattformregeln nutzen. Ohne diese Ausgangslage verliert der Ansatz einen wesentlichen Vorteil.
Ein Anbieterwechsel behebt keinen ungeklärten Prozess. Ist unklar, wer einen Antrag freigibt, welche Daten verbindlich sind oder wie ein Sonderfall behandelt wird, bildet jede Plattform diese Unklarheit nur in anderer Form ab.
Wo Fachbereiche nicht allein automatisieren sollten
Der Ausdruck „ohne Entwickler“ beschreibt den Bau einfacher Lösungen, nicht den Verzicht auf technische Verantwortung. Die IT sollte früh beteiligt werden, wenn eine Automatisierung Konten anlegt oder sperrt, Finanzbuchungen auslöst, vertrauliche Daten verarbeitet, Datensätze löscht oder mehrere zentrale Systeme verändert.
Auch individuelle APIs und ältere Fachanwendungen markieren häufig eine Grenze. Ein vorhandener Standardkonnektor kann die Verbindung vereinfachen, garantiert aber noch keine fachlich richtige Datenübertragung. Feldzuordnung, Fehlerbehandlung, Wiederholungsversuche und die Vermeidung doppelter Transaktionen müssen geplant werden. Fehlt ein Konnektor, sind benutzerdefinierte Schnittstellen oder RPA denkbar. Bei RPA bedient Software eine Oberfläche ähnlich wie ein Benutzer; schon kleine Änderungen an Fenstern oder Feldern können den Ablauf stören.
Künstliche Intelligenz erweitert Low-Code-Lösungen um Texterkennung, Klassifizierung oder generierte Inhalte. Ein KI-Ergebnis ist jedoch keine verlässliche Wenn-dann-Regel. Bei Verträgen, Zahlungen, personenbezogenen Daten oder verbindlichen Entscheidungen braucht es eine fachliche Prüfung und einen definierten Umgang mit unsicheren Ergebnissen.
Governance verhindert, dass schnelle Lösungen zur Schatten-IT werden
Eine produktive Low-Code-Lösung benötigt einen benannten Eigentümer. Diese Person verantwortet den fachlichen Ablauf, während die IT technische Leitplanken setzt. Persönliche Konten und private Verbindungen sind ungeeignet: Verlässt der Ersteller das Unternehmen oder ändert sein Kennwort, kann eine davon abhängige Automatisierung ausfallen.
Ein tragfähiger Rahmen umfasst mindestens folgende Punkte:
- getrennte Bereiche für Entwicklung, Test und produktiven Betrieb, soweit die Plattform dies unterstützt und der Umfang es rechtfertigt,
- freigegebene Datenquellen und Regeln dafür, welche Dienste miteinander Daten austauschen dürfen,
- rollenbasierte Berechtigungen nach dem Prinzip der erforderlichen Mindestzugriffe,
- Dokumentation von Auslösern, Verbindungen, Verantwortlichen und fachlichen Regeln,
- Überwachung fehlgeschlagener Ausführungen mit einer zuständigen Person für die Bearbeitung,
- ein geregelter Änderungsweg, damit Anpassungen getestet und bei Bedarf zurückgenommen werden können,
- eine Vertretung sowie ein Plan für Stilllegung, Datenexport und Nachfolge der Lösung.
Diese Regeln müssen nicht für einen ersten Wegwerfprototyp vollständig ausgebaut sein. Sobald echte Geschäftsdaten verarbeitet werden oder Kollegen auf den Ablauf angewiesen sind, werden sie Teil der Lösung und nicht bloß Verwaltungsaufwand.
Vom Prototyp zur verlässlichen Automatisierung
Ein geeigneter Pilot hat einen klaren Anfang, ein eindeutiges Ende und wenige Beteiligte. Zuerst wird der bestehende Ablauf mit seinen Ausnahmen aufgenommen. Danach entsteht eine kleine Version, die nur den Hauptfall abdeckt und mit Testdaten arbeitet. Der Fachbereich prüft, ob Status, Zuständigkeit und Ergebnis fachlich stimmen.
Vor dem produktiven Start sollte ein Test absichtlich fehlerhafte und unvollständige Eingaben enthalten. Ebenso wichtig sind doppelte Auslöser, nicht erreichbare Empfänger und fehlende Berechtigungen. Die Automatisierung muss entweder kontrolliert weiterarbeiten oder einen sichtbaren Fehler erzeugen. Ein Ablauf, der unbemerkt stehen bleibt, ist gefährlicher als ein manueller Prozess, dessen offener Vorgang auf dem Schreibtisch liegt.
Die Erfolgskontrolle sollte sich auf den ursprünglichen Engpass beziehen. Wurde die Bearbeitungszeit verkürzt? Sind weniger Rückfragen nötig? Gibt es weniger doppelte Datensätze? Lassen sich offene Vorgänge schneller finden? Erst wenn diese Fragen positiv beantwortet sind und Betrieb sowie Zuständigkeit geklärt wurden, lohnt sich die Ausweitung auf weitere Abteilungen.
Low-Code ersetzt damit nicht pauschal Entwickler. Die Plattform verschiebt vielmehr einen Teil der Umsetzung näher an die Fachabteilung. Einfache, regelbasierte Abläufe können dort selbst entstehen; IT und Entwicklung konzentrieren sich auf sichere Datenhaltung, Integrationen, Architektur und schwierige Ausnahmen. Genau diese Arbeitsteilung entscheidet, ob aus einem schnellen Prototyp eine dauerhaft nutzbare Unternehmenslösung wird.
