Zwischen Hype und Handwerk: Low Code als Motor in der Verwaltungsdigitalisierung – Welche Kompetenzen für nachnutzbare Fachverfahren nötig sind

Low-Code-Plattformen gelten als Hoffnungsträger für die Verwaltungsdigitalisierung: Fachverfahren sollen schneller entstehen, sich leichter anpassen lassen und im besten Fall sogar von Mitarbeitenden der Verwaltung – den vielzitierten »Citizen Developern« – mitgestaltet werden. Gleichzeitig zeigt die Praxis, dass ohne klare Architekturen, passende Rollen und ein durchdachtes Zusammenspiel von Fachbereichen und IT wenig gewonnen ist: Statt nachnutzbaren EfA-Fachverfahren drohen verteilte Insellösungen, die kaum wartbar sind.

Jens Tiemann (ÖFIT): Wir wollen klären, welche Teams und Fähigkeiten nötig sind, um Low Code erfolgreich in der öffentlichen Verwaltung einzuführen – und welche Rolle der oft diskutierte »Citizen Developer« dabei tatsächlich spielt.

Ich freue mich, dazu mit zwei erfahrene Low-Code-Experten sprechen zu dürfen:

Dr. Hermann Löh leitet bei bridgingIT den Bereich Prozessdigitalisierung und Low Code. BridgingIT ist eine technologieunabhängige IT-Unternehmensberatung, die unter anderem den Handlungsleitfaden »Low-Code als Triebfeder für Innovation in der Verwaltung« entwickelt hat.

Jan Gottschick vom Fraunhofer-Institut FOKUS treibt seit Jahren die Digitalisierung der Verwaltung voran. Er hat das Low‑Code‑Canvas entscheidend mitgestaltet und am daraus entstandenen ÖFIT-Wegbereiter »Startklar für Low Code« mitgewirkt.

Zum Einstieg: Jan, kurz zu deinem Hintergrund?

Jan Gottschick (FOKUS): Wir beschäftigen uns stark mit der Digitalisierung der Verwaltung. Ein Schwerpunkt von mir ist die Generierung von Code – also die Frage, wie man Software einfacher erstellen und pflegen kann, auch durch Fachexperten.

Jens Tiemann: Herr Löh, wie ist Ihr Zugang zum Thema Low Code?

Hermann Löh (bridgingIT): Ich verantworte bei bridgingIT das Thema Prozessdigitalisierung und Low Code und arbeite auch selbst als Architekt in Projekten. Vor rund zehn Jahren habe ich das Thema Low Code bei uns aufgebaut. Heute sind wir ein Team von etwa 20 Personen – mit Projekten in Wirtschaft und Verwaltung. Vom Hintergrund bin ich Maschinenbauingenieur, war in der Organisations- und Prozessentwicklung und in der Forschung zur Rolle von IT für Zusammenarbeit unterwegs – und bin so Schritt für Schritt in die IT und zu Low Code gekommen. Vielleicht konnte man mich am Anfang selber »Citizen Developer« nennen, auch wenn ich als Ingenieur immer ein Faible für Systemarchitekturen hatte.

Jens Tiemann: Wo setzen Sie Low Code typischerweise ein?

Hermann Löh: Gerade in verwaltungsorientierten Prozessen ist Low-Code fast immer die beste Wahl. Wir kommen meist dann ins Spiel, wenn die einfacheren Tools und Plattformen – wie die Microsoft Power Platform oder No-Code-Tools, nicht mehr ausreichen. Spannend wird es bei Fachverfahren, von eher einfachen bis hochkomplexen Szenarien.

Ein Beispiel: In einem Klinikum digitalisieren wir weite Teile der Verwaltung – im Zielausbau rund 100 Prozesse. Wir identifizieren und strukturieren Prozesse, aber wir schauen dabei immer auch auf den gesamten Kontext: Rollenmodelle, Vertretungsregelungen, Self-service Administration durch den Prozessverantwortlichen, Übersichten über Bearbeitungsstände für Antragsteller, wie Bereichsverantwortliche. Wenn ich im HR-Bereich 20 Prozesse habe, will ich nicht 20 Insellösungen, sondern ein stimmiges Gesamtsystem.

Wir bearbeiten auch geschäftskritische Großprozesse, z.B. die Konzernverrechnung eines Großkonzerns mit über 300 internationalen Tochtergesellschaften – komplett über eine Low-Code-Lösung. In der öffentlichen Hand arbeiten wir u.a. mit Landesbehörden, IT-Dienstleistern und öffentlichen Unternehmen wie der Deutschen Bahn an verwaltungsnahen, oft komplexen Prozessen.

Jens Tiemann: Das ist eine gute Brücke zu unserem Low-Code-Canvas: Wir wollten damit zeigen, dass die Einführung von Low Code eben nicht nur eine technische Frage ist, sondern stark organisatorische Aspekte hat – Prozesse neu denken, Organisation mitentwickeln, Rollen klären.

Jan, kannst Du unser Low-Code-Canvas kurz erklären?

Jan Gottschick: In der klassischen Verwaltungs-IT gibt es einen klaren Prozess: Lastenheft, Auftrag an ein Softwareunternehmen, strikte Trennung von Auftraggeber und Auftragnehmer. Bei Low Code ist die Ausgangssituation anders: Man führt eine Plattform ein, die für viele Vorhaben gedacht ist – das ist eine strategische Investition.

Dabei muss man sich mit mehr beschäftigen als nur fachlichen, technischen und Qualitätsanforderungen. Man braucht neues Know-how in der Organisation. Mitarbeitende arbeiten teilweise selbst mit der Plattform, Fachexperten sind an der Pflege beteiligt. Das heißt: Rollen und Kompetenzen verschieben sich.

Unser Canvas strukturiert diese technischen und organisatorischen Aspekte, um sichtbar zu machen, was es wirklich bedeutet, Low Code einzuführen.

Jens Tiemann: Im Low-Code-Canvas sind verschiedene Rollen beschrieben. Wie ordnest du Fachexperten und Citizen Developer ein?

Jan Gottschick: In der klassischen Entwicklung gibt es eine klare Trennung: Die Fachexperten schreiben Anforderungen, Entwickler setzen diese um. Mit Low Code löst sich das auf.

Die Idee ist, dass Fachexperten sich stärker an der Umsetzung beteiligen – etwa fachliche Regeln selbst formulieren. Aber: Klassische Fachexperten sind oft nicht technikaffin. Sie brauchen einen sehr leichten Zugang, grafische Unterstützung, möglichst wenige technische Formalismen. Das sind für mich eher »No Coder«.

Daneben gibt es technikaffine Personen in der Organisation, welche die Fachlichkeit gut kennen und mit Modellierungskonzepten zurechtkommen. Diese technikaffinen Fachexperten passen eher zum engeren Citizen-Developer- bzw. Low-Coder-Begriff.

Wichtig ist uns die Rolle Low-Code-Coach: Diese Person befähigt Fachexperten und Citizen Developer, die Plattform sinnvoll zu nutzen. Einerseits als »Lehrer«, um Muster, Fallstricke und Best Practices zu zeigen. Andererseits als Moderator zwischen Technikseite (Deep Coder, Administration, Hersteller) und Anwenderseite (Fachexperten, Citizen Developer).

Die Rolle ist meist nicht dauerhaft voll besetzt, sondern wird bei Bedarf genutzt – z.B. in einem internen Kompetenzzentrum oder bei einem Dienstleister. Häufig bringt der Low Code Coach auch architektonische Verantwortung mit und sorgt dafür, dass Fachteams und Low-Coder ihre Aufgaben langfristig bewältigen können.

Jens Tiemann: Herr Löh, wie sehen Sie den Citizen Developer in der Praxis?

Hermann Löh: Zunächst: Wir bieten die Rolle des Low Code Coach aktiv als Dienstleistung an – da gibt es klaren Bedarf.

Mit Citizen Developern habe ich unterschiedliche Erfahrungen gemacht. Fachlich versierte Mitarbeitende können kleinere Prozesse für ihr Team oft schneller digitalisieren als klassische IT-Projekte. Gleichzeitig stößt das Modell an Grenzen, wenn Lösungen entstehen sollen, die bereichsübergreifend nutzbar, langfristig wartbar und technisch konsistent sein müssen.

Bei einem Kunden sollte ich zum Beispiel Anwendungen, die von Citizen Developern erstellt wurden, auf eine neue Plattformversion migrieren. Die Lösungen funktionierten für den jeweiligen Anwendungsbereich, aber: Die gleiche Anwendung gab es sechs- oder siebenmal fast identisch – von verschiedenen Personen für unterschiedliche Bereiche. Wartbarkeit war praktisch nicht vorhanden. Schon eine einfache Änderung, etwa am E-Mail-Template, ließ sich nicht zentral durchführen. Nachnutzung im Sinne von »einer entwickelt, viele nutzen« war nicht gegeben. Das Problem lag dabei weniger im Engagement der Beteiligten als an geringerer Erfahrung und dem Fehlen gemeinsamer Architekturprinzipien und Governance-Strukturen.

Jens Tiemann: Gerade das wäre ja in der öffentlichen Verwaltung ein wichtiger Anspruch: Nachnutzung und EfA-Ansatz.

Hermann Löh: Die zentrale Frage ist: Will ich eine kleine Bereichslösung, um einem Team schnell zu helfen, oder will ich ein Fachverfahren, das ich langfristig einsetzen und nachnutzen will?

Wir haben Kunden mit 30 Standorten, die ähnliche, aber organisatorisch unterschiedlich verankerte Prozesse haben. Das ist auch im kommunalen Bereich typisch: Gleicher Grundprozess, andere Zuständigkeiten, zusätzliche Datenfelder, leicht abweichende Abläufe. Eine gute Low-Code-Plattform kann das abbilden – aber das effizient und gut wartbar umzusetzen ist nicht trivial. Der benötigte Expertisegrad steigt deutlich, es braucht architektonisches Denken und Projekterfahrung.

Eine Low-Code-Anwendung ist quasi ein Modell. Die Herausforderung ist: Sobald ich dieses Modell dupliziere, verliere ich im Normalfall die Rückverfolgbarkeit zum Ursprungsmodell. Wenn ich also einen Prozess in 20 Kopien habe, muss ich bei Änderungen 20 Modelle anfassen.

Wir gehen deshalb stark in Richtung parametrisierter Anwendungen und Workflows: Ein technisches Modell, das über Daten gesteuert wird. In Konfigurationstabellen steht, welche Schritte enthalten sind und wie sie verknüpft sind, oder wie sich ein Formular in einem bestimmten Schritt verhalten soll, welche Bereiche bearbeitbar sind oder was Pflichtfelder. Wenn sich etwas ändert, passe ich einen Datensatz an – und der Prozessablauf folgt den neuen Daten. Dann kann ich auch z.B. eine Schnittstelle ändern und mache es genau einmal, nicht zigmal.

In diesem Setup ist der Citizen Developer eher derjenige, der die Parametrisierung anpasst – bei organisatorischen Veränderungen, neuen Fällen usw. Er arbeitet bewusst nicht am technischen Modell selbst, sondern auf der Konfigurationsebene.

Jens Tiemann: Sie haben mal gesagt, mit »Citizen Developer« werden oft unrealistische Erwartungen geweckt. Wenn ich Sie richtig verstehe, sehen Sie eine Rolle, die generische Prozesse und Architekturen entwickelt – und eine zweite Rolle, die diese für den lokalen Kontext konfiguriert.

Hermann Löh: Genau. In unseren Projekten analysieren wir immer: Welche Teile eines Fachverfahrens sind stabil, welche variabel? Die Grundstruktur, welche Geschäftsobjekte betroffen sind und wie diese zusammenhängen, bleibt meist sehr stabil, Prozesse und Organisation ändern sich. Dafür gibt es Architekturmuster und Erfahrungswerte. Womit ich ein Problem habe, ist das Bild vom Citizen Developer als jemandem, der »ein bisschen Spaß an IT hat«, mal ein Excel baut und der dann freitags nachmittags mit Low-Code Lösungen bauen soll. Um Verwaltungsdigitalisierung voranzubringen, sind Lösungen nach meiner Erfahrung zu komplex und zu groß, um sie von jemandem »nebenbei« bauen zu lassen. Citizen Developer können entweder in der Anpassung mit ihrem Fachwissen gute Dienste leisten – oder sie entwickeln sich selber zu Experten, wenn man ihnen Raum – und Coaching – gibt.

Jan Gottschick: Wir sehen bei einer Low-Code-Plattform eine allgemeine technologische Basis, auf der wir generische Fachverfahren aufbauen können – ich glaube, das entspricht genau dem, was Sie gerade beschrieben haben: ein Grundgerüst, das Low-Coder bzw. Fachexperten später leicht verändern können.

Wir haben also zwei Aspekte: Low-Code als Mittel zur einfachen Anpassung – auch für Nicht-Informatiker – sowie generische Fachverfahren im Sinne des EfA-Prinzips, die anpassbar sein müssen.

Daraus ergibt sich folgendes Vorgehen:

• Low-Code-Plattform als allgemeine Basis,
• darauf aufbauend generische Fachverfahren, die EfA-fähig und architektonisch anspruchsvoll sind sowie
• die Anpassung vorhandener Lösungen durch Fachexperten mit Low-Code-Kenntnissen.

Hermann Löh: In diesem Kontext würde ich jedoch auf einen Punkt hinweisen: Low-Code Plattform ist nicht gleich Low-Code Plattform. Die Grundidee ist immer die gleiche: nicht alles neu programmieren, sondern Lösungen aus Bausteinen zusammensetzen, quasi aus »LEGO®«-Steinen.

Es gibt Low-Code Plattformen, die ähneln mehr »LEGO® DUPLO®«: Im ersten Moment sehr einfach und für »Citizen Developer« intuitiv zugänglich, aber die Möglichkeiten sind begrenzt.

Am anderen Ende gibt es Plattformen, die sind mehr wie »LEGO® Technic«: Die wirken im ersten Moment weniger zugänglich und man muss Erfahrung aufbauen, aber ich kann damit auch anspruchsvolle Lösungen sehr effizient aufbauen.

Man muss vom Ziel her denken: Will ich eine einfache Teamlösung oder EfA-fähige, nachnutzbare Fachverfahren? Ich darf nicht erwarten, dass eine schnelle »DUPLO®-Lösung« langfristig die gleiche Nachhaltigkeit und Anpassbarkeit hat wie eine »Technic-Lösung«. Das ist übrigens oft ein Problem bei Plattform-Auswahlverfahren: Die einfache Plattform kommt bei Präsentationen gut an, trägt aber nicht langfristig.

Ein Vorteil von Low Code ist, dass wir ein breiteres Rekrutierungsspektrum haben. Wir brauchen nicht nur klassische Programmierer, sondern Menschen, die Fachlichkeit, Organisation und Technik verbinden. Unser eigenes Team besteht – inklusive mir selbst – zu größeren Teilen aus Leuten, die man ursprünglich eher als Citizen Developer bezeichnen könnte – Ingenieure, Mathematiker, technische Betriebswirte –, die über die Jahre zu Low-Code-Architekten gereift sind. So etwas kann man aufbauen, wenn das Mindset passt und man Coaching organisiert.

Manche klassischen IT-Profile sehen Low-Code-Entwickler als »Entwickler zweiter Klasse«, weil sie »nicht richtig programmieren«. Ich sehe das anders: Intellektuell ist Low Code mindestens genauso herausfordernd, teilweise anspruchsvoller, weil man sehr nahe an Fachverfahren, Businessanforderungen und sozioökonomischen Rahmenbedingungen arbeitet. Für viele ist das ein attraktiveres Rollenbild.

Jan Gottschick: In der Low Code Association diskutieren wir genau das – Low-Coder als eigene Ausprägung von Entwicklern, im positiven Sinne. Bis hin zur Frage, ob »Low Coder« ein eigenes Berufsbild sein sollte.

Entscheidend ist: Low Coder brauchen zusätzlich zu technischen Fähigkeiten Kommunikations- und Businesskompetenzen, ähnlich wie Wirtschaftsinformatiker, aber mit noch stärkerer Nähe zur Praxis. Das hilft auch, Situationen zu vermeiden, in denen Kunden irgendwann nicht mehr verstehen, was ihr System eigentlich macht.

Jens Tiemann: Zum Schluss noch einmal zum Low Code Coach: Wie organisieren Sie Wissenstransfer konkret?

Hermann Löh: Die Low Code Coaches sind bei uns Architekten oder Entwickler, die gerne mit Menschen arbeiten und ihr Know-how weitergeben. Wir arbeiten dabei am konkreten Projekt:

• Am Anfang werden anhand eines Musterprojektes – gerne ein aktuelles Projekt des Kunden - die konzeptionellen und Entwicklungsschritte gemeinsam durchgespielt. Dann gibt es eine erste Lösung.
• Anschließend ist der Kunde selbst im Lead. Es ist wichtig, dass man nicht von einer schlechten Basis startet. Daher definieren am Anfang gemeinsam Meilensteine und machen Reviews: Passt das Prozessmodell? Ist das Datenmodell sinnvoll?
• Während der Umsetzung gibt es wöchentliche Jour-fixes, in denen wir den Stand anschauen, kritische Entscheidungen diskutieren und bei Blockaden helfen.

Dafür braucht es tiefes Plattform-Know-how – das ist Architektenniveau. In einem aktuellen Projekt mit einem großen norddeutschen öffentlichen IT-Provider haben wir genau dieses Setup: dreitägiger Einstieg, danach wöchentliche zweistündige Termine, erst mit Fokus auf Fachlichkeit und Modelle, dann auf Tricks und Kniffe der Plattform. Jede Plattform hat ihre Eigenheiten, und mit der Zeit weiß man, wie man damit umgeht.

Nachhaltiger Wissenstransfer bedeutet für uns außerdem, dass das Wissen nicht an einzelnen Personen hängt. Wir dokumentieren wichtige Entscheidungen, stellen wiederverwendbare Muster bereit und fördern den Austausch zwischen den Teams. So entsteht schrittweise eine organisationsweite Kompetenz für Low-Code-Entwicklung statt isolierter Einzellösungen.

Jan Gottschick: Das entspricht dem, was wir unter Low Code Coaching verstehen: Am Anfang Grundstrukturen legen, dann bei Bedarf gezielt unterstützen – je nach Komplexität mal näher an der Entwickler-, mal näher an der Fachseite.

Jens Tiemann: Vielen Dank für das Gespräch – und die Einblicke in Ihre Erfahrungen mit Low Code, Ausprägungen von Low-Code-Lösungen und die damit verbundenen Rollen.

Weiterführendes

Handlungsleitfaden von BridgingIT: Low-Code als Triebfeder für Innovation in der Verwaltung