Einleitung

Teil 4 hat gezeigt, dass unkodifizierte Assets zu künftigem negativem Erbe werden können. Daher stellt sich erneut die Frage: Ist Citizen Development wirklich ein Verfahren für produktive Systeme?

Die Antwort lautet nein. Citizen Development trägt den Produktivbetrieb nicht. Sein Wesen liegt darin, Nutzeranforderungen als funktionierenden „Entwurf“ greifbar zu machen.

Wer es als magisches Werkzeug missversteht, das sofort produktive Systeme liefert, reproduziert die Geschichte und erzeugt erneut negative Erbschaften en masse. Was bedeutet also „Entwurfsentwicklung“ – und wie nutzen wir sie richtig?

Die gesamte Serie

Worin liegt der Wert der Entwurfsentwicklung?

Apps oder Tools, die Bürgerteams erstellen, gelten oft als „unfertig“ oder „roh“. Genau diese Rauheit ist der Kern ihres Werts.

Anforderungen aus Nutzersicht treten hervor

Stellen wir uns eine von der Vertriebsabteilung gebaute Low-Code-Kundenverwaltung vor. Sie spiegelt das Bauchgefühl der Nutzerinnen wider, was im Alltag als bequem oder hinderlich empfunden wird.

  • Granularität der Eingabefelder
  • Welche Informationen auf der Übersichtsliste erscheinen sollen
  • Wie natürlich die Platzierung von Buttons und die Navigation wirken

Solche Nuancen lassen sich in einem klassischen „Anforderungskatalog“ nicht vermitteln. Beschreibungen in Textform verlieren fast jede Spur des gelebten Workflows. Erst ein funktionierender Prototyp löst echte Reaktionen aus: „Das ist brauchbar“ oder „In der Praxis wäre das mühsam“.

Fehlannahmen und Lücken tauchen früh auf

Gibt es einen laufenden Entwurf, lassen sich schnell Fragen klären wie „Ohne Suchfunktion an dieser Stelle kommen wir nicht aus“ oder „Der Genehmigungsworkflow braucht zwei statt drei Stufen“.

Traditionell basierte die Entwicklung häufig darauf, dass Fachleute den Anforderungskatalog interpretierten und daraus ein System „im Kopf“ entwarfen. Die Folge: Nach dem Go-Live hagelte es Beschwerden aus dem Fachbereich, weil die Lösung am Bedarf vorbeiging – Rückabwicklungen waren Alltag. Citizen Development kann diese Rückschleifen drastisch reduzieren.

Die Falle der direkten Produktivsetzung

Trotzdem darf der Entwurf nicht direkt zum Produktivsystem werden. Darin lauert ein tiefer Abgrund.

  • Skalierbarkeit: In einer kleinen Abteilung funktioniert es, im Roll-out auf das ganze Unternehmen stößt es sofort an Leistungsgrenzen.
  • Sicherheit: Zugriffskontrolle oder Log-Management sind lückenhaft; Prüfungs- und Compliance-Anforderungen bleiben unerfüllt.
  • Wartbarkeit: Die Lösung hängt an einzelnen Personen. Sobald sie wechseln oder gehen, wird alles zur Blackbox.

„Der Entwurf ist wertvoll“ bedeutet also nicht, „wir dürfen ihn produktiv setzen“. Sonst wiederholt sich exakt der Weg von Kami Excel vom Retter zum negativen Erbe.

Arbeitsteilung mit Fachleuten

Wie gehen wir also mit Citizen-Development-Ergebnissen um? Die Antwort ist klar.

  • Bürger erstellen den Entwurf: Sie konkretisieren die Nutzungsperspektive und legen einen Prototyp vor.
  • Fachleute schreiben die Reinschrift: Sie bauen die Lösung neu und erfüllen nicht-funktionale Anforderungen wie Skalierbarkeit, Sicherheit und Wartbarkeit.

Mit dieser Arbeitsteilung spielen beide Seiten ihre Stärken aus. Die Bürger übersetzen das „ungefilterte Gefühl der Front“ in Werkzeuge. Die Fachleute sichern Qualität und Nachhaltigkeit durch eine professionelle Ausarbeitung.

Während klassische Projekte auf einem textuellen Anforderungskatalog basierten und Fachleute vieles mutmaßen mussten, ermöglicht der Entwurf von Beginn an Diskussionen mit hoher Auflösung. Dadurch beschleunigt sich die Entwicklung und die Ergebnisse gewinnen an Qualität.

Was Governance schützen muss

Damit Citizen Development gesund bleibt, braucht die Organisation klare Regeln.

  • Klarstellen: „Citizen-Development-Ergebnisse bleiben Prototypen; ihr Einsatzbereich ist begrenzt.“
  • Inventarisieren: Verwaiste Apps oder RPAs regelmäßig sichten und ausmustern.
  • Übergabeprozess: Wertvolle Entwürfe gehen zwingend an die IT, werden dort professionell ausgearbeitet und erst danach produktiv gestellt.

Mit dieser Governance sinkt das Risiko, neue Kami-Excel-Erben zu erzeugen, erheblich. Ohne sie verkommt Citizen Development zum „Wild-App-Generator“ und bläht den technischen Schuldenberg nur weiter auf.

Fazit

Citizen Development ist kein Allzweckwerkzeug, um produktive Systeme zu erzeugen. Als „Entwurf“ dagegen hilft es, Fehlannahmen und Lücken in der Anforderungsdefinition zu reduzieren und die Nutzerperspektive in die Planung einzubetten.

Produktivbetrieb ist Aufgabe der Fachleute, Entwürfe stammen von den Bürgern. Halten wir uns an diese Rollenverteilung, wird Citizen Development zum Startpunkt künftiger Produktivität – nicht zu einer neuen Schuld.

Sein wahrer Wert liegt in einem demokratisierten Anforderungsprozess. Erst mit diesem Verständnis wird Citizen Development zu einer nachhaltigen Kraft für die Organisation.

Nächster Teil: Warum verschobene Perspektiven negative Erben in Serie produzieren (6/7)