Hier ist das Muster, das ich im Support immer wieder sehe. Ein Unternehmen kauft eine Low-Code-Plattform, führt sie bei einigen Teams ein, und drei Monate später eröffnet jemand ein Ticket mit der Frage, warum die Automatisierung nicht die versprochenen Ergebnisse liefert. Die Plattform funktioniert exakt wie vorgesehen. Die Workflows laufen. Die Dashboards stehen auf Grün.
Die Transformation ist nicht eingetreten.
Das ist kein Tool-Problem. Es ist ein Problem der Einordnung, und es beginnt, bevor überhaupt jemand die Plattform öffnet. Low-Code-Digitalisierung ist keine Beschaffungsentscheidung, die mit der Vertragsunterzeichnung abgeschlossen ist. Sie verändert das Betriebsmodell. Unternehmen, die sie lediglich als Tool-Auswahl behandeln, verfehlen ihre tatsächlichen Ziele regelmäßig – nicht weil die Plattformen schwach wären, sondern weil sie Software in einen Prozess implementiert haben, der nicht auf Veränderung ausgelegt war.
Das ist die These, die dieser Artikel begründet, und die die meisten Anbieter stillschweigend umgehen.
Was Teams erst spät lernen
- Der Kauf einer Low-Code-Plattform ist nicht dasselbe wie eine digitale Transformation.
- Geschwindigkeitsgewinne mit einer Low-Code-Plattform sind real – aber nur, wenn Governance und Verantwortlichkeiten vor dem Rollout aufgebaut werden.
- Citizen Developer benötigen einen klar definierten Rahmen und Zusammenarbeit mit der IT, nicht nur Zugang zu einem Tool.
- Das Betriebsmodell muss sich ändern. Die Plattform macht diese Veränderung lediglich umsetzbar.
Was Low-Code-Digitalisierung tatsächlich bedeutet
Wenn Menschen von Low-Code-Digitalisierung sprechen, meinen sie meist eines von zwei Dingen: den Kauf einer Plattform, mit der sich Apps schneller entwickeln lassen, oder den Ersatz eines Legacy-Prozesses durch etwas Neueres. Beides kann passieren. Keines davon ist jedoch die Transformation selbst.
Die tatsächliche Definition erfordert, zwei Gedanken gleichzeitig zu berücksichtigen. Low-Code ist die Tooling-Ebene. Digitale Transformation ist die organisatorische Veränderung darunter. Wenn beides zusammenwirkt, entsteht ein Unternehmen, das anders agieren kann: mit schnelleren Iterationen, bereichsübergreifender Prozessverantwortung und Entscheidungen näher an der eigentlichen Arbeit. Wird nur die Tooling-Ebene adressiert, erhalten Sie schnellere Apps auf denselben fehlerhaften Prozessen.
Die Frage vor jedem Rollout lautet: Was wird sich daran, wie dieses Unternehmen arbeitet, in sechs Monaten tatsächlich verändert haben? Wenn die Antwort lautet: „Wir werden die Plattform eingeführt haben“, dann ist das ein Projektmeilenstein, kein Transformationsziel.
Was der „Low-Code“-Teil abdeckt
Low-Code-Entwicklung nutzt eine visuelle Oberfläche und vorgefertigte Komponenten, damit sowohl professionelle Entwickler als auch Fachanwender Anwendungen entwickeln und bereitstellen können, ohne den Großteil des zugrunde liegenden Codes von Hand zu schreiben. Drag-and-Drop-Workflow-Builder, Connector-Bibliotheken, Formulargeneratoren und Datenmapping-Tools bilden die zentrale Oberfläche. Forresters Definition ist hier hilfreich: Low-Code-Plattformen abstrahieren die Mechanik des Programmierens hinter visuellen Tools, sodass die Geschwindigkeit der Entwicklung nicht mehr vollständig von der Größe des Entwicklungsteams abhängt.
Das „Minimal“ in „minimaler Programmierung“ bedeutet weiterhin Programmierung für komplexe Logik, individuelle Integrationen oder Sonderfälle, die vorgefertigte Komponenten nicht abdecken. Das ist wichtig, denn Teams, die diese Einschränkung überspringen, setzen bei Citizen Developern falsche Erwartungen und wundern sich dann, warum die Produktion in Schritt sieben scheitert.
Was der Teil „digitale Transformation“ tatsächlich erfordert
Digitale Transformation bedeutet, die Art und Weise zu verändern, wie Arbeit erledigt wird – den Workflow, die Ownership von Geschäftsprozessen, die beteiligten Rollen und die Feedback-Schleifen zwischen ihnen. Eine App bereitzustellen, die eine E-Mail-Kette ersetzt, ist ein sinnvoller Schritt. Zur Transformation wird es erst, wenn der zugrunde liegende Prozess bewusst neu gestaltet wurde und nun jemand dafür verantwortlich ist, ihn anders als zuvor zu pflegen.
Der Fehler, den ich am häufigsten sehe, besteht darin, die Bereitstellung als Ziellinie zu behandeln. Die App geht live. Das Projekt wird abgeschlossen. Niemand aktualisiert das Governance-Modell. Niemand schult das Team, das nun das Tool verantwortet. Sechs Monate später ist der Prozess wieder in Richtung des alten Musters abgedriftet, weil die organisatorische Infrastruktur, die den neuen Prozess dauerhaft verankert hätte, nie aufgebaut wurde.
Warum Low-Code zum Kern von Initiativen zur digitalen Transformation geworden ist
Die praktische Antwort lautet: Backlog-Druck. IT-Abteilungen in den meisten mittelgroßen und großen Unternehmen sind überlastet, und Fachbereiche warten nicht länger auf Entwicklungs-Sprints, um operative Probleme zu lösen. Low-Code-Plattformen haben diese Lücke geschlossen. Sie ermöglichen Stakeholdern aus den Fachbereichen, Lösungen zu entwickeln und zu iterieren, ohne sich hinter dem Entwicklungsteam einreihen zu müssen, während die Lösungen weiterhin auf einer Infrastruktur laufen, die die IT überwachen kann.
Das ist der operative Druck. Die Marktdaten bestätigen, dass es sich inzwischen um eine strukturelle und nicht mehr um eine experimentelle Entwicklung handelt.
Laut Research and Markets wird der Markt für Low-Code-Entwicklungsplattformen im Jahr 2026 auf 66,2 Milliarden USD geschätzt und soll bis 2030 auf 205,56 Milliarden USD wachsen, bei einer jährlichen Wachstumsrate von 32,7 %. Fortune Business Insights prognostiziert einen noch größeren Anstieg: von 48,91 Milliarden USD im Jahr 2026 auf 376,92 Milliarden USD im Jahr 2034. Unabhängig davon, wie hoch die genaue Zahl letztlich ausfällt, ist die Richtung eindeutig: Die Investitionen in diese Kategorie verlangsamen sich nicht. Dieses Marktwachstum spiegelt den Druck in Milliardenhöhe wider, schneller entwickeln und sich schneller anpassen zu müssen – genau das, was Digitalstrategien im Rahmen der digitalen Transformation verlangen.
Das Going Digital Integrated Policy Framework der OECD ordnet dies umfassender ein: Digitale Transformation ist ein politisches und organisatorisches Problem, nicht bloß ein Software-Thema. Sie umfasst Zugang, Nutzung, Innovation, Arbeitsplätze, Vertrauen und Marktöffnung. Low-Code ist die Ebene, die die organisatorische Seite dieser Veränderung umsetzbarer macht, insbesondere für Teams ohne die technische Tiefe, um Lösungen von Grund auf zu entwickeln.
Das IT-Backlog-Problem, das Low-Code und No-Code zu lösen begannen
In der Praxis sah das Backlog-Problem so aus: Fachbereiche reichten Anfragen bei der IT ein, warteten Wochen oder Monate und entwickelten manchmal Workarounds in Tabellenkalkulationen, die zu tragender Infrastruktur wurden, deren Existenz niemand eingestehen wollte. Low-Code- und No-Code-Plattformen veränderten die Kosten dieses Wartens.
Statt dass jede kleine Prozessänderung ein Entwicklungsticket erforderte, konnten Fachanwender eigene Tools prototypisieren, während die IT eine Prüf- und Governance-Rolle statt einer reinen Entwicklungsrolle einnahm. Entwicklungsteams konnten sich auf Aufgaben konzentrieren, die tatsächlich Engineering-Kompetenz erforderten. Betriebsteams erzielten schneller Ergebnisse. Das ist kein Marketing-Narrativ – es ist die Dynamik, die die frühe Einführung vorangetrieben hat, und der Grund, warum Unternehmen überhaupt auf Low-Code-Tools setzten, um die IT zu entlasten und ihre Agilität zu verbessern.
Der Teil, der es nicht in die Vertriebspräsentation schafft: Das funktioniert nur, wenn die IT tatsächliche Aufsicht behält. Wird die IT vollständig aus der Gleichung entfernt – was passiert, wenn Governance ausgelassen wird –, verlagert sich das Tabellenkalkulationsproblem einfach in ein anderes Tool.
Nutzungszahlen, die zeigen, dass dies nicht länger experimentell ist
Die Nutzung von Low-Code ist inzwischen Mainstream. Gartner prognostizierte, dass 75 % aller neuen Unternehmensanwendungen auf Low-Code-Plattformen entwickelt werden und damit 65 % der gesamten Anwendungsentwicklung ausmachen werden. Eine Mendix-Studie ergab, dass 84 % der Unternehmen sagen, Low-Code ermögliche mehr Menschen, Lösungen zu entwickeln, und 69 % es inzwischen als Kerntechnologie statt als Pilotprogramm behandeln.
Das Marktsignal, das Unternehmen übersehen, wenn sie dies als Tool-Evaluierung behandeln: Wenn Ihre Wettbewerber bereits produktive Workloads auf Low-Code-Plattformen ausführen, hat sich das Adoptionsrisiko umgekehrt. Das Risiko lautet nicht mehr: „Sollten wir das ausprobieren?“ Es lautet: „Was verlieren wir, wenn wir warten?“ Eine gut gesteuerte Low-Code-Lösung, die heute entwickelt wird, entfaltet im Laufe der Zeit einen kumulativen Nutzen. Unternehmen, die 2027 noch evaluieren, werden zwei oder drei Iterationen hinter Teams zurückliegen, die ihren ersten Governance-Fehler bereits erlebt und behoben haben. Low-Code-Plattformen ermöglichen schnelle Entwicklungszyklen, aber diese Zyklen beginnen nicht am ersten Tag des Vertrags. Sie beginnen am ersten Tag des Governance-Modells.
Wie Low-Code-Plattformen die Softwareentwicklung tatsächlich beschleunigen
Die Geschwindigkeit entsteht durch mehrere Ebenen, die zusammenwirken. Es lohnt sich, konkret zu betrachten, welche Ebene was leistet – denn Teams, die nur eine Ebene verstehen, schaffen falsche Erwartungen und geben dann der Plattform die Schuld für Probleme, die in Wirklichkeit Architekturentscheidungen sind.
Die erste Ebene ist die visuelle Entwicklungsoberfläche. Ein Drag-and-Drop-Canvas, mit dem Sie einen Trigger, eine Bedingung und eine Aktion verbinden können, ohne die Verbindungslogik dazwischen selbst zu schreiben, ist tatsächlich schneller als diese Logik zu programmieren. Laut Forrester kann die Low-Code-Anwendungsentwicklung bei passenden Anwendungsfällen bis zu zehnmal schneller sein als die traditionelle Entwicklung. Diese Zahl bewährt sich in der Praxis für die Problemkategorie, für die Low-Code entwickelt wurde: Automatisierung von Geschäftsprozessen, Genehmigungs-Workflows, Routing von Serviceanfragen und Abteilungsanwendungen. Sie gilt nicht für latenzsensitive Backend-Services, stark individualisierte Benutzeroberflächen oder Integrationen mit tiefgreifend nicht standardisierten Legacy-Systemen. Zu wissen, in welche Kategorie Ihr Problem fällt, erspart viel Aufwand.
Die zweite Ebene sind vorgefertigte Komponenten. Moderne Low-Code-Plattformen bieten Bibliotheken mit vorkonfigurierten Connectors für gängige SaaS-Tools, Nodes zur Datentransformation und Blöcke für bedingte Logik. Statt eine Integration von Grund auf zu schreiben, wählen Sie die App aus, autorisieren sie und ordnen die Felder zu. Hier wird KI zu einem relevanten Beschleuniger: Einige Plattformen generieren inzwischen Workflow-Vorschläge, ordnen Felder anhand von Schemata automatisch zu und zeigen passende vorgefertigte Vorlagen an, wenn Sie beschreiben, was Sie erreichen möchten. Der OECD Digital Education Outlook 2026 stellt fest, dass generative KI zunehmend in die Tools integriert wird, mit denen Menschen lernen und entwickeln – Automatisierungsplattformen sind eines der deutlichsten praktischen Beispiele für diesen Wandel.
Die dritte Ebene ist die Iterationsgeschwindigkeit der Low-Code-Entwicklungsplattform. Sobald ein Workflow live ist, erfordert seine Anpassung keinen Bereitstellungszyklus im traditionellen Sinne. Ein Fachanwender oder Entwickler passt ein Feldmapping an, aktualisiert eine Bedingung, fügt einen Schritt hinzu – und die Änderung kann innerhalb weniger Minuten getestet und live geschaltet werden. Diese Geschwindigkeit ist der Punkt, an dem Transformationsziele tatsächlich erreicht werden: nicht bei der ersten Bereitstellung, sondern in der anschließenden Iterationsschleife.
Wo Automatisierung in der Praxis die meiste Zeit spart
Nach meiner Erfahrung mit Teams, die Automatisierungs-Workflows einführen, entstehen die größten Zeitgewinne in der Mitte eines Prozesses, nicht an seinen Rändern. Den Anfang – etwa wenn jemand ein Formular absendet oder einen Datensatz erstellt – und das Ende – etwa wenn ein Bericht generiert wird – gehen Teams meist zuerst an, weil beide sichtbar sind. Die unsichtbaren Kosten liegen in den Übergaben: die Genehmigung, die in einem Posteingang wartet, das IT-Ticket in einer Warteschlange oder die Ausrüstungsanfrage, bei der jemand manuell nachfassen muss, weil nichts sie automatisch weiterleitet.
Die Automatisierung von Genehmigungen, Serviceanfragen, Fallrouting und Statusbenachrichtigungen ist der Bereich, in dem sich die tatsächliche Verkürzung der Entwicklungszeit in der Praxis zeigt. Ein Onboarding-Prozess für neue Mitarbeitende, bei dem HR bisher manuell die IT per E-Mail kontaktieren, die Verfügbarkeit von Ausstattung prüfen und bei der Kontoerstellung nachfassen musste, kann zu einem einzelnen Workflow werden, der alle drei Aufgaben erledigt und nur Ausnahmen markiert. Das ist nicht einfach schnelleres Entwickeln von Apps um seiner selbst willen. Das bedeutet, digitale Transformation mit Low-Code so einzusetzen, dass sich die Betriebskosten tatsächlich verändern. Und wenn Sie diese mittlere Ebene automatisieren und Übergaben vereinfachen, sparen Sie nicht nur Zeit – Sie machen den Prozess auf eine zuvor nicht mögliche Weise sichtbar, was oft schon eine Erkenntnis für sich ist.
Die Automatisierung, die am meisten Zeit spart, legt meist auch die meisten fehlerhaften Prozessannahmen offen.
Wie Integrationsfunktionen Low-Code mit bestehenden Systemen verbinden
Das häufigste Missverständnis, mit dem ich zu diesem Thema konfrontiert werde, lautet in etwa: „Aber wir haben Legacy-Systeme – Low-Code wird diese nicht erreichen.“ Das ist eine nachvollziehbare Sorge, liegt aber meist falsch darin, wo die tatsächliche Einschränkung besteht.
Moderne Low-Code-Entwicklungsplattformen sind darauf ausgelegt, Integration als zentrale Funktion bereitzustellen. Die meisten bieten Hunderte vorgefertigte Connectors für gängige ERP-, CRM-, HRIS- und SaaS-Systeme sowie APIs und HTTP-Request-Nodes für alles, was nicht vorgefertigt verfügbar ist. Die Frage ist meist nicht, ob die Plattform Ihre bestehenden Systeme verbinden kann – in der Regel kann sie das. Die Frage ist, ob das Team weiß, wie es mit den Sonderfällen umgeht, die auftreten, wenn diese Integration produktiv läuft und Daten nicht in der erwarteten Form eintreffen.
Das Skalierbarkeitsthema ist damit verwandt, aber eigenständig. Ein Low-Code-Workflow, der 50 Datensätze pro Tag verarbeitet, skaliert anders als ein Workflow mit 500.000 Datensätzen. Die meisten Plattformen bewältigen dies gut, wenn Workflows von Beginn an mit Blick auf Skalierung konzipiert werden. Probleme entstehen, wenn ein Connector oder eine Automatisierung für einen kleinen Anwendungsfall ohne Neugestaltung auf Unternehmensvolumen hochskaliert wird. Das ist keine Einschränkung von Low-Code als Ansatz. Es ist eine Governance-Frage: Wer prüft die Workflow-Architektur, bevor sie von einer Abteilung auf das gesamte Unternehmen ausgeweitet wird? Legacy-Systeme und Skalierbarkeit sind reale Faktoren. Sie sind lediglich Engineering-Faktoren im Low-Code-Gewand.
📊 Zahlen und Fakten:
Gartner prognostizierte, dass 70 % aller Geschäftsanwendungen auf Low-Code- oder No-Code-Plattformen entwickelt werden. Das ist längst keine Zukunftsprognose mehr – es beschreibt die Richtung, in die sich Investitionen in die Unternehmensentwicklung bereits bewegen. Wenn Ihr Team Low-Code noch immer als Abteilungsexperiment behandelt, vergrößert sich die Lücke zwischen Ihrem Takt und dem des Marktes mit jedem Quartal.
Die tatsächlichen Vorteile von Low-Code für Transformationsziele
Die Vorteile, die Sie kennen sollten, sind diejenigen, die sich tatsächlich in Transformationsergebnissen zeigen, nicht nur in Entwicklungsgeschwindigkeit. Hier ist die ehrliche Liste.
Geschwindigkeit von der Idee bis zur bereitgestellten Lösung
Die Lücke, die Transformationsprogramme scheitern lässt, ist die Zeit zwischen der Identifizierung eines Prozessproblems und der Bereitstellung einer funktionierenden Lösung. Low-Code verkürzt diese Lücke in den meisten Fällen von Wochen auf Tage. Die Forrester-Zahl – bis zu zehnmal schneller als die traditionelle Entwicklung – bezieht sich auf geeignete Anwendungsfälle, aber selbst eine dreifache Verbesserung verändert, woran ein Team in einem Quartal realistisch iterieren kann.
Demokratisierung der Softwareentwicklung über das Entwicklungsteam hinaus
Wenn Fachanwender Tools für ihren eigenen Bereich entwickeln und verantworten können, wird der Backlog abgebaut und die Lösungen liegen näher am tatsächlichen Problem. Diese Dynamik der Demokratisierung der Softwareentwicklung ist real, funktioniert jedoch nur mit Leitplanken. Demokratisierung ohne Governance führt zu siebzehn konkurrierenden Automatisierungen, die dieselben CRM-Datensätze berühren, während niemand weiß, welche davon maßgeblich ist.
IT und Fachbereiche arbeiten auf derselben Plattform statt aneinander vorbei
Die traditionelle Reibung zwischen „dem Zeitplan der IT“ und „dem Bedarf des Fachbereichs“ führt direkt zu langsamen Transformationsprogrammen. Wenn beide Seiten dieselben Low-Code-Tools nutzen – Fachanwender entwickeln, die IT steuert und unterstützt bei komplexen Integrationen –, wird die Zusammenarbeit strukturell statt politisch. Diese Zusammenarbeit ist eine der zentralen strukturellen Voraussetzungen für jedes Transformationsprogramm, das dauerhaft Bestand haben soll.
Weniger Schatten-IT und das damit verbundene Compliance-Risiko
Wenn Fachanwender keinen tragfähigen Weg haben, das zu entwickeln, was sie benötigen, erstellen sie es in Tools, von denen die IT nichts weiß. Fachanwender mit einer freigegebenen Low-Code-Plattform und Unterstützung bei deren Nutzung greifen nicht mehr zur nicht genehmigten Tabellenkalkulations-Makrolösung. Das ist ein echter Compliance- und Sicherheitsvorteil für regulierte Branchen: Unbekannte Risiken werden gegen handhabbare Risiken eingetauscht.
Schnelle Anwendungsentwicklung, die echte Agilität unterstützt
Agile Methoden setzen voraus, dass Sie schnell testen und iterieren können. Traditionelle Entwicklungszyklen machten das teuer. Low-Code macht es günstig genug, dass ein Team tatsächlich zwei Versionen eines Workflows betreiben, die Ergebnisse vergleichen und die bessere Variante bereitstellen kann – ohne einen sechswöchigen Entwicklungszyklus. Diese Iterationsgeschwindigkeit ist es, was „agil“ auf Prozessebene tatsächlich erfordert, nicht nur auf Planungsebene. Sie ermöglicht Transformationsprogrammen außerdem, nahezu in Echtzeit auf veränderte Kunden- oder Geschäftsanforderungen zu reagieren, statt auf das nächste Release-Fenster zu warten.
Produktivitätsgewinne, die sich in der Betriebsebene ansammeln, nicht nur in der Entwicklung
Die zentrale Produktivitätsaussage zu Low-Code bezieht sich meist darauf, dass Entwickler schneller entwickeln. Der weniger diskutierte Gewinn liegt im Betrieb: die wiederkehrenden Aufgaben in HR, Finanzen, Kundensupport und Vertrieb, die von den Personen automatisiert werden, denen diese Prozesse gehören. Dort liegt die nachhaltige Produktivitätsverbesserung, weil diese Teams ihre Gewinne durch Iteration vervielfachen, statt Automatisierung als einmaliges Projekt zu behandeln.
Wo Low-Code-Digitalisierung scheitert
Dies ist der Abschnitt, den die meisten Artikel von Plattformanbietern auslassen. Deshalb werde ich konkret darauf eingehen, was ich tatsächlich sehe, wenn Rollouts ins Stocken geraten.
Die Fehlermuster sind nicht technischer Natur. Mit sehr wenigen Ausnahmen sind Low-Code-Plattformen heute funktional, leistungsfähig und gut genug dokumentiert, um das zu entwickeln, was Teams benötigen. Die Probleme sind organisatorisch. Sie zeigen sich in der Lücke zwischen dem, was die Plattform leisten kann, und dem, wofür das Team tatsächlich aufgestellt ist: Wartung, Governance und Iteration.
Die zwei häufigsten Bruchstellen sind unrealistische Erwartungen daran, was Citizen Developer eigenständig entwickeln können, sowie Governance-Strukturen, die entweder gar nicht existieren oder erst nach dem ersten produktiven Vorfall konzipiert werden.
Was Citizen Developer ohne Unterstützung durch Entwickler realistisch entwickeln können
Citizen Development funktioniert innerhalb eines klar definierten Rahmens gut. Ein Finanzanalyst erstellt eine automatisierte Ausgabenübersicht, die jeden Montag um 8 Uhr läuft und in Slack veröffentlicht wird – ohne Hilfe von Entwicklern vollständig umsetzbar. Ein HR-Koordinator erstellt einen Benachrichtigungs-Workflow, der ausgelöst wird, wenn ein neuer Mitarbeiter im HRIS hinzugefügt wird – ebenfalls umsetzbar. Ein Teamleiter im Kundenservice erstellt eine Fallrouting-Regel, die Tickets der ersten Stufe an die richtige Warteschlange weiterleitet – unkompliziert.
Probleme entstehen, wenn derselbe Citizen Developer versucht, eine produktionsreife Low-Code-Anwendung zu entwickeln, die sich mit vier Systemen integriert, komplexe bedingte Logik verarbeitet und skalieren muss, wenn sich die Teamgröße verdoppelt. Ab diesem Punkt reicht die visuelle Ebene der Plattform nicht mehr aus. Individueller Code kommt ins Spiel, Integrations-Sonderfälle nehmen zu, und die Person, die die Lösung entwickelt hat, weiß nicht mehr, wie sie das debuggen soll, was in den Logs erscheint.
Low-Code erweitert die Möglichkeiten professioneller Entwickler. Es ersetzt sie nicht bei komplexer Logik und Integrationsarbeit. Die Fehlannahme, dass jeder nichttechnische Nutzer jeden Workflow vollständig allein entwickeln und verantworten kann, ist der Punkt, an dem Citizen-Development-Programme ihre teuersten Probleme erzeugen. Traditionelles Programmieren verschwindet nicht – es verlagert sich auf einen kleineren Teil der Arbeit. Die Kompetenz, diesen Teil zu bewältigen, muss weiterhin irgendwo vorhanden sein, und dieses „irgendwo“ muss explizit definiert sein, nicht vorausgesetzt werden. Entwickeln Sie Anwendungen von Anfang an unter Berücksichtigung dieser Einschränkung, dann funktioniert das Citizen-Developer-Modell. Ignorieren Sie sie, und der erste Produktionsfehler ist zugleich das letzte Mal, dass diese Person freiwillig etwas auf der Plattform entwickelt.
Die Governance- und Skalierbarkeitsprobleme nach der ersten Bereitstellung
Ich habe mit Teams gesprochen, die einen erfolgreichen Low-Code-Piloten durchgeführt haben – einen Workflow, ein Team, hohe Akzeptanz – und ihn anschließend auf fünf Teams ausgeweitet haben, bevor auch nur ansatzweise ein Governance-Modell vorhanden war. Innerhalb von drei Monaten hatten sie mehrere Teams, die überlappende Automatisierungen für dieselben Daten entwickelten, keine Dokumentation darüber, welche Workflows existierten oder wem sie gehörten, und eine wachsende Liste intermittierender Fehler, die niemand zurückverfolgen konnte. Die Logs der Entwicklungsplattform waren auf getrennte Umgebungen verteilt, die von verschiedenen Personen mit unterschiedlichen Zugangsdaten eingerichtet worden waren.
Das Skalierbarkeitsproblem ist hier nicht technisch. Traditionelle Softwareentwicklung erforderte schon immer Architekturprüfungen, Change Management und Zugriffskontrollen. Low-Code erzeugt die Illusion, dass diese Anforderungen verschwinden, weil die Entwicklung so schnell ist. Das tun sie nicht. Sie werden nur mit Zinsen aufgeschoben.
Sicherheit und Compliance sind die Bereiche, in denen dies wirklich ernst wird. Wenn ein Citizen Developer ohne IT-Prüfung einen aktiven CRM-Datensatz mit einem neuen Workflow verbindet und dieser Workflow beginnt, Kundendaten an einen externen Dienst zu übertragen, erfährt das Compliance-Team davon im ungünstigsten Moment – meist während eines Audits und nicht während der Entwicklung. Governance muss vor der ersten Bereitstellung in einer gemeinsamen Produktionsumgebung vorhanden sein, nicht nach dem zweiten Vorfall. Teams, die Low-Code-Transformation als eine wirklich andere Oberfläche für dieselbe Entwicklungsdisziplin behandeln, vermeiden diese Probleme. Teams, die sie als Entwicklungsplattform ohne Leitplanken behandeln, starten einen Countdown zu etwas Unangenehmem. Traditionelle Softwareentwicklungsprozesse existieren aus Gründen, die sich nicht ändern, wenn sich die Oberfläche ändert.
Wer Low-Code tatsächlich für die digitale Transformation nutzt – und wie
Die realistische Nutzungslandschaft sieht ganz anders aus als die Anbieter-Demo.
IT-Abteilungen nutzen Low-Code, um geschäftskritische Anwendungen zu modernisieren – interne Portale, Genehmigungssysteme, Reporting-Dashboards –, ohne alles von Grund auf neu entwickeln zu müssen. Anwendungsentwicklungszyklen, die früher Quartale dauerten, verkürzen sich auf Wochen, wenn der Anwendungsfall passt. Die Einschränkung: Die IT muss weiterhin Architektur und Sicherheitsprüfung verantworten. Der Geschwindigkeitsgewinn ist daher nur verfügbar, wenn die IT für diese Governance-Rolle ausgestattet wurde und nicht erst nachträglich hineingezogen wird.
Betriebsteams nutzen Low-Code, um Übergabeprozesse zu digitalisieren – die Lücke zwischen einem System und dem nächsten, in der aktuell etwas in einer Tabellenkalkulation oder E-Mail lebt. Diese Teams nutzen Low-Code-Plattformen, um ihre spezifischen Geschäftsanforderungen zu erfüllen, ohne auf die Entwicklungswarteschlange der IT zu warten. Die digitalen Lösungen, die sie entwickeln, sind nach Engineering-Maßstäben oft bescheiden, nach Betriebsmaßstäben jedoch transformativ: die Onboarding-Checkliste, die nun automatisch weitergeleitet wird, oder die Lieferantenrechnung, die eine Slack-Benachrichtigung auslöst, statt in einem Posteingang verloren zu gehen.
Citizen Developer in Finanzen, HR und Kundenservice entwickeln bereichsspezifische Tools. Dies sind die Nutzer, an die die Plattformen tatsächlich vermarktet werden, und sie erzeugen die interessanteste Mischung aus echten Erfolgen und Governance-Problemen. Die Erfolge entstehen, wenn der Rahmen definiert und die Leitplanken vorhanden sind. Die Probleme entstehen, wenn die Nutzung einer Low-Code-Plattform als Erlaubnisschein verstanden wird, alles ohne Beteiligung der IT entwickeln zu dürfen.
Hier ist ein konkretes Beispiel dafür, wie dies auf Prozessebene aussieht. Ein HR-Team, das bisher das Onboarding neuer Mitarbeitender über eine E-Mail-Kette koordinierte – HR an die IT zur Kontoerstellung, IT an das Facility Management für den Ausweiszugang, zurück an HR zur Bestätigung –, ersetzt diese Kette durch einen einzigen Workflow, der durch den neuen Mitarbeiterdatensatz im HRIS ausgelöst wird. Der Workflow leitet Aufgaben weiter, versendet Benachrichtigungen und zeigt nur die Ausnahmen an, die menschliches Urteilsvermögen erfordern. Der Anwendungsentwicklungsprozess ist visuell, die Integrationen sind vorgefertigt, und der HR-Manager verfügt nun über eine Statusansicht statt über einen Posteingang voller Nachfass-Threads. Wenn dies gut funktioniert, liegt es daran, dass jemand zunächst den tatsächlichen Prozess neu gestaltet und dann die saubere Version mit der Plattform automatisiert hat. Wenn es nicht funktioniert, liegt es daran, dass stattdessen einfach die E-Mail-Kette automatisiert wurde. Die Plattform kennt den Unterschied nicht.
🤔 Denken Sie darüber nach:
Die Unternehmen, die mit Low-Code-Transformation am wahrscheinlichsten erfolgreich sind, sind nicht diejenigen, die die beste Plattform kaufen. Es sind diejenigen, die vor dem Go-live des ersten Workflows in Citizen-Developer-Schulungen und IT-Governance investieren. Mendix-Daten zufolge glauben 84 % der Unternehmen, dass Low-Code mehr Menschen befähigt – doch diese Befähigung entfaltet nur dann einen kumulativen Nutzen, wenn das Betriebsmodell darauf ausgelegt ist, sie zu unterstützen. Die Plattform zu kaufen und darauf zu hoffen, dass das Betriebsmodell folgt, ist die Strategie, die die meisten Support-Tickets erzeugt.
Was erfolgreiche Low-Code-Transformation von stagnierender Transformation unterscheidet
Der Unterschied liegt nicht in der Auswahl der Plattform. Ich habe stagnierende Transformationsprogramme auf jeder großen Low-Code-Plattform gesehen und erfolgreiche Programme auf Plattformen, die objektiv weniger funktionsreich waren. Die Plattform ist weniger wichtig als das, was sie umgibt.
Die praktische Checkliste für Low-Code-Digitalisierung, die tatsächlich Ergebnisse liefert:
Governance vor dem ersten produktiven Workflow definieren
Wer genehmigt einen Workflow, bevor er live geht? Wer verantwortet ihn danach? Was passiert, wenn die Person, die ihn entwickelt hat, die Rolle wechselt? Das sind keine bürokratischen Fragen. Es sind die Fragen, die darüber entscheiden, ob Ihr Automatisierungs-Stack in 18 Monaten wartbar oder eine Belastung ist.
Citizen Developer in ihrem Rahmen schulen, nicht nur im Tool
Ein Citizen Developer, der weiß, was er entwickeln darf und was eine Prüfung durch professionelle Entwickler erfordert, ist deutlich effektiver als jemand mit vollständigem Plattformzugang ohne Anleitung. Die Investition in Schulungen zahlt sich durch weniger Produktionsvorfälle aus.
IT-Sponsoring mit Verantwortung der Fachbereiche verbinden
Low-Code-Transformation braucht beides. Fachbereiche bringen Prozesswissen ein. Die IT bringt Architektur und Sicherheitsleitplanken ein. Wenn eine Seite fehlt, entstehen entweder technisch fragile Lösungen oder Lösungen, die niemand tatsächlich nutzt.
Mit vorgefertigten Vorlagen und bestehenden Entwicklungsprozessen beginnen
Von einer Vorlage auszugehen, die Ihrem Anwendungsfall nahekommt, und sie anzupassen, ist schneller und besser wartbar als eine Entwicklung von Grund auf. Außerdem zwingt es zur Prüfung, ob Ihr Prozess tatsächlich dem Muster entspricht, bevor Sie mit der Anpassung beginnen.
Einen Prüfzyklus für Workflows einrichten, die nicht aktiv gepflegt werden
Eine automatisierte Prüfung pro Quartal – zur Kontrolle von Workflows, die in den letzten 30 Tagen nicht erfolgreich ausgeführt wurden, zur Kennzeichnung von Integrationen mit abgelaufenen Zugangsdaten und zur Erkennung von Anwendungen, die schneller entstehen, als die Teams sie pflegen können – macht den Unterschied zwischen einer verwalteten Automatisierungsumgebung und Archäologie aus.
Der Ansatz zur Softwareentwicklung innerhalb eines echten Low-Code-Transformationsprogramms ähnelt einer Entwicklungsumgebung, in der professionelle Entwickler Architektur, Integrationen und alles übernehmen, was individuellen Code erfordert – während Citizen Developer bereichsspezifische Tools innerhalb einer definierten Sandbox entwickeln. Künstliche Intelligenz wird zunehmend Teil dieses Stacks: KI-gestütztes Feldmapping, KI-generierte Workflow-Vorschläge und KI-Agenten, die Routing und Klassifizierung innerhalb von Workflows übernehmen. Latenode bietet beispielsweise mehr als 1.200 KI-Modelle in einem einzigen Dropdown-Menü sowie einen vollständigen JavaScript-Node für Logik, die über visuelle Abläufe hinausgehen muss. Diese Kombination ist praktisch relevant, weil der Ausweg für komplexe Logik integriert und nicht nachträglich angesetzt ist. Wenn der No-Code-Weg an seine Grenzen kommt, können professionelle Entwickler auf derselben Plattform weitermachen, ohne zu einem anderen Entwicklungstool wechseln zu müssen.
Entwickeln Sie Anwendungen mit dieser Aufteilung der Verantwortlichkeiten im Hinterkopf, stellen Sie sicher, dass beide Seiten Transparenz darüber haben, was existiert und wem es gehört, und die digitalen Lösungen aus der Low-Code-Transformation werden sich tatsächlich von den Ergebnissen unterscheiden, die Unternehmen erzielen, wenn sie direkt zur Bereitstellung übergehen und hoffen, dass das Betriebsmodell aufholt. Das tut es meist nicht.
