Drei Zeichen, dass dir deine Automatisierungen nicht gehören, obwohl du sie bezahlst
Über das Eigentum an einem automatisierten System entscheidet nicht die Rechnung. Es entscheidet sich daran, wo es läuft, auf wessen Namen die Schlüssel stehen und ob jemand außer dem Erbauer es versteht. Drei Zeichen tauchen immer auf, und alle drei prüfst du an einem Nachmittag, ohne jemanden zu fragen.
- Du kommst nicht allein rein. Wenn du für den Stand eines Prozesses jemanden um einen Screenshot bitten musst, hast du keinen Zugang: du hast einen Mittelsmann. Der Test ist wörtlich — melde dich heute an, unangekündigt, und schau dir den letzten Lauf an.
- Du weißt nicht, was es entscheidet. Wenn niemand in deinem Team erklären kann, warum ein Fall in der Prüfschlange gelandet ist und ein ähnlicher nicht, gehört dir die Geschäftsregel nicht. Sie läuft, aber du besitzt sie nicht.
- Du kannst den Dienstleister nicht ohne Stillstand wechseln. Wenn die einzige Antwort auf "und wenn wir nächsten Monat aufhören?" lautet "dann steht alles", hast du keine Dienstleistung gekauft: du hast eine Abhängigkeit mit monatlicher Rechnung.
Keines der drei bedeutet böse Absicht. Meistens sind es die natürlichen Folgen eines schnellen Starts: gebaut im Konto dessen, der gebaut hat, weil das der flotte Weg war, verbunden mit den Zugangsdaten, die gerade da waren, und die Regel wurde am Telefon vereinbart. Es funktioniert. Und es funktioniert weiter — bis zu dem Tag, an dem du es bewegen willst. Deshalb prüft man das, während alles gut läuft, nicht erst, wenn die Trennung schon beschlossen ist.
Konto und Zugangsdaten: wo das System lebt und auf wessen Namen
Das ist der Punkt, der am häufigsten übersprungen wird, und der einzige, der alles andere entwertet, wenn er kippt. Es gibt zwei Ebenen, und sie werden ständig verwechselt: das Konto der Plattform, in dem die Flows laufen, und die Zugangsdaten jedes Dienstes, mit dem diese Flows sprechen.
- Das Plattform-Konto. Der Make-Workspace, die n8n-Instanz, das Zapier-Projekt. Es muss auf einer Adresse deiner Domain liegen —nicht auf dem privaten Postfach von irgendwem—, mit deiner Zahlungsart und mindestens zwei Admins auf deiner Seite. Zahlt der Dienstleister den Tarif und stellt ihn dir weiter in Rechnung, gehört es dir nicht.
- Die Zugangsdaten jeder Verbindung. Der Zugriff auf dein CRM, dein ERP, das gemeinsame Postfach, das Zahlungs-Gateway. Jede sollte von dir angelegt sein, idealerweise als Dienstnutzer mit eng gesetzten Rechten, nicht als Privatkonto eines Beraters, der irgendwann geht.
- Domain und Webhooks. Die URLs, an die andere Systeme dir Daten schicken. Zeigen sie auf eine Domain des Dienstleisters, zwingt ein Wechsel dazu, Konfiguration bei Dritten anzufassen — und das ist der langsame Teil jeder Migration.
Die ehrliche Prüfung ist eine Frage: wenn du morgen das Admin-Passwort änderst, läuft dann noch alles? Lautet die Antwort nein, oder weißt du es nicht, liegt dort deine offene Arbeit. Und das ist keine Verhandlungsaufgabe: das ist eine sauber gemachte technische Migration von zwei Tagen, die dir nebenbei ein Inventar deiner Zugangsdaten hinterlässt — genau das, was jede ernsthafte Kontrolle darüber, was eine Automatisierung anfassen darf, verlangt.
Flows exportieren: was eine Datei mitnimmt und was draußen bleibt
Hier entspannen sich fast alle zu früh. Du bekommst eine JSON-Datei mit den Flows, legst sie ab und hältst die Sache für erledigt. Die Datei ist notwendig, aber sie ist nicht das System: sie ist der Bauplan. Und einen Teil des Bauplans lassen die Plattformen bewusst draußen.
- Bei Make ist der Szenario-Blueprint ein JSON mit den Modulen, ihren Einstellungen und den gemappten Werten; Verbindungen reisen nicht mit, wer importiert, muss also jeden Dienst mit eigenen Konten neu autorisieren.
- Bei n8n enthält das Workflow-JSON Name und ID der Credential, aber nicht ihren Inhalt; Credentials werden separat über die Kommandozeile exportiert, kommen verschlüsselt heraus und entschlüsseln sich nur auf einer Instanz mit demselben Verschlüsselungsschlüssel.
- Überall bleibt die Umgebung draußen: Variablen, Header, mit einem Anbieter vereinbarte Ratenlimits, versandberechtigte Postfächer. Genau dieser Teil sorgt dafür, dass derselbe Flow hier läuft und dort scheitert.
Deshalb nimmt man die Übergabe nicht gegen eine Datei ab, sondern gegen einen Lauf. Der Test ist einfach und lässt keine Nuancen zu: die Flows in ein eigenes Konto importieren und sie einen echten Fall von Anfang bis Ende abschließen sehen, mit deinen Zugangsdaten, bevor irgendjemand etwas unterschreibt. Bewegt der Prozess Geld oder Kundenzusagen, passiert dieser Test zuerst in einer Testumgebung — mit derselben Disziplin, mit der man jede Änderung testet, ohne die Automatisierung zu zerlegen.
Die Geschäftsregel: der Teil, der in keinem Export auftaucht
Ein exportierter Flow sagt dir, was das System tut. Er sagt dir nicht, warum. Und das Warum ist der teure Teil: die 3.000-Euro-Schwelle, die Liste der fünf Kunden, die nie durch die automatische Freigabe laufen, der Grund, warum E-Mails einer bestimmten Domain seit März ignoriert werden. Nichts davon steht im JSON. Es steckt in Entscheidungen, die jemand getroffen und nie aufgeschrieben hat.
Der Weg zurück führt nicht über die Bitte um "Dokumentation" —dieses Wort produziert PDFs, die niemand liest—. Er führt über eine Liste von Entscheidungen: ein viel kleineres und viel nützlicheres Artefakt.
- Jede Verzweigung des Flows, mit Schwelle und Grund. Eine Zeile pro "wenn… dann…": was verglichen wird, gegen welchen Wert, und woher dieser Wert stammt.
- Die benannten Ausnahmen. Kunden, Lieferanten oder Fälle mit Sonderbehandlung — und wer diese Sonderbehandlung genehmigt hat.
- Was das System tut, wenn etwas schiefgeht. Wen es alarmiert, was es erneut versucht, was es für einen Menschen parkt.
- Was es absichtlich nicht tut. Die Liste der bewusst weggelassenen Dinge hält das neue Team davon ab, etwas zu "reparieren", das so richtig war.
Kann der Dienstleister diese Liste nicht in zwei Stunden liefern, ist das kein böser Wille: das System wurde nie dokumentiert und die Regel lebt in einem Kopf. Das ist dein Risiko, nicht seins, und es löst sich mit derselben Methode, mit der man jede bereits produktive Automatisierung dokumentiert: das Warum aus echten Läufen rekonstruieren, nicht aus der Erinnerung.
Die Ausführungshistorie: das Gut, das niemand anfordert und alle vermissen
Es ist die Anforderung, die in neun von zehn Übergaben vergessen wird — und die, die einen Monat später am meisten fehlt. Die Historie —was lief, wann, mit welchen Daten, mit welchem Ergebnis— macht aus einer Automatisierung etwas Messbares statt eines Glaubensakts.
- Sie ist deine Ausgangslinie. Ohne zu wissen, wie viele Läufe pro Tag es gab und welcher Anteil scheiterte, kannst du nicht belegen, dass das interne System gleich gut oder besser arbeitet. Du wirst es aus dem Gedächtnis diskutieren, und das Gedächtnis sagt immer, früher sei es besser gewesen.
- Sie ist dein Detektor für Sonderfälle. Die Fälle, die einen Flow zerlegen, stehen nicht in der Dokumentation: sie stehen in sechs Monaten Fehlerprotokoll. Diese Liste ist mehr wert als das Handbuch.
- Sie verfällt. Die meisten Plattformen halten Lauf-Details je nach Tarif nur begrenzt vor. Drei Monate nach dem Schnitt angefragt, existiert sie nicht mehr.
Fordere sie an, bevor du den Wechsel ankündigst, und lege sie außerhalb der Plattform ab: ein Export des Protokolls, notfalls roh. Es ist auch das Material, mit dem du feststellst, was durchgefallen ist und neu verarbeitet werden muss, falls die Migration eine Lücke lässt.
Die Übergangsphase: wie man kappt, ohne den Betrieb zu kappen
Eine saubere Übergabe hat keinen Stichtag. Sie hat ein Fenster, in dem beide Systeme koexistieren und nur eines das Sagen hat. Der klassische Fehler läuft andersherum: Vertragsende, Licht aus, und das neue Team entdeckt unter Druck, dass der Fakturierungs-Flow eine Bedingung hatte, von der niemand sprach.
- Erst spiegeln, dann führen. Das neue System läuft parallel, ohne in die Produktion zu schreiben —oder in ein Testziel— und die Ergebnisse werden mehrere Tage verglichen. Was abweicht, wird untersucht, bevor irgendetwas angefasst wird.
- In Abschnitten kappen, nicht auf einen Schlag. Ein Flow wechselt, wird eine Woche geprüft, dann der nächste. Der Prozess, der Geld bewegt, geht zuletzt, nie zuerst.
- Das alte System wird abgeschaltet, nicht gelöscht. Es bleibt deaktiviert und erreichbar, solange die Übergangsphase läuft. Ein am Umschalttag gelöschter Flow ist eine verbrannte Brücke zu dem Einzigen, der wusste, wie er funktionierte.
- Ein vollständiger Zyklus, bevor du schließt. Gibt es einen Monatsabschluss, enthält die Übergangsphase einen ganzen. Sonderfälle kommen nicht dienstags: sie kommen am 30.
Die Logik ist die jeder gut geplanten Plattform-Migration —genau die Methode, um von einem Werkzeug zum anderen zu wechseln, ohne den Betrieb anzuhalten— mit einem Unterschied: hier wechselst du nicht nur das Werkzeug, du wechselst den Eigentümer des Wissens. Und dieser Teil importiert sich nicht mit einem JSON.
Zum Schluss eine ehrliche Anmerkung: ins Haus holen ist nicht immer die Antwort. Die Flows heimzuholen heißt, dass jemand bei dir die Rufbereitschaft übernimmt, die API-Updates und die laufende Pflege — echte Arbeit mit echten Kosten. Die richtige Frage lautet nicht "drinnen oder draußen?", sondern "gehört mir das in beiden Fällen?". Lautet die Antwort ja, ist das Bleiben beim Dienstleister eine ruhige wirtschaftliche Entscheidung. Lautet sie nein, kaufst du keine Dienstleistung: du mietest deinen eigenen Prozess. Wenn du diese Prüfung von außen willst —Konto-Inventar, bewiesener Export, rekonstruierte Geschäftsregel und Übergangsplan—, genau das machen wir in der Automatisierung von Abläufen.