Der Mythos vom Citizen Developer: warum wir ihn nicht mehr predigen
Wir verkaufen seit 2022 keine Citizen-Developer-Programme mehr, auch nicht auf Nachfrage. Warum die Idee in der Praxis nach 18 Monaten zusammenbricht, was wir aus über 40 Kundenfällen beobachten, und welches Modell wir stattdessen empfehlen.
Der Mythos vom Citizen Developer: warum wir ihn nicht mehr predigen
Wir verkaufen seit 2022 keine Citizen-Developer-Programme mehr. Auch nicht, wenn Kunden ausdrücklich danach fragen. Das hat uns Umsatz gekostet. Es hat uns vor sehr viel Aufräumarbeit bewahrt. In diesem Artikel erklären wir, warum.
Der Begriff "Citizen Developer" wurde Anfang der 2020er Jahre von Gartner populär gemacht. Die Idee: Mitarbeiter aus Fachbereichen, ohne Programmierausbildung, bauen mit No-Code-Werkzeugen die Workflows, die sie selbst brauchen. Die IT-Abteilung wird entlastet. Die Wertschöpfung passiert dort, wo das Wissen sitzt. Klingt nach einer guten Idee. War es auch, in der Theorie.
In der Praxis haben wir in den letzten vier Jahren bei mehr als 40 Kunden beobachtet, was passiert, wenn ein Citizen-Developer-Programm produktiv geht. Das Muster wiederholt sich. In den ersten sechs Monaten passiert viel: drei oder vier engagierte Fachmitarbeiter bauen zehn bis dreißig Workflows, einige davon nützlich, einige davon nicht. Es entsteht Begeisterung, weil etwas in Bewegung kommt, das vorher im IT-Backlog versumpft war.
Nach achtzehn Monaten sieht das Bild anders aus. Der Hauptbauer hat das Unternehmen verlassen oder die Rolle gewechselt. Die Workflows laufen, aber niemand weiß mehr, wie sie funktionieren. Die ehemaligen Citizen Developer wurden zu Schatten-IT-Verantwortlichen, ohne Mandat, ohne Budget, ohne klare Verantwortung. Die IT-Abteilung schaut auf die Plattform und weiß nicht, was sie damit anfangen soll. Wenn etwas bricht, ruft jemand an, meistens den, der eigentlich die Plattform sponsoren sollte.
Warum es nicht funktioniert hat
Drei Gründe, die wir immer wieder beobachten.
Erstens. Automatisierung ist keine Frage des Werkzeugs, sondern des Denkens. Wer einen Workflow baut, muss verstehen, was passiert, wenn Eingabedaten fehlerhaft sind, wenn ein externes System antwortet, das niemand erwartet hatte, wenn ein Trigger zweimal hintereinander auslöst. Wer das nicht weiß, baut Workflows, die im Demo-Modus funktionieren und im Echtbetrieb still scheitern. Make, n8n und Zapier reduzieren die Hürde, ein Werkzeug zu bedienen. Sie reduzieren nicht die Hürde, robust zu denken.
Zweitens. Workflows sind Software, auch wenn sie aus Klicken statt aus Tippen entstehen. Software braucht Wartung, Versionierung, Tests, Monitoring. Ein Citizen Developer, der nebenher zwei Stunden in der Woche Workflows baut, hat keine Zeit, sich um diese Aspekte zu kümmern. Sie werden ignoriert, bis etwas bricht. Dann ruft man die IT, die das Werkzeug nicht kennt, weil sie bewusst auf Abstand gehalten wurde.
Drittens. Der Karriereanreiz fehlt. Ein Citizen Developer baut Wert für die Firma, bekommt dafür aber keine Beförderung, keinen Titel, keine Spezialisierung im Lebenslauf. Wer wirklich gut wird, wechselt entweder ins Operations- oder Engineering-Team oder verlässt das Unternehmen. Was bleibt, sind halbfertige Workflows ohne Eigentümer.
Was wir stattdessen empfehlen
Wir empfehlen ein Modell, das wir "Automation Steward" nennen. Eine Rolle, kein Titel. Ein bis zwei Personen im Unternehmen, abhängig von der Größe, die offiziell Zeit für Automatisierung haben. Nicht nebenbei, sondern als Teil ihrer Stellenbeschreibung. Mindestens zwanzig Prozent ihrer Arbeitszeit. Idealerweise mehr.
Diese Personen müssen nicht aus der IT kommen. Sie können aus Operations stammen, aus dem Customer Success, aus dem Vertrieb, aus der Buchhaltung. Wichtig ist, dass sie ein Mandat haben: Sie dürfen Workflows bauen, sie dürfen Workflows ablehnen, sie dürfen alte Workflows stilllegen. Sie haben Budget für ein Werkzeug und für externe Beratung. Sie berichten regelmäßig an die Geschäftsführung, was läuft und was gebrochen ist.
Dieses Modell ist nicht so demokratisch wie Citizen Development. Es konzentriert Wissen in wenigen Köpfen. Das hat Risiken: was, wenn diese Person geht? Aber das Risiko ist kleiner als bei einem Modell mit zwanzig halbbewussten Bauern, weil eine konzentrierte Rolle dokumentieren, übergeben und nachbesetzen kann. Eine verstreute Citizen-Developer-Truppe kann das nicht.
Wann Citizen Development trotzdem Sinn ergibt
Es gibt einen schmalen Korridor, in dem das Modell funktioniert. In Unternehmen mit einer starken IT-Governance, klaren Plattform-Standards, einer aktiven Plattform-Eigentümer-Rolle und einer Kultur, die Dokumentation als Selbstverständlichkeit behandelt, kann Citizen Development eine Ergänzung sein. Nicht eine Strategie. Eine Ergänzung.
Konkret: wenn die IT-Abteilung eine vorbereitete Sandbox bereitstellt, in der Mitarbeiter persönliche Produktivitäts-Workflows bauen können, ohne an produktive Daten zu kommen, ist das ein guter Anwendungsfall. Persönliche Mail-Vorlagen, automatische Kalendereinträge, kleine Reminder, das alles ist Citizen-Developer-Material.
Was nicht funktioniert: Citizen Developer für Workflows einzusetzen, die produktive Geschäftsdaten verändern, externe Systeme beeinflussen oder Kundenkommunikation auslösen. Das ist nicht ihr Spielfeld, auch wenn die Marketing-Folien der Plattform-Anbieter etwas anderes nahelegen.
Was Plattform-Anbieter nicht gerne hören
Make, Zapier, n8n, Microsoft Power Platform und andere haben ein wirtschaftliches Interesse daran, das Citizen-Developer-Narrativ am Leben zu halten. Es verkauft mehr Lizenzen, weil es im Idealfall jeden Mitarbeiter zum Lizenzkonsumenten macht. Es senkt die wahrgenommene Komplexität, was den Verkaufsprozess vereinfacht.
Wir verstehen das. Wir sind selbst Partner einiger dieser Plattformen. Wir profitieren auch, wenn Lizenzen verkauft werden. Aber wir haben in zu vielen Audits gesehen, was nach achtzehn Monaten von einer Citizen-Developer-Initiative übrig bleibt. Meistens ein Berg aus halben Lösungen, niemandem zuzuordnen, niemand bereit, sie zu warten.
Wir sagen das unseren Kunden offen. Manche akzeptieren es, andere nicht. Wer es nicht akzeptiert, baut trotzdem ein Citizen-Developer-Programm auf, kommt nach zwei Jahren zurück und bittet uns, das Chaos aufzuräumen. Wir tun das, gegen Honorar. Aber wir hätten es lieber von vorne herein vermieden.
Eine kurze Bilanz
Citizen Development war keine schlechte Idee. Sie war eine Idee, die ein Problem überschätzt und ein anderes unterschätzt hat. Sie überschätzte den Engpass IT. In den meisten Unternehmen ist die IT-Abteilung kein Engpass für Automatisierung, sondern für klassische Software-Projekte. Automatisierungs-Plattformen sind im Vergleich dazu leicht. Was fehlt, sind nicht die Hände, sondern das systematische Denken über Wartung und Eigentümerschaft.
Sie unterschätzte, was Bauen wirklich heißt. Bauen heißt nicht nur, einmal etwas funktionierend zu machen. Bauen heißt auch, in zwei Jahren noch verstehen zu können, was man gebaut hat, und es entweder warten oder abschalten zu können.
Wer überlegt, ein Citizen-Developer-Programm zu starten, sollte sich vorher diese Frage stellen: Wer ist in achtzehn Monaten für die Workflows verantwortlich, die heute begonnen werden? Wenn die Antwort lautet "die, die sie gebaut haben", ist die Antwort falsch. Diese Personen werden in achtzehn Monaten nicht mehr dieselben Workflows pflegen wollen oder können.
Wenn die Antwort lautet "wir wissen es noch nicht", ist die ehrliche Konsequenz, das Programm nicht zu starten, bis die Antwort klar ist.
Wenn Sie unsicher sind, welches Modell zu Ihrer Organisation passt, ist der kostenlose Automations-Check ein guter Einstieg. In rund 30 Minuten haben wir gemeinsam einen ersten Eindruck.