Kontext schlägt Tool: Die einfache Entscheidungshilfe für KI-Automatisierungen

Warum die Parole „n8n = WordPress der Automatisierung“ ohne Kontext in die Irre führt – und wie du Schritt für Schritt die passende Lösung wählst.

In der Abfrage gestern haben sich die meisten Teilnehmer für mehr Strategie-Themen ausgesprochen, deshalb möchte ich Euch heute, den Begriff der Technologie-Sprungmatrix (Wenn die Anforderungen immer höher werden, braucht man oft einen Technologiesprung zu einer anderen Technologie) näher bringen.

Hier findest du auch ein Online Tool in dem du selber mal ausprobieren kannst, wie deine Technologie-Sprungmatrix aussieht.

Warum ist das wichtig?

Damit Ihr damit einschätzen könnt, wie die Aussagen auf LinkedIn von Experten zu lesen sind und ihr damit einordnen könnt, ob die Aussagen verkürzt, verallgemeinert oder einfach falsch sind.

Viele Aussagen sind einfach ohne Kontext sinnlos. Zuletzt habe ich gelesen, das man n8n oder Zapier….nicht für professionelle Aufgaben einsetzt. Der Author kennt aber nicht genug Beispiele ausserhalb seines Horizonts. Es gibt z.B. ein Unternehmen die sind innerhalb von drei Jahren von zwei auf 1800 Mitarbeiter gewachsen, und da laufen 550 Zaps (Zapier), d.h. die Plattform hat mitskaliert.

Worum geht’s wirklich im Bereich KI?

In vielen Diskussionen taucht der Satz auf: „n8n ist wie WordPress: super zum Start, aber später problematisch.“
Diese Zuspitzung trifft manchmal, ist aber zu allgemein. Denn sie ignoriert das Wichtigste: deinen Kontext.

  • Beispiel 1: Social-Media-Planung. Du bereitest einmal pro Tag 10 Posts vor. Wenn das System heute mal hakt, lädst du sie eben morgen hoch. Ärgerlich – aber nicht dramatisch.

  • Beispiel 2: Produktionsablauf. Dein Fertigungsprozess darf keine Sekunde stehen. Jeder Ausfall kostet richtig Geld. Hier ist „mal schauen“ keine Option.

Merke: Nicht das Tool ist „gut“ oder „schlecht“. Die Passung zwischen Tool und Aufgabe entscheidet.

Damit du diese Passung findest, brauchst du als erstes zwei einfache Zahlen und ein paar klare Fragen. Das bekommst du hier – ohne Technik-Jargon.

Die zwei wichtigsten Zahlen: RTO & RPO (ohne Fachchinesisch)

RTO (Recovery Time Objective) – wie schnell muss es wieder laufen?

Stell dir vor, etwas geht schief (Server down, Timeout, Passwort abgelaufen).
RTO beantwortet: Wie viele Minuten/Stunden sind okay, bis alles wieder läuft?

  • Entspannt: „Wenn’s morgen wieder geht, reicht mir.“ → RTO ≈ 24h

  • Mittel: „In ein paar Stunden sollte es wieder funktionieren.“ → RTO ≤ 4h

  • Eilig: „Innerhalb einer Stunde bitte!“ → RTO ≤ 60min

  • Sehr eilig: „In wenigen Minuten, am besten sofort.“ → RTO ≤ 5min

RPO (Recovery Point Objective) – wie viel darf verloren gehen?

Es passiert ein Fehler mitten in der Verarbeitung.
RPO beantwortet: Wie viele Daten/Einträge darf ich maximal verlieren?

In einer Näherung lässt sich auch aus dieser Zahl das Budget für die Lösung entwickeln.

  • Entspannt: „Zur Not fülle ich es morgen neu ein.“ → RPO ≈ 24h

  • Mittel: „Ein paar Stunden Verlust sind okay.“ → RPO ≤ 4h

  • Eilig: „Bitte höchstens wenige Minuten.“ → RPO ≤ 15min

  • Sehr eilig: „Nichts verlieren!“ → RPO ≤ 1min

Kurzformel zum Merken:
RTO = Zeit bis wieder alles läuft.
RPO = Daten, die maximal verloren gehen dürfen.

Wenn du diese zwei Werte ehrlich einschätzt, hast du 80 % der Entscheidung schon gewonnen.

Vier Zusatzfragen, die völlig reichen

Du brauchst nicht 20 Kriterien. Für den Start genügen diese vier:

  1. Wie viel läuft pro Stunde?
    Grob schätzen: < 50, 50–200, 200–1000, > 1000 Vorgänge pro Stunde.

  2. Wie lange dauert ein Durchlauf?
    Kurz (<5 min), mittel (5–60 min), lang (>1 h).

  3. Gibt es Regeln/Änderungen zur Laufzeit?
    Musst du Entscheidungen während des Ablaufs umschalten können (z. B. „Wenn Kunde VIP ist, dann…“)?

  4. Gibt es besondere Pflichten?
    Personendaten (DSGVO) oder Prüfbarkeit/Audit? Wenn ja, steigt der Anspruch automatisch.

Die einfache Klassen-Einordnung (statt Tool-Glaubenskrieg)

Wir fassen typische Situationen in fünf Klassen zusammen. Lies sie von oben nach unten und hake das ab, was zu dir passt.

Klasse 1 – Mini-Automationen (sehr entspannt)

  • Ausfall: egal bis morgen (RTO ~24h)

  • Datenverlust: egal bis morgen (RPO ~24h)

  • Last: < 50 pro Stunde

  • Beispiele: Social-Posts vorbereiten, interne Erinnerungen, einfache Dateikonvertierungen, Content-Kalender

  • Geeignete Werkzeuge: n8n/Make/Zapier out of the box

  • Sicherheitsgurte: Ein Wiederhol-Schutz (Idempotenz), 2–3 automatische Neuversuche, Fehler-Mail

Klasse 2 – Team-Automationen (ein bisschen wichtiger)

  • Ausfall: bitte in ≤ 4h beheben

  • Datenverlust: ≤ 4h ok

  • Last: bis ~200 pro Stunde

  • Beispiele: Freigabe-Workflows, CRM-Listen abgleichen, Benachrichtigungen mit Bedingungen

  • Geeignete Werkzeuge: n8n/Make mit etwas Sorgfalt

  • Sicherheitsgurte: Fehler-Auffangkörbchen („DLQ“), feste Neuversuche mit Pause, einfache Protokolle/Notizen

Klasse 3 – Bereich-kritisch (es wird ernst)

  • Ausfall: ≤ 60min

  • Datenverlust: ≤ 15min

  • Last: 200–1000 pro Stunde oder Personendaten/Audit

  • Beispiele: Leads zuverlässig ins CRM/ERP, Bestellungen in die Warenwirtschaft, verbindliche E-Mail-Strecken

  • Geeignete Werkzeuge:

    • Entweder robust aufgesetztes n8n/Make (mit Regeln, Warteschlangen, Protokollen)

    • Oder professionelle Plattformen („iPaaS“)

  • Sicherheitsgurte: Fester Notfallkorb (DLQ) mit Benachrichtigung, klare Wiederhol-Regeln, einfache „Stopp/Weiter“-Schalter

Klasse 4 – Unternehmens-kritisch (Kernabläufe)

  • Ausfall: ≤ 5min

  • Datenverlust: ≤ 1min

  • Last: oft > 1000 pro Stunde; Abläufe mit vielen Schritten und Rückabwicklung („erst X, dann Y; wenn Y schiefgeht, X rückgängig“)

  • Beispiele: Bestell- und Zahlungsprozesse, zentrale Logistik, produktionsnahe Abläufe

  • Geeignete Werkzeuge: spezialisierte Workflow-Systeme („Orchestratoren“), die genau für solche Fälle gebaut sind

  • Sicherheitsgurte: „Wiederholen ohne Doppelwirkung“, genaue Ablauf-Spuren, sofortige Alarme

Klasse 5 – 24/7/Null-Ausfall (nur wenn wirklich nötig)

  • Ausfall: praktisch 0

  • Datenverlust: 0

  • Beispiele: Fließband-Steuerung, Zahlungs-Kern, medizinische Steuerungen

  • Geeignete Werkzeuge: Hochverfügbare Architekturen mit Reserve-Systemen

  • Sicherheitsgurte: Betrieb rund um die Uhr, Tests von Ausfällen („Fehler proben“), strenge Freigaben

Einfacher Sprung-Merksatz:
Sobald zwei Punkte deutlich „schärfer“ werden (z. B. Ausfall ≤ 60 min und Personendaten), spring eine Klasse höher. Nicht zerren, springen.

In 10 Minuten zur richtigen Klasse (Schritt-für-Schritt)

  1. RTO festlegen:
    Wenn heute alles ausfällt – bis wann muss es wieder laufen? (Morgen? 4 h? 60 min? 5 min?)

  2. RPO festlegen:
    Wie viel Verlust wäre gerade noch okay? (Ein Tag? 4 h? 15 min? 1 min?)

  3. Last & Dauer grob einschätzen:
    Vorgänge pro Stunde + typische Laufzeit (<5 min, 5–60 min, >1 h).

  4. Pflichten checken:
    Personendaten? Braucht jemand später prüfbare Nachweise?

  5. In Tabelle oben vergleichen und Klasse auswählen.

  6. Sicherheitsgurte einsetzen (siehe unten) und klein starten.

  7. Einen „Fehler-Tag“ simulieren: Einmal absichtlich etwas scheitern lassen → prüfen: Hätten wir es gemerkt? Wissen wir, was zu tun ist?

„n8n richtig einsetzen“ – simpel erklärt

n8n,make.com, Zapier (und ähnliche Tools) sind ideal, wenn du schnell loslegen willst und die Welt nicht davon abhängt, dass jede Sekunde alles perfekt ist.

  • Glanzbereich: Klasse 1–2

  • Machbar mit Sorgfalt: Klasse 3 (wenn du die Sicherheitsgurte konsequent nutzt)

  • Lieber anderes Werkzeug: Klasse 4–5 (dafür gibt es spezialisierte Systeme, die genau solche Anforderungen stemmen)

Wichtiger Punkt: Viele Frust-Geschichten entstehen nicht, weil n8n „schlecht“ wäre, sondern weil Basics fehlen. Setz diese drei Dinge immer um:

  1. Wiederholen ohne Doppelwirkung
    Wenn ein Schritt noch mal läuft, soll nichts doppelt angelegt/verschickt/gebucht werden. (Stichwort: „Duplikate erkennen“)

  2. Notfallkorb
    Geht etwas trotz Wiederholungen schief, landet es sichtbar in einem „Korb“. Du bekommst eine Nachricht („Bitte ansehen!“) und kannst manuell lösen.

  3. Alarm & Protokoll
    Wenn etwas Wichtiges nicht gelaufen ist, willst du das merken – und im Nachhinein sehen was passiert ist.

Mit diesen drei Basics trägt n8n erstaunlich viel – ohne dass du tief in Technik einsteigen musst.

Typische Anfänger-Fehler (und wie du sie vermeidest)

  • „Ein Riesen-Flow für alles“
    Besser: Mehrere kleine Flows, die jeweils eine Sache zuverlässig tun.

  • „Unendlich neu versuchen“
    Besser: Ein paar Neuversuche mit Pause – dann in den Notfallkorb und melden.

  • „Doppelt ausgelöst = doppelt ausgeführt“
    Besser: Duplikate erkennen (z. B. anhand einer eindeutigen ID wie Bestellnummer).

  • „Fehler merkt niemand“
    Besser: E-Mail/Chat-Benachrichtigung, wenn ein Flow scheitert oder in den Notfallkorb geht.

  • „Wir schieben später nach“
    Besser: Die drei Basics (Wiederholen ohne Doppelwirkung, Notfallkorb, Alarm/Protokoll) von Anfang an.

8) Fünf echte Beispiel-Szenarien (mit Entscheidung)

A) „Täglich 10 LinkedIn-Posts“

  • RTO/RPO: Morgen ist ok → entspannt

  • Last/Dauer: niedrig/kurz

  • Entscheidung: Klasse 1

  • Set-up: n8n einfach, plus: Duplikate stoppen, 2–3 Neuversuche, E-Mail bei Fehler

B) „Urlaubsanträge im Team abwickeln“

  • RTO/RPO: Bitte heute noch, aber kein Drama → ≤ 4h

  • Last/Dauer: moderat

  • Entscheidung: Klasse 2

  • Set-up: n8n mit Notfallkorb, Wiederhol-Regeln, kleinem Protokoll

C) „Leads zuverlässig ins CRM & Mails versenden“

  • RTO/RPO: ≤ 60min / ≤ 15min, Personendaten → ernst

  • Last: 200–1000/h

  • Entscheidung: Klasse 3

  • Set-up-Optionen: Robust gemachtes n8n oder professionelle Plattform; unbedingt: Notfallkorb + Benachrichtigung, saubere Wiederhol-Regeln, einfache „Stopp/Weiter“-Schalter

D) „Checkout/Bestellung im Online-Shop“

  • RTO/RPO: minutenentscheidend, fast kein Verlust erlaubt

  • Last: oft hoch, viele Schritte

  • Entscheidung: Klasse 4

  • Set-up: Spezialisierte Workflow-Systeme („Orchestratoren“), genaue Ablauf-Spuren, sofortige Alarme

E) „Fließband darf nie stehen“

  • RTO/RPO: 0 / 0

  • Entscheidung: Klasse 5

  • Set-up: Hochverfügbare Architektur mit Reserve, strenge Freigaben, Tests von Ausfällen („Fehler proben“)