Make: visuelle Automatisierung im Überblick

Make in einem Satz

Make ist eine Automatisierungsplattform, auf der du Abläufe als Szenario zusammensetzt: ein visuelles Netz aus Modulen, das sich verzweigen, Listen durchlaufen, Daten zusammenführen und auf Fehler reagieren kann – ohne Programmierung, aber mit deutlich mehr Struktur als eine einfache Wenn-Dann-Kette.

Der Unterschied zu klassischen No-Code-Diensten liegt genau in dieser Struktur. Wo andere Werkzeuge einen linearen Ablauf abbilden, zeichnest du in Make ein Flussdiagramm mit mehreren Zweigen. Das macht den Einstieg etwas anspruchsvoller und die Umsetzung verwinkelter Prozesse deutlich einfacher.

Das Szenario-Konzept

Drei Begriffe genügen für den Einstieg.

Module

Ein Modul ist ein einzelner Baustein im Szenario. Es gibt drei Rollen:

• Trigger-Module starten das Szenario – nach Zeitplan, per eingehendem Aufruf oder beim Auftreten eines Ereignisses in einem angebundenen Dienst.
• Aktions-Module führen etwas aus: anlegen, aktualisieren, senden, abrufen.
• Such- und Werkzeugmodule holen Datensätze, formen Werte um, rechnen oder steuern den Ablauf.

Module werden per Linie verbunden und bilden dabei kein starres Band, sondern ein Netz.

Bundles

Jeder Datensatz, der durch das Szenario läuft, ist ein Bundle. Liefert ein Modul zehn Zeilen, entstehen zehn Bundles – und jedes davon läuft einzeln durch die nachfolgenden Module. Diese Bundle-Logik ist der Schlüssel zum Verständnis von Make, weil sie sowohl das Verhalten bei Listen als auch die Abrechnung erklärt.

Routen

Ein Router teilt den Ablauf in mehrere Zweige auf, die parallel weiterlaufen. Jeder Zweig bekommt einen eigenen Filter und eigene Module. Damit lassen sich Fälle sauber trennen: Eine eingehende Anfrage wandert je nach Typ in eine andere Verarbeitung, ohne dass du drei separate Szenarien pflegen musst.

Wenn dir Trigger, Aktion und Logik als Grundbegriffe noch fehlen, starte mit Workflow-Automatisierung: Grundlagen.

Wo Make wirklich stark ist

Vier Werkzeuge erklären, warum Make bei komplexen Abläufen den Vorsprung hat.

Iterator. Zerlegt eine Struktur in einzelne Bundles. Aus einer Bestellung mit zwölf Positionen werden zwölf Datensätze, die jeweils einzeln weiterverarbeitet werden. Genau das, woran lineare Tools regelmäßig scheitern.

Aggregator. Das Gegenstück: führt viele Bundles wieder zu einem zusammen – etwa alle Positionen zu einer Textliste für eine Bestätigungsmail oder alle Tageseinträge zu einem einzigen Report. Die Kombination aus Iterator und Aggregator deckt einen Großteil der anspruchsvollen Datenaufgaben ab.

Fehlerbehandlung pro Modul. An jedes Modul lässt sich ein eigener Fehlerpfad hängen: erneut versuchen, überspringen, mit Ersatzwert weiterlaufen oder gezielt abbrechen. Das ist feiner steuerbar als eine globale Fehlerregel und der Grund, warum Make-Szenarien im Dauerbetrieb oft stabiler laufen.

Datenspeicher und Zwischenablagen. Make bringt eigene Speicher mit, in denen ein Szenario Zustände über Durchläufe hinweg ablegen kann – etwa um zu merken, welche Datensätze bereits verarbeitet wurden. Ohne diese Möglichkeit werden viele Abläufe zur Bastelei.

Dazu kommt der visuelle Nutzen: Ein Szenario mit fünfzehn Modulen und drei Routen bleibt als Diagramm lesbar. Dieselbe Logik als lange Schrittliste ist es nicht.

Das Preismodell: Operationen statt Tasks

Make rechnet nach Operationen ab. Eine Operation ist grob gesagt ein Modul, das ein Bundle verarbeitet. Der Unterschied zu einer Abrechnung nach Aktionen ist wichtig:

• Ein Szenario mit vier Modulen und einem einzigen Datensatz kostet vier Operationen.
• Dasselbe Szenario mit zehn Datensätzen kostet nicht vier, sondern vielfach mehr – weil jedes Modul jedes Bundle einzeln verarbeitet.
• Auch Such-, Filter- und Werkzeugmodule verbrauchen Operationen, nicht nur die Schreibaktionen.

Daraus folgen drei Planungsregeln:

1. Früh filtern. Je früher überflüssige Bundles ausscheiden, desto weniger Module berühren sie.
2. Aggregieren, bevor du schreibst. Zehn Bundles einzeln in ein Zielsystem zu schreiben ist teurer, als sie vorher zusammenzufassen.
3. Trigger-Takt prüfen. Ein Szenario, das alle paar Minuten leer läuft, verbraucht trotzdem Operationen. Bei seltenen Ereignissen ist ein größeres Intervall oder ein ereignisbasierter Trigger die günstigere Wahl.

Die Tarifstruktur folgt einem gestaffelten Muster: eine kostenlose Ebene mit kleinem Operationskontingent und begrenztem Ausführungstakt, darüber Bezahltarife mit mehr Operationen, kürzeren Intervallen und Zusatzfunktionen wie Datenspeichern, eigenen Anbindungen und schließlich Team- und Unternehmensfunktionen mit Rechteverwaltung. Anders als bei manchen Wettbewerbern sind mehrstufige Abläufe und Verzweigungen nicht hinter einer höheren Tarifebene versteckt – das ist einer der Gründe, warum Make für komplexere Einstiege attraktiv ist.

Ein Szenario Schritt für Schritt

Am Beispiel „Eingehende Rechnungen erfassen und zur Freigabe vorlegen":

1. Trigger wählen. Ein Mail-Modul überwacht ein Sammelpostfach und startet das Szenario bei neuen Nachrichten mit Anhang.
2. Anhänge zerlegen. Ein Iterator macht aus einer Mail mit drei Anhängen drei Bundles, die einzeln weiterlaufen.
3. Filtern. Ein Filter lässt nur PDF-Dateien durch. Alles andere endet hier – und verbraucht keine weiteren Operationen.
4. Inhalte auslesen. Ein Modul extrahiert den Text aus dem Dokument. Für Rechnungsnummer, Betrag, Datum und Lieferant folgt ein KI-Schritt, der die Werte in ein festes Feldschema überführt. Warum die Ausgabe dabei zwingend gegen ein Schema geprüft gehört, erklärt KI-Automatisierung.
5. Plausibilität prüfen. Ein weiterer Filter fängt offensichtliche Fehler ab: fehlender Betrag, unmögliches Datum, leerer Lieferant. Diese Fälle gehen in einen Prüfordner statt in die Buchhaltung.
6. Router einsetzen. Zweig eins schreibt den Datensatz in die Buchhaltungstabelle. Zweig zwei legt die Datei umbenannt im Cloud-Ordner ab. Zweig drei erzeugt bei Beträgen über einer Schwelle eine Freigabeaufgabe.
7. Aggregieren und melden. Am Ende fasst ein Aggregator alle verarbeiteten Rechnungen einer Mail zu einer einzigen Übersichtsnachricht zusammen – statt drei Einzelmeldungen zu verschicken.
8. Fehlerpfade hängen. An die schreibenden Module kommt jeweils ein Fehlerpfad mit Wiederholung und einer Meldung an eine reale Person, falls auch die scheitert.

Beachte den Aufbau: Filter früh, KI eng geschnitten, Zusammenfassung spät. Genau diese Reihenfolge hält ein Szenario sowohl günstig als auch stabil.

Stärken und Grenzen

Stark ist Make bei verschachtelten Datenstrukturen, mehrstufigen Abläufen mit Verzweigungen, feiner Fehlerbehandlung und überall dort, wo ein Prozess visuell nachvollziehbar bleiben soll. Auch KI-Schritte lassen sich sauber einbinden – von Modellaufrufen bis zu Wissensanbindungen.

Grenzen liegen in der Einstiegshürde: Wer nur zwei Tools verbinden will, kommt mit einem geführteren Werkzeug schneller ans Ziel. Die Zahl fertiger Integrationen liegt unter der des Marktführers. Und bei sehr hohen Volumina wird die Abrechnung pro Operation spürbar, weil jedes Modul jedes Bundle einzeln zählt. Wo die Alternativen besser passen, klärt n8n vs. Zapier vs. Make – ein Blick auf Zapier lohnt vor allem wegen der größeren Integrationsauswahl.

Fazit

Make ist die richtige Wahl, wenn deine Abläufe verzweigen, Listen verarbeiten und im Fehlerfall differenziert reagieren müssen. Iterator, Aggregator, Router und modulweise Fehlerpfade decken Anforderungen ab, an denen einfachere Werkzeuge scheitern – und das Szenario bleibt dabei als Diagramm lesbar. Wer die Operationslogik versteht, früh filtert und spät aggregiert, hält die Kosten dabei berechenbar.