In vielen Betrieben laufen Urlaubsanträge, Freigaben und wiederkehrende Auswertungen noch als Ketten aus E-Mails und Tabellen: Ein Antrag wird per Mail gestellt, von Hand weitergeleitet, in einer Liste vermerkt und am Monatsende mühsam zusammengesucht. Low-Code-Werkzeuge versprechen, genau solche Abläufe ohne klassische Programmierung selbst zusammenzubauen — und zunehmend häufiger tut das nicht die IT, sondern die Fachabteilung. Das ist Chance und Risiko zugleich. Sauber eingesetzt, verschwindet echte Handarbeit; ohne belastbare Datenanbindung und ein paar Leitplanken entstehen Insellösungen, die niemand außer der bauenden Person versteht. Dieser Beitrag ordnet ein, wo Fachabteilungen sinnvoll selbst bauen, wo die Grenze zur IT verläuft und wie Governance aussieht, die schützt, ohne zu bremsen. Wo die Übergänge zu bestehenden Systemen sauber gezogen werden, zeigt unsere Prozessautomatisierung.
Das Wichtigste in Kürze
- Low-Code wandert in die Fachbereiche: Bis 2026 sitzen rund 80 Prozent der Nutzer von Low-Code-Werkzeugen außerhalb der IT, nach 60 Prozent im Jahr 2021 (Gartner). Das ist kein Kontrollverlust, sondern eine Verlagerung, die sich gestalten lässt.
- Selbst bauen lohnt bei abgegrenzten Abläufen ohne heikle Datenflüsse: Urlaubsanträge, interne Freigaben mit Betragsgrenze, einfache Meldungen und Checklisten. Dort spart ein geführtes Formular echte Handarbeit gegenüber Mail und Tabelle.
- Zur Insel wird ein Selbstbau, sobald er Kundendaten schreibt, Preise oder Bestände führt oder mehrere Systeme verbinden soll. Diese Fälle gehören an eine verlässliche Datenquelle und damit in die Hände der IT.
- Governance braucht keine Antragsbürokratie, sondern wenige Leitplanken: ein Register aller Selbstbauten, eine verbindliche Datenquelle je Kennzahl, zwei benannte Verantwortliche je Ablauf und eine Nachschau je Quartal (Projekterfahrung).
- Über Insel oder Baustein entscheidet die Datenanbindung. Ein Formular, das seine Daten aus dem führenden System zieht und dorthin zurückschreibt, ist ein Baustein; eines mit eigener Nebenliste ist eine zweite Wahrheit.
Warum Low-Code gerade in die Fachabteilungen wandert
Low-Code beschreibt Werkzeuge, mit denen sich Formulare, Freigabewege und kleine Anwendungen weitgehend über Bausteine und Konfiguration erstellen lassen, statt jede Zeile von Hand zu programmieren. Der Ansatz ist nicht neu, aber sein Gewicht wächst spürbar: Nach einer Prognose von Gartner entstehen bis 2025 rund 70 Prozent neuer Anwendungen mit Low-Code- oder No-Code-Technologien, gegenüber weniger als 25 Prozent im Jahr 2020 (Gartner). Getragen wird diese Verschiebung nicht mehr allein von der IT — bis 2026 sollen rund 80 Prozent der Low-Code-Nutzer außerhalb der klassischen IT-Abteilung arbeiten (Gartner).
Die Ursache liegt selten in einer Mode, sondern im Alltag. In der IT stapeln sich Anfragen, Fachkräfte sind knapp, und ein Urlaubsantragsformular landet in der Warteschlange hinter Themen mit größerer Tragweite. Gleichzeitig wächst der Druck in den Fachbereichen: Urlaubsanträge, Freigaben und Reports laufen vielerorts noch als Excel- und Mail-Ketten, die täglich Zeit kosten. Wer diese Reibung selbst beseitigen kann, wartet nicht auf ein Projekt. Genau hier setzt Low-Code an — und genau hier entscheidet sich, ob daraus ein Gewinn oder eine Baustelle wird.
Der Trend zur sogenannten Schatten-IT verstärkt das. Gartner erwartet, dass bis 2027 rund 75 Prozent der Beschäftigten Technik beschaffen, verändern oder selbst erstellen, die außerhalb der Sichtbarkeit der IT liegt, gegenüber 41 Prozent im Jahr 2022 (Gartner). In großen Organisationen übersteigt die Zahl der bauenden Kräfte außerhalb der IT die der Profi-Entwickler inzwischen deutlich (Gartner). Die entscheidende Frage lautet deshalb nicht, ob Fachabteilungen bauen, sondern ob sie es geordnet tun. Ein pauschales Verbot verlagert das Bauen nur in den unsichtbaren Bereich; sinnvoller ist, es sichtbar und anschlussfähig zu machen.
Low-Code ist ein Werkzeug, kein Prozess
Wo selbstgebaute Abläufe echte Handarbeit sparen
Es gibt eine klar umrissene Zone, in der Selbstbau durch die Fachabteilung erfahrungsgemäß gut funktioniert und schnell spürbar entlastet. Kennzeichen sind: der Ablauf ist abgegrenzt, es sind wenige Beteiligte betroffen, es werden keine heiklen Daten geschrieben, und das Ergebnis bleibt zunächst intern. In dieser Zone ersetzt ein geführtes Formular eine Mail-Kette, und ein einfacher Status ersetzt die Sammelliste, die niemand pflegt.
Urlaubs- und Abwesenheitsanträge
Antrag, Freigabe und Übersicht in einem geführten Ablauf statt in Mail und Kalender nebeneinander. Der Vorgesetzte sieht Resturlaub und Überschneidungen sofort, die Freigabe ist nachvollziehbar dokumentiert.
Interne Freigaben mit Betragsgrenze
Kleine Beschaffungen, Ausgaben oder Materialanforderungen mit einer klaren Regel: bis zu einem Betrag genügt eine Freigabe, darüber braucht es zwei. Der Nachweis liegt an einem Ort, nicht in mehreren Postfächern.
Meldungen und Checklisten
Mängelmeldungen, Wartungslisten, Schichtübergaben oder Sicherheitsbegehungen als kurzes Formular mit Pflichtfeldern. Was gemeldet wurde, ist auffindbar — und nicht auf Zetteln am schwarzen Brett verteilt.
Einfache Status- und Sammelübersichten
Eine gemeinsame Liste offener Punkte, die alle Beteiligten sehen, statt einer Tabelle, die per Mail herumgereicht wird und in fünf Versionen existiert. Ideal für Aufgaben, die keine Anbindung an ein führendes System brauchen.
Der gemeinsame Nenner dieser Fälle: Sie erzeugen keine Wahrheit, die anderswo schon verwaltet wird. Ein Urlaubsantrag konkurriert nicht mit dem ERP, eine Mängelmeldung nicht mit der Warenwirtschaft. Deshalb ist der Schaden gering, wenn etwas hakt, und der Gewinn unmittelbar spürbar. Wer hier beginnt, sammelt Erfahrung mit dem Werkzeug an unkritischer Stelle — eine gute Grundlage, bevor größere Abläufe angefasst werden. Verwandt ist die Frage, wann sich der Aufwand überhaupt lohnt: Dazu ordnet der Beitrag wann sich Automatisierung rechnet die typischen Schwellen ein.
Wo aus Low-Code Insellösungen und Schatten-IT werden
So klar die gute Zone ist, so klar ist die Kippstelle. Ein Selbstbau verlässt den sicheren Bereich, sobald er in Daten eingreift, die an anderer Stelle schon geführt werden. Legt ein Formular Kunden neu an, ändert es Preise, bucht es Bestände ab oder soll es zwei Systeme miteinander sprechen lassen, dann baut die Fachabteilung nicht mehr ein Hilfsmittel, sondern eine zweite Datenquelle neben der ersten. Genau dort entstehen die Probleme, die als Medienbruch und doppelte Erfassung im Alltag teuer werden — beschrieben in doppelte Datenerfassung abschaffen und Medienbrüche im Betrieb erkennen.
Zu den fachlichen Risiken kommen betriebliche. Ein selbstgebautes Werkzeug hängt oft an einer einzigen Person: Sie hat es gebaut, sie kennt die stillen Annahmen, und mit ihrem Urlaub oder Weggang steht der Ablauf. Häufig fehlt eine Datensicherung, es gibt keine Testumgebung, und niemand weiß, wer eigentlich zugreifen darf. Werden dabei personenbezogene Daten verarbeitet — und ein Urlaubs- oder Freigabeformular tut das —, ist zusätzlich der Datenschutz betroffen; die rechtlichen Anforderungen ordnet der Beitrag Datenschutz bei der Prozessdigitalisierung ein. Nichts davon ist ein Argument gegen Low-Code. Es ist ein Argument dafür, die Grenze bewusst zu ziehen.
Vier Warnzeichen für eine entstehende Insel
Die Grenze: was in die Fachabteilung gehört und was in die IT
Statt jeden Einzelfall neu zu diskutieren, hilft eine einfache Prüfung entlang weniger Merkmale. Sie beantwortet die Frage nicht mit einem Bauchgefühl, sondern mit nachvollziehbaren Kriterien — und lässt sich in wenigen Minuten je Vorhaben durchgehen. Die folgende Gegenüberstellung fasst zusammen, was erfahrungsgemäß gut in der Fachabteilung aufgehoben ist und was in die IT gehört.
| Merkmal | Fachabteilung baut selbst | Gehört in die IT |
|---|---|---|
| Datenrichtung | Liest oder erfasst nur intern | Schreibt in führende Systeme zurück |
| Art der Daten | Unkritisch, betrifft nur das Team | Personenbezogen, finanziell oder kundennah |
| Beteiligte Systeme | Ein System oder gar keins | Mehrere Systeme sollen zusammenspielen |
| Zahl der Beteiligten | Ein Team, überschaubar | Abteilungsübergreifend oder standortweit |
| Folge bei Ausfall | Gering, kurzer Rückfall auf Papier | Der Betrieb steht oder Daten laufen auseinander |
| Pflegeaufwand | Selten, im Team leistbar | Dauerhaft, versioniert, mit Sicherung |
Die Grenze ist keine Mauer, sondern ein Übergabepunkt. Vieles beginnt sinnvoll als kleiner Selbstbau und wächst dann in die IT-Verantwortung hinein, weil es sich bewährt und mehr Beteiligte gewinnt. Wichtig ist, dass dieser Übergang bewusst geschieht und nicht unbemerkt: Ein Werkzeug, das für drei Personen gedacht war und nun standortweit genutzt wird, braucht andere Zusagen zu Verfügbarkeit, Sicherung und Datenschutz als am ersten Tag. Ob ein Fall überhaupt eine Anbindung braucht oder Handarbeit die günstigere Antwort bleibt, wägt der Beitrag Schnittstelle oder Handarbeit ab.
Governance ohne Bürokratie: Leitplanken statt Verbote
Governance hat in vielen Betrieben einen schlechten Ruf, weil sie mit Anträgen, Formularen und Wartezeiten verbunden wird — genau dem, was Low-Code umgehen sollte. Wirksame Steuerung braucht das nicht. Sie besteht aus wenigen Leitplanken, die im Alltag kaum spürbar sind und trotzdem verhindern, dass aus hilfreichen Werkzeugen unkontrollierte Inseln werden. Die folgenden fünf Schritte reichen für die meisten mittelständischen Betriebe aus (Projekterfahrung).
Schritt 1: Ein Register anlegen
Jeder Selbstbau wird an einer Stelle erfasst: Wer hat ihn gebaut, was tut er, welche Daten berührt er, wer vertritt im Krankheitsfall? Das Register ist keine Genehmigung, sondern eine Landkarte. Ohne sie weiß niemand, was im Betrieb überhaupt läuft — und genau das ist der Kern des Schatten-IT-Problems.
Schritt 2: Die Datenquelle festlegen
Für jede wichtige Angabe — Kunde, Artikel, Preis, Bestand — gilt genau ein führendes System. Ein Selbstbau darf daraus lesen, aber nicht heimlich eine eigene Fassung pflegen. Diese eine Regel verhindert die meisten späteren Widersprüche zwischen Listen.
Schritt 3: Zwei Verantwortliche je Ablauf benennen
Nicht die bauende Person allein trägt den Ablauf, sondern zwei benannte Zuständige, damit Urlaub und Krankheit ihn nicht aussetzen (Projekterfahrung). Sie kennen die Annahmen, pflegen die Kurzanleitung und entscheiden über Änderungen.
Schritt 4: Datenschutz kurz prüfen
Sobald personenbezogene Daten im Spiel sind, wird in wenigen Sätzen festgehalten: Welche Daten, wozu, wer sieht sie, wie lange bleiben sie? Diese Kurzprüfung ersetzt keine Rechtsberatung, macht aber sichtbar, wann eine solche nötig ist.
Schritt 5: Regelmäßig nachschauen
Einmal je Quartal wird das Register durchgesehen (Projekterfahrung): Was ist gewachsen, was gehört inzwischen in die IT, was wird gar nicht mehr genutzt und kann weg? Diese kurze Nachschau hält den Bestand gesund, statt ihn wuchern zu lassen.
Jeder Selbstbau wird an einer Stelle erfasst: Wer hat ihn gebaut, was tut er, welche Daten berührt er, wer vertritt im Krankheitsfall? Das Register ist keine Genehmigung, sondern eine Landkarte. Ohne sie weiß niemand, was im Betrieb überhaupt läuft — und genau das ist der Kern des Schatten-IT-Problems.
Für jede wichtige Angabe — Kunde, Artikel, Preis, Bestand — gilt genau ein führendes System. Ein Selbstbau darf daraus lesen, aber nicht heimlich eine eigene Fassung pflegen. Diese eine Regel verhindert die meisten späteren Widersprüche zwischen Listen.
Nicht die bauende Person allein trägt den Ablauf, sondern zwei benannte Zuständige, damit Urlaub und Krankheit ihn nicht aussetzen (Projekterfahrung). Sie kennen die Annahmen, pflegen die Kurzanleitung und entscheiden über Änderungen.
Sobald personenbezogene Daten im Spiel sind, wird in wenigen Sätzen festgehalten: Welche Daten, wozu, wer sieht sie, wie lange bleiben sie? Diese Kurzprüfung ersetzt keine Rechtsberatung, macht aber sichtbar, wann eine solche nötig ist.
Einmal je Quartal wird das Register durchgesehen (Projekterfahrung): Was ist gewachsen, was gehört inzwischen in die IT, was wird gar nicht mehr genutzt und kann weg? Diese kurze Nachschau hält den Bestand gesund, statt ihn wuchern zu lassen.
Ein Registereintrag muss nicht umfangreich sein. Die wenigen Angaben, die zählen, passen auf eine halbe Seite:
- Name und Zweck des Selbstbaus in einem Satz, verständlich auch für Außenstehende.
- Verwendete Datenquellen und ob nur gelesen oder auch geschrieben wird.
- Zwei benannte Verantwortliche und die Regel für Vertretung.
- Ob personenbezogene Daten verarbeitet werden und wer sie einsehen darf.
- Wo die Kurzanleitung liegt und wann der Selbstbau zuletzt geprüft wurde.
Freigeben statt verbieten
Datenanbindung entscheidet über Insel oder Baustein
Der Unterschied zwischen einer nützlichen Anwendung und einer teuren Insel ist selten die Oberfläche, sondern fast durchweg die Datenanbindung. Ein Formular, das seine Stammdaten aus dem führenden System zieht und sein Ergebnis dorthin zurückschreibt, ist ein Baustein: Es fügt sich in den bestehenden Datenfluss ein, statt einen zweiten zu eröffnen. Ein Formular mit eigener Nebenliste dagegen erzeugt eine zweite Wahrheit, und ab dem ersten Widerspruch zwischen beiden Listen beginnt die Handarbeit, die man eigentlich abschaffen wollte.
Technisch führt der Weg über eine Schnittstelle oder eine kleine Vermittlungsschicht, die Daten zwischen dem Selbstbau und dem führenden System sauber hin- und herträgt. Wo mehrere Systeme im Spiel sind, sorgt eine geordnete Datenintegration dafür, dass jede Angabe genau eine Herkunft hat und Änderungen an einer Stelle überall ankommen. Der Aufwand dafür ist der eigentliche Grund, warum solche Fälle in die IT gehören: Nicht das Formular ist schwierig, sondern die verlässliche Verbindung dahinter.
Eine Anwendung ist so viel wert wie ihre Datenanbindung. Ohne sie ist das schönste Formular nur eine weitere Liste, die jemand am Monatsende mit der Wahrheit abgleichen muss.
Beispiel: von der Mail-Kette zur geführten Freigabe
Ein häufiger Einstieg ist die interne Freigabe kleiner Ausgaben. Vorher läuft sie als Mail-Kette mit einer handgeführten Liste; nachher als geführtes Formular, das an das führende System angebunden ist. Das folgende, gekürzte Beispiel zeigt den Unterschied nicht in der Optik, sondern im Datenfluss — und genau daran entscheidet sich, ob ein Baustein oder eine Insel entsteht.
Vorher: Freigabe per E-Mail und Tabelle
1. Beschäftigte schreiben eine Mail an die vorgesetzte Stelle
2. Antwort "passt" kommt kurz, oft aus dem Urlaub
3. Die Assistenz trägt den Vorgang von Hand in eine Liste ein
4. Die Buchhaltung fragt am Monatsende nach dem Nachweis
-> Stand verteilt auf Postfach, Tabelle und Zuruf
Nachher: geführte Freigabe (Low-Code, angebunden)
1. Das Formular zieht Name, Kostenstelle und Budget aus dem System
2. Regel: bis 500 EUR eine Freigabe, darüber zwei
3. Das Ergebnis wird in das führende System zurückgeschrieben
4. Die Buchhaltung sieht den Nachweis am selben Ort wie die Buchung
-> eine Datenquelle, ein nachvollziehbarer VerlaufDer sichtbare Gewinn ist die eingesparte Handarbeit; der eigentliche Gewinn ist die Nachvollziehbarkeit. Wer freigegeben hat, mit welcher Regel und auf welcher Grundlage, steht am selben Ort wie die spätere Buchung. Damit verschwindet die Zweitliste, und die Buchhaltung sucht am Monatsende nicht mehr zusammen, was verstreut ist. Wie sich Freigaben grundsätzlich sauber abbilden lassen, vertieft der Beitrag Freigaben digital abbilden; wie sich hartnäckige Tabellen-Workarounds ablösen lassen, zeigt Tabellenkalkulation ablösen.
Was ein Betrieb selbst vorbereiten kann
Der größere Teil einer geordneten Low-Code-Praxis liegt in der Vorbereitung, nicht im Werkzeug. Vieles davon lässt sich ohne externe Unterstützung erledigen — und wer es vorab klärt, startet unter deutlich besseren Bedingungen. Die folgende Reihenfolge hat sich bewährt.
- Bestehende Selbstbauten einmal sammeln: Wer nutzt was, und welche Daten berührt es? Diese Bestandsaufnahme fördert erfahrungsgemäß ein bis zwei Dutzend Werkzeuge zutage, die zentral niemand kannte (Projekterfahrung).
- Die Datenquellen-Regel aufschreiben: Für jede wichtige Angabe genau ein führendes System benennen, aus dem alle anderen lesen.
- Erlaubte Fälle für Selbstbau festlegen und ebenso die Fälle, die in die IT gehören — anhand der Merkmale aus der Gegenüberstellung.
- Je Selbstbau zwei Verantwortliche benennen und deren Zeit für Pflege und Rückfragen verbindlich einplanen (Projekterfahrung).
- Einen kurzen Datenschutz-Check für alle Formulare mit personenbezogenen Daten einführen, mit klarem Weg zur fachlichen Prüfung.
- Einen festen Termin je Quartal für die Nachschau des Registers in den Kalender setzen, bevor der erste Selbstbau live geht.
Wie eine geordnete Einführung im Team ankommt, ohne dass Beschäftigte das neue Formular umgehen, beschreibt der Beitrag Mitarbeitende bei neuen Abläufen mitnehmen. Was danach dauerhaft läuft — Sicherung, kleine Anpassungen, Störungsannahme —, gehört in den geregelten Betrieb und die Wartung und nicht in die Restzeit einer Projektphase; die Dokumentation dazu findet ihren Ort in einer gepflegten Prozessdokumentation. Wer parallel an gesetzlichen Pflichten arbeitet, findet in E-Rechnungspflicht 2027 und KI in der Sachbearbeitung angrenzende Themen.
Verwandte Artikel
Empfängerprüfung im Zahlungslauf: Abweichungen richtig klären
Seit Oktober 2025 gleichen Banken Name und IBAN vor jeder Überweisung ab. So kommen Rückmeldungen in Lieferantenstamm, Sperre und Rückruf im Zahlungslauf.
Abschläge und Nachträge am Bau: den Zahlungsfluss ordnen
Wie aus dem Leistungsstand eine Abschlagsrechnung wird, warum ein Nachtrag ein eigener Vorgang mit Frist ist und wie daraus eine prüffähige Schlussrechnung ohne Nacharbeit entsteht.
Verpackungsdaten melden: Material und Masse je Artikel
Welches Feld am Artikel fehlt, wie Verpackungsgewichte je Variante und Versandkarton gepflegt werden und wie aus Lieferscheinmengen eine belastbare Meldemenge je Materialart entsteht.