Prozessautomatisierung selbst gemacht: Wie Low-Code, No-Code und KI kontinuierliche Verbesserung auf ein neues Level heben können

Kontinuierliche Verbesserung geschieht selten von selbst (hier mehr dazu). Was aber aktuell sehr schnell geschieht ist eine Veränderung in den Werkzeugen, mit denen wir Verbesserungen und Automatisierung von Prozessen technisch umsetzen können. Das gilt insbesondere für administrative Prozesse. Während man früher für jede kleine Anpassung in einem digitalen System auf IT-Ressourcen hoffen musste, ermöglichen heute Low- und No-Code-Plattformen in Kombination mit KI auch Nicht-Programmierern wie mir den Einstieg in die Prozessautomatisierung. Und das eröffnet auch gerade im Kontext von Lean Management und KVP ganz neue Möglichkeiten. Ein weiterer, persönlicher Antrieb für die App und diesen Beitrag war die Aussage eines befreundeten CTOs, der meinte, dass eine funktionierende Software immer besser ist als jede PowerPoint-Präsentation.

Der Beitrag stellt stellt verschiedene Low-/No-Code Tools vor und zeigt zwei Beispiele auf, die mit zwei verschiedenen Plattformen erstellt wurden. Außerdem konnte ich mit Hannah Michel eine erfahrene Expertin für einen Praxisbericht zu Low- bzw. No-Code Automatisierung von Prozessen gewinnen.

Low-Code und No-Code: Was ist das eigentlich?

Vereinfacht gesagt ermöglichen es Low- und No-Code-Tools, digitale Anwendungen zu erstellen, ohne selbst Code schreiben zu müssen (No-Code) bzw. nur sehr wenig davon (Low-Code). Stattdessen wird mit visuellem Drag-and-Drop, konfigurierbaren Steuerelementen und vordefinierten Logik-Bausteinen gearbeitet. Damit lassen sich z. B. Formulare, Datenflüsse, Benachrichtigungen oder ganze Workflows gestalten und das oft schneller, als man einen Change-Request bei der IT absetzen kann.

Unterschied zwischen Low-Code und No-Code

Die folgende Tabelle zeigt die wesentlichen Unterschiede zwischen No-Code und Low-Code und enthält außerdem einige Tool-Beispiele.

Merkmal	No-Code	Low-Code
Zielgruppe	Fachanwender ohne Programmierkenntnisse	Fortgeschrittene Anwender oder Entwickler
Komplexität	Einfach, eingeschränkt in der Flexibilität	Höher, dafür deutlich anpassbarer
Anpassung durch Code	Nicht vorgesehen	Möglich (z. B. mit JavaScript, PowerFX etc.)
Beispiele für Tools	Make, Zapier, Ninox	Microsoft Power Apps, Mendix, OutSystems

Wenn man beginnt, sich mit der Welt der Low-Code- und No-Code-Plattformen auseinanderzusetzen, wird schnell deutlich: Es gibt nicht die eine Lösung, sondern mittlerweile eine breite Palette an Tools, die sich je nach Anwendung, Zielgruppe und technischer Infrastruktur unterscheiden. Als Prozessverantwortliche Person, es hilfreich die Grundzüge dieser Plattformen zu kennen wenn man wissen möchte, welche Lösung sich wofür eignet.

Low- und No-Code-Plattformen

Zunächst gibt es die Microsoft Power Platform. Sie besteht im Kern aus vier Komponenten: Power Apps für die eigentliche App-Entwicklung, Power Automate für Workflow-Automatisierung, Power BI für Reports und Dashboards sowie Power Virtual Agents für die Erstellung von Chatbots. Besonders stark ist die Power Platform überall dort, wo bereits mit Microsoft 365 gearbeitet wird, etwa mit SharePoint, Outlook oder Teams. Die Tools greifen nahtlos ineinander und machen es leicht, bestehende Strukturen weiterzudenken. Der Einstieg erfolgt in der Regel über ein M365-Konto mit entsprechender Lizenz (z. B. E3, E5 oder Developer Plan), alternativ kann man auch über dedizierte Power-Apps-Pläne starten.

Technisch braucht man nicht viel: ein Browser reicht. Die App-Entwicklung erfolgt visuell im Power Apps Studio, und über SharePoint lassen sich Datenmodelle schnell aufbauen. Typische Anwendungsfälle sind digitale Formularprozesse, einfache mobile Apps oder – wie bei meiner selbst erstellten KVP-App – schlanke Systeme zur Erfassung und Bewertung von Verbesserungsvorschlägen. Obwohl die Power-Plattform sehr visuell ist, ist es durch die Nutzung von Funktionen hilfreich wenn man die Logik von Programmen und Abläufe versteht. Man kommt um die Nutzung von Code-Elementen nur schwer herum, weshalb ich die Plattform bei Low-Code einordnen würde.

Im Gegensatz zu Make. Make (früher: Integromat) stammt ursprünglich aus Tschechien und wurde 2016 von einem kleinen Entwicklerteam gegründet, das ein visuell leistungsfähigeres Pendant zu Zapier schaffen wollte. Seit 2020 gehört Make zur Celonis-Gruppe – einem Spezialisten für Process Mining –, was den Fokus auf datengetriebene Prozessautomatisierung weiter verstärkt hat. Bei diesen beiden Tools geht es weniger um die Entwicklung eigener Apps, sondern um die Automatisierung bestehender Abläufe zwischen Tools. So kann man z. B. eine Regel erstellen, die automatisch eine Slack-Nachricht verschickt, wenn in einem Formular etwas eingetragen wurde – oder einen Ordner in Google Drive erzeugen, wenn in Trello eine neue Karte erstellt wird. Die Nutzung erfolgt browserbasiert, Einstieg und Registrierung sind schnell erledigt. Die kostenlose Version reicht für viele Standardfälle aus; bei höherem Datenvolumen oder komplexeren Szenarien braucht man einen kostenpflichtigen Plan. Für schnelle Prototypen oder um Digitalisierungsinseln miteinander zu verbinden, ist das Tool ideal – allerdings stößt man an Grenzen, wenn komplexere Geschäftslogiken oder Benutzerrollen notwendig sind.

Ich habe Make ausprobiert und einen einfachen Workflow erstellt, der aus einem PDF-Rechnungsdokument die wichtigsten Daten extrahiert und diese dann in eine Liste einträgt. Das hat ohne größere Probleme mit Google und OpenAI-Lösungen funktioniert. Die Konnektoren waren einfach und intuitiv einzurichten und die Daten in einer intuitiven, visuellen Oberfläche zu nutzen. Da ich an keiner Stelle Code eingeben musste, würde ich Make in die Kategorie No-Code einordnen.

Im Folgenden werden kurz noch weitere Low- und No-Code Tools beschrieben.

Mendix wurde ursprünglich als eigenständige Plattform entwickelt und gehört seit 2018 zu Siemens. Die Low-Code-Plattform Mendix ist etwas anspruchsvoller in der Infrastruktur, aber auch flexibler und eignet sich besonders für komplexere Unternehmensanwendungen. Mendix ist ideal, wenn es darum geht, umfangreiche Datenmodelle, rollenbasierte Logik oder Backend-Integrationen umzusetzen – etwa bei der Erstellung eines Serviceportals für interne Prozesse oder bei Außendienst-Apps mit Anbindung an ERP-Systeme. Der Zugang erfolgt über mendix.com, wo man auch eine kostenlose Community Edition nutzen kann. Für produktive Anwendungen sind jedoch Cloud- oder Enterprise-Pläne notwendig. Die Apps können in der Mendix-Cloud laufen, aber auch On-Premise oder in Containern – hier zeigt sich die Plattform besonders integrationsstark. Als positiv bewertet wird bei Mendix die Kombination aus visueller Entwicklung und der Möglichkeit, bei Bedarf tief einzusteigen. Etwa, wenn es um Businessregeln oder Schnittstellenlogik geht.

Ein weiterer Vertreter im Low-Code-Bereich ist OutSystems. OutSystems wurde im Jahr 2001 in Portugal gegründet mit dem Ziel, eine Entwicklungsplattform zu schaffen, die es Unternehmen ermöglicht, komplexe Anwendungen schneller und flexibler bereitzustellen als mit klassischer Programmierung. Heute hat OutSystems seinen Hauptsitz in den USA (Boston) und operiert als eigenständiges Unternehmen mit weltweiter Präsenz, unterstützt durch Investoren wie Goldman Sachs und KKR.

OutSystems fällt vor allem durch seine starke Performance bei mobilen Anwendungen auf. OutSystems erlaubt es, Anwendungen sowohl für Web als auch Mobile zu entwickeln und das mit einer gemeinsamen Codebasis. Der Zugang erfolgt über ein Personal Environment (kostenlos), für den produktiven Einsatz sind kostenpflichtige Pläne nötig. Auch hier laufen die Anwendungen standardmäßig in der Cloud, können aber bei Bedarf auch lokal betrieben werden. Besonders stark ist OutSystems bei der Erstellung komplexerer Self-Service-Portale, der Integration mit Legacy-Systemen und bei der Umsetzung von Außendienst- oder Instandhaltungs-Apps mit Offline-Funktionalität. Für Organisationen, die bereits bestehende Prozesse ablösen oder modernisieren wollen, ist OutSystems eine sehr leistungsfähige Plattform auch wenn sie etwas technikaffiner wirkt als andere Tools.

Ein weiteres einfacheres, aber auch nicht ganz so leistungsfähiges Tool, mit dem vor allem bestehende Webdienste miteinander verknüpft werden können, ist Zapier als klassischer Vertreter im No-Code-Segment. Zapier wurde 2011 von drei Studenten in Columbia, Missouri (USA) gegründet, um wiederkehrende Aufgaben im Internet automatisieren zu können – ohne Programmierkenntnisse. Das Unternehmen ist bis heute unabhängig, vollständig remote organisiert und gehört zu den bekanntesten No-Code-Automatisierungsplattformen weltweit.

Ein interessantes Grenztool zwischen No-Code und Low-Code ist Appgyver, das inzwischen unter dem Namen SAP Build Apps weitergeführt wird. Diese Plattform ermöglicht es, sehr visuell ansprechende Anwendungen zu bauen – mit mehr Freiheitsgraden im UI-Design als etwa Power Apps. Die Bedienung erfolgt komplett im Browser, die Vorschau kann über mobile Apps auf dem Smartphone getestet werden. Besonders spannend ist Appgyver für Szenarien, bei denen visuelle Nutzerführung im Vordergrund steht. Etwa bei Feedbacksystemen, Scorecards oder Apps zur Unterstützung von Entscheidungsprozessen auf dem Shopfloor. Technisch lässt sich Appgyver an eigene REST-APIs oder an SAP-Systeme anbinden, es ist also auch hier einiges möglich. Allerdings ist die Plattform tendenziell eher etwas für Bastler mit gestalterischer Affinität.

Ein anderer spannender Ansatz zur Prozessautomatisierung kommt von der Plattform Camunda. Hier stehen nicht Apps oder Formulare im Vordergrund, sondern der Geschäftsprozess selbst, der in BPMN 2.0 modelliert werden kann. Die Nutzer erstellen Prozessdiagramme mit Abläufen, Zuständigkeiten und Bedingungen. Diese Modelle können dann direkt z. B. in der Cloud von der Camunda-Engine ausgeführt werden. Die Verbindung zu Services erfolgt über REST-APIs, Tasks können automatisch abgearbeitet oder manuell über sogenannte Task-Listen erledigt werden. Besonders hilfreich ist, dass sich bestehende IT-Systeme über sogenannte „Worker“ integrieren lassen und Code nur dort gebraucht wird, wo es wirklich nötig ist. Für prozessgetriebene Automatisierung mit hoher Transparenz und Governance ist Camunda eine gute Lösung.

Fazit: Die Wahl der passenden Plattform hängt also stark vom Anwendungsfall, dem vorhandenen Ökosystem und der eigenen technischen Affinität ab. Wer bereits in der Microsoft-Welt unterwegs ist, wird mit Power Apps sehr schnell produktiv. Wer dagegen komplexere Anwendungen mit vielen Datenflüssen plant, sollte sich Mendix oder OutSystems anschauen. Und wenn es einfach nur darum geht, schnell und unkompliziert Web-Tools zu verknüpfen, sind Zapier oder Make oft der pragmatischste Einstieg. Wichtig ist in jedem Fall: Die Tools nehmen einem das Denken nicht ab – aber sie helfen dabei, Ideen schneller zur Anwendung zu bringen. Und genau das ist es, worauf es beim KVP ankommt.

Mein Praxisbeispiel: Eine selbst gebaute KVP-App

Als Berater, Trainer und Professor mit dem Schwerpunkt Prozessmanagement wollte ich selbst ausprobieren, wie weit man mit No-/Low-Code kommt. Ausgesucht habe ich mir dazu eine Lösung zur Unterstützung eines Kernprozesses aus dem Lean Management, nämlich eine App, die einen kontinuierlichen Verbesserungsprozess (KVP) unterstützt. Meine Idee war eine App, mit der Vorschläge zur Verbesserung digital erfasst, bewertet und nachverfolgt werden können. Also ein digitales KVP-System für den Shopfloor – intuitiv, transparent und schnell einsetzbar. Als Tool habe ich mich für Microsoft Power Apps entschieden, weil es sich gut mit einer einfach nutzbaren Datenquelle wie SharePoint verbinden lässt (z. B. zur Speicherung der Vorschläge), die Power Plattform mit Power Automate auch eine Automatisierungslösung bietet und die Microsoft-Tools bereits weit verbreitet sind.

Bei der Vorgehensweise habe ich mich an den Grundideen von Lean-Start-up-Prinzip orientiert. Statt Statt umfangreich und langsam im stillen Kämmerlein zu planen wollte ich schnell Ausprobieren, Lernen und Anpassen. Durch eine erste minimal funktionsfähige App-Version (Minimum Viable Product), die ich auch potenziellen Nutzern in meinen Seminaren zeigen kann, möchte ich früh an reale Nutzer gehen um echtes Feedback zu erhalten. Das soll dann direkt in die Weiterentwicklung neuer Funktionalitäten einfließen.

Verstehen, was das Low-Code-Tool kann

Aber ohne Vorkenntnisse musste ich zuerst verstehen, was das Tool grundsätzlich funktioniert. Anhand eines Fachbuchs zu Power Apps habe ich mir einen systematischen Überblick verschafft. So konnte ich die Grundbegriffe wie Steuerelemente, Screens, Variablen, Datenverbindungen und Navigationslogik, die das Fundament der App-Entwicklung bilden, einordnen. Mir ging es darum zu verstehen, welche Möglichkeiten Power Apps bietet, wo die Grenzen liegen und welche Denkweise man sich aneignen muss, um damit zu arbeiten.

Mini-Lastenheft schreiben

Als nächstes habe ich kurz und pragmatisch in einem Mini-Lastenheft notiert, welche Funktionen die App haben soll. Ich habe mit wenigen Bullet-Points grob skizziert, was die App können muss. Das Ergebnis war keine „perfekte“ Anforderungsliste, sondern ein grober Fahrplan. Wichtig waren mir vier Dinge:

• ein einfaches Prozessmodell, wie Einreicher, Bewerter und ggf. Moderator miteinander interagieren,
• ein benutzerfreundliches Formular zur Vorschlagseinreichung,
• eine Bewertungsfunktion mit Statuswechsel (z. B. von „Neu“ zu „in Bearbeitung“ oder „Umgesetzt“) und
• eine Auswertungsmöglichkeit als Grundlage für Kennzahlen (z. B. Vorschläge pro Status).

Das folgende, mit bpmn.io erstellte, Diagramm bildet den Prozessfluss in der App ganz grob ab: Ein Erfasser reicht einen Vorschlag ein. In der App soll er mit weiteren Daten angereichert werden, bevor der ausgewählte Bewerter den Vorschlag bewertet. Je nach Ergebnis der Bewertung geht der Vorschlag zum Erfasser zurück zur Umsetzung und der Dokumentation des Standards oder der Vorschlag wird abgelehnt.

Datengrundlage in SharePoint bauen

Der Kern meiner App ist eine solide Datenstruktur. Deshalb habe ich anschließend in SharePoint meine Datenbank für die Verbesserungsvorschläge erstellt. Darin konnte ich alle nötigen Felder definieren – etwa Vorschlagsbeschreibung, Foto des Ist-Zustands, Einreichungsdatum, zuständiger Bewerter, Kategorie oder Status. Dabei war es, wie sich bei der Erstellung der App noch herausgestellt hat, wichtig die Auswahlfelder korrekt zu konfigurieren. Sonst gibt es Probleme beim Zugriff auf die Daten aus Power Apps oder Power Automate heraus.

Navigation und Branding

Eine App braucht auch eine sinnvolle Benutzerführung und ein einfaches Branding. Die Benutzerführung war ein wenig herausfordernd, aber nach ein wenig ausprobieren stand auch die Startseite und das klickbare Hamburger-Menü. Das Branding und die durchgängige Gestaltung der Screens ist schlicht und orientierte sich an einem einheitlichen Farbschema.

Eingabe- und Ausgabefunktionen bauen

Die Formulare sind modular aufgebaut: ein Formular zur Einreichung von Vorschlägen, ein separates Bewertungselement für Bewerter und eine Übersicht mit Filterfunktionen. Dabei traten einige Probleme auf wie zum Beispiel, dass Kommentare nicht gespeichert wurden, obwohl alle Datenkarten vorhanden waren. Nach ein wenig Ausprobieren konnte ich auch dieses Problem lösen.

In der folgenden Abbildung ist die Abfolge der Screens dargestellt, die die App beinhaltet. Nach dem Home-Screen wird der Vorschlag in ein Formular eingegeben. Im Auswertungs-Screen kann man die neu eingereichten Vorschläge sehen und einen auswählen. Im Bewertungs-Screen kann der ausgewählte Bewerter den Vorschlag dann bewerten. Dort kann dann auch der umgesetzte Standard per Foto dokumentiert werden. Und schließlich bietet der Auswertungs-Screen die Möglichkeit alle Vorschläge nach ihrem Status auszuwerten.

Bestätigungsmail mit Power Automate

Zum Schluss habe ich noch einen kleinen automatischen Workflow mit Power Automate eingerichtet. Der Flow generiert immer dann eine Mail wenn ein neuer Vorschlag in SharePoint eingeht. So wird sichergestellt, dass kein Vorschlag unbeachtet bleibt. Die Verbindung zwischen SharePoint, Flow und E-Mail funktionierte bei einigen Tests zuverlässig.

Künstliche Intelligenz als Entwicklungspartner – wie ChatGPT mich beim App-Bau begleitet hat

Beim Bau meiner KVP-App habe ich neben einem Power-Apps-Fachbuch auch auf Künstliche Intelligent (KI) zurückgegriffen. Ich wollte ja ausprobieren, wie weit ich ohne klassische Programmiererfahrung mit einer Low-Code-Plattform komme und wie eine KI mir dabei helfen kann, typische Hürden zu überwinden. Wie beschrieben, habe ich zunächst mit Hilfe eines Fachbuchs die grundlegenden Konzepte von Power Apps erschlossen. Als ich anschließend ein Mini-Lastenheft formulierte, tauchten schon die ersten Herausforderungen für mich als „Neu-App-Entwickler“ auf: Welche Steuerelemente brauche ich für die Bewertung? Wie soll die Navigation zwischen den einzelnen Stufen eines Verbesserungsvorschlags funktionieren? Aber auch später wenn bei der Erstellung Dinge nicht so wie geplant funktionierten, war KI in Form von ChatGPT ein hilfreicher Coach.

Ich habe ganz konkret gefragt: Wie baue ich ein Rollenmodell in Power Apps auf? – oder: Warum wird mein Kommentar im Formular nicht gespeichert, obwohl alle anderen Felder übernommen werden? Bei den Antworten lernte ich, dass es hilft, viel Kontext mitzugeben, um eine bessere Lösung zu finden. Oft wollte ich auch eine Erklärung haben, um zu verstehen, was falsch war und wie man es richtig macht. Auch habe ich konkrete Codebeispiele bekommen, die ich einfach einfügen konnte. Wenn etwas nicht funktionierte, habe ich den Code dann Schritt-für-Schritt auf Basis von Hinweisen auf die Ursache und eine bessere Lösung angepasst. Besonders hilfreich war ChatGPT, wenn ich zwar wusste, was ich wollte – aber nicht genau, wie ich das in dem Tool umsetzen kann. Ein Beispiel ist der Sichtbarkeitssteuerung in Abhängigkeit vom Benutzerstatus. Hier war die KI eine Art kontinuierlicher Sparringspartner.

ChatGPT konnte dabei auch gut mit Fragen umgehen, wie sie mir gerade durch den Kopf gingen. Oft eher pragmatisch als technisch präzise. Ich bekam dann Antworten, die dann an mein Wissensniveau angepasst waren. Gerade im KVP-Kontext, wo man oft iterativ und mit begrenzten Ressourcen arbeitet, war das extrem wertvoll. Natürlich hat die KI nicht alles automatisch und sofort gelöst, aber sie hat mir geholfen, schneller zu lernen, typische Fehler zu vermeiden und die gewünschten Funktionalitäten umzusetzen. Meine Erkenntnis war, dass KI wie ChatGPT die menschliche Kreativität und Prozesskenntnis so ergänzt, dass aus Ideen schneller funktionierende Anwendungen werden.

Und noch ein Punkt wurde während der Erstellung für mich deutlich: Die Plus-Version von ChatGPT war gegenüber der Basis-Variante sehr hilfreich. Nicht nur, weil sie auf dem leistungsfähigeren GPT-4-Modell basiert, sondern weil sie in der Interaktion präziser, strukturierter und konsistenter antwortete. Gerade bei komplexeren Problemstellungen hatte ich den Eindruck, dass GPT-4 konkrete Lösungsvorschläge machte, die auch gut erklärt waren. GPT-4 agierte eher wie ein Gesprächspartner, der auf Basis der Inputs „mitdenkt“.

Ein weiterer Vorteil der Plus-Version: Die Möglichkeit, auch Screenshots oder Bilder hochzuladen und analysieren zu lassen. In der App-Entwicklung kommt es häufig vor, dass man einfach mal zeigen will, was gerade nicht funktioniert – z. B. ein fehlerhaftes Formular, ein falsch verknüpftes Steuerelement oder eine missverständliche Fehlermeldung. In der Basis-Version ist diese Funktion gar nicht verfügbar oder stark eingeschränkt. Mit GPT-4 konnte ich direkt Screenshots meiner Power-Apps-Oberfläche hochladen und bekam konkrete Hinweise, wo das Problem liegt. Es waren zwar manchmal einige Iterationsschritte nötig, aber es hat am Ende zu einem funktionierenden Tool geführt.

Interview Hannah Michel

Es freut mich, dass ich mit Hannah Michel für einen Praxisbericht zu Low-Code gewinnen konnte. Unsere Wege kreuzten sich vor zehn Jahren als sie Studentin im Studiengang European Business (heute International Business Management) an der OTH Regensburg war. Ihre Leidenschaft für Logistik und Prozesse zeigte sich schnell und ich betreute ihre Abschlussarbeit zu Lean Management im Gesundheitswesen. Nach ihrem Masterstudium in Supply Chain Management und Logistik sowie fünf Jahren in der IT-Beratung bei einem globalen Tech-Konzern, arbeitet sie heute als Unternehmensberaterin bei einem big4-Unternehmen. Ihr Schwerpunkt liegt dabei auf Modernisierungs- und Digitalisierungsprojekten im öffentlichen Sektor. Seit mehreren Jahren setzt sie dabei auch auf Low-Code-Ansätze zur Modernisierung von IT-Systemen.

TL: Nicht jedem ist der Begriff Low-/No-Code geläufig. Vielleicht kannst du den Begriff kurz einordnen und erzählen, wie du selbst Zugang zu dem Thema gefunden hast?

Na klar. High-Code bedeutet, dass du alles von Grund auf selbst programmierst, was dir mehr Kontrolle über die Details gibt, aber auch mehr Aufwand erfordert. Bei Low-Code/No-Code kannst du hingegen vorgefertigte Bausteine nutzen, um schnell Lösungen zu erstellen, ohne viel Code zu schreiben. Ich spreche meistens von Low-Code, weil die meisten Aufgaben und auch Plattformen trotzdem etwas Programmieren erfordern, während No-Code das ausschließt. 

Ursprünglich kam ich aus der Steuerung von High-Code-Projekten und stieß dann zufällig auf den Low-Code-Anbieter Pega. Ich habe mich damit beschäftigt, mein Netzwerk in dem Themenfeld erweitert, mich mit Gleichgesinnten zusammengetan und dabei schnell die Vorteile von Low-Code für mich entdeckt – und diese Begeisterung hält bis heute an.

TL: Danke Hannah, lass uns doch ein wenig mehr in die Details einsteigen: Viele kleine und mittlere Unternehmen kämpfen mit aufwendigen Abläufen und bürokratischen Anforderungen. Gleichzeitig können umfassende Software-Lösungen oft nicht eingesetzt werden, weil die Investitionsmittel nicht ganz so locker sitzen. Können flexible Low-/No-Code-Lösungen hier eine Alternative sein? Wenn ja, was sind erfahrungsgemäß die Bereiche mit Quick-Win-Potenzial?

HM: Ja, Low-/No-Code-Lösungen bieten in diesem Kontext auf jeden Fall eine Alternative. Sie sind häufig kostengünstig, schnell implementierbar und können oft ohne tiefgreifende IT-Kenntnisse von den Fachbereichen mitgestaltet werden. Low Code ist aber mit Sicherheit keine Wunderwaffe und auch nicht immer die richtige Wahl. Bereiche mit besonders hohem Quick-Win-Potenzial sind typischerweise Prozessautomatisierung (Stichwort „Workflow-Engine“), Datenmanagement (z.B. über visuelle Konnektoren Kundendaten aus unterschiedlichen Quellen zusammenführen und Dubletten automatisch bereinigen), IT-Service Management (also ITSM) und Customer Relationship Management (z.B. per Drag-and-Drop-Regeln Leads qualifizieren, Datensätze anlegen und automatisch Mails auslösen). Aber Vorsicht: Pauschalisieren kann und will ich das nicht, weil das sehr abhängig von den Bedarfen des Unternehmens und der daraus resultierenden Plattform ist.

TL: Hast Du ein konkretes Beispiel für eine richtige Success-Story, wo Low-/No-Code erstaunlich schnell einen großen Mehrwert geschaffen hat?

HM: Ein tolles, medienwirksames Beispiel ist die digitale Antragsbearbeitung für die Corona-Soforthilfe durch das Bayerische Wirtschaftsministerium im Zuge der COVID-19 Pandemie. Zu dem Zeitpunkt als diese Umsetzung stattfand, wusste ich noch nicht mal was Low-Code wirklich bedeutet. Dank Low-Code-Technologie konnte in nur wenigen Tagen ein vollständig digitaler Prozess aufgesetzt werden, der es ermöglichte, über 300.000 Anträge schnell und effizient zu bearbeiten. Innerhalb von wenigen Wochen wurden finanzielle Hilfen in Höhe von mehreren Milliarden Euro ausgezahlt. 

TL: Ein weiterer Grund für Low-/No-Code ist ja, dass die Fachbereiche selbst gestalten können und man die Ressourcen aus der IT nicht bzw. nicht so umfangreich in Anspruch nehmen muss. Wie schnell kann man denn mit Low-/No-Code eine funktionierende aber gleichzeitig sichere und gute Lösung auf die Beine stellen?

HM: Klassisch Beraterin … es kommt ganz drauf an [lacht] – auf Umfang und Komplexität. Im Allgemeinen lässt sich eine erste Version einer Lösung meist in wenigen Tagen erstellen, besonders wenn der Fachbereich die Anforderungen bereits gut kennt. Es gibt jedoch viele Dinge, die man vorab beachten sollte, die meist Zeitaufwand mit sich bringen. Ein Beispiel: Will ich meine Low-Code Lösung selbst betreiben oder nutze ich einen Cloud-Dienst, denn bei den vielen Anbietern von Low-Code Plattformen ist fast jedes Betriebsmodell in Summe denkbar. Beide Antworten bedeuten, dass ich mich mit Folgefragen auseinandersetzen muss, die ein Go-Live-Datum maßgeblich nach hinten schieben können. Ich könnte hier eine Vielzahl an weiteren Fragestellungen nennen. Ganz abgesehen davon gilt das gleiche Prinzip wie bei jeder anderen Lösung – High oder Low Code: Eine erste Version kann schnell live gehen, aber iteratives Testen und Optimieren sind essenziell, um eine Lösung sowohl funktional als auch sicher auf langfristige Nutzung auszurichten.

TL: Ganz ohne IT wird es also nicht gehen, oder? Wie habe ich mir das vorzustellen und wie klappt das in der Praxis?

HM: Ganz ohne IT wird es nicht gehen, nein. Aber der Aufwand ist geringer und anders gelagert. Die IT-Abteilung wird vor allem bei der Auswahl und Integration von Tools herangezogen, z.B. bei der Sicherstellung der Systemkompatibilität. Die Fachabteilungen können viel mehr „Entwicklungsarbeit“ leisten – sie entwickeln bzw. entwickeln mit, testen und passen die Lösungen im eigenen Verantwortungsbereich an. Es ist wichtig, dass beide Seiten eng zusammenarbeiten, um optimale Ergebnisse zu erzielen und es ist essenziell bei der Systemintegration ein ordentliches Change-Management zu betreiben und als Teil davon die Schulung der Fachbereiche sicherzustellen und Aufwand dafür einzuplanen.

TL: Gibt es ansonsten noch weitere Stolperfallen oder versteckte Aufwände, die zu berücksichtigen sind?

HM: Ja, auf jeden Fall. Sonst wäre mein Job als Beraterin auch vermutlich nicht existent [lacht]. Neben der Schulung der Nutzenden, gibt es bei der Einführung eine Vielzahl an Dingen zu beachten – von der Governance bis hin zur Planung einer Verteilung der laufenden, teilweise variablen Kosten (Betrieb, Wartung, Lizenzen usw. …). Ein häufiger Stolperstein ist nach der Initialisierung aber auch die Pflege der Lösung. Auch wenn Low- Code-Plattformen relativ einfach zu nutzen sind, können sich mit der Zeit die Anforderungen ändern. Das kann dazu führen, dass eine scheinbar einfache Lösung plötzlich schwieriger zu verwalten wird. Und natürlich gibt es im Sinne der Weiterentwicklung immer die Herausforderung der Skalierbarkeit, wenn ein Unternehmen wächst oder Systemgrenzen verschoben werden sollen.

TL: Stichwort Skalierbarkeit: Wann stoße ich mit Low-Code an Grenzen?

HM: Viele denken, die größten Grenzen von Low-Code-Lösungen treten dann auf, wenn das Unternehmen deutlich wächst und die Anforderungen komplexer werden und im Zuge dessen die Nutzendenzahlen steigen oder Datenmengen wachsen. Das ist definitiv eine Herausforderung. Auch sehr spezifische Integrationen mit bestehenden IT-Systemen können mit Low-Code-Lösungen schwierig werden. Hier ist dann oft ein Schritt zu individuell entwickelten Lösungen notwendig, aber das ist wirklich sehr abhängig von der Gewählten Low-Code-Plattform und den integrierten Standardschnittstellen. 

Ich persönlich sehe die größten Schwierigkeiten bei der Skalierung auf der kommunikativen Ebene. Ganz explizit dann, wenn eine Wiederverwendbarkeit von Elementen dadurch verhindert wird, dass über die bisherigen Grenzen eines Systems hinaus die Kommunikation zwischen den technischen und fachlichen Verantwortlichen ausbleibt. Da geht viel Potenzial verloren, im schlimmsten Fall führt es dazu, dass das System nicht nur ineffizient ist, sondern an einigen Stellen dann eben gar nicht genutzt wird. 

TL: Wenn jetzt jemand auf den Geschmack gekommen ist und morgen selbst mit Low-/No-Code starten möchte – welchen Tipp würdest Du dieser Person als allererstes mitgeben?

HM: Der wichtigste Tipp ist: Fang klein an – bzw. fang überhaupt an! Wähle eine überschaubare Aufgabe oder ein kleines Projekt, um dich mit einer Plattform vertraut zu machen. Es ist leicht, sich von der Vielzahl an Anbietern überwältigen zu lassen. Ich würde mich anfangs nicht sofort auf eine Plattform festlegen, sondern mir erstmal einen groben Überblick verschaffen. Dazu gehört auch, die Schwerpunkte der verschiedenen Plattformen zu kennen. Wenn ich dann das Gefühl habe, Low-Code passt zu mir, meiner Unternehmensstrategie und den Herausforderungen, die ich habe, starte ich mit einem klassischen Projekt, hole Experten dazu und gehe Schritt für Schritt vor, um die Anforderungen zu konkretisieren und die richtige Plattform zu finden. Wichtig ist, aus den ersten Projekten zu lernen und Feedback-Schleifen im Team einzuplanen, um frühzeitig Schwachstellen zu erkennen.

TL: Und zum Schluss noch eine persönliche Frage. Ich habe mal gehört, dass Low-/No-Code so etwas wie LEGO für Prozesse wäre – wie viel Spaß macht es Dir, damit zu arbeiten?

HM: Ich liebe es – ich arbeite täglich so viele Stunden in dem Themenfeld und habe mir gerade zu Anfang vieles selbst erarbeitet. Das geht ganz ohne eine gewisse Leidenschaft für das Thema und bestimmte Plattformen nicht. Erst kürzlich habe ich mich endlich in der Plattform Pega zertifizieren lassen und wieder gemerkt, wie viel Freude mir das Arbeiten mit der Plattform bereitet. Der Spaß kommt definitiv daher, dass man sehr schnell Ergebnisse sieht und gleichzeitig die Kontrolle über den gesamten Prozess hat. Und genauso wie bei LEGO gibt es immer wieder neue „Herausforderungen“, die es zu meistern gilt – das macht es spannend und motivierend!

Hannah zeigte mir dann noch ein Beispiel bei dem Sie das Tool Pega Blueprint™ genutzt hat. Es ist kostenfrei über folgenden Link aufzurufen: https://www.pega.com/blueprint/dashboard. Innerhalb von wenigen Minuten hat sie online eine Demo erstellt, welche dann auch schnell in ein Live System überführbar wäre. Sie betonte, dass nicht jede Plattform gleich aussähe, aber hier schon gut erkennbare sei, was mit Funktionsbausteinen der Low Code Plattform gemeint sei. Jeder Workflow hat mehrere Phasen, die wiederum Schritte beinhalten. Jeder Schritt entspricht in der finalen Anwendung einer Aktion. Diese kann beispielsweise eine Dateneingabe sein, eine Automatisierung, eine Genehmigung oder eine Entscheidung.

Mein Fazit (mit Bezug zu KVP)

In Summe schätze ich, dass ich nach der Lektüre netto etwa drei Personentage an der App gebaut habe. Und das nur mit einem relativ klaren Verständnis davon, was die App können soll, ein wenig logischem und strukturierten Denken für die Iterationsschritte in der Umsetzung und tatsächlich relativ wenig Code. Mein persönliches Fazit ist deshalb, dass No-/Low-Code-Tools in Kombination mit künstlicher Intelligenz sehr viele Möglichkeiten für einfache und effektive Prozessautomatisierungen bieten.

Ohne auf IT-Ressourcen warten zu müssen, können die gewünschten Funktionalitäten relativ einfach in funktionierende technische Lösungen übersetzt werden. Eine wichtige Voraussetzung ist jedoch, den Bedarf der späteren Nutzer zu verstehen und einschätzen zu können, wie das am einfachsten umzusetzen ist. Insofern kann die KI das Denken und die Kreativität sicherlich nicht komplett übernehmen. Schließlich macht es auch sehr viel Sinn, einen Profi noch einmal über die Lösungen sehen zu lassen und diese beispielsweise auf Sicherheitsaspekte zu überprüfen.

Und um auch noch die Brücke zu KVP zu schlagen: Mit Low- und No-Code und KI-Unterstützung können Lean- oder Prozessverantwortliche ihre Ideen heute selbst in kleinen Schritten selbst umsetzen und nach und nach weiter entwickeln und dabei lernen. Genau das ist im Sinne von KVP: Nicht auf Freigaben warten, sondern selbst machen und nicht nur konfektionieren, sondern auch eigene Prototypen bauen.