Konnektoren sind nicht tot und verschwinden nicht. Die meisten Szenarien, die Firmen darin bauen, existieren aber nur, weil ihre Werkzeuge nicht miteinander reden. Wann ein Konnektor Sinn ergibt, wann er ein Pflaster ist und was passiert, wenn man die Ursache beseitigt.
Die provokante Frage in der Überschrift verdient gleich zu Beginn eine ehrliche Antwort: nein, sie sind nicht tot. Zapier, Make und ihre Verwandten sind gute Werkzeuge und in bestimmten Situationen unersetzlich.
Interessanter ist etwas anderes. Wenn Sie die Szenarien durchgehen, die Firmen tatsächlich betreiben, löst ein großer Teil davon keine Automatisierung. Er löst, dass zwei Werkzeuge keine Datenbank teilen.
Wofür Konnektoren wirklich gut sind
Beginnen wir mit dem, was sie gut können, denn das wird in solchen Texten meist übersprungen:
- Zwei fremde Dienste verbinden. Onlineshop und Buchhaltung. Buchungssystem und Kalender. Dinge, die nie unter einem Dach liegen werden.
- Eine Idee schnell prüfen. Bevor jemand etwas programmiert, zeigt ein Szenario, ob der Ablauf überhaupt Sinn ergibt.
- Einmalige Übertragungen. Migrationen, einmalige Datenverarbeitung.
- Dinge, für die Ihr System schlicht keine Funktion hat.
Das sind legitime Aufgaben, und ein Konnektor ist dafür das richtige Werkzeug.
Wo es teuer wird
Das Problem entsteht, wenn der Konnektor zum Klebstoff wird, der den Betrieb zusammenhält. Drei konkrete Gründe:
Abrechnung pro Operation. Jeder Schritt eines Szenarios ist eine Operation. Ein Szenario mit vier Schritten, das bei jeder Anfrage startet, bedeutet bei fünfhundert Anfragen im Monat zweitausend Operationen. Die Preislisten sind genau darauf gebaut.
Stiller Ausfall. Ein Szenario bricht mittendrin ab. Die Daten sind im ersten System, im zweiten nicht. Niemand erfährt davon - außer jemandem fällt auf, dass etwas fehlt. Und das ist meist der Kunde.
Zusätzliche Pflege. Ein Feld ändert sich in einem System, das Szenario funktioniert nicht mehr. Sie haben eine vierte Sache zu pflegen, neben den drei Systemen, die Sie verbinden wollten.
Dasselbe Ergebnis, zwei verschiedene Wege
Vier Sprünge zwischen Werkzeugen sind vier Stellen, an denen es abbrechen kann. Im System wird nichts übertragen, weil die Daten schon da sind.
Was Automatisierung im System bedeutet
Der Unterschied ist einfach: ein Konnektor überträgt Daten, eingebaute Automatisierung arbeitet mit ihnen an Ort und Stelle.
Ein konkretes Beispiel. Ein Formular kommt herein und Folgendes soll passieren:
- einen Anfrage-Datensatz anlegen,
- ihn nach Region einem Vertriebler zuweisen,
- dem Kunden eine Bestätigung schicken,
- nach drei Tagen erinnern, falls niemand geantwortet hat.
Über einen Konnektor: Formular-Tool → Konnektor → CRM → E-Mail-Tool → Planer. Fünf Dienste, mindestens vier Operationen pro Anfrage, vier Stellen, an denen es auseinanderfällt.
Im System: eine Regel mit vier Schritten. Das Formular schreibt direkt in die Datenbank, weil es Teil davon ist. Die E-Mail verschickt das System, das den Datensatz kennt. Die Erinnerung ist eine Bedingung auf einem Feld, das bereits existiert.
Keine Datenübertragung findet statt, weil es nichts dazwischen gibt.
| Externer Konnektor | Eingebaute Automatisierung | |
|---|---|---|
| Wo die Daten sind | In zwei oder mehr Systemen | An einem Ort |
| Abrechnung | Pro Operation | Teil des Systems |
| Wenn es abbricht | Daten bleiben halbiert | Der Schritt läuft nicht, der Datensatz bleibt ganz |
| Wer es repariert | Wer das Szenario gebaut hat | Jeder, der eine Regel ändern kann |
| Laufhistorie | Im Konnektor | Am betroffenen Datensatz |
Es geht nicht darum, Konnektoren zu verbieten
Ein vernünftiger Zustand sieht meist so aus: alles, was Ihre eigenen Daten betrifft, läuft im System. Der Konnektor bleibt für das, was wirklich nach außen geht - etwa die Verbindung von Onlineshop und Buchhaltung.
Woran Sie ein Pflaster-Szenario erkennen
Gehen Sie Ihre Szenarien durch und fragen Sie bei jedem: wie viele seiner Schritte übertragen nur dieselbe Information zwischen Werkzeugen?
Sind es alle bis auf den letzten, haben Sie ein Pflaster. Berechnet, entscheidet oder spricht das Szenario wirklich mit einem fremden Dienst, ist es an seinem Platz.
Der zweite Test: wenn beide Werkzeuge eines wären, gäbe es dieses Szenario überhaupt? Diese Frage deckt die meisten Fälle schneller auf als jede Analyse.
Was passiert, wenn man die Ursache beseitigt
Firmen, die ihre Datenbasis zusammenführen, berichten meist von drei Dingen:
Die meisten Szenarien verschwinden. Nicht umgezogen - sie werden schlicht überflüssig, weil die Übertragung kein Woher und Wohin mehr hat.
Niemand prüft mehr, ob die Daten stimmen. Sie können nicht auseinanderlaufen, weil sie einmal existieren.
Automatisierungen sind für mehr Menschen lesbar. Eine Regel im System, in dem die Daten leben, versteht auch ein nicht-technischer Kollege. Ein Szenario in einem separaten Werkzeug liest nur, wer es gebaut hat.
Eine vollständige Einführung steht in Automatisierung in Apexloop. Warum man in jeden Schritt hineinsehen können sollte, steht in Automatisierung ohne Blackbox. Technische Details zur Anbindung fremder Dienste auf Webhooks und API. Das gesamte Thema - vom Finden der Kandidaten bis zur Rentabilitätsrechnung - führt der Leitfaden zur Prozessautomatisierung.
Häufige Fragen zu Konnektoren und Automatisierung
Sollen wir Make oder Zapier also kündigen?
Nein. Es heißt, die Szenarien durchzugehen und zu prüfen, wie viele davon nur existieren, weil Ihre Werkzeuge keine Daten teilen. Den Rest lassen Sie - für die Anbindung fremder Dienste bleibt ein Konnektor die vernünftigste Wahl.
Was, wenn wir etwas brauchen, das eingebaute Automatisierung nicht kann?
Dafür gibt es Notausgänge - einen Webhook oder einen API-Aufruf innerhalb der Automatisierung. Der Unterschied zum Konnektor: Sie lösen diese eine Ausnahme, nicht den gesamten Datenfluss.
Wie finde ich heraus, was uns ein Konnektor wirklich kostet?
Schauen Sie sich den Operationsverbrauch der letzten drei Monate an und teilen Sie ihn durch die Zahl der Szenarien. Meist zeigt sich, dass zwei bis drei Szenarien achtzig Prozent des Guthabens verbrauchen - und genau die sind das Pflaster.