Mittelständische Unternehmen stehen unter einem enormen Marktdruck. Sie bewegen sich im Spannungsfeld von steigenden Kundenanforderungen, eines zunehmenden Fachkräftemangels sowie komplexer gesetzlicher Rahmenbedingungen u. a. in Bezug auf Cybersecurity, Nachhaltigkeit sowie Sorgfaltspflichten bezüglich Menschenrechte und Klimaschutz. Digitalisierung und Automatisierung von Geschäftsprozessen verspricht, diesen Druck auf die Unternehmen zu reduzieren, den Anforderungen verschiedener Stakeholder in kürzerer Zeit nachzukommen und Freiheit für strategische Handlungsfähigkeit zu gewinnen.
Anhand eines Herstellers von Maschinenkomponenten wird gezeigt, welche Rolle Low-Code-Ansätze für die digitale Transformation in mittelständischen Unternehmen spielen. Mit einer Low-Code Integrationsplattform wurden die bereits vorhandenen jedoch isolierten Daten und Informationen im Unternehmen aufgabenorientiert aus den verschiedenen IT-Systemen erschlossen und zusammengeführt. Mittels APIs und ansprechenden Frontends wurden diese Daten für die verschiedenen Stakeholder (Kunden, Servicepartner, interne Vertriebs- und Serviceabteilungen) spezifisch aufbereitet und als digitaler Produktpass bereitgestellt. Durch den Einsatz von Low-Code-Ansätzen betrug der Aufwand dafür insgesamt nur 20 Personentage.
Der Beitrag liefert zunächst eine Begriffsbildung und gibt anschließend einen Einblick in die Konzeption und Umsetzung des digitalen Produktpasses, diskutiert anhand konkreter Szenarien Grenzen von Low-Code-Ansätzen und zeigt Lösungsansätze auf. Ein Ausblick auf den Zusammenhang von Low-Code und künstlicher Intelligenz rundet den Beitrag ab.
Hinweise
Hinweis des Verlags
Der Verlag bleibt in Hinblick auf geografische Zuordnungen und Gebietsbezeichnungen in veröffentlichten Karten und Institutsadressen neutral.
1 Der produzierende Mittelstand unter Marktstress
Der produzierende Mittelstand ist unter Marktstress. So auch das in der Fallstudie betrachtete Unternehmen, das hier als Komponenten AG bezeichnet wird. Dabei handelt es sich um einen Anbieter von hochwertigen Komponenten für den Maschinenbau, die für den Einsatz in höchst anspruchsvollen Umgebungen ausgelegt sind. Sie werden schnell wechselnden und dynamischen mechanischen Belastungen, hohen Drehzahlen, extremen Temperaturbereichen und aggressiven Medien ausgesetzt. Dazu werden die Komponenten mit speziellen Beschichtungen versehen, die wiederum eine feine Abstimmung der einzusetzenden Schmierstoffe benötigen. Für die Auslegung von Belastungsparametern werden manuell komplexe Berechnungen durchgeführt, wobei viele Datenblätter, Testdaten und auch kaufmännische Informationen hinzugezogen werden müssen. Dieser Prozess ist zeitaufwändig und benötigt entsprechend geschultes Fachpersonal.
Das Unternehmen bewegt sich im Spannungsfeld (a) immer anspruchsvollerer Kunden, die primär unter Nachhaltigkeitsaspekten entscheiden, (b) gesetzlicher Rahmenbedingungen u. a. auf den Gebieten Cybersecurity (NIS2-Richtlinie), Nachhaltigkeit, Sorgfaltspflichten in Bezug auf Menschenrechte und Klimaschutz, (c) eines großen Preis- und Lieferdrucks in der gesamten Branche sowie (d) den Auswirkungen eines spürbaren Fachkräftemangels.
Anzeige
Konkret stellen sich die Herausforderungen der Komponenten AG wie folgt dar:
Kunden und Interessenten möchten sich über Komponenten umfassend informieren und Daten zur Zusammensetzung, Herstellung und Betriebseigenschaften abrufen können.
Interessenten möchten Komponenten selbständig auslegen und Preise vergleichen können.
Kunden möchten Ersatzteile komfortabel über einen Webshop bestellen können.
Service-Mitarbeiter und Vertragspartner möchten bei einem Servicefall einfach und schnell die jeweiligen Produktions- und Qualitätsinformationen einsehen können.
Im Grunde fordern die Kunden der Komponenten AG schon heute, was in der EU-Gesetzgebung für viele Produkte verpflichtend sein wird: einen Digitalen Produktpass (DPP). Dieser soll für Batterien ab 2026 verpflichtend werden. Anschließend werden weitere Produkte folgen und insofern werden viele mittelständische Unternehmen vor der gleichen Herausforderung stehen.
Der vorliegende Beitrag untersucht, wie mittels Low-Code ein digitaler Produktpass entwickelt und bereitgestellt werden kann. Low-Code verspricht effizientere Entwicklungsprozesse und größere Unabhängigkeit von spezialisierten Software-Entwicklern (Hinrichsen und Adrian 2023).
2 Der digitale Produktpass
Der digitale Produktpass (DPP) „ist [ganz allgemein ausgedrückt] ein Datensatz, der die Komponenten, Materialien und chemischen Substanzen oder auch Informationen zu Reparierbarkeit, Ersatzteilen oder fachgerechter Entsorgung für ein Produkt zusammenfasst. Die Daten stammen aus allen Phasen des Produktlebenszyklus und können in all diesen Phasen für verschiedene Zwecke genutzt werden (Design, Herstellung, Nutzung, Entsorgung)“ (Bundesministerium für Umwelt, Naturschutz, nukleare Sicherheit und Verbraucherschutz 2024). Laut Jansen et al. (2023) kann der digitale Produktpass als Konzept zur Sammlung und zum Austausch von produktbezogenen Informationen zu Hersteller, Eigenschaften, Reparatur und Entsorgung verstanden werden.
Anzeige
Die Aggregation der relevanten Daten, deren Verarbeitung und Aufbereitung zu höherwertigen Informationen und ihre zielgruppenspezifische Bereitstellung erfordert eine geeignete Infrastruktur mit spezifischen IT-Systemen (Kaib 2004). Jansen et al. unterscheiden daher zwischen dem DPP als Datensatz bzw. spezifischem Artefakt sowie dem DPP-System als Informationssystem, in das der DPP eingebunden ist. Nach Neligan et al. (2023) soll ein DPP folgende drei Funktionen bedienen:
1.
Eindeutige Identifikation und Beschreibung einer konkreten Instanz des Produkts.
2.
Standardisiertes und einheitliches Datenmanagement, sodass ein DPP sowohl von Unternehmen als auch von Konsumenten entlang der gesamten Wertschöpfungskette (Hersteller, Lieferanten, Händler usw.) genutzt werden können.
3.
Beherrschung der Komplexität branchenspezifischer Inhalte entlang der Wertschöpfungskette. (Je weiter hinten sich ein Unternehmen in der Wertschöpfungskette einbringt, desto komplexer ist das Produkt und damit auch die produktbezogenen Informationen.)
Daraus ergeben sich folgende Anforderungen an den digitalen Produktpass:
Inhaltliche Anforderungen werden durch die Ökodesign-Richtlinien der Europäischen Kommission jeweils für spezifische Produktgruppen festgelegt (Europäische 2022). Obligatorische Informationen können Haltbarkeit, Zuverlässigkeit, Wiederverwendbarkeit, Nachrüstbarkeit, Reparierbarkeit, einfache Wartung und Aufarbeitung, Energieverbrauch oder Energieeffizienz von Produkten sowie Ressourcennutzung oder Ressourceneffizienz von Produkten sein. Anbieter für DPP sollten die gesetzlichen Anforderungen für ihre spezifischen Produkte genau prüfen.
Technische Anforderungen stellen eine sektoren- und systemübergreifende Nutzung sowie eine Datenbereitstellung durch verschiedene Akteure sicher. Diese umfassen die vollständige technische, semantische und organisatorische Interoperabilität für die nahtlose Zusammenarbeit verschiedener Systeme, freier Zugang zum Produktpass für Verbraucher, Wirtschaftsteilnehmer, sichere Datenspeicherung und Datenverarbeitung, Gewährleistung der Authentizität, Zuverlässigkeit und Integrität der Daten sowie Datensicherheit und Datenschutz (Europäische 2022)
Für die Nutzbarkeit von DPPs für verschiedene Akteure ist die Verwendung von Standards zielführend. Zur Strukturierung der Informationen schlagen Neligan et al. den Datenstandard ECLASS (ECLASS e. V. 2024) vor. Bei der Einführung von DPP in Unternehmen sollte der vorhandene Digitalisierungsgrad berücksichtigt werden. Um die Unternehmen mit dem DPP nicht zu überfordern, ist eine agile Vorgehensweise angebracht, mit der der DPP schrittweise eingeführt werden kann. Vorzugsweise werden erst die inhaltlichen Anforderungen erfüllt und anschließend die technische Umsetzung in Richtung Standards geführt.
Für die Umsetzung eines DPP müssen die relevanten Daten eines Unternehmens zusammengeführt werden. Diese sind meist schon vorhanden:
Maschinen- und Anlagen(-komponenten) stellen Daten bereit, die Einblicke in den Produktionsprozess bieten und Aussagen über den Energieverbrauch oder Qualitätseigenschaften erlauben.
In den Anwendungen zur Produktionssteuerung wie MES-Systeme oder IIoT-Plattformen laufen alle Informationen zu den Umgebungsbedingungen zum Zeitpunkt der Produktion zusammen, woraus wiederum Qualitätsmerkmale, Haltbarkeiten oder Gefährdungen bestimmter Chargen oder einzelner Produkte abgeleitet werden können.
Konstruktionstools bieten die nötige Transparenz auf Stücklisten und fördern damit die Reparierbarkeit.
Testdaten, d. h. Informationen zum Verhalten der Produkte bei der Verwendung, werden als strukturierte Massendaten zumeist auf Fileserver abgelegt.
Handbücher, Verfahrensanweisungen oder Anleitungen zur Assemblierung sind entweder über das Product Lifecycle Management (PLM) Tool zugänglich, über ein Document Management System (DMS) oder auch über Fileserver.
Im ERP-System sind Angaben zur Zusammensetzung der verwendeten Stoffe zugänglich.
Im ERP-System ist darüber hinaus zumeist der Einkaufsprozess abgebildet und die dabei erzeugten Daten begünstigen die Nachweisführung zur Einhaltung der Sorgfaltspflichten entlang der Lieferkette.
Im Folgenden wird gezeigt, dass Unternehmen im Vorteil sind, wenn sie eine Low-Code-Integrationsplattform einsetzen, die diese Daten zentral erschließt und ein agiles Vorgehen bei der Umsetzung von DPP unterstützt.
3 Die Bedeutung von Low-Code für Integrationsplattformen
Eine Low-Code-Plattform ist eine Anwendungsplattform, die eine schnelle Anwendungsentwicklung, -bereitstellung, -ausführung und -verwaltung mit Hilfe von deklarativen, höheren Programmierabstraktionen wie modellgetriebenen und metadatenbasierten Programmiersprachen und Deployments auf Knopfdruck unterstützt. Low-Code-Plattformen unterstützen Benutzerschnittstellen (Uls), Geschäftsprozesse und Datendienste (Bock und Frank 2021).
Eine Low-Code-Integrationsplattform ist eine domänenspezifische Spezialisierung einer Low-Code-Plattform mit dem Ziel, Daten von Anwendungssystemen in Unternehmen über deren Schnittstellen zu erschließen, Geschäftsprozesse zu modellieren und diese auf Grundlage des erschlossenen Datenhaushalts zu automatisieren. In einer Integrationsplattform werden Use Cases wie der DPP zu automatisierten Geschäftsprozessen zusammengesetzt. Dazu muss die IT eng mit ihren Stakeholdern zusammenarbeiten, die die fachlichen (Geschäfts‑)Anforderungen definieren und validieren. Insofern muss eine Integrationsplattform zur Verständigung zwischen Menschen mit unterschiedlichem technischem Hintergrund beitragen, um alle relevanten Stakeholder in den Entwicklungsprozess einbeziehen zu können. Visuelle Kommunikationsmittel, die von technischen Details abstrahieren und auf den fachlichen Prozess bzw. auf die Domäne abgestimmt sind, haben sich hierfür etabliert.
Low-Code-Plattformen bringen visuellen Sprachen direkt in einen Ausführungskontext (Bock und Frank 2021) und überwinden den Medienbruch zwischen Konzeption und Umsetzung (Hinrichsen und Adrian 2023). Damit begünstigen sie eine effiziente und flexible Anwendungsentwicklung, indem sie
visuelle Entwicklungstools bereitstellen, die es Benutzern ohne umfassende Programmierkenntnisse ermöglichen, Anwendungen durch Drag & Drop von Komponenten, Aktionen und Logik zu erstellen bzw. anzupassen sowie die Zusammenarbeit zwischen Fachexperten und Entwicklern zu fördern;
vordefinierte Module und Komponenten anbieten, mit denen Entwickler auf getestete Funktionsbausteine zurückgreifen können;
Automatisierung von Routinetätigkeiten erlauben, um wiederkehrende Aufgaben noch effizienter und fehlerärmer zu erledigen;
iteratives Prototyping unterstützen, um agile Entwicklungsansätze zu ermöglichen und auf Benutzerfeedback und sich ändernde Anforderungen flexibel zu reagieren.
Zur Beschreibung, Umsetzung und zum Betrieb digitaler Use Cases stellen Integrationsplattformen entsprechende Low-Code-Werkzeuge zur Verfügung, die die o. g. Eigenschaften aufweisen:
1.
Adapter-Konfigurationen für die Parametrierung systemspezifischer Schnittstellen.
2.
Mapping-Editoren für Daten zur Abbildung von Datentransformationen, um Daten von einem Format in ein anderes zu überführen.
3.
Prozesseditoren zur Modellierung der Abläufe und Interaktionen der digitalen Use Cases. Der Trend geht hierbei in Richtung domänenspezifischer, jedoch proprietärer Notationen.
4.
Prozessübersichten für einen zentralen Überblick über alle Use Cases und automatisierten Geschäftsprozesse inkl. Dokumentationsgenerator für eine etwaige Zertifizierung.
5.
Monitoring inkl. konfigurierbarer Dashboards für ein technisches Monitoring (Plattform) sowie fachliches Monitoring (KPI). Laufen alle Datenströme eines Unternehmens in der Plattform zusammen, können daraus fachliche Prozesskennzahlen abgeleitet und über Dashboards den interessierten Parteien (Stakeholdern) bereitgestellt werden.
6.
API-Management zur Erstellung, Bereitstellung und Verwaltung von Application Programming Interfaces (APIs), um Softwareanwendungen einen einheitlichen und kontrollierbaren Zugang auf Datenquellen bis hinein in die Geschäftsprozesse zu ermöglichen.
7.
Optional: Programmierumgebungen für die Abbildung komplexer Datentransformationen, Einbindung spezifischer Protokolle und Bibliotheken oder für die Umsetzung komplexer Algorithmen und Rechenoperationen.
TRANSCONNECTⓇ ist eine Low-Code-Integrationsplattform und Grundlage für die Umsetzung des DPP im vorliegenden Fallbeispiel. Durch die Architektur und die Anwendung von TRANSCONNECTⓇ können heterogene IT-Landschaften in Unternehmen auch bei sich ändernden Geschäftsprozessen einfach und iterativ weiterentwickelt werden. Die Schnittstelle zwischen TRANSCONNECTⓇ und den zu koppelnden Systemen bilden die Adapter. Jeder Adapter besitzt einen Satz an Interaktionen für das angeschlossene System, die jeweils auf das verwendete Protokoll bzw. auf die genutzte Technologie abgestimmt sind. Die Kommunikation kann dabei bidirektional erfolgen. Der Datenaustausch erfolgt im standardisierten XML-Format und kann beispielsweise mit XSLT in andere Strukturen (Daten-Mappings) übersetzt werden.
Zum Entwerfen der Anwendungen oder Prozesse auf dem TRANSCONNECTⓇ-Server wird der TRANSCONNECTⓇ-Manager verwendet. Dieser stellt die grafische Benutzeroberfläche für die Anwender dar. Der Startpunkt für die Konfiguration von Prozessen im TRANSCONNECTⓇ-Manager ist die Orchestrierung, die eine Prozessübersicht bietet und darstellt, wie die vorhandenen Prozesse ineinandergreifen. Beispielhaft ist dies für einen einfachen Anwendungsfall in Abb. 1 dargestellt.
Abb. 1
Eine Orchestrierung in TRANSCONNECTⓇ. Der Aufbau eines Use Cases folgt stets dem Schema: Eingangsadapter, Nachrichtenverteilung, Queue (bei asynchroner Verarbeitung), Prozess, Ausgangsadapter
×
Diese Orchestrierung besteht aus einem Eingangsadapter (HTTP-Eingang), einem Nachrichtenverteiler, einer Queue sowie einem Prozess mit weiteren integrierten Adaptern. An erster Stelle eines Use Cases befindet sich immer ein Nachrichtenersteller. In diesem Fall der HTTP-Eingangsadapter. Dieser erzeugt nach seinem Aufruf die Nachricht „Testnachricht“. Alternativ kann die Funktion auch über eine zeitgesteuerte Aufgabe ausgelöst werden.
Die Nachrichten werden über den Nachrichtenverteiler zur weiteren Verarbeitung einem Prozess zugeführt. Dabei kann zwischen synchroner und asynchroner Verarbeitung unterschieden werden. Im Falle einer asynchronen Verarbeitung wird die Nachricht zunächst in eine Queue gestellt und wird dort vom Prozess abgeholt. Im Prozess selbst findet die Verarbeitung der Daten statt. Die einzelnen Aktionen und Interaktionen (Prozessschritte) werden als vordefinierte Bausteine per Drag & Drop zusammengestellt. Diese Prozessschritte können dabei eine Formatänderung der Daten, das Durchlaufen einer Schleife oder Gateways oder eine direkte Transformation mit anschließender Datenbankabfrage sein. Abb. 2 zeigt einen Prozessablauf mit typischen Low-Code-Bausteinen.
Abb. 2
Low-Code Prozessmodellierung und Datentransformationen
×
Zusätzlich bieten Low-Code-Plattformen Basisfunktionen für Data-Governance, Persistenz und Protokollierung, Rückverfolgbarkeit von Nachrichten und deren Verarbeitungsschritte, Ausfallsicherheit und Monitoring. Damit stellen Low-Code-Plattformen sicher, dass sich die Anwender bzw. Entwickler auf die Realisierung der Use Cases, also der fachlichen Inhalte, fokussieren können.
Wird auf dem Datenhaushalt der Integrationsplattform mit den Funktionen des API-Managements eine API errichtet, können diese Daten mittels Frontend für menschliche Anwender aufbereitet werden. Darüber können sich Kunden über Produktmerkmale informieren oder Servicemitarbeiter Informationen zu den Produktionsbedingungen einer bestimmten Charge abrufen. Zudem können über APIs die Geschäftsanwendungen oder Integrationsplattformen von Zulieferern, Partnern oder Kunden angebunden werden. Dies schafft die Voraussetzungen, um ganze Wertschöpfungsketten zu automatisieren.
4 Fallbeispiel: Mit Low-Code zum digitalen Produktpass
Der Aufbau eines digitalen Produktpasses muss sich an den Wertschöpfungs- und Geschäftsprozessen orientieren. Kernfragen beim Aufbau eines digitalen Produktpasses sind:
Die Erhebung und Transparenz welcher Informationen tragen zur Wertschöpfung bei?
Welche Stakeholder werden welchen Nutzen aus diesen Informationen ziehen?
Wie ordnen sich diese Informationen in die Geschäftsprozesse ein bzw. welchen Mehrwert liefern sie?
Welche zusätzlichen Informationen müssen generiert werden?
Wie muss die Systemlandschaft erweitert werden, um diese Informationen zu generieren?
Welche neuen Geschäftsprozesse sind auf Basis dieser Informationen nötig und welche Auswirkungen hat dies auf das bestehende Geschäftsmodell?
Welche neuen Geschäftsmodelle sind strategisch geplant bzw. können daraus abgeleitet werden?
Welche Investitionen stehen dem gegenüber?
Auf Basis dieser Fragen kann eine Digitalisierungs-Roadmap erarbeitet werden. Wird diese Roadmap im Sinne einer agilen Vorgehensweise so in Teilschritte und Sprints zerlegt, dass jede Iteration den Stakeholdern einen weiteren Teilnutzen stiftet, dann wird ein frühzeitiger Return on Invest (ROI) ermöglicht. In der Folge kann eine belastbare Business Case-Betrachtung vorgenommen werden.
4.1 Methodik
Zur Einführung des DPP bei der Komponenten AG wurde eine bewährte Methodik für Integrationsprojekte angewendet (Abb. 3). Sie bedient sich wesentlicher Elemente der agilen Softwareentwicklung, die um Fragestellungen zur Unternehmensstrategie und Stakeholdern erweitert wurde, sowie die aktuelle Prozess‑, System- und Datenlandschaft berücksichtigt. In einem iterativen Prozess wird zunächst die Spezifikations- und dann die Konzeptionsarbeit geleistet. Jede Iteration startet mit einer Positionsbestimmung. Hier wird die aktuelle Situation – in der ersten Iteration die Ausgangslage und in jeder weiteren Iteration vergleichbar mit einer Retrospektive – bewertet und mit dem übergeordneten strategischen Ziel abgeglichen bzw. dieses bei Bedarf angepasst. Daraus ergibt sich ein Wunschzustand für die nächste Iteration. In der Navigationsphase wird dieser Wunschzustand in die Unternehmensvision/-strategie eingeordnet, mit einem Marktbild abgeglichen sowie auf die vorhandene Prozess- und Systemlandschaft abgebildet. Da sich letztere mit jeder Iteration weiterentwickeln, ist in regelmäßigen Abständen auch eine gewisse Kontrolle möglich, ob die strategischen Ziele erreicht bzw. die zugrunde liegenden Hypothesen erfüllt werden.
Abb. 3
Integrationsmethodik für Digitalisierungsprojekte
×
Die ersten Schritte sind also, die Ausgangslage der Komponenten AG zu identifizieren, relevante interne Prozesse aufzunehmen und ein realistisches Zielbild zu entwickeln. Dabei waren Mitarbeitende aus Geschäftsführung, Vertriebsinnendienst und Qualitätssicherung beteiligt, da diese Bereiche vorrangig für den Vertrieb und die Beschaffung der Komponenten verantwortlich sind.
4.2 Ausgangslage
Die Komponenten AG hat aktuell ca. 300.000 Artikel inklusive ihrer Varianten im Artikelstamm definiert. Die einzelnen Artikel weichen in ihren Attributen und Eigenschaften stark voneinander ab. Die Komponenten werden kundenspezifisch gefertigt und unterscheiden sich unter anderem in den Abmessungen, der Verschraubungen und Montagerichtungen (von oben/von unten), der Bauform, den maximalen Traglasten und der verwendeten Schmiermittel.
Sie werden nach Auslieferung an den Kunden meist zusammen mit anderen, auf dem System aufgesetzten Baugruppen, in einer Maschine fest verbaut. Ein Zugriff darauf ist nach der Montage kaum noch möglich. Sobald jedoch ein Defekt aufgrund von Verschleiß, Ausfall oder Schaden auftritt, muss das Bauteil ausgetauscht werden. Durch eine komplexe Integration der Baugruppe im Inneren der Maschine ist das Abnehmen der Bauteilgeometrien und die Bestimmung der Artikelvariante meist stark erschwert.
Engpass 1: Zwar wird ein Datenblatt mit Auslieferung der Ware beigefügt, diese stehen jedoch zumeist nicht (mehr) zur Verfügung, wenn ein Austausch des Produktes bevorsteht.
Auf Prüfständen werden die Schwingungseigenschaften der Komponenten mittels piezo-keramischer Sensortechnik Schwinggeschwindigkeiten und -beschleunigungen bei definierten Belastungen gemessen. Die während der Prüfvorgänge ermittelten Testdaten werden als CSV-Dateien auf einem Fileserver abgelegt.
Engpass 2: Diese Testdaten helfen, das Verhalten der Bauteile während des Einsatzes vorherzusagen bzw. Fehler zu analysieren. Sie stehen dem Service der Komponenten AG oder Vertragspartnern jedoch nicht zur Verfügung.
Weiterhin sieht sich die Komponenten AG einem großem Preis- und Lieferdruck ausgesetzt. Dies führt zu einem Preisverfall, wodurch Qualitätsbedenken beim Kunden entstehen, welche sich zumeist auf Negativerfahrungen mit anderen Fabrikaten begründen. Kunden fragen daher zusätzlich auch Ergebnisse der Qualitätsprüfungen sowie technische Zeichnungen und Skizzen an. Diese Konstruktionsdaten werden in einem DMS abgelegt.
Engpass 3: Kunden hilft für die bessere Einordnung und Auswahl passender Komponenten sowie zur Vertrauensbildung eine Inaugenscheinnahme von Test- und Konstruktionsdaten. Hierauf haben Kunden und teilweise auch Mitarbeiter der Komponenten AG jedoch keinen Zugriff.
Die Komponenten AG sieht hier das Potenzial, den Kunden die gewünschten Informationen, anders als bisher, dauerhaft bereitzustellen.
4.3 Wunschzustand
Zusammengefasst besteht in der Komponenten AG der Bedarf nach einem digitalen Abbild eines beim Kunden physisch eingesetzten Bauteils.
Kunden wünschen sich einen Zugang zu technischen Datenblättern, kundenspezifischer Konfigurationen sowie kaufmännischer Informationen (Kaufdatum, Lieferzeit, etc.).
Servicekräfte und Vertragspartner wünschen sich den Zugang zu den Testdaten und damit zum Verhalten der Komponenten bei verschiedenen Belastungsszenarien.
Die Geschäftsleitung wünscht sich ein Monitoring, auf dessen Basis eine interne Validierung und Weiterentwicklung der Lösung ermöglicht wird. Einigkeit herrscht darüber, dass es in einem dynamischen Marktumfeld von großem Vorteil sei, rechtzeitig zu erkennen, wenn sich Kunden mit den Produkten der Komponenten AG beschäftigt.
Für die Kunden muss die Anwendung einfach zugänglich sein. Die Mitarbeitenden der Komponenten AG sind meist direkt in der Produktion bzw. in der Instandhaltung tätig. Ihr Informationsbedarf entsteht beim Arbeiten an der Anlage bzw. wenn eine äußere Sichtprüfung bei einem potenziellen Defekt vorgenommen wird. Daher soll die Anwendung als Web-Frontend bereitgestellt werden.
Die Möglichkeit, Informationen zu einem physischen, in der Anlage verbauten Produkt beispielsweise im Web abzurufen, existierte bis dato bei der Produktgruppe wettbewerbsübergreifend nicht. Die das Web-Frontend der Anwendung sollte dabei ggf. in die bestehende Website oder in den Online-Shop integriert werden.
Dementsprechend kann der Wunschzustand der Komponenten AG in drei Hauptanforderungen zusammengefasst werden: (1) Zugriff auf kundenspezifische Abmessungen und Produktinformationen anhand der Artikelnummer, (2) Bereitstellung von Daten der Qualitätsprüfungen und (3) Monitoring der Nutzung der Lösung.
Für Umsetzung der Anforderungen müssen die zugrundeliegenden internen Prozesse bei der Komponenten AG analysiert werden, um die nötigen Informationen des DPP ableiten zu können.
4.4 Digitaler SOLL-Prozess
Die Komponenten AG kauft die notwendigen Rohteile bei Zulieferern ein und veredelt später die Produkte für Spezialanwendungen bzw. auf Wunsch der Kunden. Beim Wareneingang finden umfangreiche Qualitätskontrollen statt. Ziel der Untersuchung sind Aussagen zu Qualitätsmerkmalen, die die zu erwartende Lebensdauer der Komponenten beeinträchtigen könnten. Das heißt, es erfolgt eine äußere Sichtprüfung (Prüfung auf äußere Schäden und Konservierung), eine Überprüfung technischer Spezifikationen (Vermessung Lagergeometrie, Rauheitsmessung) und eine chemische Lageranalyse.
Im Unternehmen gibt es drei Prüfstände, die jeweils für verschiedene Anforderungen ausgelegt sind. Die Unterteilung orientiert sich an den eben genannten Produktgruppen. Die Prüfung erfolgt durch speziell geschultes Personal und wird in einem festen Schema dokumentiert, bevor ein gesammelter Prüfbericht erstellt wird. Die Prüfdaten werden als CSV-Dateien manuell exportiert und abgelegt. Sie sind Grundlage für Prüfberichte.
Aktuell werden Anfragen der Kunden dazu manuell vom Vertriebsinnendienst bearbeitet, was zu einem hohen Koordinationsaufwand führt. Bei Anfragen zu spezifischen Datenblättern muss zusätzlich die Abteilung Qualitätssicherung konsultiert werden. Dies resultiert in hohen Aufwand für die Kommunikation und verzögert die Bearbeitung von Verkaufsaufträgen.
In den erwähnten CSV-Dateien werden die Werte der Schwingungsanalyse der Komponenten gespeichert. Die Schwingungswerte sind ein Maß für die Güte der Produkte und werden folglich vom Kunden als Qualitätsprüfung angefragt. Für eine Messung können weitere Merkmale wie Hersteller, Typenbezeichnungen oder Name der Mitarbeitenden erfasst werden. Derzeit gibt es bei der Komponenten AG keinen definierten Prozess zur Speicherung der Prüfdaten. Dies erfolgt nach Ermessen des Prüfenden aus der Abteilung Qualitätssicherung in einem Dateisystem.
Prozesserweiterung 1: Das automatisierte Bereitstellen der Testdaten aus den Qualitätsprüfungen.
Nach erfolgreicher Qualitätsprüfung werden die Artikel chargenrein eingelagert. Das bedeutet, ein Lagerplatz ist eindeutig einem Wareneingangslos zugeordnet. Die Zuordnung erfolgt derzeit im betagten IBM-Warenwirtschaftssystem und soll zukünftig im ERP-System Microsoft Dynamics 365 abgebildet werden.
Nach Bestellung des zuvor eingelagerten Bauteils wird dieses nach den Anforderungen der Kunden weiter zusammengestellt. In der Regel sind mehrere Anpassungen der Komponenten nötig, wie das Zuschneiden auf eine bestimmte Länge, das Befetten mit einem Schmierstoff oder das Montieren von Bauteilen für höhere Traglasten. Die Informationen werden im ERP-System verbucht und können unter den entsprechenden Artikeleigenschaften des geprüften Bauteils eingesehen werden.
Die beschriebenen Aufgaben zur Veredelung werden in Form eines Arbeitsauftrags abgearbeitet. Die Artikel werden dafür geschlossen aus dem Lager kommissioniert und bei Fertigstellung zum Packplatz gebracht. Am Packplatz erfolgt die Vorbereitung für den Versand, wobei Datenblätter, Versandpapiere und Lieferschein der Bestellung zugeführt werden. Die Details zum Auftrag und die Konfigurationen der inbegriffenen Artikel können über die Auftragsnummer im Warenwirtschaftssystem bzw. zukünftig im ERP-System eingesehen werden. Aktuell ist eine Beschriftung der Komponenten mit Abschluss des Auftrags nicht vorgesehen. Zukünftig soll ein Zugriff auf die kundenspezifischen Daten mittels QR-Codes erfolgen.
Prozesserweiterung 2: Erstellung eines QR-Codes, der auf den Komponenten oder auf dem Lieferschein aufgebracht wird, als Teil der Abarbeitung eines Arbeitsauftrags.
Die Geschäftsführung der Komponenten AG ist im Prozess der Auftragsabwicklung nicht direkt beteiligt und beschäftigt sich vorrangig mit strategischen Themen, der Produktentwicklung und der Koordinierung der Vertriebsaktivitäten. Zur Optimierung der Vertriebsprozesse sollen umfangreiche Daten zu den Vertriebsaktivitäten erhoben und ausgewertet werden.
Prozesserweiterung 3: Monitoring der Kundenanfragen und des Auftragsbestands (Geschäftskennzahlen).
Den Kunden soll ein Web-Frontend zur eigenständigen Informationsbeschaffung geboten werden. Dazu sind die Qualitätsdaten, die Artikeleigenschaften sowie die Produktinformationen entsprechend aufzubereiten und mit den Aufträgen zu verknüpfen.
Prozesserweiterung 4: Verknüpfung der Produktdaten mit den Aufträgen und Aufbereitung für die Darstellung auf einem Web-Frontend.
Abb. 4 verdeutlicht den Geschäftsprozess in einer eigenen Notation. Orange sind die bereits bestehenden Prozessschritte dargestellt. Blau hervorgehoben sind die neuen, zu erweiternden bzw. zu automatisierenden Prozessschritte. Grün ist der Wunschzustand: der digitale Produktpass der Komponenten AG. Die nicht eingefärbte Kachel zeigt die Interaktion des Kunden.
Abb. 4
SOLL-Prozess zur Realisierung des digitalen Produktpasses der Komponenten AG
×
4.5 Systemlandschaft
Zur Abbildung des SOLL-Prozesses mit den beschriebenen Prozesserweiterungen sind laut Systemanalyse keine Erweiterungen an bestehenden Systemen nötig. Alle Daten und Informationen sind bereits vorhanden; sie müssen lediglich erschlossen und automatisiert werden. Dazu wird die Integrationsplattform TRANSCONNECTⓇ in die Systemlandschaft eingeführt (Abb. 5).
Abb. 5
Die Low-Code Integrationsplattform TRANSCONNECTⓇ in der Systemlandschaft der Komponenten AG erschließt die nötigen Daten und setzt die zu automatisierenden Prozesserweiterungen um
×
Für die automatisierte Bereitstellung der Testdaten aus den Qualitätsprüfungen (Prozesserweiterung 1) werden die CSV-Dateien aus dem Dateisystem der Prüfstände gelesen und in einer SQL-Datenbank (QM DB) abgelegt. In dieser Datenbank werden die Testdaten mit den Artikel- und Auftragsdaten verknüpft. Dieser Prozess läuft zeitgesteuert. Für die Generierung des QR-Codes (Prozesserweiterung 2) wird eine frei zugängliche Online-API verwendet. Der QR-Code wird als Bilddatei zur weiteren Verwendung mit einer eindeutigen Nomenklatur auf einem Fileserver abgelegt. Das Monitoring (Prozesserweiterung 3) setzt auf eine Datenbank, in der die Anfragen des Web-Frontends mitgeschrieben werden. Für die Versorgung des Web-Frontends (Prozesserweiterung 4) mit den nötigen Daten wird eine HTTPS-REST-API in der Integrationsplattform bereitgestellt. Diese greift im Hintergrund auf die vorhandenen Systeme zu, um die angefragten Daten zu ermitteln und zurückzuliefern. Jeder API-Call wird in der Log-DB protokolliert.
4.6 Der digitale Produktpass der Komponenten AG
Alle Workflows und Prozesse in der Integrationsplattform sind mittels Low-Code umgesetzt worden:
Konfiguration der Adapter zu den Quell- und Zielsystemen mittels No-Code-Editoren
Prozesse zur Automatisierung von Abläufen mittels No-Code-Ablaufsprache
Prozesse zur Aggregation der Daten aus den verschiedenen Anwendungssystemen und Datenbanken des Unternehmens in einen digitalen Produktpass
Datentransformationen und -aufbereitung mittels XML-basierter Programmiersprache (XSLT)
Abb. 6 zeigt einen Prozessausschnitt aus der Automatisierung der Prozesserweiterung 1.
Abb. 6
Auszug einer Prozessdefinition für die Automatisierung der Bereitstellung der Testdaten aus den Prüfständen
×
Abb. 7 zeigt eine Übersicht über die Prozesse, die im Rahmen der Entwicklung des digitalen Produktpasses modelliert wurden. Sie sind auf vier Orchestrierungen (siehe linker Navigationsbaum des dargestellten Anwendungsfensters) aufgeteilt. Eine Orchestrierung ist in der Low-Code-Integrationsplattform TRANSCONNECTⓇ eine Prozessübersicht. Dargestellt ist nachfolgend die Orchestrierung, die die Prozesse aus Prozesserweiterung 4 zusammenfasst.
Abb. 7
Orchestrierung: Übersicht der Prozesse aus Prozesserweiterung 4
×
Die beiden Prozesse dieser Orchestrierung stellen die API für das Web-Frontend bereit. Dieses wird über eine HTTPS-REST-API gespeist und enthält alle Informationen eines bestimmten Auftrags. Es kann von Kunden und Servicemitarbeitenden gleichermaßen genutzt werden. Der HTTP-Eingangsadapter, der dem Prozess „DT_Landing“ vorgeschaltet ist, nimmt eine Auftragskennung entgegen. Diese wurde zuvor als QR-Code auf die Komponenten bzw. auf den Lieferschein aufgebracht. Insofern müssen Kunden lediglich den Lieferschein abscannen, um alle relevanten Informationen zu einem Auftrag zu finden. Servicetechniker können dazu den QR-Code auf der verbauten Komponente verwenden. Abb. 8 zeigt das Web-Frontend des digitalen Produktpasses.
Abb. 8
Web-Frontend des digitalen Produktpasses
×
4.7 Diskussion der Ergebnisse
Die vorgestellte Lösung eines digitalen Produktpasses wurde mittels Low-Code-Ansätzen und einer Integrationsplattform sowie mittels der Elemente aus einem Low-Code Web-Toolkit realisiert. Der Aufwand für die Umsetzung bemisst sich hierbei auf 20 Personentage. Der Gesamtaufwand lag bei 60 Personentagen.
Anders als bei klassischen Programmieransätzen, bei denen der Aufwand für Spezifikation und Konzeption ungleich kleiner ist als der nötige Aufwand für Umsetzung und Betrieb, hält sich dieses Verhältnis bei der Verwendung von Low-Code-Ansätzen die Waage. Insbesondere für die Arbeit mit den Stakeholdern zur Anforderungsaufnahme, zur Herausstellung des Nutzens für die einzelnen Stakeholder, zur Definition einer Roadmap, zum Aufbrechen dieser in User Stories, zum Refinement und zur Priorisierung sind erfahrene Spezialisten nötig. Eine Low-Code-Plattform kann hier lediglich unterstützen und gewonnene Informationen aufnehmen, um sie in späteren Phasen nutzen zu können, ohne sie erneut eingeben zu müssen.
Insgesamt zeigt dieses Verhältnis, dass Low-Code den Aufwand für die Umsetzung weit unter den Konzeptionsaufwand drückt. In Abschn. 6 werden Ansätze diskutiert, wie die Entwicklung digitaler Use Cases und Geschäftsprozessautomatisierung weiter optimiert und demokratisiert werden kann.
5 Grenzen von Low-Code
Low-Code-Bausätze erlauben nur eingeschränkt Individualisierungen. Die Stärke einer Low-Code-Plattform kann nur domänenspezifisch ausgespielt werden, was sich am Fallbeispiel wie folgt zeigt:
1.
Die Integrationsplattform stellt Low-Code-Bausteine zur Datenaggregation, -aufbereitung und -verarbeitung sowie für das API-Management bereit. Die Umsetzung des digitalen Produktpasses mittels Low-Code-Technologie ist keinen Einschränkungen unterlegen.
2.
Das Web-Frontend wurde ebenfalls mittels Low-Code-Technologie erstellt. Das verwendete Toolkit legt den Fokus auf die Erstellung von Dashboards zur Datenauswertung. Hier sind alle benötigten Funktionen erfüllt. Jedoch hat es Grenzen bei der individuellen Gestaltung, was sich sehr anschaulich an den schwarzen Kästen zeigt: Es wird nur der Dark Mode unterstützt.
Die Integrationsplattform TRANSCONNECTⓇ ist von Beginn an als Low-Code-Plattform konzipiert und umgesetzt worden. Das erste öffentliche Release fand bereits 1998 statt. Seit diesem Zeitpunkt werden Projekte verschiedener Größenordnungen in vielen Branchen damit realisiert. Aus diesen Erfahrungen ist nicht nur das in Abschn. 4.1 „Methodik“ vorgestellte methodische Framework entstanden, sondern es konnten auch die folgenden Grenzen und Herausforderungen erkannt werden (vgl. Rokis und Kirikova 2022):
Komplexität der Anforderungen: Bei hochkomplexen Fachanforderungen oder spezifischen technischen Anforderungen kann Low-Code an seine Grenzen stoßen. In solchen Fällen ist handgeschriebener Code notwendig, um die gewünschten Funktionalitäten zu implementieren. Im Fallbeispiel könnte der Dark Mode durch Codeanpassungen geändert werden.
Skalierbarkeit: Während Low-Code-Plattformen für die schnelle Entwicklung von Prototypen und kleineren Anwendungen gut geeignet sind, können sie bei der Skalierung großer und komplexer Unternehmensanwendungen bzw. bei komplexen Datentransformationen an Leistungsfähigkeit verlieren. Im Fallbeispiel werden Datentransformationen mit der XML-basierten Programmiersprache XSLT vorgenommen, die auch für komplexe Szenarien sehr gut skaliert. Im Extrem erlaubt die Plattform das Einlassen von Java-Code in die XSLT-Templates.
Anpassungsfähigkeit an spezifische Technologien: In manchen Fällen können spezifische Technologien oder Frameworks erforderlich sein, die möglicherweise nicht nahtlos in Low-Code-Plattformen integrierbar sind.
Kontrolle über den Code: In Projekten, bei denen die Kontrolle über den Quellcode von entscheidender Bedeutung ist (z. B. in sicherheitskritischen Anwendungen), könnten Unternehmen Vorbehalte gegenüber Low-Code haben, da der generierte Code möglicherweise nicht so transparent oder anpassbar ist wie handgeschriebener Code. Open Source bietet hier einen Ausweg.
Langfristige Wartbarkeit: Die Wartbarkeit von Anwendungen kann eine Herausforderung darstellen, insbesondere wenn Änderungen oder Upgrades erforderlich sind. Der generierte Code könnte schwieriger zu verstehen sein, was zu Herausforderungen bei der Fehlerbehebung und Wartung führen kann. Jedoch generieren nur die wenigsten Low-Code-Plattformen Code. Üblicherweise werden die Low-Code-Modelle interpretiert.
Abhängigkeit von Anbieterlösungen: Unternehmen, die Low-Code-Plattformen nutzen, sind oft stark von den Lösungen und Updates der Anbieter abhängig. Änderungen in der Plattform könnten sich auf vorhandene Anwendungen auswirken, und Unternehmen müssen sicherstellen, dass sie mit den Entwicklungen des Anbieters Schritt halten können.
Sicherheitsbedenken: Da Low-Code-Anwendungen oft auf vordefinierten Modulen und Funktionen basieren, können Sicherheitsrisiken entstehen, wenn diese nicht ordnungsgemäß konfiguriert oder aktualisiert werden. Es ist wichtig sicherzustellen, dass die erstellten Anwendungen den Sicherheitsstandards entsprechen.
Trotz dieser Herausforderungen wird Low-Code weiterhin als wertvolles Werkzeug angesehen und zunehmend mit traditionellen Entwicklungsansätzen kombiniert (Bock und Frank 2021) bzw. werden diese durch Low-Code gänzlich ersetzt. Unternehmen sollten jedoch die Grenzen von Low-Code verstehen und sorgfältig prüfen, ob es für ihre spezifischen Anforderungen geeignet ist.
6 Lösungsansätze zur Überwindung der Grenzen von Low-Code
Eine häufig geäußerte Kritik an Low-Code ist, dass dieser Ansatz entweder zu technisch für Fachanwender/-innen ist oder einen zu geringen Funktionsumfang für die Umsetzung komplexer Anforderungen bietet. Folgende Lösungsansätze können zur Überwindung dieser Grenzen beitragen:
Domänenspezifischer Fokus: Je spezifischer eine Low-Code-Plattform auf eine bestimmte Domäne zugeschnitten ist, desto leistungsfähigere Bausteine können bereitgestellt werden. Damit ist die Umsetzung auch hochkomplexer Anwendungen möglich.
Zielgruppenfokus: Je technischer der Hintergrund der Zielgruppe, für die die Low-Code-Plattform entworfen wurde, desto weiter kann die Terminologie der Bausteine in den Problemraum reichen. Plattformen, die auf sogenannte „Citizen Developer“ abzielen, sind in der Regel in ihrem Lösungsraum recht beschränkt. Plattformen, die auf Professional IT abzielen, benötigen mehr manuelle Arbeit, sind jedoch leistungsfähiger.
Plattformen, die einen eleganten Hand-Off zwischen Citizen Developer und Professional IT ermöglichen, werden die Grenzen von Low-Code am besten überwinden. Zum Beispiel ist dies über einen Marktplatz, also einer transparenten Erweiterung des Funktionsumfangs der Plattform, möglich. Professional-IT-Entwickler erstellen fach- oder domänenspezifische Lösungsbausteine unter anderem unter Zuhilfenahme von Full-Code und stellen diese Bausteine in einen Marktplatz oder App Store der jeweiligen Plattform. Von dort werden sie von den Citizen Developern für die Lösung eines konkreten Problems eingebunden.
Low-Code-Plattformen, die es Citizen Developern ermöglichen, Applikationen zu entwickeln oder Geschäftsprozesse zu automatisieren, führen zielgruppenspezifisch durch den Erstellungsprozess. Da Citizen Developer keine IT-Ausbildung absolviert haben, fehlen ihnen hinreichende Kenntnisse zu IT-Governance-Regelungen, Abstraktionen und Wiederverwendung. Diese Aspekte beeinflussen insbesondere die Sicherheit und Skalierbarkeit der Lösungen. Dabei können Vorgehensmodelle und Methodiken (siehe Abschn. 4.1) eine wichtige Orientierung bieten.
Schließlich tragen auch KI-Ansätze dazu bei, die Grenzen von Low-Code und sogar No-Code zu überwinden. Die nachfolgenden Abschnitte stellen hierzu einige Details vor.
6.1 Weiterführende Entlastung der IT durch No-Code-Ansätze
Ein wichtiger und wirkungsvoller Hebel für die weitere Entlastung der IT-Abteilungen für die anstehenden Digitalisierungsaufgaben ist nicht die weitere Optimierung der Entwicklungsprozesse, sondern das Auslagern der Konzeptionsarbeit zu den Fachexperten und -expertinnen (Citizen Developer). Da die Konzeptionsarbeit durch Low-Code-Ansätze den Großteil des Aufwands (ca. 80 %, vgl. Abschn. 4.7) ausmacht, liegt hierin liegt das größte Potenzial.
Citizen Developer benötigen dafür eine stark vereinfachte und domänenspezifische Terminologie – einen No-Code-Ansatz – zur Umsetzung digitaler Use Cases bzw. zur Automatisierung von Geschäftsabläufen. Durch zielgruppenspezifisches Führen durch den Konzeptionsprozess, durch domänenspezifischen Fokus der No-Code-Terminologien sowie einer eleganten Übergabe (Hand-Off) zur Professional-IT, also einem adäquaten Weg zur Zusammenarbeit dieser beiden Welten, kann die weitere Entlastung der IT durch die Citizen Developer gelingen.
6.2 Entstehung einer neuen Datenkultur durch No-Code-Ansätze
Der Hand-Off zwischen Citizen Developer und Professional IT-Developer findet auf der Datenebene statt. Es werden fachliche und technische Daten unterschieden. Fachliche Daten werden in digitalen Use Cases und automatisierten Geschäftsprozessen genutzt. Sie werden aus technischen Daten konstruiert, die wiederum durch die IT-Systeme generiert und bereitgestellt werden.
Citizen Developer arbeiten in der fachlichen Welt, also auf Prozessebene mit fachlichen Daten. Sie wissen, dass beispielsweise Kunden immer am Monatsersten eine Rechnung über die im Vormonat abgearbeiteten Aufträge per E‑Mail erhalten und wie der genaue Prozessablauf dazu zu gestalten ist. Die Professional IT-Developer wissen, mittels welcher technischen Daten aus welchen Systemen und über welche Schnittstellen die fachlichen Daten konstruiert werden können. Das fachliche Datenobjekt Kunde wird bspw. durch Abfrage des CRM über eine HTTP-REST-Schnittstelle erstellt. Die technischen Daten für das fachliche Datenobjekt Auftrag können hingegen verteilt im ERP (vereinbarter Tagessatz) und im Zeiterfassungssystem (tatsächlicher Aufwand) liegen und über unterschiedliche Schnittstellentechnologien nutzbar gemacht werden.
Integrationsplattformen, die diesen Dreiklang aus Prozessen (Citizen Developer), Systemen (Professional IT-Developer) und Daten (Hand-Off) unterstützen, werden die Vorteile der No-Code‑/Low-Code-Technologien in die Anwendung bringen. Damit tragen sie nicht nur zur Demokratisierung der IT bei, sondern auch zur Verständigung der verschiedenen Akteure in Digitalisierungsinitiativen. Moderne Organisationsformen sehen schon heute cross-funktionale Teams aus Citizen Developern und IT vor. Durch diese Datenkultur sprechen sie dann auch eine gemeinsame Sprache.
6.3 Optimierung mittels Künstlicher Intelligenz
Künstliche Intelligenz (KI) und generative künstliche Intelligenz (GenKI) helfen, die Grenzen von No-Code/Low-Code zu überwinden, indem sie an den folgenden drei Punkten angreifen:
1.
Betrieb der Plattform und der Use Cases: Laufen alle Daten- und Informationsströme eines Unternehmens zentral in der Integrationsplattform zusammen, dann kann eine KI von den Kommunikationsmustern lernen und über die kleinsten Abweichungen und Anomalien benachrichtigen. Diese können die Plattform selbst betreffen, die Zustände umliegender Systeme oder auch Fehlbedienungen oder gar Angriffe frühzeitig erkennen.
2.
Entwicklung von Use Cases & Geschäftsprozessen: Anwender – sowohl Citizen Developer als auch Professional IT-Developer – können Unterstützung in ihren Tätigkeiten durch eine GenKI erhalten. So kann eine GenKI Daten-Mappings zwischen zwei Systemen selbständig ermitteln und vorschlagen. Sie kann aber auch durch den gesamten Erstellungsprozess anhand der in Abschn. 4.1 vorgestellten Methodik führen und den richtigen Personen zur richtigen Zeit die richtigen Fragen stellen.
3.
Optimierung von Use Cases & Geschäftsprozesse: Aufgrund einer Messung und Bewertung der Prozessdurchläufe können wertvolle Aussagen zur Prozessqualität getroffen und Vorschläge zur Prozessoptimierung bzw. -beschleunigung abgeleitet werden.
Ein deutlich weitführender Ansatz, der wohl am meisten zur Demokratisierung der IT beitragen würde, ist ein sogenannter Use Case Prompt. In einem Dialog mit einer GenKI wird beschrieben, was der Use Case leisten soll. Das Beispiel aus Abschn. 6.2 könnte ein Citizen Developer als Prompt wie folgt formulieren: Alle Kunden sollen immer am Monatsersten eine Rechnung über die im Vormonat abgearbeiteten Aufträge per E‑Mail erhalten. Rechnungen sollen nur erstellt werden, wenn die Summe der geleisteten Stunden >0 ist.
Die GenKI erstellt daraufhin im No-Code-Teil der Plattform einen entsprechenden Prozessablauf, der als Grundlage für weitere Verfeinerungen genutzt wird. Die GenKI könnte auch noch Rückfragen stellen, bspw. welche Informationen die Rechnung beinhalten soll oder aus welchen Systemen die Daten ermittelt werden sollen. Die GenKI ermittelt die technischen Daten, indem sie selbständig Adapter für die APIs dieser Systeme konfiguriert und die Daten-Mappings erstellt. Da Citizen Developer für die Erfüllung ihrer Geschäftsprozesse in den entsprechenden Systemen arbeiten, kann davon ausgegangen werden, dass sie wissen, welches System welche Daten liefert. Die Daten zu erschließen, ist dann Aufgabe der Professional IT-Developer oder einer generativen künstlichen Intelligenz.
7 Fazit
Der Beitrag hat gezeigt, dass mittels Low-Code die Geschäftsanforderung „Digitaler Produktpass“ in kürzester Zeit umgesetzt werden konnte. Dazu wurde eine Low-Code Integrationsplattform eingesetzt und im Entstehungsprozess des Use Cases alle relevanten Stakeholder einbezogen. Grundlage für das Vorgehen war eine standardisierte und erprobte Methodik.
Allerdings wurde deutlich, dass Low-Code nur beschränkt zur Demokratisierung der IT beiträgt. Low-Code ist für Professional IT-Developer gemacht. Es begünstigt die Verständigung zwischen den einzelnen Akteuren im Entstehungsprozess, es wird jedoch nicht selbständig durch Citizen Developer angewendet. Ein Weg in Richtung Demokratisierung kann über No-Code-Technologien führen, die den Anwender durch den Entstehungsprozess begleiten. Es werden Übergabepunkte in die Professional IT benötigt, die auf der beschriebenen Datenkultur fußen oder Marktplätze integrieren. Zusätzlich begünstigen Erweiterungen auf Grundlage (generativer) künstlicher Intelligenz diese Entwicklung.
Funding
Die Veröffentlichung dieses Beitrags wird gefördert aus Mitteln des Europäischen Sozialfonds
Plus (ESF Plus) und aus Steuermitteln auf Grundlage des vom Sächsischen Landtag beschlossenen
Haushalts (Förderkennzeichen: 100693812).
Open Access Dieser Artikel wird unter der Creative Commons Namensnennung 4.0 International Lizenz veröffentlicht, welche die Nutzung, Vervielfältigung, Bearbeitung, Verbreitung und Wiedergabe in jeglichem Medium und Format erlaubt, sofern Sie den/die ursprünglichen Autor(en) und die Quelle ordnungsgemäß nennen, einen Link zur Creative Commons Lizenz beifügen und angeben, ob Änderungen vorgenommen wurden.
Die in diesem Artikel enthaltenen Bilder und sonstiges Drittmaterial unterliegen ebenfalls der genannten Creative Commons Lizenz, sofern sich aus der Abbildungslegende nichts anderes ergibt. Sofern das betreffende Material nicht unter der genannten Creative Commons Lizenz steht und die betreffende Handlung nicht nach gesetzlichen Vorschriften erlaubt ist, ist für die oben aufgeführten Weiterverwendungen des Materials die Einwilligung des jeweiligen Rechteinhabers einzuholen.
HMD liefert IT-Fach- und Führungskräften Lösungsideen für ihre Probleme, zeigt ihnen Umsetzungsmöglichkeiten auf und informiert sie über Neues in der Wirtschaftsinformatik (WI).
