Citizen Developer: Wenn dein Team selbst automatisiert — und warum das funktioniert
Nicht jede Automatisierung braucht die IT. Wie Citizen Developer entstehen, was sie brauchen — und welche Governance verhindert, dass es schiefgeht.
Eine Buchhalterin in einem mittelständischen Handwerksbetrieb baut in einem Nachmittag eine Automation, die Rechnungs-Eingänge automatisch kategorisiert und ins Buchhaltungssystem überträgt. Sie hat keinen IT-Hintergrund. Sie hat Make genutzt — ein No-Code-Tool, das sie sich über ein paar YouTube-Videos selbst beigebracht hat.
Das ist kein Ausnahmefall mehr.
Warum Citizen Developer entstehen
Der klassische Weg zur Automatisierung: Jemand identifiziert ein Problem, schreibt eine Anforderung, reicht sie bei der IT ein, wartet. Wochen später, manchmal Monate, ist eine Lösung da — die manchmal das Problem löst, manchmal an ihm vorbeizielt.
Das ist nicht die Schuld der IT. Es ist ein strukturelles Problem: Die Menschen, die ein Problem am besten kennen, sind nicht dieselben, die die Lösung bauen.
Citizen Development dreht das um: Die Menschen mit dem Problem bauen die Lösung — mit Werkzeugen, die dafür gemacht sind, dass Nicht-Entwickler sie nutzen können.
Was No-Code heute tatsächlich leisten kann
Vor zehn Jahren war “No-Code” ein Versprechen, das oft nicht hielt. Heute ist es anders.
Moderne [[No-Code]]-Plattformen können:
- Daten zwischen beliebigen Systemen über APIs synchronisieren
- Formulare auswerten und Aktionen auslösen
- E-Mails filtern, weiterleiten, beantworten
- Benachrichtigungen an relevante Personen schicken
- Dokumente generieren aus vorhandenen Daten
- KI-Bausteine einbinden — Texte zusammenfassen, kategorisieren, prüfen
Das sind echte, produktiv nutzbare Automationen. Nicht Spielzeug.
Die Grenzen liegen bei komplexer Logik, unstrukturierten Sonderfällen und tiefen Systemintegrationen. Dort braucht es professionelle Entwicklung. Aber der Bereich dazwischen — wiederkehrende, regelbasierte Aufgaben mit stabilen Systemen — ist riesig und weitgehend unbesetzt.
Was Citizen Developer wirklich brauchen
Werkzeuge mit niedrigem Einstieg — Nicht jede Plattform eignet sich gleich. Make, Microsoft Power Automate und Notion Automations sind für Einsteiger zugänglich. [[N8n|n8n]] bietet mehr Flexibilität, aber auch mehr Komplexität. Die richtige Plattform hängt von den Systemen ab, die das Unternehmen bereits nutzt.
Grundlagen, keine Expertise — Citizen Developer müssen keine Entwickler werden. Sie müssen verstehen, was ein Trigger ist, wie Daten von A nach B fließen, und was passiert, wenn etwas schiefgeht. Das ist in einem halben Tag vermittelbar.
Echte Fälle zum Üben — Abstrakte Schulungen verpuffen. Was bleibt: an einem eigenen, konkreten Problem arbeiten. Die erste selbst gebaute Automation ist die Lernerfahrung.
Psychologische Sicherheit — Wer Angst hat, Fehler zu machen, probiert nichts aus. Citizen Development braucht eine Kultur, die Experimente erlaubt — und klarmacht, dass Fehler in einer kontrollierten Umgebung passieren sollen, nicht in der Produktion.
Warum Governance kein Widerspruch ist
Der verbreitete Fehler: Unternehmen führen No-Code-Tools ein und schauen zu, was passiert. Das Ergebnis nach zwölf Monaten: hunderte kleiner Automationen, von denen niemand weiß, welche noch laufen. Daten fließen an Orten, die niemand geplant hat. Wenn jemand das Unternehmen verlässt, fällt plötzlich ein Dutzend Prozesse aus.
[[AI Governance|Governance-Strukturen]] für Citizen Developer sind kein Bürokratieauftrag — sie sind das, was Citizen Development erst nachhaltig macht.
Drei Regeln genügen für den Anfang:
Inventar — Jede selbst gebaute Automation wird dokumentiert: Was macht sie? Wer hat sie gebaut? Welche Systeme und Daten berührt sie?
Zugriffsregeln — Citizen Developer dürfen nur auf Systeme und Daten zugreifen, die für ihre Rolle freigegeben sind. Keine Admin-Zugänge, keine Produktionsdaten ohne Freigabe.
Freigabeprozess — Automationen, die Kundendaten verarbeiten oder kritische Systeme verändern, brauchen eine kurze Prüfung, bevor sie in Betrieb gehen.
Das klingt nach Aufwand. In der Praxis kostet die Erstdokumentation einer Automation fünf Minuten.
Was wirklich schiefgeht — und was nicht
Was schiefgeht: Automationen ohne Fehlerbehandlung, die still scheitern ohne dass es jemand merkt. Daten, die in externe Dienste fließen, die nicht DSGVO-konform sind. Automationen, die auf einem Tool hängen, das nach einem Preisanstieg nicht mehr bezahlbar ist.
Was nicht schiefgeht: Dass Citizen Developer schlechteren Code bauen als Entwickler. Das ist ein falscher Vergleich. Sie bauen andere Dinge für andere Zwecke — und näher am Problem als jeder externe Entwickler.
Die unterschätzte Wirkung
Citizen Developer haben eine Nebeneffekt, der selten im ROI-Kalkül auftaucht: Sie verändern, wie ein Team über seine eigene Arbeit nachdenkt.
Wer gelernt hat, Prozesse in Automationen zu denken, sieht Ineffizienzen anders. Wer einmal selbst eine Automation gebaut hat, versteht besser, warum Datenqualität wichtig ist und was ein Trigger ist. Das ändert die Gesprächsqualität — mit IT, mit Management, mit Dienstleistern.
Citizen Development ist keine Bedrohung für Entwickler. Es ist eine Erweiterung der Fähigkeiten, die ein Team hat.