Die erste Frage ist fast immer die falsche
Wenn ein mittelständischer Betrieb anfängt, über Automatisierung nachzudenken, klingt die erste Frage in neun von zehn Fällen gleich: „Sollen wir n8n, Make oder Zapier nehmen?"
Ich verstehe den Reflex. Eine Tool-Entscheidung fühlt sich konkret an. Man kann sie googeln, vergleichen, in einem Nachmittag treffen. Sie gibt das gute Gefühl, vorangekommen zu sein. Und trotzdem ist es fast immer die falsche erste Frage. Die Antwort ist nicht egal. Sie steht nur an der falschen Stelle.
Ich habe das Muster oft genug gesehen, um es vorherzusagen: Ein Betrieb entscheidet sich für ein Werkzeug, baut darin über Monate dreißig Workflows, und stellt zwei Jahre später fest, dass genau dieses Werkzeug an einer Grenze steht. Die Preise sind gestiegen, eine Datenschutzanforderung lässt sich nicht erfüllen, oder ein neuer Use-Case braucht eine Tiefe, die das Tool nicht hergibt. Jetzt müsste man wechseln. Aber die dreißig Workflows existieren nur in der Logik dieses einen Anbieters. Sie sind nicht dokumentiert, nur geklickt. Der Wechsel ist kein Nachmittag mehr. Er ist ein Projekt.
Das eigentliche Thema ist also nicht „welches Tool". Es lautet: Passt das Werkzeug zu einer Architektur, die ich auch dann noch in der Hand habe, wenn ich das Werkzeug wechseln will?
Warum die Tool-Frage zu früh kommt
Ein Automatisierungstool ist eine Schicht in Ihrem System, die Schicht, die Dinge auslöst, transformiert und weiterreicht. Es ist eine wichtige Schicht. Aber es ist nicht das Fundament. Das Fundament sind Ihre Daten, Ihre Prozesse und die Frage, was überhaupt automatisiert werden soll und in welcher Reihenfolge.
Wer die Tool-Frage zuerst stellt, hat diese Reihenfolge umgedreht. Er entscheidet über das Werkzeug, bevor klar ist, was gebaut werden soll. Das ist, als würde man die Bohrmaschine kaufen, bevor man weiß, ob man ein Regal aufhängt oder ein Haus baut.
Bevor man überhaupt zur Tool-Frage kommt, sind drei andere Fragen dran:
- Was ist hier eigentlich Automatisierung, und was ist KI? Vieles, was als „KI-Projekt" startet, ist regelbasierte Automatisierung ohne ein einziges Sprachmodell. Das ist keine Schwäche. Im Gegenteil: Es ist robuster, billiger und vorhersagbarer. Diese Trennung gehört an den Anfang, nicht in die Tool-Auswahl.
- Wo liegen meine Daten, und in welchem Zustand? Ein Werkzeug, das sauberen Input bekommt, ist die halbe Miete. Ein Werkzeug auf chaotischen Daten automatisiert nur das Chaos schneller.
- Wie viel Datenhoheit brauche ich wirklich? Ein Steuerberater, der Mandantendaten verarbeitet, hat hier andere Antworten als eine Marketingagentur, die öffentliche Social-Media-Posts plant. Diese Antwort entscheidet die Tool-Frage stärker als jedes Feature.
Erst wenn diese drei Punkte geklärt sind, wird die Tool-Frage sinnvoll. Und dann hat sie meistens eine ruhige, fast langweilige Antwort, weil das Werkzeug jetzt zu etwas passt, statt etwas zu definieren.
Die drei im Profil
Schauen wir uns die drei häufigsten Kandidaten an. Kein Ranking, eher drei unterschiedliche Charaktere, die jeweils zu unterschiedlichen Situationen passen.
Zapier, einfach und breit
Zapier ist das Werkzeug für den schnellen Einstieg. Es verbindet mehr Apps als jeder andere Anbieter, die Bedienung ist nah an „wenn dies, dann das", und für eine geradlinige Verkettung von zwei bis fünf Schritten ist man in Minuten fertig. Wer schnell zeigen will, dass Automatisierung im eigenen Betrieb überhaupt etwas bewirkt, kommt mit Zapier am schnellsten zu einem Ergebnis.
Die Kehrseite zeigt sich, sobald die Logik verzweigt. Komplexere Abläufe mit Schleifen, Bedingungen und Datentransformationen werden in Zapier schnell unhandlich. Und die Preislogik orientiert sich an der Zahl der ausgeführten Schritte, was bei Erfolg unangenehm werden kann: Je besser eine Automatisierung läuft, desto mehr läuft sie, desto teurer wird sie. Self-Hosting gibt es nicht. Ihre Workflows leben auf den Servern des Anbieters, und dort bleiben sie.
Make, visuell und flexibel
Make (früher Integromat) sitzt in der Mitte. Es bietet eine visuelle Oberfläche, auf der man Abläufe als Diagramm baut, mit Verzweigungen, Schleifen und einer für Nicht-Entwickler erstaunlichen Tiefe. Man sieht buchstäblich, wie die Daten durch die Szenarien fließen. Für mittelständische Betriebe, die mehr wollen als simple Wenn-dann-Ketten, aber keine Entwickler-Mannschaft haben, ist das oft der Sweet Spot.
Die Preislogik rechnet hier über „Operationen" statt über Schritte, was bei vielen kleinen Aktionen anders skaliert als bei Zapier, manchmal günstiger, manchmal nicht, je nach Workflow-Zuschnitt. Self-Hosting ist auch hier nicht vorgesehen. Make ist flexibler als Zapier, bleibt aber eine gehostete Plattform mit der dazugehörigen Abhängigkeit.
n8n, offen und self-hostbar
n8n ist der Charakter, der in einer Architektur-Diskussion die meiste Aufmerksamkeit verdient. Es ist quelloffen und lässt sich auf einem eigenen Server betreiben, in Ihrem Rechenzentrum, in Ihrer Cloud, hinter Ihrer Firewall. Das heißt: Die Daten, die durch Ihre Workflows fließen, müssen das Haus nicht verlassen. Für Betriebe mit sensiblen Daten ist das oft das entscheidende Argument und kein Feature unter vielen.
Funktional spielt n8n in der oberen Liga: tiefe Verzweigungen, eigene Code-Schritte, wo es nötig wird, eine wachsende Bibliothek an Knoten. Der Preis dafür ist ein höherer Einstieg. Self-Hosting heißt: Es muss jemand betreiben, aktualisieren und absichern. Wer das nicht selbst kann oder will, nutzt die gehostete Variante, oder lässt sich den Betrieb begleiten. Mehr dazu, wie n8n als Open-Source-Baustein in einem KMU konkret aussieht, steht in KI-Prozessautomatisierung ohne API-Wildwuchs.
Der Vergleich entlang sinnvoller Achsen
Statt zu fragen „welches ist das beste Tool", lohnt der Blick entlang der Achsen, die für eine offene Architektur wirklich zählen.
| Achse | Zapier | Make | n8n |
|---|---|---|---|
| Einstieg / Bedienung | Am einfachsten, schnellster erster Erfolg | Visuell, mittlere Lernkurve | Steiler, mehr technisches Vorwissen |
| Flexibilität / Tiefe | Begrenzt bei komplexer Logik | Hoch, gute Verzweigungen | Sehr hoch, eigener Code möglich |
| Self-Hosting / Datenhoheit | Nicht möglich, Daten beim Anbieter | Nicht möglich, gehostet | Self-Hosting möglich, Daten im Haus |
| Preislogik (qualitativ) | Pro Schritt, steigt mit Erfolg | Pro Operation, anders skalierend | Self-Hosted: Infrastruktur statt Nutzungsgebühr |
| Lock-in-Risiko | Hoch, proprietär und gehostet | Mittel, proprietär aber portabler | Niedrig, offen und exportierbar |
Lesen Sie diese Tabelle nicht als „rechts gewinnt". Lesen Sie sie als Landkarte: Je weiter rechts ein Werkzeug steht, desto mehr Kontrolle bekommen Sie, und desto mehr Eigenleistung verlangt es. Je weiter links, desto schneller sind Sie produktiv, und desto mehr geben Sie an den Anbieter ab. Die richtige Wahl ist die, deren Tausch zu Ihrem Geschäft passt.
Datenhoheit ist das Mittelstands-Argument
Wenn ich die Achsen gewichten müsste, würde ich für den Mittelstand eine nach oben ziehen: Self-Hosting und Datenhoheit. Aus praktischen Gründen, nicht aus ideologischen.
Viele Mittelständler verarbeiten genau die Daten, die sie nicht beiläufig über fremde Server schicken sollten, Mandantenunterlagen, Patientendaten, Konstruktionsdaten, Personaldaten, Preiskalkulationen. Bei einer gehosteten Plattform fließen diese Daten durch die Infrastruktur des Anbieters. Vertraglich ist das meist sauber geregelt, technisch ist es trotzdem ein Datenabfluss, den man bewusst entscheiden sollte.
Self-Hosting dreht dieses Verhältnis um. Die Automatisierung läuft, wo Sie sie sehen, und die Daten bleiben in Ihrem Haus. Das ist kein Argument für alle. Eine Agentur, die Instagram-Posts plant, braucht es nicht. Aber für jeden Betrieb, dessen Wert in seinen Daten steckt, ist es das Argument, das die Tool-Frage entscheidet.
Wer mit sensiblen Daten arbeitet, sollte fragen „welches lässt meine Daten im Haus". Die Frage nach dem bequemsten Tool führt in die Irre.
Wann welches passt
Aus all dem lässt sich keine pauschale Empfehlung ableiten, aber eine Logik, mit der Sie selbst die passende Wahl treffen.
- Sie wollen schnell einen ersten Effekt zeigen, die Workflows sind simpel, die Daten unkritisch. Zapier bringt Sie am schnellsten ans Ziel. Behandeln Sie es als Lern- und Beweisinstrument. Der Endzustand muss es nicht sein.
- Sie brauchen echte Logik, haben aber kein Entwicklerteam, und Ihre Daten sind moderat sensibel. Make ist oft der pragmatische Mittelweg, visuell genug zum Selbermachen, tief genug für reale Prozesse.
- Ihre Daten sind sensibel, Sie denken langfristig, und Sie wollen oder können etwas Betrieb selbst tragen (oder begleiten lassen). n8n gibt Ihnen Datenhoheit und die niedrigste Lock-in-Gefahr. Das ist die Wahl, die in fünf Jahren am wenigsten erpressbar ist.
Und ein durchaus üblicher Fall: Man startet links, um zu lernen, und wandert nach rechts, sobald klar ist, was sich lohnt. Das ist kein Fehler, vorausgesetzt, man hat von Anfang an so gebaut, dass dieser Wechsel möglich bleibt. Womit wir beim eigentlich entscheidenden Punkt sind.
Bauen Sie so, dass der Wechsel möglich bleibt
Die Tool-Frage verliert ihren Schrecken, sobald Sie akzeptieren, dass jedes dieser Werkzeuge eine austauschbare Schicht ist. Kein Werkzeug, das Sie heute wählen, wird in fünf Jahren unverändert dieselbe Wahl sein. Modelle ändern sich, Preise ändern sich, Anbieter werden gekauft oder eingestellt. Dieses Risiko vermeiden Sie nicht, indem Sie das „richtige" Tool wählen. Es ist eine Konstante, auf die man sich einstellt.
Man stellt sich darauf ein, indem man die Workflows beherrscht, statt sie nur zusammenzuklicken. Konkret heißt das:
- Dokumentieren Sie, was ein Workflow tut, in Worten, nicht nur als Klick-Strecke. Ein Workflow, der nur als Diagramm in einem fremden Tool existiert, ist beim Wechsel verloren. Eine kurze Beschreibung in Klartext, Auslöser, Schritte, Ziel, überlebt jeden Tool-Wechsel.
- Halten Sie Daten getrennt vom Werkzeug. Die Daten sollen in einem System liegen, das exportierbar ist und das Werkzeug überlebt. Das Automatisierungstool greift darauf zu, besitzt sie aber nicht.
- Nutzen Sie Standard-Schnittstellen, wo Sie die Wahl haben. Webhooks, REST, offene Formate. Je standardisierter die Anbindung, desto leichter lässt sie sich auf ein anderes Werkzeug umbiegen.
- Vermeiden Sie tiefe Abhängigkeit von anbieter-exklusiven Funktionen. Jede proprietäre Spezialfunktion, die Ihnen heute einen Nachmittag spart, kostet Sie beim Wechsel eine Woche. Das kann sich lohnen, aber es soll eine bewusste Entscheidung sein.
Wenn Sie so bauen, ist die Wahl zwischen n8n, Make und Zapier keine Schicksalsfrage mehr. Sie wird das, was sie sein sollte: eine Werkzeugwahl. Reversibel, überprüfbar, dem Geschäft untergeordnet, nicht umgekehrt. Genau das ist gemeint, wenn von einer offenen Architektur die Rede ist, und genau das unterscheidet sie von der Plattform-Logik, in der jeder Wechsel zum Großprojekt wird. Warum die nächste integrierte KI-Plattform Ihr Unternehmen nicht rettet, folgt aus demselben Prinzip.
Die Reihenfolge, die zählt
Die ehrliche Antwort auf „n8n, Make oder Zapier?" lautet also: Es kommt darauf an, aber nicht auf das, was die Frage vermutet. Es kommt auf die Architektur an, in die das Werkzeug eingebettet wird, weniger auf das Werkzeug selbst. Wählen Sie das Werkzeug zuletzt, nicht zuerst. Klären Sie davor, was Automatisierung und was KI ist, wo Ihre Daten liegen und wie viel Datenhoheit Sie wirklich brauchen. Dann ergibt sich das Werkzeug fast von selbst, und Sie bleiben in der Lage, es zu wechseln, ohne von vorne anzufangen.
Das Werkzeug ist eine austauschbare Schicht. Die Architektur-Entscheidung dahinter trägt über Jahre.
Wenn Sie gerade vor genau dieser Frage stehen und nicht sicher sind, ob Sie zuerst die Architektur oder zuerst das Werkzeug klären sollten, ist ein nüchterner Digital-Realitäts-Check der schnellste Weg, die Reihenfolge richtig zu setzen. Und wenn die Richtung klar ist, zeigt der KI-Sprint, wie aus dieser Klarheit in vier Wochen ein erster, sauber dokumentierter Workflow entsteht, in einem Werkzeug, das Sie auch wieder verlassen könnten.