Low-Code in der Verwaltung: Chancen und Grenzen moderner Formularmanagementsysteme

Verwaltungsdigitalisierung ohne Programmierer – das ist das Versprechen von Low-Code-Plattformen. Wer Formulare konfigurieren statt entwickeln kann, soll Dienste schneller, günstiger und mit weniger Abhängigkeit von knappen IT-Ressourcen auf den Weg bringen. Das Versprechen ist nicht falsch. Aber es ist auch nicht vollständig. Wer Low-Code-Werkzeuge in Verwaltungsprojekten eingesetzt hat, kennt beide Seiten dieser Medaille.

Im OZG-Kontext hat sich eine Handvoll Plattformen als De-facto-Standard etabliert: form.io, das FIM-Redaktionssystem, Formular-Management-Systeme einzelner Länder-IT-Dienstleister sowie spezialisierte Lösungen wie das Formular-System des Bundes. Alle eint die Grundidee: Fachliche Anforderungen werden konfiguriert, nicht programmiert. Was sich im Detail unterscheidet, ist, wie weit diese Konfiguration trägt – und wo der Übergang zur Individualentwicklung unvermeidlich wird.

Was Low-Code in der Verwaltungspraxis tatsächlich leistet

Die Stärken sind real und sollten nicht kleingeredet werden. Für eine große Klasse von Verwaltungsformularen – strukturierte Antragsformulare mit klaren Pflichtfeldern, Bedingungslogiken und definierten Wertelisten – ist Low-Code genau das richtige Werkzeug.

• Schnelle Prototypen: Wer eine Antragsstrecke in form.io konfiguriert, hat in wenigen Stunden einen klickbaren Prototyp, der in Workshops mit Fachbehörden diskutiert werden kann. Das beschleunigt Anforderungserhebung und Abstimmung erheblich.
• Abbildung komplexer Bedingungslogiken: Felder, die nur sichtbar sind, wenn eine bestimmte Auswahl getroffen wurde; Pflichtfelder, die von vorangegangenen Angaben abhängen; mehrstufige Validierungen – das alles lässt sich in modernen Low-Code-Plattformen ohne eine Zeile Code konfigurieren.
• Wartbarkeit durch Fachseite: Wenn sich Rechtsgrundlagen ändern und ein Formularfeld angepasst werden muss, können fachkundige Mitarbeitende diese Änderung selbst vornehmen – ohne IT-Ticket und ohne Entwicklungszyklus.
• Standardisierte Datenausgabe: Plattformen, die auf FIM-Schemata aufbauen oder XÖV-konforme Ausgaben erzeugen, schaffen automatisch die Grundlage für die Anbindung an nachgelagerte Fachverfahren.

Wo die Grenzen liegen – drei Muster aus der Praxis

1. Komplexe Fachlogiken stoßen an Konfigurationsgrenzen

Nicht jede Verwaltungsleistung folgt einer linearen Antragslogik. Leistungen mit mehrstufigen Prüfketten, Ermessensentscheidungen oder stark verzweigten Prozesspfaden lassen sich in Low-Code-Systemen oft nur mit erheblichen Workarounds abbilden – oder gar nicht. Der Versuch, komplexe Fachlogik in ein Konfigurationssystem zu pressen, das dafür nicht ausgelegt ist, erzeugt fragile Lösungen, die beim nächsten Rechtsänderung auseinanderfallen.

Die ehrliche Einschätzung: Nicht jede Leistung eignet sich für Low-Code. Wer das zu Projektbeginn nicht klärt, investiert in eine Plattform, die am Ende durch Individualentwicklung ergänzt werden muss – mit dem vollen Aufwand beider Welten statt dem versprochenen Effizienzgewinn.

2. Vendor Lock-in und fehlende Interoperabilität

Formulare, die in einer proprietären Low-Code-Plattform erstellt wurden, lassen sich selten ohne erheblichen Aufwand in eine andere Umgebung übertragen. Im EfA-Kontext ist das ein strukturelles Problem: Wenn ein federführendes Land form.io einsetzt, ein Mitnutzer aber auf ein anderes System angewiesen ist, entstehen Migrationsaufwände, die im ursprünglichen Skalierungsversprechen nicht berücksichtigt waren.

Standards wie XÖV und FIM-Schemata mildern dieses Problem, weil sie die Datenstruktur entkoppeln. Wer sicherstellt, dass seine Low-Code-Lösung standardkonforme Ausgaben erzeugt, schafft zumindest auf der Datenseite Portierbarkeit – auch wenn die Konfiguration selbst plattformgebunden bleibt.

3. Fehlende föderale Standardisierung der Plattformen selbst

Deutschland hat im OZG-Kontext keine einheitliche Low-Code-Plattform. Verschiedene Länder setzen auf verschiedene Systeme, verschiedene IT-Dienstleister haben eigene Präferenzen, und selbst innerhalb eines Bundeslandes können unterschiedliche Ressorts unterschiedliche Werkzeuge nutzen. Das führt dazu, dass Erfahrungen, Konfigurationen und Vorlagen nicht zwischen Projekten transferiert werden können – und jede Implementierung weitgehend bei null anfängt.

Die entscheidende Frage vor Projektstart

Wer Low-Code in einem OZG-Projekt einsetzen will, sollte vor der Plattformentscheidung eine Frage beantworten: Wie komplex ist die Fachlogik der zu digitalisierenden Leistung wirklich?

Eine Checkliste für die Einschätzung:

• Gibt es mehr als drei ineinandergreifende Bedingungsebenen?
• Sind externe Datenquellen oder Registerabfragen im Prozess erforderlich?
• Sind mehrstufige Entscheidungen mit Ermessensspielräumen abzubilden?
• Müssen mehrere Behörden unterschiedliche Prozessschritte bearbeiten?
• Bestehen starke länderspezifische Varianten, die im selben System abgebildet sein müssen?

Je mehr dieser Punkte zutreffen, desto kritischer sollte die Low-Code-Entscheidung geprüft werden. Das bedeutet nicht automatisch Vollentwicklung – oft ist eine Kombination sinnvoll: Low-Code für die Formularebene, Individualentwicklung für die Schnittstellenlogik und die Fachverarbeitungsschicht.

Fazit

Low-Code ist kein Allheilmittel, aber für viele Leistungsklassen das richtige Werkzeug. Wer seine Leistungen ehrlich einschätzt, die passende Plattform wählt und von Anfang an auf standardkonforme Datenausgaben setzt, kann erheblich schneller und günstiger digitalisieren als mit klassischer Entwicklung.

Wer Low-Code als Abkürzung für jede Leistung betrachtet, unabhängig von ihrer Fachkomplexität, wird früher oder später an die Grenzen stoßen – und dann mit einem System weitermachen müssen, das nicht für die Anforderungen ausgelegt war. Die Entscheidung fällt am Anfang, nicht in der Mitte des Projekts.