Fast jede gute Automatisierung beginnt gleich: Jemand im Betrieb entdeckt n8n, Make oder Zapier, verbindet das Kontaktformular mit einer Tabelle, hängt eine Benachrichtigung dran und spart ab Montag zwei Stunden pro Woche. Das ist keine Bastelei, das ist die richtige Entscheidung.
Das Problem kommt später. Nach 18 Monaten laufen 30 Szenarien, drei davon kennt nur eine Person, und niemand traut sich mehr, etwas zu ändern.
Die Kurzfassung:
- Workflow-Werkzeuge sind hervorragend im Verbinden und schwach im Verwahren.
- Fünf Grenzen tauchen zuverlässig auf. Die gefährlichste ist, dass Fehler still ins Leere laufen.
- Der Umstieg gelingt schrittweise: zuerst die Datenhaltung ablösen, den Rest laufen lassen.
Wo die Grenze wirklich verläuft
Es gibt eine brauchbare Trennlinie zwischen beiden Welten:
Ein Workflow-Werkzeug ist gut darin, Daten von A nach B zu bringen. Es ist schlecht darin, Daten zu besitzen.
Solange Ihre Automatisierung nur weiterreicht, also Formular an Tabelle, Bestellung an Buchhaltung, Nachricht an Team, ist sie am richtigen Platz. In dem Moment, in dem der Workflow selbst zur Quelle der Wahrheit wird, weil dort der aktuelle Status eines Vorgangs steht, ist die Grenze überschritten.
Das passiert schleichend und nie durch eine Entscheidung.
Fünf Grenzen, an denen es zuverlässig kippt
1. Keine echte Datenbank
Tabellen und die Datenspeicher der Workflow-Werkzeuge halten Daten, aber sie kennen keine Beziehungen. Ein Kunde hat mehrere Aufträge, jeder Auftrag mehrere Positionen, jede Position einen Bearbeitungsstand.
In einer Tabelle wird daraus entweder eine sehr breite Zeile oder eine Sammlung von Blättern, die per Suchfunktion zusammengehalten wird. Beides bricht an derselben Stelle: Sobald zwei Vorgänge gleichzeitig dieselbe Zeile ändern, gibt es keine verlässliche Antwort mehr darauf, was jetzt gilt.
Frühwarnsignal: Sie haben eine Spalte, in der IDs anderer Tabellen stehen, und pflegen sie von Hand.
2. Kein Rechtekonzept
Workflow-Werkzeuge kennen Zugang zum gesamten Werkzeug, nicht zu einzelnen Datensätzen. Wer den Workflow bearbeiten darf, sieht alles: Preise, Margen, Kundendaten, Personalbezüge.
Sobald jemand nur einen Ausschnitt sehen soll, der Monteur also seinen Auftrag, aber nicht die Kalkulation, beginnt eine Reihe von Umwegen: eigene Tabellen pro Rolle, gefilterte Ansichten, Kopien. Jede davon ist eine neue Fehlerquelle und aus Sicht der DSGVO schwer zu verteidigen.
Frühwarnsignal: Es existiert eine zweite Tabelle, die nur eine gefilterte Kopie der ersten ist.
3. Keine Historie
Die entscheidende Frage im Streitfall lautet: Wer hat wann was geändert? Workflow-Werkzeuge protokollieren Durchläufe, nicht Datenstände, und meist nur für begrenzte Zeit. Wenn ein Kunde im November fragt, warum sein Auftrag im August umgestellt wurde, gibt es keine Antwort.
Bei Reklamationen, Gewährleistung und allem, was mit Nachweisen zu tun hat, ist das keine Bequemlichkeitsfrage.
Frühwarnsignal: Sie haben schon einmal aus einer E-Mail rekonstruiert, was in der Tabelle früher stand.
4. Fehler laufen still ins Leere
Das ist die gefährlichste Grenze. Ein Szenario schlägt fehl, weil ein Dienst kurz nicht erreichbar war. Es gibt keine Fehlermeldung an einen Menschen, keine Wiederholung, keinen Vermerk. Der Vorgang existiert einfach nicht.
Auffallen wird es, wenn ein Kunde nachfragt, wo seine Bestätigung bleibt. Und dann fehlt der Datensatz komplett, weil er nie angelegt wurde.
Echte Anwendungen behandeln das mit Wiederholungsversuchen, einer Warteschlange für Fehlgeschlagenes und einer Übersicht, in der jemand sieht, was liegen geblieben ist.
Frühwarnsignal: Sie prüfen morgens von Hand, ob die Läufe der Nacht durchgegangen sind.
5. Niemand außer einer Person versteht es
30 Szenarien mit Verzweigungen, ineinander verschachtelten Aufrufen und Kommentaren wie „nicht anfassen" sind ein Betriebsrisiko. Es gibt keine Testumgebung, keine Versionsverwaltung im üblichen Sinn und keinen Weg, eine Änderung auszuprobieren, ohne die Produktion zu berühren.
Frühwarnsignal: Es gibt einen Ablauf, den nur eine Person ändern darf, und diese Person plant Urlaub.
Was das kostet, bevor es auffällt
Die Kosten einer überdehnten Automatisierung sind selten sichtbar, weil sie in Nacharbeit und Nachverfolgung stecken.
Beispielrechnung (Werte anpassen): Eine Mitarbeiterin prüft täglich 20 Minuten, ob alle Abläufe durchgelaufen sind, und korrigiert wöchentlich zwei Vorgänge zu je 30 Minuten. Das sind rund 100 Stunden im Jahr; bei angesetzten 45 € Vollkosten je Stunde etwa 4.500 € jährlich, nur für Kontrolle, ohne den Schaden aus einem übersehenen Fall.
Rechnen Sie das gegen den Aufwand, den Kern in eine eigene Anwendung zu holen. Häufig ist die Kontrolltätigkeit die teurere Position, und sie wächst mit jedem weiteren Szenario.
Der Migrationspfad ohne Stillstand
Der übliche Fehler ist, alles auf einmal ersetzen zu wollen. Das führt zu einem Projekt, das drei Monate nichts liefert, während parallel die alte Lösung weiter gepflegt werden muss.
Besser in vier Schritten:
Schritt 1: Die Datenhaltung herausziehen. Eine echte Datenbank mit den zentralen Datensätzen: Kunde, Vorgang, Status, Historie. Die bestehenden Szenarien schreiben ab sofort dorthin statt in die Tabelle. An den Abläufen selbst ändert sich zunächst nichts.
Schritt 2: Eine Oberfläche für die Menschen. Wer heute in der Tabelle nachschaut, bekommt eine Ansicht mit Rechten: sieht nur, was er sehen darf, und ändert nur, was er ändern darf. Ab hier ist der DSGVO-Punkt entlastet.
Schritt 3: Die kritischen Abläufe in die Anwendung holen. Alles, wo Fehler teuer sind, wandert in richtigen Code mit Wiederholung, Fehlerbehandlung und Protokoll. Das sind meist zwei oder drei von dreißig Szenarien.
Schritt 4: Den Rest bewusst dort lassen. Anbindung an Newsletter-Werkzeuge, Benachrichtigungen ins Team, kleine Verbindungen zwischen Diensten: Das bleibt im Workflow-Werkzeug, weil es dort schneller anzupassen ist.
Nach Schritt 1 und 2 ist der größte Teil des Risikos weg, üblicherweise nach wenigen Wochen statt nach Monaten. Wie Sie den Umfang dafür beschreiben, ohne technisch zu werden, steht in Das Lastenheft auf einer Seite.
Wann Sie nichts ändern sollten
Damit das nicht als Generalabsage an Low-Code endet: in diesen Fällen bleiben Sie besser, wo Sie sind:
- Der Ablauf ändert sich ständig. Was Sie monatlich anpassen, ist im Workflow-Werkzeug richtig aufgehoben. Dort ist eine Änderung eine Sache von Minuten.
- Es geht nur ums Verbinden. Ein Dienst ruft einen anderen, keine eigene Datenhaltung, kein Rechtebedarf. Genau dafür sind diese Werkzeuge gebaut.
- Geringes Volumen und unkritische Daten. Bei zehn Vorgängen im Monat lohnt kein eigenes System.
- Es läuft und niemand kontrolliert es täglich. Wenn keines der fünf Frühwarnsignale zutrifft, gibt es keinen Anlass.
Der Auslöser für den Wechsel ist nie die Zahl der Szenarien. Er ist der Moment, in dem Sie anfangen, dem eigenen Datenbestand nicht mehr zu trauen.
Die Standortbestimmung in zehn Minuten
Gehen Sie die fünf Frühwarnsignale durch und zählen Sie:
- Von Hand gepflegte Verweise zwischen Tabellen
- Gefilterte Kopien für einzelne Rollen
- Rekonstruktion alter Datenstände aus E-Mails
- Tägliche manuelle Kontrolle der Läufe
- Ein Ablauf, den nur eine Person versteht
Null bis eins: Alles in Ordnung, weitermachen. Zwei bis drei: Ziehen Sie die Datenhaltung heraus, bevor es mehr werden. Vier oder fünf: Das ist kein Automatisierungsthema mehr, sondern ein Betriebsrisiko.
Ob am Ende eine eigene Anwendung oder eine Standardlösung passt, ist eine eigene Frage. Dafür hilft die Entscheidungsmatrix Standardsoftware gegen Eigenentwicklung.