Einleitung

In Teil 1 und Teil 2 haben wir gesehen, dass EUC und Kami Excel die Teams an der Front kurzfristig retteten, dabei jedoch langfristig negative Erbschaften für die Organisationen hinterließen. In diesem Beitrag richten wir den Blick auf die Gegenwart und beleuchten die Licht- und Schattenseiten moderner Citizen-Development-Plattformen wie RPA sowie No-Code-/Low-Code-Tools.

Diese Werkzeuge sind eine Neuauflage des Kami-Excel-Phänomens und tragen zugleich durch ihren Maßstab und ihre Abhängigkeiten ein noch größeres Risiko in sich. Um im nächsten Teil den Einfluss generativer KI einordnen zu können, müssen wir ihre Natur präzise verstehen.

Die gesamte Serie

Licht – warum sie angenommen wurden

Sofortige Wirkung

Ohne eine Zeile Code zu schreiben lassen sich per GUI-Aktionen kleine Automatisierungen oder Apps sofort fertigstellen. Das Ersetzen täglicher Übertragungen oder standardisierter Abläufe innerhalb weniger Tage bringt den Teams einen enormen Vorteil.

Überzeugende Visualisierung

Flows und Screens werden in sichtbare Modelle gegossen, sodass auch Menschen ohne Spezialwissen sie nachvollziehen können. Für das Management ist eine „bewegte Visualisierung“ ein greifbares Ergebnis und häufig der ausschlaggebende Faktor für Investitionsentscheidungen.

Der erste Schritt der Bürger

Bei begrenzten Szenarien wie Eingabeformularen oder einfachen Workflows können auch Nicht-Entwicklerinnen eigene Lösungen bauen. Bis zu diesem Punkt lässt sich tatsächlich spüren, dass „es jede Person schaffen kann“ – ein Einstieg, der die Basis für Citizen Development in der gesamten Organisation verbreitert.

Schatten (1) – Die „Profi-Mauer“ in der Praxis

Oberflächlich scheinen diese Plattformen „von jeder Person bedienbar“. Versucht man jedoch, sie im operativen Alltag ernsthaft einzusetzen, verlangt es nach derselben Denke wie Programmieren und nach einem System-Engineering-Blick.

  • Unvermeidbare Kontrollstrukturen
    Um je nach Kundensituation andere Pfade zu gehen, braucht es Bedingungen (If/Else). Wer hunderte Datensätze verarbeitet, kommt ohne Schleifen (ForEach) nicht aus. Externe Systeme reagieren langsam oder fehlerhaft – Ausnahmebehandlung (Try/Catch) wird zwingend. Die GUI kaschiert nur, dass es im Kern Programmierung bleibt.

  • Verständnis für Datenstrukturen
    JSONs und Arrays müssen entpackt, Hierarchien gemappt und Datums- oder Zahlenformate vereinheitlicht werden – ohne dieses Wissen scheitert jede Integrationsaufgabe. Es ist weit mehr als nur Tabellen auszutauschen.

  • Komplexität in der Systemkopplung
    Tokenlaufzeiten verwalten, Konsistenz über mehrere Systeme hinweg sichern, Rate Limits umgehen – klassische Software-Engineering-Probleme treffen unverändert zu. Die GUI versteckt sie lediglich, wodurch die wahrgenommene Hürde sogar steigt.

  • Betriebs- und Qualitätsanforderungen
    Monitoring, Log-Sammlung, die Trennung zwischen Test- und Produktionsumgebung oder Rollbacks bei Releases müssen geplant werden. Weil kaum Quellcode existiert, sinkt die Beobachtbarkeit besonders schnell.

Angesichts dieser Hürden ist es für Citizen Developer schwer, allein Systeme zu bauen und zu pflegen, die dem Alltag standhalten. Am Ende bleiben Organisationen auf Fachkräfte angewiesen – obwohl ihre Kapazität schon zuvor knapp war.

Schatten (2) – Vendor-Lock-in und Portierungsprobleme

Kami Excel bot wenigstens einen gewissen Ausweg: Es bestand aus einer einzigen Datei. Tabellen ließen sich als CSV exportieren, für Formeln und Makros gab es teils kompatible Tabellenprogramme, und die Logik war zumindest grundsätzlich lesbar. Moderne RPA- und No-Code-/Low-Code-Lösungen sperren ihre Ergebnisse dagegen in plattformspezifische UIs oder Konfigurationsdateien ein.

  • Ein Wechsel zu einem anderen Produkt entspricht faktisch einem kompletten Neubau.
  • Das Ende oder die Änderung eines SaaS-Angebots liegt außerhalb der Nutzerkontrolle – angesammelte Assets können über Nacht wertlos werden.
  • Wer auf einer PaaS-Plattform baut, wird eng an deren Ökosystem gebunden; ein Umzug in andere Umgebungen ist äußerst schwer.
  • Wird Logik nicht im Code, sondern in der UI hinterlegt, lassen sich Problemstellen kaum finden oder durchsuchen.
  • Je nach Tool-Design ist der Ablauf erst nach einem Doppelklick auf Komponenten sichtbar – die Lesbarkeit sinkt drastisch.

Verglichen mit den in einer Tabelle eingeschlossenen Kami-Excel-Dateien sind Abhängigkeit und Verschuldungsrisiko hier deutlich größer.

Schatten (3) – Der Visualisierungs-Bias des Managements

Fachleute sehen schnell, dass sie früher oder später an die „Profi-Mauer“ stoßen. Das Management hingegen interpretiert grafische Flows und Bildschirme oft als Beweis, dass „es jede Person bedienen kann“.

Warum? Für die Unternehmensführung sind Systeme meist Blackboxen. Sobald Pfeile zwischen Prozesskästen erscheinen oder Eingabemasken sichtbar werden, entsteht das Gefühl, die innere Komplexität verstanden zu haben. In Wirklichkeit steckt dahinter dieselbe Kontrolllogik und Fehlerbehandlung wie in klassischer Software. Um sie alltagstauglich zu machen, braucht es zwingend Engineering-Know-how.

Diese Lücke zwischen der „Beruhigung“ des Managements und den Bedenken der Fachleute beschleunigt zwar die Einführung, züchtet aber zugleich den zukünftigen Schuldenberg.

Auf dem Weg zu „Kami Excel 2.0“

In der Summe wiederholen RPA sowie No-Code-/Low-Code-Plattformen das Muster von Kami Excel. Sie retten den Alltag mit schneller Wirkung, überzeugen das Management durch Visualisierung und hinterlassen durch Blackboxing und Personenabhängigkeit schwere Lasten.

Entscheidend anders ist jedoch der Wirkungsradius. Kami Excel blieb eine Datei. Moderne Citizen-Development-Ergebnisse greifen in Clouds und ganze Kernprozesse ein – sie können zu organisationweiten Schuldenfesseln werden. Dazu kommt eine noch stärkere Lock-in-Struktur als bei Excel. Genau das führt uns in Richtung dessen, was man „Kami Excel 2.0“ nennen könnte.

Fazit

  • RPA und No-Code-/Low-Code-Plattformen wurden dank sofortiger Wirkung und überzeugender Visualisierung sowohl an der Front als auch im Management akzeptiert.
  • Für robuste Anwendungen braucht es jedoch Wissen zu Kontrollstrukturen, Datenstrukturen, Systemintegration und Betrieb – reine Citizen Developer können das nicht allein stemmen.
  • Plattformspezifische UIs erschweren Portierung und verstärken den Vendor-Lock-in.
  • Der Visualisierungs-Bias im Management führt dazu, dass diese Risiken unterschätzt werden.

Moderne Citizen-Development-Ansätze sind mächtiger als Kami Excel, aber mindestens ebenso fragil. Im nächsten Teil betrachten wir, was passiert, wenn sich diese Dynamik mit generativer KI verbindet.

Nächster Teil: Wie generative KI das Citizen Development beeinflusst (4/7)