Low-Code-Erfolgsfaktoren kursierten, obwohl die Studie fehlte

Eine Zahlenkette geistert derzeit durch die Fachpresse zu Low-Code- und No-Code-Plattformen: 51 ausgewertete Publikationen, daraus 25 kritische Erfolgsfaktoren, gebündelt in acht Handlungsbereichen für den sogenannten Citizen Developer, den Mitarbeiter ohne Programmierausbildung, der in der Fachabteilung selbst Software baut. Wer in einem Unternehmen entscheidet, ob es dafür ein zentrales Kontrollgremium, ein Anwendungsregister oder abgestufte Freigaben braucht, bekommt die Zahlen als abgeschlossenen wissenschaftlichen Befund vorgesetzt. Wer ihnen bis zur Studie dahinter folgt, findet zu dem Zeitpunkt, an dem sie bereits zitiert werden, keine nachlesbare Quelle.

Zur Studie mit 25 Erfolgsfaktoren führt bislang nur ein Konferenzprogramm#

Eine Suche nach der Publikation selbst liefert weder Preprint noch Datenbankeintrag noch DOI. Zu finden ist nur ein anderes Paper desselben Autorenteams aus dem Vorjahr, mit einer eigenen Auswertung von 58 Publikationen¹, aber zum Fachkräftemangel bei Low-Code-Einführungen, nicht zu Erfolgsfaktoren. Die Arbeit mit den 51/25/8-Zahlen selbst steht erst jetzt auf dem Programm einer internationalen Fachkonferenz für Informatik und Systemwissenschaften in Riga, vom 23. bis 26. August 2026²; die formale Publikation ist laut Zitationsvorschau erst für den Herbst 2026 vorgesehen. Eine vielzitierte Verhaltensstudie musste ihre Schlagzeile schon einmal ähnlich relativieren: In der Fußzeile der Präsentation waren mehrere Antwortstufen zu einem einzigen Wert zusammengerechnet³.

Erfolgsfaktoren-Listen zeigen nur die Überlebenden#

Der Wirtschaftswissenschaftler Jerker Denrell zeigte 2003 formal, wie Stichproben aus überlebenden, sichtbaren Organisationen auch riskante oder wirkungslose Praktiken fälschlich als erfolgsförderlich ausweisen, weil gescheiterte Fälle aus der Beobachtung herausfallen, bevor jemand sie auswertet (Denrell, „Vicarious Learning, Undersampling of Failure, and the Myths of Management“, Organization Science 14/3, 2003 pubsonline.informs.org ↗). Eine Literaturarbeit zu Erfolgsfaktoren von Low-Code-Einführungen wertet fast zwangsläufig überwiegend Berichte über funktionierende Projekte aus, denn über gescheiterte Einführungen wird selten publiziert. Selbst eine sauber gearbeitete Studie erbt diese Verzerrung von ihrer Grundgesamtheit.

Der Citizen Developer trägt eine Rolle ohne Stellenbeschreibung#

Verarbeitet die selbstgebaute Anwendung Verhaltens- oder Leistungsdaten von Kolleginnen und Kollegen, etwa eine Auswertung von Bearbeitungszeiten oder Fehlerquoten, greift § 87 Abs. 1 Nr. 6 Betriebsverfassungsgesetz gesetze-im-internet.de ↗: Die Einführung und Anwendung technischer Einrichtungen, die zur Überwachung von Verhalten oder Leistung bestimmt sind, unterliegt der Mitbestimmung des Betriebsrats, unabhängig davon, wer die Software gebaut hat. Wer haftet, wenn eine solche Anwendung fehlerhafte Werte ausgibt oder personenbezogene Daten falsch verarbeitet, bleibt in der Praxis meist ungeklärt: Weder die Stellenbeschreibung, die vom eigentlichen Fachjob handelt, noch die Vergütung, die keine Entwicklungstätigkeit vorsieht, noch die verbreitete Governance-Empfehlung, die nur Rollen und Prozesse beschreibt, regelt die Frage.

Tabellenkalkulationen liefern die einzige gemessene Fehlerquote#

Für die verwandte Praxis, dass fachfremde Beschäftigte produktive Logik in Tabellenkalkulationen bauen, fanden Feldaudits realer Excel-Dateien je nach Prüftiefe in 24 bis 94 Prozent der Fälle mindestens einen Fehler, mit Fehlerraten auf Zellebene von 0,4 bis 6,9 Prozent (R. Panko, „What We Don’t Know About Spreadsheet Errors Today“, EuSpRIG-Konferenzbeitrag, 2016⁴). Was eine einzelne falsche Formel anrichten kann, zeigte sich 2013: Eine vielzitierte Wachstumsstudie hatte fünf Länder aus einer Mittelwertformel versehentlich ausgeschlossen, ihr Kernergebnis kippte von minus 0,1 auf plus 2,2 Prozent Wachstum (Herndon, Ash und Pollin, Cambridge Journal of Economics, 2014). Beide Belege betreffen Tabellenkalkulationen, keine Low-Code-Plattform; eine methodisch vergleichbare Fehlerraten-Studie zu Low-Code-Anwendungen fand diese Recherche nicht. Wer diese gemessenen Grenzen kennt, übergibt riskante Logik an ausgebildete Entwickler in der Fachabteilung oder behält die Tabelle und ihre bekannten Schwächen.

Der Data Act sichert Daten, nicht die gebaute Anwendung#

Seit dem 12. September 2025 verpflichtet die europäische Datenverordnung Anbieter von Datenverarbeitungsdiensten, einen Wechsel zu erleichtern, ein oft angeführtes Argument gegen die Bindung an eine einzelne Plattform. Gesichert ist damit der Export der Daten, nicht die in der Plattform kodierten Workflows, Regeln und Oberflächen einer Fachbereichsanwendung. Die stärkste Garantie, dass ein System nach dem Wechsel funktional gleichwertig weiterläuft, gilt nur für Anbieter von Infrastrukturdiensten⁵. Die Plattform- und Softwareebene, auf der Low-Code läuft, bleibt davon ausgenommen.

Die IKT-Erhebung zählt Cloud- und KI-Nutzung, aber kein Low-Code#

Die IKT-Erhebung des Statistischen Bundesamts⁶ erfasst für 2025 Cloud-Computing-Nutzung (54 Prozent der Unternehmen ab zehn Beschäftigten) und den Einsatz künstlicher Intelligenz (26 Prozent), aber kein eigenes Merkmal für Low-Code, No-Code oder Citizen Development. Kursierende Prozentzahlen zur Verbreitung von Low-Code stammen damit von Plattformanbietern oder Marktanalysen, nicht vom Amt. Ein öffentlich einsehbares Register, das gebaute Anwendungen und ihre Wartung erfasst, wie es die Governance-Literatur regelmäßig empfiehlt, existiert bislang nicht; die einzige verfügbare Größe bleibt die Zahl gebauter Anwendungen, die für sich genommen weder Nutzen noch Wartungsaufwand ausweist. Der Reiz von Low-Code lag darin, an einer zentralen IT-Abteilung vorbeizukommen. Ein Kontrollgremium mit Freigaben und Register stellt genau diese Instanz wieder her, nur mit einer eigenen Lizenzrechnung obendrauf.

Governance-Entscheidungen wie ein zentrales Kontrollgremium oder ein Anwendungsregister stützen sich auf die 51/25/8-Kette, seit sie zitiert wird; nachprüfen ließ sich die Arbeit dahinter zu diesem Zeitpunkt nicht. Auch die für den Herbst angekündigte Fassung zeigt dann nur die Gemeinsamkeiten der gelungenen Projekte.

Die methodische Kritik an Erfolgsfaktoren-Literatur aus überwiegend gelungenen Fällen geht auf Jerker Denrell, „Vicarious Learning, Undersampling of Failure, and the Myths of Management“, Organization Science 14/3 (2003) pubsonline.informs.org ↗ zurück. Ort und Datum der Fachkonferenz, auf der die zugrunde liegende Studie erstmals vorgestellt wird, stammen von der öffentlichen Konferenzseite 2026.fedcsis.org ↗ (Riga, 23.–26. August 2026); der Konferenzband-Eintrag zum Beitrag annals-csis.org ↗ verzeichnet zum Stand dieses Textes nur Titel und Autoren, keinen Volltext. Die Mitbestimmungspflicht bei Überwachungseinrichtungen ergibt sich aus § 87 Abs. 1 Nr. 6 Betriebsverfassungsgesetz gesetze-im-internet.de ↗. Die Einschränkung der Data-Act-Portabilitätspflicht auf Infrastrukturdienste ist in einer früheren Ausgabe ausführlich hergeleitet. Die Zahlen zu Cloud- und KI-Nutzung sowie das Fehlen einer Erhebungskategorie für Low-Code stammen aus der IKT-Erhebung des Statistischen Bundesamts destatis.de ↗ für 2025. Die Fehlerraten in Tabellenkalkulationen belegt R. Panko, „What We Don’t Know About Spreadsheet Errors Today“, EuSpRIG-Konferenzbeitrag (2016) arxiv.org ↗; der Rechenfehler in der Wachstumsstudie ist dokumentiert in Herndon, Ash und Pollin, Cambridge Journal of Economics 38/2 (2014) doi.org ↗.