No-Code oder individuelle Automatisierung?

No-Code bezeichnet Plattformen, auf denen Fachanwender Abläufe ohne Programmierung zusammenstellen: Ein Auslöser wird gewählt, Schritte werden per Maus verbunden, fertige Konnektoren übernehmen die Anbindung gängiger Dienste. Individuelle Automatisierung dagegen ist Code, der für einen bestimmten Ablauf geschrieben, versioniert, getestet und betrieben wird. Beide Wege haben ihren Platz.

No-Code, Low-Code und individueller Code

Zwischen den beiden Polen liegt Low-Code: Plattformen, die grafisch arbeiten, an einzelnen Stellen aber eigene Ausdrücke oder Skripte zulassen. Die Grenzen sind fließend, viele Anbieter bewerben ihre Produkte mit beiden Begriffen. Für die Entscheidung im Unternehmen hilft eine andere Unterscheidung als die nach dem Etikett:

• Integrationsplattformen verbinden Cloud-Dienste über fertige Konnektoren: neue Zeile im Webformular, E-Mail an den Vertrieb, Eintrag im CRM.
• Anwendungsbaukästen erzeugen Formulare, Tabellen und einfache Oberflächen, etwa eine Freigabeliste für Bestellungen.
• Individuelle Automatisierung ist ein Programm oder Dienst mit eigener Datenbank, der die beteiligten Systeme über ihre Schnittstellen anspricht und in einem Repository mit Versionsgeschichte liegt.

Viele Firmen nutzen Plattformen der ersten Art bereits, oft ohne dass die Geschäftsführung davon weiß: Jemand hat irgendwann eine Verbindung zwischen Webformular und Tabelle eingerichtet, die seitdem jeden Tag läuft und in keiner Übersicht auftaucht.

Wo No-Code-Plattformen stark sind

Ihr Vorteil ist die Nähe zur Fachabteilung. Wer den Ablauf kennt, kann ihn selbst abbilden, ausprobieren und am nächsten Tag ändern, ohne auf eine Entwicklung zu warten. Das passt zu Abläufen, die

• zwischen verbreiteten Cloud-Diensten laufen, für die fertige Konnektoren existieren,
• überschaubare Mengen verarbeiten und keine lange Kette voneinander abhängiger Schritte bilden,
• bei einem Fehler keinen bleibenden Schaden anrichten, etwa eine interne Benachrichtigung oder das Anlegen einer Aufgabe,
• als Versuch gedacht sind: Man will sehen, ob sich ein Ablauf überhaupt lohnt, bevor man ihn dauerhaft baut.

Gerade die letzte Rolle wird unterschätzt. Ein Prototyp auf einer Plattform zeigt bald, wie oft ein Ablauf wirklich ausgelöst wird und welche Sonderfälle auftreten. Diese Erkenntnis bleibt auch dann wertvoll, wenn der Ablauf später anders gebaut wird.

Wo die Grenzen im Betrieb liegen

Die Grenzen zeigen sich selten am ersten Tag, sondern erst im laufenden Betrieb:

• Fehlerbehandlung: Fällt ein angebundener Dienst kurz aus, muss der Schritt wiederholt werden, ohne doppelt zu buchen. Auf Plattformen ist das oft nur eingeschränkt steuerbar.
• Nachvollziehbarkeit: Änderungen am Ablauf haben selten eine Versionsgeschichte mit Begründung, automatische Tests fehlen meist ganz.
• Logik: Mit jeder Sonderregel wächst das Diagramm, bis nur noch die Person es versteht, die es gebaut hat.
• Abrechnung: Viele Anbieter rechnen nach Ausführungen oder Schritten ab; mit der Menge wachsen die laufenden Kosten.
• Daten und Vertrag: Bei Cloud-Plattformen laufen die Daten über die Server des Anbieters. Für personenbezogene Daten braucht es einen Auftragsverarbeitungsvertrag, und der Serverstandort muss geklärt sein.
• Anbieterbindung: Ein Ablauf lässt sich kaum exportieren und anderswo ausführen; ein Wechsel bedeutet Neubau.

Kriterien entlang des Auftragswegs

Die Frage lässt sich selten für ein ganzes Unternehmen beantworten, wohl aber für jeden Schritt eines Weges von der Anfrage bis zur Zahlung. Vier Fragen sortieren die Schritte:

1. Was kostet ein Fehler? Eine verlorene Benachrichtigung ist ärgerlich; eine doppelt gestellte Rechnung oder ein falsch zugeordneter Zahlungseingang landet beim Kunden und in der Buchhaltung.
2. Wie oft läuft der Schritt? Ein Ablauf, der einige Male im Monat anfällt, rechtfertigt keinen eigenen Dienst. Einer, der jeden Auftrag betrifft, schon eher.
3. Wie viele Systeme und Sonderfälle? Zwei Cloud-Dienste und eine Regel passen auf eine Plattform; Warenwirtschaft, Buchhaltung, Bank und Teillieferungen eher nicht.
4. Wer betreibt ihn? Gibt es jemanden, der Fehler bemerkt, den Ablauf anpasst und im Urlaub vertreten werden kann?

In der Praxis entsteht oft eine Mischung: Benachrichtigungen, Aufgaben und interne Formulare bleiben auf einer Plattform, während Angebot, Rechnung und Zahlungsabgleich als individueller Dienst mit Protokoll laufen. Welche Schritte ohne menschlichen Eingriff durchlaufen dürfen, beschreibt der Artikel Dunkelverarbeitung; wo ein Mensch bewusst freigibt, der Artikel Human in the Loop.

Typische Fehler

• Die Plattform vor dem Ablauf wählen. Dann wird gebaut, was die Konnektoren hergeben, nicht was der Ablauf braucht.
• Den Prototyp stillschweigend zum Dauerbetrieb machen. Aus dem Versuch wird ein kritischer Ablauf ohne Verantwortlichen, Protokoll und Vertretung.
• Individuell bauen, was eine Plattform erledigt. Nicht jede Benachrichtigung braucht einen eigenen Dienst mit Datenbank.
• Die Bestandsaufnahme vergessen. Vor jeder Entscheidung gehört gesammelt, welche Abläufe schon irgendwo auf Plattformen laufen und wer sie eingerichtet hat.

Wie wir die Wahl treffen

Wir entscheiden nicht nach Vorliebe für eine Technik, sondern nach dem Befund einer Prozessanalyse des Auftragswegs. Schritte, die auf einer vorhandenen Plattform gut aufgehoben sind, bleiben dort, und das sagen wir auch so. Wo ein Fehler Kunden oder Buchhaltung erreicht, bauen wir den Schritt als Dienst mit Tests, Protokoll und Ausnahmeliste und legen im Angebot fest, woran er abgenommen wird. Wie ein solches Vorhaben abläuft, beschreibt die Seite Workflow-Automatisierung.