Jeder Pitch für Low-Code-Workflow-Automatisierung setzt auf denselben Aspekt: Geschwindigkeit. Schnellere Erstellung, schnellere Bereitstellung – einfach alles schneller.
Es stimmt, dass Geschwindigkeit hilft, aber sie entscheidet nicht darüber, ob ein Workflow sein erstes Jahr überlebt. Entscheidend ist vielmehr die Frage der Zuständigkeit: Wer ist für die zugrundeliegende Logik verantwortlich, und was geschieht, wenn diese Person das Team verlässt, befördert wird oder einfach zwei Wochen im Urlaub ist? Ein Workflow, der heute schnell ausgeführt wird, aber nur im Kopf einer Person existiert, ist nicht automatisiert. Er ist zwar schnell, aber nicht beständig – und genau das ist ein Problem.
Diese Lücke zwischen Geschwindigkeit und Beständigkeit zeigt sich verständlicherweise selten in einer Produktdemo, da dies nicht gerade ein Verkaufsargument für ein Tool ist. In der Praxis tritt das Problem meist erst nach etwa acht Monaten zutage, wenn die Person, die den Workflow erstellt hat, abwesend ist oder nicht mehr im Unternehmen, doch der Bericht, der auf diesem Workflow basiert, am Montagmorgen vorliegen muss. In diesem Moment feiert niemand mehr die ursprüngliche Schnelligkeit der Entwicklung.
Dieser Artikel beleuchtet fünf Bereiche, in denen Geschwindigkeit und Beständigkeit auseinanderklaffen, angefangen bei dem Versprechen der Schnelligkeit selbst.
Warum Geschwindigkeit nicht der einzige Grund ist, warum Low-Code wichtig ist
Geschwindigkeit ist zweifellos ein echter Vorteil von Low-Code, aber wenn sie als alleiniges Ziel verfolgt wird, erhält man lediglich eine schnellere Tabellenkalkulation und keine dauerhafte Workflow-Automatisierung.
Unternehmen setzen massiv auf Geschwindigkeit, und die Marktzahlen bestätigen dies. Gartner prognostiziert, dass der Markt für Low-Code-Entwicklungstechnologien bis 2029 ein Volumen von 58,2 Milliarden USD erreichen wird, was einem jährlichen Wachstum von 14,1 % entspricht, da agentenbasierte KI und Citizen Development die Annahme weiter vorantreiben. Das sagt jedoch nichts darüber aus, ob das, was sie entwickeln, auch langfristig Bestand hat.
Und genau hier spielt der Unterschied zwischen Akzeptanz und Beständigkeit eine entscheidende Rolle. Ein Workflow, der schnell zu erstellen und einfach zu übergeben ist, wird jeden Monat wertvoller, da auch jemand anderes als der/die ursprüngliche Ersteller:in ihn übernehmen und weiter verbessern kann. Ein Workflow, der lediglich schnell zu erstellen ist, wird hingegen jeden Monat riskanter, da außer dem/der Ersteller:in niemand wirklich weiß, was darin vor sich geht. Genau diese Verwechslung ist der Fehler, der der Low-Code-Vermarktung oft unterläuft.
Ein Analyst erstellt beispielsweise an einem Nachmittag eine Lösung. Sie funktioniert und wird still und leise zu einer unverzichtbaren Komponente. Sechs Monate später traut sich niemand mehr, Änderungen daran vorzunehmen. Dieses Muster findet sich in fast jedem Analyseteam, und wahrscheinlich haben Sie es selbst schon einmal miterlebt.
Keines dieser Muster ist ein spezifisches Low-Code-Problem, aber die Geschwindigkeit von Low-Code macht es einfacher, diesen Zustand schneller und mit weniger Überprüfung zu erreichen, als es bei einem manuell programmierten Prozess jemals der Fall wäre.
Stellen Sie sich zwei Workflows vor, die in derselben Woche erstellt wurden und beide dasselbe Problem lösen. Der erste wird schnell erstellt und bleibt genauso schnell wie am Tag seiner Bereitstellung, ohne Dokumentation und ohne klar benannten Verantwortlichen außer demjenigen, der ihn geschrieben hat – das Workflow-Äquivalent einer unbeschrifteten Tür, die niemand öffnen möchte. Der zweite benötigt etwas länger für die Fertigstellung, da er über eine dokumentierte Struktur und einen klaren Übergabepunkt verfügt.
Ein Jahr später bleibt der erste Workflow unberührt, weil eine Aktualisierung als riskant empfunden wird. Der zweite Workflow wurde bereits vier- oder fünfmal von verschiedenen Personen angepasst, weil eine Aktualisierung als sicher gilt.
Die Erstellungsgeschwindigkeit für die beiden Workflows war nahezu identisch, doch der Wert, den sie über einen Zeitraum von zwölf Monaten lieferten, unterschied sich erheblich.
Code-frei oder Code-freundlich war nie eine dauerhafte Entscheidung
Eine manuelle Fehlerbehebung wird zu einem skriptbasierten Schritt. Ein skriptbasierter Schritt wird zu einem gemeinsam genutzten, wiederverwendbaren Teil, auf den andere Workflows zugreifen. Diese Entwicklung ist der eigentliche Lebenszyklus, auch wenn die meisten Inhalte der Anbieter „Code-frei“ versus „Code-freundlich“ als einmalige Entscheidung beim Kauf behandeln.
Käufer:innen entscheiden sich teilweise für Low-Code, um nicht an eine starre Methode der Entwicklung gebunden zu sein, aber diese Entscheidung bereits bei der Beschaffung festzulegen, kann sich als nachteilig erweisen. Setzt man zu stark auf „Code-frei“, wird der erste Sonderfall, den die Benutzeroberfläche nicht bewältigen kann, durch einen außerhalb der Plattform implementierten Workaround gelöst. Setzt man hingegen zu stark auf „Code-first“, verbringt das Team Monate damit, Funktionen zu entwickeln, die ein kontrollierter Arbeitsbereich nativ abgedeckt hätte – und übernimmt obendrein den Wartungsaufwand, der durch Low-Code eigentlich hätte vermieden werden sollen.
Die wichtigere Frage lautet: Lässt sich in einem Workflow ein Drag & Drop-Schritt mit einer Zeile SQL oder Python kombinieren, ohne dass bei jeder Anforderungsänderung alles neu aufgebaut werden muss? Diese Fähigkeit ist entscheidender als die Bezeichnung „Code-frei“ oder „Code-freundlich“, da die Anforderungen an einen Workflow selten dauerhaft gleich bleiben. Eine Drag & Drop-Verknüpfung, die bei der Einführung einwandfrei funktioniert, benötigt möglicherweise sechs Monate später einen benutzerdefinierten Regex-Schritt, nachdem ein Quellsystem ein Feld sendet, das nun anders formatiert ist als zuvor.
Wenn die Plattform nur Drag & Drop unterstützt, wird dieser Regex-Schritt woanders erstellt, in einem Skript, das nur die Person kennt, die es geschrieben hat. Der Workflow „funktioniert“ zwar noch, aber die Logik, auf die es wirklich ankommt, hat sich still und heimlich aus dem System verlagert, das sie eigentlich steuern sollte.
Gibt es in Ihrem Team einen Workflow, der derzeit feststeckt, speziell weil diese Entweder-oder-Entscheidung zu früh getroffen wurde und sie seitdem niemand mehr überprüft hat?
Die Einschränkung von Citizen Development führt unweigerlich zu Schatten-IT
Wenn Sie Citizen Development unterbinden, um die Kontrolle zu behalten, stehen Sie wahrscheinlich vor folgendem Problem: Sie erhalten in der Regel mehr Schatten-IT, nicht weniger. Dieses Paradoxon entsteht, weil der Bedarf an Automatisierung nicht einfach verschwindet, wenn der Zugang blockiert wird. Er verlagert sich lediglich auf das Tool, das sich am einfachsten ohne Genehmigung nutzen lässt. Und das ist selten das Tool, das man gezielt ausgewählt hätte.
Untersuchungen von Forrester zu Citizen Development haben ergeben, dass mindestens zwei Drittel der Unternehmen bereits über eine formelle Strategie für Citizen Development verfügen oder planen, eine solche innerhalb der nächsten 12 Monate zu entwickeln. Forrester hat drei Ansätze für eine verantwortungsvolle Skalierung aufgezeigt:
- Privateer: Ein kleines, autonomes Team, das in einen Geschäftsbereich eingebettet ist.
- Democracy: Ein weitgehend offenes Modell, das allen zugänglich ist, jedoch mit definierten Leitplanken für die Entwicklung.
- Federation: Ein Hybridmodell, das beide Ansätze kombiniert, mit zentralen Standards und verteilter Erstellung.
Der beste Weg, Citizen Development zu steuern, besteht darin, die Governance-Struktur aufzubauen, bevor der Bedarf ihr davonläuft, anstatt im Nachhinein hektisch nachbessern zu müssen.
Bevor man jedoch eine solche Struktur aufbauen kann, muss geklärt werden, wer die eigentliche Entwicklungsarbeit leistet. Untersuchungen des MIT zum Citizen Development unterscheiden dabei drei verschiedene Rollen:
- Citizen Developer erstellen Anwendungen.
- Citizen Automators konfigurieren Automatisierungen zwischen Systemen, die nicht nativ miteinander kommunizieren.
- Citizen Data Scientists erstellen die Modelle und Dashboards.
Jede dieser Rollen erfordert eine andere Art der Aufsicht, und sie alle unter dem Begriff „Citizen Development“ zusammenzufassen, verschleiert lediglich diese Unterscheidung.
Ziel ist es nicht, dass weniger Menschen Workflows erstellen. Es geht darum, dass sie innerhalb eines Systems arbeiten, das die Arbeit sichtbar und überprüfbar macht. Self-Service Analytics ist ein hervorragendes Beispiel dafür, wie dieselbe Idee in der Praxis funktioniert: Als die IT diesen Ansatz nicht mehr als Bedrohung, sondern als Chance zur Gestaltung benutzerfreundlicher Lösungen begriff, nahm die Verbreitung rasant zu.
Ehrlich gesagt wurde die Frage „Sollten Data Analysts ihre eigene Arbeit automatisieren dürfen?“ schon vor langer Zeit beantwortet, als das erste Mal jemand ein Makro schrieb, nur um sich einen Nachmittag Arbeit zu sparen. Diese Frage ist also nicht mehr wirklich das Gespräch, das die IT führen sollte.
Das eigentliche Gespräch dreht sich darum, wo die Leitplanken gesetzt werden, welche Workflows einen dokumentierten Verantwortlichen und einen Prüfschritt benötigen, bevor sie Finanzdaten berühren, und welche so risikoarm sind, dass ein Citizen Automator sie direkt umsetzen kann, ohne auf die Bearbeitung eines Tickets warten zu müssen. Wer diese Diskussion ausklammert, erreicht nicht weniger Citizen Development. Am Ende gibt es genauso viel davon. Nur ist es für die IT nicht mehr sichtbar.
Eine Checkliste für Gespräche mit Low-Code-Anbietern
Die folgenden vier Fragen eignen sich hervorragend für jedes Anbietergespräch, unabhängig davon, welche Plattform Sie gerade evaluieren:
- Lässt sich die Logik eines Workflows auf dem Spektrum von Code-free bis Code-freundlich verschieben, ohne dass eine Neuentwicklung erforderlich ist?
- Ist Citizen Development innerhalb der Plattform gesteuert und sichtbar oder lediglich erlaubt und unüberwacht?
- Werden Workflows als wiederverwendbare, dokumentierte Komponenten erstellt oder als einmalige Skripte, die niemand sonst sicher öffnen kann?
- Unterstützt die Plattform eine kontinuierliche Iteration bei sich ändernden Anforderungen oder nur die Erstbereitstellung?
Low-Code scheitert, wenn nichts wiederverwendet wird
Was den Erfolg einer Low-Code-Implementierung bestimmt, läuft fast immer auf die Wiederverwendbarkeit hinaus: Wurde der Workflow so erstellt, dass er wieder aufgegriffen werden kann, oder wurde er erstellt, um in dem Moment vergessen zu werden, in dem er funktioniert?
Ein Beispiel hierfür ist die Arbeitsweise eines Beschaffungsteams, das Unstimmigkeiten zwischen Bestellungen und Lieferantenrechnungen abgleicht. Oft erstellt ein Teammitglied ein persönliches Excel-Makro, das Abweichungen beim Rechnungsbetrag markiert. Da es meist hinreichend gut funktioniert, hinterfragt es jahrelang niemand, was im Raum-Zeit-Kontinuum von Büro-Makros einer Ewigkeit gleichkommt.
Solche Makros erfassen zwar meist die meisten Fehlerarten zuverlässig – etwa sieben von neun –, übersehen jedoch jene Sonderfälle, an die bei der Erstellung niemand gedacht hat. Ein Beispiel hierfür sind unterschiedliche Formate der Bestellnummer im ERP-System und auf der Rechnungs-PDF – eine Eigenheit, die oft von der spezifischen Dokumentengestaltung bestimmter Lieferanten herrührt. Genau solche Lücken führen häufig zu Beanstandungen bei SOX-Audits.
Wenn Sie jemals die Tabellenkalkulation einer anderen Person übernommen haben, wird Ihnen dieses Szenario bekannt vorkommen. Der zuständige Analyst ist abwesend, und der Rückstand bei der Bearbeitung von Unstimmigkeiten wächst über Wochen unbemerkt an. Niemand sonst im Team wusste von der Existenz des Makros, geschweige denn, wie man es öffnet.
Erst ein solcher Ausfall veranlasst das Team meist dazu, die Abgleichslogik grundlegend neu zu gestalten, als dokumentierte, wiederverwendbare Workflow-Komponente mit eigenem Zeitplan und Auslöser, die auch jene Sonderfälle berücksichtigt, die das ursprüngliche Makro übersehen hatte.
Dabei geht es nicht darum, schneller zu bauen. Es geht darum, etwas aufzubauen, das nicht davon abhängt, dass eine Person sich daran erinnert, dass es existiert. Dies ist für einen Stakeholder aus der Finanzabteilung oder Wirtschaftsprüfung genauso wichtig wie für das Team.
Hier ist ein Beispiel für eine wiederverwendbare Komponente, in diesem Fall ein Makro, das in Alteryx erstellt wurde:
| Vorher: Persönliches Makro | Nachher: Wiederverwendbare Komponente | |
|---|---|---|
| Eigentümer | Ein/e Analyst:in, nicht dokumentiert | Geteilt, dokumentiert, für das ganze Team zugänglich |
| Abdeckung von Ausnahmen | 7 von 9 Typen | Alle 9, einschließlich der Abweichung bei der Bestellnummer |
| Zeitaufwand für die Abstimmung | Manuelle Bearbeitung über mehrere Tage | Liste der Ausnahmen am selben Tag |
| Wiederverwendung über Kategorien hinweg | Keine; jedes Mal von Grund auf neu erstellt | Für zwei weitere Ausgabenkategorien wiederverwendet, ohne erneute Erstellung |
Wenn das nach der Situation Ihres Teams klingt, lohnt es sich, den aktuellen Stand Ihres eigenen Workflows auf den Prüfstand zu stellen, bevor Sie sich für einen Anbieter entscheiden. Von Tabellenblättern zu Workflows zeigt anhand konkreter Beispiele, wie der Wechsel von Tabellenkalkulationen, die nur von einer Person gepflegt werden, zu wiederverwendbaren und dokumentierten Workflows in der Praxis aussieht.
Automatisierung endet nicht bei der Bereitstellung
Ein Workflow, der einmal automatisiert und nie wieder überprüft wird, verschlechtert sich auf die gleiche Weise wie eine ungepflegte Tabelle, nur weniger sichtbar. Die Probleme treten oft erst später zutage, etwa durch Feststellungen bei einer Prüfung oder durch Zahlenwerte, die schleichend nicht mehr der Realität entsprechen.
Die Idee der wiederverwendbaren Komponente aus dem Beschaffungsbeispiel zahlt sich auch hier wieder aus. Aktualisieren Sie die gemeinsam genutzte Abgleichskomponente einmalig – etwa wenn sich ein Anbieter ändert oder ein Schwellenwert verschiebt – und jeder darauf basierende Workflow wird automatisch aktualisiert. Niemand muss ein Dutzend Kopien aufspüren und diese einzeln korrigieren, da von Anfang an nur eine einzige Kopie vorhanden ist.
KI-Assistenten mit natürlicher Sprachverarbeitung halten auch hier Einzug, und es lohnt sich, sich darüber im Klaren zu sein, was sie tatsächlich tun. Ask Alteryx ist ein gutes Beispiel. Es unterstützt Teams dabei, bestehende, kontrollierte Workflows mittels natürlicher Sprache abzufragen oder zu aktualisieren, ersetzt jedoch nicht die zugrundeliegende, geregelte Struktur. Betrachten Sie das Tool als Assistenten, nicht als Architekten – es handelt sich um zwei unterschiedliche Rollen, die man bei der Bewertung eines Tools klar voneinander unterscheiden sollte.
Die Checkliste, geprüft anhand von Alteryx One
Hier sehen Sie, wie Alteryx im Vergleich zu der zuvor besprochenen Anbieterbewertung abschneidet.
| Frage | Wie Alteryx One die Anforderung erfüllt |
|---|---|
| Lässt sich die Logik auf dem Spektrum zwischen „Code-frei“ und „Code-freundlich“ verschieben, ohne dass eine Neuentwicklung erforderlich ist? | Workflows kombinieren Drag & Drop-Schritte mit nativem Python und SQL auf demselben Arbeitsbereich, sodass ein Team bei der Beschaffung nicht auf ein Ende des Spektrums festgelegt ist. |
| Ist Citizen Development gesteuert und sichtbar, oder nur gestattet? | Rollenbasierter Zugriff und Versionsverlauf geben der IT die nötige Transparenz, damit Data Analysts entwickeln können, ohne den Überblick über die bereits erstellten Versionen zu verlieren. |
| Sind Workflows wiederverwendbare Komponenten oder einmalige Skripte? | Makros und Analyse-Apps werden einmalig als dokumentierte, wiederverwendbare Komponenten erstellt – nach demselben Muster, das den Abstimmungsprozess des Beschaffungsteams in eine gemeinsam genutzte Infrastruktur verwandelt hat. |
| Unterstützt die Plattform nicht nur die anfängliche Bereitstellung, sondern auch fortlaufende Iterationen? | Copilot unterstützt Teams dabei, bestehende Workflows in natürlicher Sprache abzufragen und zu aktualisieren – aufbauend auf der bereits vorhandenen, kontrollierten Struktur. |
Erste Schritte mit Low-Code-Workflow-Automatisierung
Wenn Sie noch die Details abwägen, bieten die Automatisierung wiederkehrender Analysten-Workflows und ein formales Bewertungs-Framework tiefergehende Einblicke in diese Thematik, als dieser Artikel bieten kann.
Sie müssen aber nicht alles lesen oder eine komplette Plattform einführen, bevor Sie beginnen. Wählen Sie einen wiederkehrenden Bericht oder einen manuellen Abgleichprozess aus – die Art von Prozess, die wahrscheinlich noch in der persönlichen Tabellenkalkulation von jemandem existiert – und bauen Sie nur diesen Teil als geregelte, wiederverwendbare Komponente neu auf. Schauen Sie, wie es läuft, bevor Sie entscheiden, ob sich die Migration des restlichen Katalogs lohnt.
Die wichtigste Erkenntnis ist: Low-Code-Workflow-Automatisierung bewährt sich durch ihre Zuverlässigkeit und Langlebigkeit, nicht nur durch die Geschwindigkeit der ersten Implementierung. Alteryx One wurde genau mit diesem Ziel entwickelt, und eine kostenlose Testversion ist der schnellste Weg, um herauszufinden, ob es Ihren eigenen Workflow unterstützt.