Low-Code-Plattformen im Mittelstand: Einsatzfelder, Governance und Auswahlkriterien

Low-Code-Plattformen im Mittelstand versprechen, Fachanwendungen mit grafischen Werkzeugen und wenig Programmierung zu erstellen, sodass Fachbereiche Lösungen für ihre eigenen Abläufe schneller bereitstellen können, als es über klassische Softwareprojekte möglich wäre. Der Reiz liegt auf der Hand: Viele Abläufe laufen noch über Tabellen, E-Mails und Papierformulare, während die IT-Abteilung durch Wartung und Sicherheitsaufgaben ausgelastet ist. Eine Plattform, mit der sich Formulare, Genehmigungen, Datenerfassung und einfache Auswertungen selbst bauen lassen, scheint beide Probleme zu lösen. In der Praxis hängt der Erfolg jedoch weniger vom Werkzeug als von den Rahmenbedingungen ab: Wer darf was bauen, wer betreibt die Anwendungen, wie werden Daten geschützt und was geschieht, wenn der Entwickler das Unternehmen verlässt? Wer die Plattform als Ergänzung der vorhandenen Systemlandschaft versteht und nicht als Ersatz für Fachlichkeit, vermeidet die meisten Enttäuschungen. Dieser Beitrag richtet sich an Geschäftsführung, IT-Leitung und Prozessverantwortliche. Er beschreibt geeignete Einsatzfelder, die Abgrenzung zu anderen Lösungswegen, Auswahlkriterien, ein tragfähiges Betriebsmodell sowie typische Stolperfallen und einen Fahrplan für die Einführung.

Hinweis: Dieser Beitrag gibt ausschließlich die redaktionellen Ansichten der Redaktion von effizienzpraxis.de wieder. Er stellt keine Rechts- oder Steuerberatung dar und ersetzt nicht die Beratung durch qualifizierte Fachleute. Für verbindliche Auskünfte zu Ihrem konkreten Fall wenden Sie sich bitte an eine zugelassene Beratung.

Titelbild: Foto von Daniil Komov auf Unsplash.

Was Low-Code leistet und was nicht

Low-Code bezeichnet Entwicklungsumgebungen, in denen Anwendungen überwiegend durch das Zusammenfügen vorgefertigter Bausteine entstehen: Formularelemente, Datenmodelle, Regeln, Workflows und Schnittstellenkonnektoren. Programmcode wird nur an Stellen benötigt, an denen die Bausteine nicht ausreichen. Verwandt ist der Begriff No-Code, bei dem ganz auf Programmierung verzichtet wird und der sich vor allem an Anwender ohne technische Vorkenntnisse richtet.

Die Plattformen leisten vor allem dort viel, wo Abläufe strukturiert, aber nicht standardisierbar durch Fertigsoftware abgedeckt sind. Sie sparen Entwicklungszeit, verkürzen Abstimmungswege und lassen Anpassungen im laufenden Betrieb zu. Sie ersetzen jedoch weder eine Architektur noch eine saubere Datenhaltung. Wer Probleme mit unklaren Prozessen hat, erhält mit einer Plattform lediglich schneller digitalisierte Unklarheit.

Geeignete Einsatzfelder im Mittelstand

Besonders geeignet sind Anwendungen mit überschaubarer Komplexität, klarer Zuständigkeit und begrenztem Nutzerkreis. Typische Beispiele finden sich in nahezu allen Bereichen eines mittelständischen Unternehmens.

• Genehmigungs- und Freigabeprozesse, etwa für Urlaubsanträge, Investitionsanträge oder Bestellfreigaben, die bisher per E-Mail laufen.
• Datenerfassung vor Ort, etwa Prüfprotokolle, Wartungsberichte oder Wareneingangskontrollen, die mobil ausgefüllt werden.
• Interne Verzeichnisse und Register, etwa Geräteverwaltung, Schlüsselverwaltung oder Schulungsnachweise.
• Einfache Auswertungen und Dashboards, die Daten aus mehreren Quellen zusammenführen.
• Kundenanfragen und Serviceaufträge in kleinen Teams, für die ein vollständiges CRM oder Ticketsystem überdimensioniert wäre.

Weniger geeignet sind Anwendungen mit hohen Anforderungen an Performance, Transaktionssicherheit oder komplexer Buchungslogik. Dazu zählen Kernbereiche wie Finanzbuchhaltung, Lohnabrechnung oder Produktionssteuerung mit Echtzeitanforderungen. Hier bleibt Standardsoftware oder eine individuell entwickelte Lösung die bessere Wahl.

Abgrenzung zu Standardsoftware, Eigenentwicklung und Tabellenkalkulation

Die Entscheidung für Low-Code sollte als Ergebnis eines Vergleichs fallen, nicht als Reflex. Die folgende Übersicht zeigt die typischen Unterschiede.

Lösungsweg	Stärke	Schwäche	Geeignet für
Tabellenkalkulation	Sofort verfügbar, flexibel	Fehleranfällig, kaum Rechte- und Versionskontrolle	Einzelne Auswertungen, Prototypen
Standardsoftware	Geprüft, gepflegt, mit Support	Begrenzte Anpassbarkeit	Kernprozesse mit Branchenstandard
Low-Code-Plattform	Schnelle Anpassung, Fachbereichsnähe	Abhängigkeit vom Anbieter, Governance erforderlich	Individuelle Abläufe mittlerer Komplexität
Eigenentwicklung	Maximale Freiheit	Hoher Aufwand, Wartung, Know-how-Abhängigkeit	Wettbewerbsdifferenzierende Systeme

Eine Plattform lohnt sich in der Regel erst, wenn mehrere Anwendungsfälle vorliegen. Für einen einzelnen Prozess ist Standardsoftware oder ein vorhandenes Modul im ERP häufig wirtschaftlicher, weil Lizenz, Einarbeitung und Betrieb der Plattform auf viele Schultern verteilt werden müssen, um sich zu rechnen.

Auswahlkriterien für die Plattform

Die Auswahl sollte anhand dokumentierter Kriterien erfolgen. Hilfreich ist eine gewichtete Bewertungsmatrix, in der Fachbereiche, IT und Datenschutz gemeinsam festlegen, was wichtig ist. Die nachfolgenden Kriterien haben sich in der Praxis bewährt.

Funktionale Kriterien

• Abbildung der geplanten Anwendungsfälle, getestet mit einem echten Prozess statt mit einer Demo des Anbieters.
• Verfügbare Konnektoren zu vorhandenen Systemen wie ERP, CRM, Verzeichnisdienst und Dokumentenmanagement.
• Mobile Nutzung, Offlinefähigkeit und Unterstützung von Dateiuploads, wenn Anwendungen im Außendienst oder in der Produktion eingesetzt werden.
• Möglichkeiten zur Erweiterung mit eigenem Code für Sonderfälle.

Technische und organisatorische Kriterien

• Rollen- und Rechtekonzept mit Anbindung an das zentrale Identitätsmanagement und Single Sign-on.
• Trennung von Entwicklungs-, Test- und Produktivumgebung sowie Versionierung der Anwendungen.
• Protokollierung von Änderungen und Zugriffen.
• Exportmöglichkeiten für Daten und Anwendungsdefinitionen, um einen Wechsel des Anbieters zu ermöglichen.

Rechtliche und wirtschaftliche Kriterien

• Standort der Datenverarbeitung, Auftragsverarbeitungsvertrag und Unterauftragnehmer.
• Lizenzmodell: pro Entwickler, pro Nutzer oder pro Anwendung, und die Entwicklung der Kosten bei wachsender Nutzung.
• Vertragslaufzeit, Kündigungsfristen und Regelungen zur Datenrückgabe.
• Finanzielle und fachliche Stabilität des Anbieters.

Bewertungsmatrix am Beispiel

Die Gewichtung sollte vor der Anbieterpräsentation festgelegt werden, damit sie nicht durch den Eindruck der Vorführung beeinflusst wird. Die folgende Tabelle ist ein illustratives Beispiel mit erfundenen Werten.

Kriterium	Gewicht in Prozent	Anbieter A (1 bis 5)	Anbieter B (1 bis 5)
Abbildung der Anwendungsfälle	25	4	3
Anbindung an vorhandene Systeme	20	3	5
Rechte, Protokollierung, Umgebungen	20	4	4
Datenschutz und Vertragsgestaltung	20	5	3
Gesamtkosten über drei Jahre	15	3	4

Aus Gewicht und Punktzahl ergibt sich der gewichtete Gesamtwert je Anbieter. Im Beispiel erreicht Anbieter A 3,85 Punkte und Anbieter B 3,75 Punkte. Ausschlaggebend ist weniger die Rangfolge als die Erkenntnis, wo ein Anbieter Schwächen hat, die sich durch organisatorische Maßnahmen ausgleichen lassen oder eben nicht.

Datenschutz und Informationssicherheit

Sobald in einer Anwendung personenbezogene Daten verarbeitet werden, gelten die Anforderungen der Datenschutz-Grundverordnung. Für Low-Code-Anwendungen sind drei Punkte besonders wichtig. Erstens muss die Verarbeitung im Verzeichnis der Verarbeitungstätigkeiten (Art. 30 DSGVO) erfasst werden, auch wenn die Anwendung von einem Fachbereich gebaut wurde. Zweitens ist mit dem Plattformanbieter ein Auftragsverarbeitungsvertrag nach Art. 28 DSGVO abzuschließen. Drittens sind technische und organisatorische Maßnahmen nach Art. 32 DSGVO umzusetzen, etwa Zugriffsbeschränkungen und Protokollierung.

Der Grundsatz des Datenschutzes durch Technikgestaltung nach Art. 25 DSGVO wird in der Praxis häufig übersehen, weil Fachbereiche Formulare schnell bauen und Felder ohne Prüfung der Erforderlichkeit anlegen. Eine einfache Vorgabe hilft: Für jedes Datenfeld wird der Zweck benannt, und nicht erforderliche Felder werden nicht angelegt.

Aus Sicht der Informationssicherheit sind besonders Freigaben nach außen zu beachten. Viele Plattformen erlauben es, Formulare öffentlich bereitzustellen oder Daten über Schnittstellen zu teilen. Solche Funktionen sollten nur nach Prüfung durch die IT aktiviert werden.

Governance: Wer darf was bauen?

Der wichtigste Erfolgsfaktor ist ein klares Regelwerk. Ohne Governance entsteht innerhalb kurzer Zeit eine unübersichtliche Landschaft aus Anwendungen, deren Verantwortliche niemand kennt. Bewährt hat sich eine Einteilung nach Risiko.

Kategorie	Beispiel	Wer baut	Freigabe
Persönliche Anwendung	Eigene Aufgabenliste, persönliche Auswertung	Jeder Mitarbeiter	Keine
Teamanwendung	Prüfprotokoll für eine Abteilung	Geschulte Fachbereichsentwickler	Abteilungsleitung
Bereichsübergreifende Anwendung	Freigabeprozess mit Schnittstelle zum ERP	Fachbereich gemeinsam mit IT	IT-Leitung und Datenschutz
Geschäftskritische Anwendung	Anwendung mit Auswirkung auf Rechnungen oder Lieferungen	IT oder externer Partner	Geschäftsführung, IT, Datenschutz

Ergänzend sollte ein zentrales Anwendungsregister geführt werden, in dem jede produktive Anwendung mit Verantwortlichem, Zweck, Datenarten, Schnittstellen und Vertretung eingetragen ist. Dieses Register ist die Grundlage für Wartung, Datenschutzdokumentation und Notfallplanung.

Betriebsmodell und Rollen

Ein tragfähiges Betriebsmodell legt fest, wer die Plattform betreibt und wer Anwendungen verantwortet. In mittelständischen Unternehmen hat sich ein Modell mit einem kleinen zentralen Team bewährt, das die Plattform verwaltet, Standards setzt und Fachbereichsentwickler schult.

• Plattformverantwortliche: Verwalten Lizenzen, Umgebungen und Konnektoren, pflegen Vorlagen und Richtlinien.
• Fachbereichsentwickler: Setzen Anwendungen für ihren Bereich um und sind für Inhalt und Datenqualität verantwortlich.
• Anwendungsverantwortliche: Benannte Personen pro Anwendung, die Änderungen freigeben und bei Störungen ansprechbar sind.
• Datenschutz und Informationssicherheit: Prüfen Anwendungen mit personenbezogenen oder vertraulichen Daten vor der Freigabe.

Für jede produktive Anwendung sollte eine Vertretung benannt sein. Der häufigste Ausfallgrund solcher Lösungen ist nicht die Technik, sondern das Ausscheiden des einzigen Mitarbeiters, der sie verstanden hat.

Einführung in vier Phasen

1. Bedarf erheben: Sammlung der Anwendungsfälle aus den Fachbereichen, Bewertung nach Nutzen, Komplexität und Datenschutzrelevanz.
2. Pilot durchführen: Umsetzung von zwei bis drei überschaubaren Anwendungen mit klaren Erfolgskriterien, etwa eingesparter Bearbeitungszeit und Nutzerzufriedenheit.
3. Regeln festlegen: Governance, Rollen, Namenskonventionen, Dokumentationspflichten und Freigabeprozess auf Basis der Pilotergebnisse.
4. Skalieren: Schulung weiterer Fachbereichsentwickler, Aufbau des Anwendungsregisters und regelmäßiger Review der bestehenden Anwendungen.

Der Pilot sollte bewusst mit Anwendungen starten, die einen sichtbaren Nutzen haben, aber nicht geschäftskritisch sind. So lassen sich Erfahrungen sammeln, ohne dass ein Fehler den laufenden Betrieb gefährdet.

Änderungsmanagement und Wartung im laufenden Betrieb

Eine Anwendung, die ein Fachbereich in wenigen Tagen gebaut hat, muss über Jahre betrieben werden. Daher gehört zu jeder Einführung ein Änderungsmanagement, das auch bei schnellen Anpassungen Nachvollziehbarkeit sichert. Änderungen werden zunächst in einer Testumgebung umgesetzt, von der anwendungsverantwortlichen Person abgenommen und erst danach in die produktive Umgebung übernommen. Die Plattform sollte dazu Versionen speichern und einen früheren Stand wiederherstellen können.

Zur Wartung zählen außerdem die regelmäßige Prüfung von Berechtigungen, das Entfernen ungenutzter Anwendungen und die Beobachtung von Plattformaktualisierungen des Anbieters. Aktualisierungen können Konnektoren oder Funktionen verändern, sodass kritische Anwendungen nach größeren Updates getestet werden sollten. Ein jährlicher Review des Anwendungsregisters, in dem jede Anwendung auf Nutzung, Datenarten und Verantwortlichkeit geprüft wird, hält die Landschaft übersichtlich.

Wirtschaftlichkeit betrachten

Die Kostenseite besteht aus Lizenzen, Einführung, Schulung, Betrieb und gegebenenfalls externer Unterstützung. Der Nutzen ergibt sich aus eingesparter Bearbeitungszeit, vermiedenen Medienbrüchen, geringerer Fehlerquote und kürzeren Durchlaufzeiten. Für eine belastbare Rechnung sollte der Nutzen je Anwendung geschätzt und mit den Gesamtkosten verglichen werden.

Als Beispielrechnung: Ein Freigabeprozess mit 40 Vorgängen pro Woche spart durch die digitale Abwicklung je Vorgang zehn Minuten Suchen, Nachfragen und Weiterleiten. Das entspricht etwa 400 Minuten pro Woche, also rund 6,7 Stunden. Bei einem angenommenen internen Stundensatz kann daraus ein jährlicher Betrag errechnet werden, der den Lizenz- und Betriebsaufwand einer einzelnen Anwendung gegenüberzustellen ist. Die Zahlen sind illustrativ und im Einzelfall durch eigene Messungen zu ersetzen.

Häufige Fehler und Stolperfallen

• Schatten-IT durch Plattform: Ohne Regeln entstehen unkontrollierte Anwendungen, die personenbezogene Daten verarbeiten, ohne dass die Datenschutzdokumentation davon weiß.
• Auswahl nach Demo: Die Entscheidung beruht auf einer Vorführung mit idealen Daten, nicht auf einem Test mit einem echten Prozess.
• Fehlender Ausstieg: Anwendungen lassen sich nicht exportieren, und der Wechsel des Anbieters wird dadurch faktisch unmöglich.
• Unklare Verantwortung: Niemand ist für Wartung, Lizenzen und Aktualisierungen zuständig, sodass Anwendungen veralten.
• Überforderung der Plattform: Komplexe Kernprozesse werden mit Mitteln abgebildet, die dafür nicht gedacht sind, und führen zu schwer wartbaren Konstruktionen.
• Mangelnde Schulung: Fachbereichsentwickler erhalten Werkzeuge, aber keine Grundlagen in Datenmodellierung, Rechtevergabe und Dokumentation.

Low-Code verkürzt die Zeit bis zur ersten Version, nicht die Zeit, die ein Unternehmen braucht, um Verantwortung für den Betrieb zu übernehmen.

Zusammenspiel mit Prozessanalyse und Automatisierung

Eine Plattform entfaltet ihren Nutzen am stärksten, wenn die Prozesse vorher geklärt wurden. Eine Prozessaufnahme zeigt, wo Medienbrüche, Wartezeiten und manuelle Übergaben auftreten, und liefert die Vorlage für die Umsetzung. Wird anschließend Automatisierung ergänzt, etwa durch regelbasierte Benachrichtigungen oder die Anbindung an Dokumentenverarbeitung, sollte jeweils geprüft werden, ob die Plattform dafür geeignet ist oder ob ein spezialisiertes System sinnvoller bleibt.

Hilfreich ist es, die Plattform in die bestehende Systemlandschaft einzuordnen und die Rolle klar zu beschreiben: Sie ergänzt Standardsoftware an den Rändern, ersetzt aber keine Kernsysteme. Diese Einordnung beugt überzogenen Erwartungen vor und erleichtert Entscheidungen, wenn ein neuer Anwendungsfall auftaucht.

Checkliste vor der Entscheidung

1. Anwendungsfälle gesammelt und nach Nutzen, Komplexität und Datenschutzrelevanz bewertet.
2. Alternativen verglichen: Standardsoftware, vorhandene ERP-Module, Eigenentwicklung.
3. Bewertungsmatrix mit Gewichtung vor der Anbieterpräsentation festgelegt.
4. Test mit einem realen Prozess durchgeführt, nicht nur Demo.
5. Auftragsverarbeitungsvertrag, Standort der Daten und Unterauftragnehmer geprüft.
6. Anbindung an Identitätsmanagement und Rechtekonzept geklärt.
7. Exportmöglichkeiten und Ausstiegsregelung vertraglich abgesichert.
8. Governance mit Risikoklassen, Anwendungsregister und Vertretungsregelung beschlossen.
9. Schulungskonzept für Fachbereichsentwickler erstellt.
10. Pilotprojekt mit Erfolgskriterien und Überprüfungstermin vereinbart.

FAQ

Was sind Low-Code-Plattformen?
Low-Code-Plattformen sind Entwicklungsumgebungen, in denen Anwendungen überwiegend aus vorgefertigten Bausteinen wie Formularen, Datenmodellen und Workflows zusammengestellt werden. Programmcode wird nur für Sonderfälle benötigt. Dadurch können auch Fachbereiche einfache Anwendungen selbst erstellen.

Für welche Anwendungen eignet sich Low-Code im Mittelstand?
Geeignet sind strukturierte Anwendungen mit überschaubarer Komplexität, etwa Freigabeprozesse, mobile Datenerfassung, interne Register und einfache Auswertungen. Für Kernsysteme mit hohen Anforderungen an Transaktionssicherheit und Performance bleibt Standardsoftware die bessere Wahl.

Welche Datenschutzpflichten gelten bei Low-Code-Anwendungen?
Werden personenbezogene Daten verarbeitet, gelten die Anforderungen der DSGVO unabhängig davon, wer die Anwendung gebaut hat. Dazu gehören der Eintrag im Verarbeitungsverzeichnis, ein Auftragsverarbeitungsvertrag mit dem Anbieter und angemessene technische und organisatorische Maßnahmen.

Wie lässt sich unkontrollierter Wildwuchs vermeiden?
Durch eine Governance mit Risikoklassen, einem zentralen Anwendungsregister, benannten Verantwortlichen und einem Freigabeprozess für Anwendungen mit sensiblen Daten. Zusätzlich sollten Fachbereichsentwickler geschult und produktive Anwendungen regelmäßig überprüft werden.

Wann lohnt sich eine Plattform wirtschaftlich?
In der Regel erst bei mehreren Anwendungsfällen, weil Lizenz, Schulung und Betrieb auf mehrere Anwendungen verteilt werden. Für einen einzelnen Prozess ist Standardsoftware oder ein vorhandenes ERP-Modul häufig günstiger.