Low-Code-Plattformen in der Fertigung ermöglichen es Fachabteilungen, digitale Werkzeuge für wiederkehrende Aufgaben selbst zu entwickeln, ohne auf eine vollständige Softwareentwicklung durch die IT-Abteilung angewiesen zu sein. Gerade in mittelständischen Fertigungsunternehmen, in denen IT-Ressourcen knapp bemessen sind und größere ERP- oder MES-Projekte oft monatelange Vorlaufzeiten haben, schließen Low-Code-Anwendungen eine Lücke für kleinere, spezifische Anwendungsfälle wie digitale Checklisten, einfache Meldeformulare oder Auswertungen aus Maschinendaten. Anders als klassische Individualsoftware werden Low-Code-Anwendungen über visuelle Entwicklungsoberflächen mit vorgefertigten Bausteinen erstellt, wodurch auch Mitarbeiter ohne klassische Programmierausbildung, sogenannte Citizen Developer, eigene Anwendungen bauen können. Dieser Beitrag erläutert, für welche Anwendungsfälle sich Low-Code in der Fertigung eignet, welche organisatorischen Leitplanken notwendig sind und wo die Grenzen des Ansatzes liegen. Orientierung zu geförderten Digitalisierungsvorhaben im Mittelstand, auch im Bereich Low-Code, bietet die Initiative Mittelstand-Digital des Bundesministeriums für Wirtschaft und Klimaschutz.
Titelbild: Foto von Compagnons auf Unsplash.
Was Low-Code-Plattformen technisch leisten
Low-Code-Plattformen stellen grafische Oberflächen zur Verfügung, mit denen sich Datenmodelle, Formulare, Workflows und einfache Auswertungen per Drag-and-Drop zusammenstellen lassen, statt jede Funktion in klassischem Programmcode zu implementieren. Für komplexere Logik erlauben die meisten Plattformen zusätzlich das Einbinden von Skripten oder Formeln, wodurch sich der Ansatz von No-Code-Werkzeugen unterscheidet, die auf jegliche Programmierung verzichten. In der Fertigung werden Low-Code-Anwendungen häufig über Schnittstellen an bestehende Systeme wie ERP, MES oder Zeiterfassung angebunden, um Daten nicht doppelt erfassen zu müssen, sondern bestehende Datenquellen in neuen, auf einen konkreten Anwendungsfall zugeschnittenen Oberflächen nutzbar zu machen.
Abgrenzung zu klassischer Individualentwicklung
Der zentrale Unterschied zur klassischen Softwareentwicklung liegt in der Entwicklungsgeschwindigkeit und der Zielgruppe der Entwickler. Während klassische Individualsoftware üblicherweise von ausgebildeten Softwareentwicklern über Wochen oder Monate erstellt wird, lassen sich einfache Low-Code-Anwendungen von geschulten Fachanwendern innerhalb weniger Tage umsetzen. Dieser Geschwindigkeitsvorteil erkauft sich jedoch mit Einschränkungen bei komplexer Geschäftslogik, hoher Transaktionslast oder speziellen Sicherheitsanforderungen, für die klassische Individualentwicklung weiterhin die geeignetere Wahl bleibt.
| Merkmal | Low-Code | Klassische Individualentwicklung |
|---|---|---|
| Typischer Entwickler | Fachanwender mit Schulung | Ausgebildeter Softwareentwickler |
| Entwicklungsdauer | Tage bis wenige Wochen | Wochen bis Monate |
| Geeignet für | Abteilungsspezifische Einzelanwendungen | Unternehmensweite, komplexe Kernsysteme |
| Wartungsaufwand | Gering bis mittel | Höher, aber planbarer |
Typische Anwendungsfälle in der Fertigung
In der industriellen Praxis haben sich mehrere wiederkehrende Anwendungsfälle für Low-Code-Plattformen etabliert. Digitale Checklisten für Maschinenrüstungen oder Qualitätskontrollen ersetzen papierbasierte Formulare und ermöglichen eine automatische Auswertung wiederkehrender Abweichungen. Meldeformulare für Werkzeugausfälle oder Materialengpässe leiten Informationen unmittelbar an die zuständigen Stellen weiter, statt auf mündliche Weitergabe oder E-Mail-Ketten angewiesen zu sein. Auswertungsdashboards, die Daten aus mehreren bestehenden Systemen zusammenführen, schaffen Transparenz über Kennzahlen, für die es in den Ursprungssystemen keine geeignete Berichtsfunktion gibt.
Praxisbeispiel: Digitale Werkzeugverwaltung in einer mittelständischen Fertigung
Ein anschauliches, beispielhaft konstruiertes Szenario verdeutlicht die praktische Anwendung: Ein Zulieferbetrieb verwaltet seine Fertigungswerkzeuge bislang über eine unübersichtliche Excel-Tabelle, in der Standort, Zustand und nächster Wartungstermin jedes Werkzeugs manuell gepflegt werden. Häufige Fehleingaben und veraltete Stände führen wiederholt dazu, dass Werkzeuge trotz überfälliger Wartung eingesetzt werden. Statt ein vollständiges Werkzeugverwaltungssystem extern zu beauftragen, entwickelt ein technisch versierter Meister gemeinsam mit der IT-Abteilung innerhalb von zwei Wochen eine Low-Code-Anwendung, die jedes Werkzeug über einen QR-Code identifiziert, den aktuellen Standort per Scan aktualisiert und bei Erreichen eines Wartungsintervalls automatisch eine Benachrichtigung an die Instandhaltung sendet.
Nach der Einführung berichtet das Unternehmen von einer deutlich verbesserten Datenaktualität, da die Erfassung direkt am Ort des Geschehens per Smartphone erfolgt, statt nachträglich am Bürocomputer übertragen zu werden. Die Investition in die Anwendung blieb dabei deutlich unter den Kosten einer spezialisierten, extern beauftragten Werkzeugverwaltungssoftware, wenngleich der Funktionsumfang bewusst auf die konkreten Anforderungen des Betriebs zugeschnitten und nicht mit einer vollwertigen Standardsoftware vergleichbar ist. Nach den ersten positiven Erfahrungen erweiterte das Unternehmen die Anwendung schrittweise um eine einfache Verschleißhistorie je Werkzeug, wodurch sich mittelfristig auch Muster erkennen ließen, welche Werkzeugtypen überdurchschnittlich häufig vorzeitig ausfielen, eine Erkenntnis, die in die Beschaffungsentscheidungen für Ersatzwerkzeuge einfloss. Ein solcher schrittweiser Ausbau ausgehend von einer einfachen Grundfunktion gilt in der Praxis als deutlich risikoärmer als der Versuch, von Beginn an eine möglichst vollständige Lösung mit allen denkbaren Zusatzfunktionen zu entwickeln.
IT-Sicherheit bei Low-Code-Anwendungen
Da Low-Code-Anwendungen häufig an bestehende Kernsysteme angebunden werden, entstehen mit jeder neuen Anwendung zusätzliche Schnittstellen, die aus Sicherheitssicht bewertet werden müssen. Viele Plattformen bieten zwar vorkonfigurierte Sicherheitsmechanismen wie Rollen- und Rechtekonzepte, die tatsächliche Wirksamkeit hängt jedoch davon ab, ob Fachanwender diese Mechanismen korrekt konfigurieren. Ein häufiger Fehler besteht darin, Zugriffsrechte großzügiger zu vergeben als notwendig, um Diskussionen mit Kollegen über fehlende Berechtigungen zu vermeiden, wodurch mit der Zeit ein unübersichtliches Berechtigungsgeflecht entsteht. Eine regelmäßige, mindestens jährliche Überprüfung der vergebenen Zugriffsrechte durch die IT-Abteilung, ähnlich einem klassischen Berechtigungsaudit, verringert dieses Risiko erheblich.
Zusätzlich sollte geklärt werden, wo die von Low-Code-Anwendungen verarbeiteten Daten gespeichert werden, insbesondere wenn die Plattform als Cloud-Dienst betrieben wird. Werden in einer Anwendung personenbezogene Daten von Beschäftigten oder produktionskritische, unternehmensvertrauliche Informationen verarbeitet, ist vor der Produktivsetzung zu prüfen, ob der Anbieter angemessene technische und organisatorische Maßnahmen nachweisen kann und ob eine Auftragsverarbeitung im Sinne der Datenschutz-Grundverordnung erforderlich ist. Diese Prüfung sollte fester Bestandteil des Freigabeprozesses sein, nicht eine nachträgliche, oft vergessene Zusatzaufgabe. Für produktionsnahe Anwendungen empfiehlt sich zudem eine klare Trennung zwischen der Low-Code-Umgebung und den eigentlichen Steuerungssystemen der Fertigung, damit eine fehlerhafte Anwendung im schlechtesten Fall nicht unmittelbar auf sicherheitsrelevante Maschinenfunktionen durchgreifen kann.
Wirtschaftlichkeitsbetrachtung und Plattformauswahl
Bei der Auswahl einer geeigneten Low-Code-Plattform sollten Unternehmen neben den unmittelbaren Lizenzkosten auch den Aufwand für Schulung, Support und die spätere Anbindung an bestehende Systeme berücksichtigen. Plattformen unterscheiden sich zudem deutlich in ihrer Ausrichtung: Manche sind auf einfache Formular- und Workflow-Anwendungen spezialisiert, während andere auch komplexere Datenmodelle und umfangreichere Integrationen unterstützen, dafür aber eine steilere Lernkurve für Fachanwender mit sich bringen. Für die erste Einführung empfiehlt sich in der Regel eine Plattform mit geringerer Komplexität, die sich mit vertretbarem Schulungsaufwand erschließen lässt, auch wenn dies bedeutet, dass für anspruchsvollere spätere Anwendungsfälle möglicherweise eine ergänzende, leistungsfähigere Plattform erforderlich wird.
Eine belastbare Wirtschaftlichkeitsbetrachtung sollte den eingesparten Aufwand für externe Beauftragung oder manuelle, papierbasierte Prozesse den laufenden Lizenzkosten sowie dem internen Aufwand für Schulung, Pflege und Governance gegenüberstellen. Insbesondere bei nutzerbasierten Lizenzmodellen steigen die Kosten mit wachsender Verbreitung im Unternehmen an, weshalb eine Hochrechnung auf die geplante Nutzerzahl bereits vor der Plattformentscheidung sinnvoll ist, um spätere Kostenüberraschungen zu vermeiden. Ein einfacher jährlicher Kostencheck, bei dem Lizenzausgaben den tatsächlich genutzten Anwendungen gegenübergestellt werden, hilft zusätzlich dabei, veraltete oder kaum genutzte Anwendungen rechtzeitig zu identifizieren und gegebenenfalls abzuschalten.
Governance und Rollenverteilung als Erfolgsfaktor
Die größte Herausforderung bei der Einführung von Low-Code-Plattformen liegt selten in der Technik, sondern in der organisatorischen Steuerung. Ohne klare Regeln entstehen in der Praxis schnell zahlreiche, von einzelnen Mitarbeitern eigenständig erstellte Anwendungen, die weder dokumentiert noch bei Personalwechsel weitergeführt werden können, ein Phänomen, das häufig als Schatten-IT bezeichnet wird. Sinnvoll ist daher die Einrichtung eines zentralen Verzeichnisses aller Low-Code-Anwendungen, in dem Zweck, Verantwortlicher und verwendete Datenquellen dokumentiert sind, sowie eine verbindliche Regel, wonach neue Anwendungen erst nach kurzer Abstimmung mit der IT-Abteilung produktiv geschaltet werden, um Datenschutz- und Sicherheitsanforderungen von Beginn an zu berücksichtigen.
Rollenmodell zwischen Fachabteilung und IT
Bewährt hat sich ein Rollenmodell, bei dem die IT-Abteilung die Plattform selbst, deren Sicherheitskonfiguration und die Anbindung an Kernsysteme verantwortet, während Fachabteilungen innerhalb dieser Leitplanken eigenständig Anwendungen für ihren jeweiligen Bereich entwickeln dürfen. Für Anwendungen, die auf sensible Daten wie Personaldaten oder produktionskritische Steuerungsdaten zugreifen, sollte zusätzlich eine Freigabe durch die IT-Abteilung vor der Produktivsetzung vorgesehen werden, während einfache, rein abteilungsinterne Anwendungen ohne sensible Datenzugriffe mit geringerem Prüfaufwand freigegeben werden können.
Low-Code demokratisiert die Anwendungsentwicklung, ersetzt aber nicht die Notwendigkeit klarer Verantwortlichkeiten. Ohne Governance entsteht aus der gewonnenen Geschwindigkeit schnell ein unübersichtliches Sammelsurium nicht gewarteter Einzellösungen.
Akzeptanz in der Belegschaft und Umgang mit Skepsis
Die Einführung von Low-Code-Werkzeugen in der Fertigung trifft nicht selten auf Skepsis, insbesondere bei erfahrenen Mitarbeitern, die über Jahre mit etablierten, papierbasierten oder in Excel geführten Prozessen gearbeitet haben. Diese Skepsis speist sich häufig weniger aus technischer Ablehnung als aus der Sorge, dass eine neue digitale Anwendung zusätzlichen Erfassungsaufwand ohne erkennbaren eigenen Nutzen mit sich bringt. Erfolgreiche Einführungen zeichnen sich daher dadurch aus, dass die entwickelte Anwendung den Nutzern selbst einen unmittelbaren, spürbaren Vorteil bietet, etwa eine schnellere Erfassung, weniger Doppelarbeit oder eine bessere Übersicht über den eigenen Arbeitsbereich, statt ausschließlich der übergeordneten Auswertung durch das Management zu dienen.
Bewährt hat sich zudem, Anwendungen zunächst mit einer kleinen Gruppe besonders aufgeschlossener Mitarbeiter zu pilotieren und deren Rückmeldungen aktiv in die Weiterentwicklung einzubeziehen, bevor eine Anwendung auf die gesamte Abteilung oder das gesamte Werk ausgerollt wird. Diese frühen Anwender fungieren häufig als informelle Multiplikatoren, die bei der Einführung in der breiteren Belegschaft glaubwürdiger für den praktischen Nutzen der Anwendung werben können als eine Ankündigung aus der Geschäftsführung oder der IT-Abteilung.
Schritt-für-Schritt-Einführung im Unternehmen
- Auswahl einer Plattform anhand bestehender Systemlandschaft und benötigter Schnittstellen
- Definition eines Governance-Rahmens mit Freigabeprozess und zentralem Anwendungsverzeichnis
- Schulung interessierter Fachanwender in den Grundlagen der visuellen Entwicklungsumgebung
- Umsetzung eines überschaubaren Pilotprojekts mit klar abgegrenztem Anwendungsfeld
- Bewertung von Nutzen und Wartungsaufwand nach einer Testphase von einigen Monaten
- Schrittweise Ausweitung auf weitere Fachabteilungen mit etablierten Governance-Regeln
Grenzen und typische Stolperfallen
Low-Code-Anwendungen eignen sich besonders für Aufgaben mit überschaubarer Komplexität und klar abgrenzbarem Anwendungsfeld, stoßen jedoch dort an Grenzen, wo hohe Transaktionsvolumen, komplexe Integrationslogik oder strenge regulatorische Anforderungen an die Softwarequalität bestehen, etwa bei sicherheitsrelevanten Steuerungsfunktionen. In solchen Fällen sollte weiterhin auf klassische Individualentwicklung oder spezialisierte Standardsoftware zurückgegriffen werden. Ein weiterer häufiger Fehler liegt darin, Low-Code-Anwendungen ohne ausreichende Dokumentation zu erstellen, sodass bei Ausscheiden des ursprünglichen Entwicklers niemand mehr die Anwendung warten oder anpassen kann. Eine verbindliche Mindestdokumentation, etwa zu Zweck, Datenquellen und Verantwortlichem, sollte daher fester Bestandteil des Freigabeprozesses sein. Ergänzend empfiehlt sich, für jede Anwendung eine Vertretungsregelung zu benennen, damit auch bei Urlaub oder kurzfristiger Abwesenheit des Hauptverantwortlichen dringende Anpassungen nicht auf unbestimmte Zeit liegen bleiben.
Zudem unterschätzen viele Unternehmen den langfristigen Lizenz- und Wartungsaufwand von Low-Code-Plattformen, da mit wachsender Zahl an Anwendungen und Nutzern häufig gestaffelte Lizenzmodelle greifen, die bei unkontrolliertem Wachstum zu unerwartet hohen laufenden Kosten führen können. Eine regelmäßige Überprüfung, welche Anwendungen tatsächlich noch aktiv genutzt werden, verhindert, dass ungenutzte, aber weiterhin lizenzierte Anwendungen unnötig Kosten verursachen.
Checkliste für die Einführung
- Ist ein zentrales Verzeichnis aller Low-Code-Anwendungen mit Zweck und Verantwortlichem eingerichtet?
- Existiert ein Freigabeprozess mit erhöhten Anforderungen für Anwendungen mit sensiblen Datenzugriffen?
- Sind Fachanwender ausreichend geschult, um Anwendungen eigenständig, aber sauber dokumentiert zu entwickeln?
- Wird die tatsächliche Nutzung bestehender Anwendungen regelmäßig überprüft, um Lizenzkosten zu kontrollieren?
- Ist klar geregelt, ab welcher Komplexität ein Anwendungsfall an die klassische Softwareentwicklung übergeben wird?
Fazit: Geschwindigkeit mit klaren Leitplanken verbinden
Low-Code-Plattformen in der Fertigung bieten mittelständischen Unternehmen die Möglichkeit, kleinere, spezifische digitale Werkzeuge deutlich schneller und kostengünstiger umzusetzen, als dies mit klassischer Individualentwicklung möglich wäre. Der nachhaltige Nutzen stellt sich jedoch nur ein, wenn die gewonnene Entwicklungsgeschwindigkeit von Beginn an mit einer klaren Governance-Struktur, dokumentierten Verantwortlichkeiten und einem sauberen Zusammenspiel zwischen Fachabteilung und IT verbunden wird. Unternehmen, die diese Balance finden, gewinnen ein flexibles Werkzeug für den langen Schwanz kleinerer Digitalisierungsvorhaben, die sich für eine vollständige Individualentwicklung wirtschaftlich nicht lohnen würden, und schaffen zugleich eine Grundlage, auf der Fachabteilungen eigene digitale Lösungskompetenz aufbauen können, ohne dabei die Kontrolle über Datensicherheit und Systemlandschaft aus der Hand zu geben.
Zusammenspiel mit bestehenden IT-Strategien
Low-Code-Plattformen sollten nicht isoliert von der übrigen IT-Strategie eines Fertigungsunternehmens betrachtet werden, sondern als ein Baustein neben ERP, MES und spezialisierter Standardsoftware. In der Praxis empfiehlt sich eine klare Einordnung, für welche Aufgabenklassen künftig Low-Code zum Einsatz kommt und für welche weiterhin auf etablierte Standardsoftware oder klassische Individualentwicklung gesetzt wird, damit keine widersprüchlichen Parallelstrukturen für dieselben Datenbestände entstehen. Eine solche Einordnung sollte regelmäßig überprüft werden, da sich sowohl der Funktionsumfang von Low-Code-Plattformen als auch die Anforderungen der Fachabteilungen im Zeitverlauf verändern.
FAQ
Wer sollte in einem Fertigungsunternehmen Low-Code-Anwendungen entwickeln dürfen?
Geschulte Fachanwender aus den jeweiligen Abteilungen können einfache Anwendungen selbst entwickeln, sensible oder komplexere Anwendungsfälle sollten jedoch mit Beteiligung der IT-Abteilung umgesetzt werden.
Wie unterscheidet sich Low-Code von No-Code?
No-Code-Plattformen verzichten vollständig auf Programmierung, während Low-Code für komplexere Logik zusätzlich das Einbinden von Skripten oder Formeln erlaubt und dadurch mehr Flexibilität bietet.
Welche Anwendungsfälle eignen sich nicht für Low-Code?
Anwendungen mit hohem Transaktionsvolumen, komplexer Integrationslogik oder strengen Sicherheitsanforderungen an sicherheitsrelevante Steuerungsfunktionen sollten weiterhin klassisch entwickelt werden.
Wie lässt sich Schatten-IT bei Low-Code-Anwendungen vermeiden?
Ein zentrales Anwendungsverzeichnis mit verpflichtender Registrierung sowie ein Freigabeprozess vor der Produktivsetzung neuer Anwendungen reduzieren das Risiko unkontrollierter Einzellösungen deutlich.
Wie hoch ist der Schulungsaufwand für Fachanwender?
Für einfache Anwendungsfälle reichen häufig wenige Tage Einarbeitung in die visuelle Entwicklungsumgebung der jeweiligen Plattform aus, komplexere Funktionen erfordern zusätzliche, vertiefende Schulungen.
Wie wird sichergestellt, dass Anwendungen nach Personalwechsel weiter gepflegt werden können?
Eine verbindliche Mindestdokumentation zu Zweck, Datenquellen und Verantwortlichem als Teil des Freigabeprozesses stellt sicher, dass Anwendungen auch nach einem Wechsel des ursprünglichen Entwicklers nachvollziehbar bleiben.
