Wer baut eure Automatisierung? Die Frage, die über zwei Jahre entscheidet

Die teuerste Automatisierungsentscheidung trifft niemand bewusst

Ein Kunde aus Köln, Maschinenbau, knapp 200 Mitarbeiter, rief uns im März an. Ihre Auftragsbestätigungen liefen seit anderthalb Jahren automatisch raus, gebaut von einem Werkstudenten, der inzwischen bei einem Konzern angefangen hatte. Der Prozess funktionierte. Bis zu dem Dienstag, an dem er es nicht mehr tat. Ein Lieferant hatte ein Feld in seinem Portal umbenannt, die Automatisierung zog leere Werte, und drei Tage lang gingen Bestätigungen mit fehlenden Positionen an Kunden. Niemand im Haus wusste, wie das Ding aufgebaut war. Der Werkstudent antwortete nicht mehr auf E-Mails.

Die Frage, die dieser Kunde nie gestellt hatte, war nicht "welches Tool nehmen wir". Die hatte er beantwortet, Make in dem Fall. Die Frage, die er nie gestellt hatte, war: wer baut das, wer versteht das in zwei Jahren noch, und wer steht am Telefon, wenn es um 22 Uhr kaputt geht.

Das ist die Entscheidung, über die kaum jemand nachdenkt, bevor er automatisiert. Sie fällt implizit. Jemand hat gerade Zeit, jemand kann ein bisschen was mit Zapier, ein Freelancer war günstig. Und genau diese implizite Entscheidung bestimmt, ob eine Automatisierung ein Vermögenswert wird oder eine tickende Schuld. In diesem Artikel geht es nicht um Tools. Es geht um das Betriebsmodell dahinter, um die Frage, wer eure Automatisierung baut und betreibt, und warum diese Frage teurer ist als jede Lizenzgebühr.

Warum das Tool die falsche erste Frage ist

Wenn Unternehmen mit uns über Automatisierung sprechen, drehen sich die ersten zwanzig Minuten fast immer um Werkzeuge. Make oder n8n. Zapier oder selbst gehostet. Power Automate, weil Microsoft eh schon da ist. Das sind reale Fragen, aber sie sind zweitrangig.

Ein Workflow ist selten das Problem. Ein Workflow ist zwei Nachmittage Arbeit. Das Problem beginnt am Tag danach: Der Workflow läuft, und ab jetzt muss ihn jemand am Leben halten. APIs ändern sich. Anbieter benennen Felder um. Ein Rate-Limit, das gestern nicht existierte, blockiert heute die Hälfte der Durchläufe. Eine fachliche Anforderung verschiebt sich, und die Logik von vor einem Jahr passt nicht mehr. Automatisierung ist kein Projekt mit Enddatum. Sie ist ein Betrieb.

Und Betrieb braucht einen Verantwortlichen. Die eigentliche Entscheidung ist deshalb nicht "welches Werkzeug", sondern "welches Betriebsmodell". Wer trägt die Verantwortung dafür, dass diese Automatisierung in zwei Jahren noch verlässlich läuft, wer versteht sie, wenn der, der sie gebaut hat, weg ist, und wie schnell ist jemand erreichbar, wenn sie ausfällt.

Es gibt im Kern vier Antworten auf diese Frage. Ihr baut selbst. Ihr holt einen Freelancer. Ihr beauftragt eine Agentur oder einen spezialisierten Dienstleister. Oder ihr stellt jemanden ein und baut die Kompetenz intern auf. Jedes dieser Modelle hat eine ehrliche Berechtigung, und jedes hat einen Preis, der selten auf der Rechnung steht. Gehen wir sie durch.

Modell 1: Selbst bauen

Der Klassiker, vor allem bei kleineren Betrieben und Solo-Selbstständigen. Jemand im Team hat sich in Make eingearbeitet, YouTube-Tutorials geschaut, und baut die ersten Automatisierungen selbst. Kein externes Budget, volle Kontrolle, sofort startklar. Für einen bestimmten Reifegrad ist das nicht nur okay, es ist richtig.

Wann Selbstbauen die beste Wahl ist

Wenn ein Prozess unkritisch ist, wenn ein Ausfall niemanden ruiniert, und wenn die Logik überschaubar bleibt, dann ist Selbstbauen die sinnvollste Option. Eine Solo-Beraterin, die eingehende Kontaktanfragen automatisch in ihr CRM schreibt und sich eine Slack-Nachricht schickt, braucht dafür keine Agentur. Sie braucht einen Nachmittag und ein Tutorial. Wenn das mal einen Tag ausfällt, sieht sie es und trägt drei Anfragen von Hand nach. Kein Drama.

Der Wert des Selbstbauens liegt nicht nur im gesparten Geld. Er liegt im Verständnis. Wer seine eigenen Automatisierungen baut, entwickelt ein Gefühl dafür, was möglich ist und was Aufwand kostet. Dieses Gefühl ist später Gold wert, auch wenn man irgendwann externe Hilfe holt. Die schlimmsten Auftraggeber sind die, die keine Ahnung haben, was sie da eigentlich beauftragen. Ein bisschen selbst gebaut zu haben, schützt davor.

Wo es kippt

Selbstbauen hat eine harte Grenze, und die heißt Betriebsreife. Ein Prozess, der Geld bewegt, Rechnungen verschickt oder rechtliche Fristen auslöst, gehört nicht in die Hände von jemandem, der es nebenbei macht und dessen eigentlicher Job ein anderer ist. Nicht weil die Person zu dumm wäre, sondern weil ihr die Zeit fehlt, es richtig zu machen: Fehlerbehandlung, Monitoring, Dokumentation, Tests. Das sind die Teile, die man beim Selbstbauen zuerst weglässt, weil sie unsichtbar sind und der Workflow ja auch ohne läuft. Bis er es nicht mehr tut.

Der zweite Bruchpunkt ist Personenabhängigkeit. Der Bus-Faktor eines selbst gebauten Systems ist fast immer eins. Es gibt genau einen Menschen im Haus, der weiß, warum das so gebaut ist. Geht der, geht das Wissen mit. Der Kunde aus Köln vom Anfang ist genau daran gescheitert. Nicht am Werkzeug, nicht am Werkstudenten, sondern daran, dass niemand ein Modell hatte, das über eine einzelne Person hinaus trägt.

Selbstbauen ist die richtige Wahl für unkritische Prozesse in kleinen Strukturen. Sobald ein Prozess geschäftskritisch wird oder die Zahl der Automatisierungen zweistellig, braucht es ein Modell, das nicht an einem einzelnen Nachmittagsprojekt hängt.

Modell 2: Freelancer

Der nächste Schritt für viele. Ein Freelancer baut, was intern niemand bauen kann oder will. Auf Plattformen findet man Leute, die Make und n8n im Schlaf beherrschen, oft zu Tagessätzen, die deutlich unter denen einer Agentur liegen. Für klar umrissene Aufgaben ist das ein gutes Modell.

Wo Freelancer glänzen

Ein Freelancer ist ideal, wenn die Aufgabe abgeschlossen und beschreibbar ist. "Baue mir eine Automatisierung, die neue Bestellungen aus Shopify in unser Buchhaltungssystem überträgt, mit dieser Feldzuordnung." Klarer Auftrag, klares Ergebnis, klarer Preis. Ein guter Freelancer liefert das schneller und sauberer, als ein interner Laie es je könnte, und er hat den Fall wahrscheinlich schon dreimal gebaut.

Ein mittelständischer Onlinehändler, mit dem wir gearbeitet haben, hatte über die Jahre einen festen Freelancer, der punktuell neue Workflows ergänzte. Das lief gut, weil die Zusammenarbeit kontinuierlich war. Der Mann kannte das Setup, war erreichbar, und der Händler behandelte ihn eher wie einen externen Teil des Teams als wie einen einmaligen Dienstleister.

Der Bruchpunkt heißt Kontinuität

Genau diese Kontinuität ist die Ausnahme, nicht die Regel. Das typische Freelancer-Problem ist der Abschluss. Der Auftrag ist erledigt, die Rechnung bezahlt, der Freelancer zieht weiter zum nächsten Kunden. Sechs Monate später bricht der Workflow, und die Person ist ausgebucht, hat den Kontext vergessen oder ist gar nicht mehr auf der Plattform. Der Bus-Faktor bleibt eins, er sitzt jetzt nur außerhalb eures Hauses und schickt keine Rechnung mehr, wenn er verschwindet.

Dazu kommt die Dokumentationsfrage. Viele Freelancer bauen schnell und funktional, aber nicht für den Nachfolger. Warum eine bestimmte Verzweigung existiert, welche Sonderfälle bewusst abgefangen wurden, welche stillschweigend nicht, das steht nirgends. Ihr habt ein laufendes System und keine Landkarte dafür. Solange es läuft, merkt niemand das Problem. Es ist ein latenter Schaden, der erst beim ersten Ausfall sichtbar wird.

Wenn ihr mit Freelancern arbeitet, macht Übergabe und Dokumentation zum Teil des Auftrags, schriftlich, mit Abnahme. Und baut, wenn möglich, eine kontinuierliche Beziehung auf statt einmaliger Projekte. Ein Freelancer, der euren Stack kennt und erreichbar bleibt, ist Gold wert. Ein Freelancer, der einmal baut und verschwindet, hinterlässt euch dieselbe Personenabhängigkeit wie das Selbstbauen, nur mit einer Rechnung dazu.

Modell 3: Agentur oder spezialisierter Dienstleister

Ab einer gewissen Größe und Kritikalität landen Unternehmen bei uns oder bei Kollegen. Eine Agentur oder ein spezialisierter Automatisierungsdienstleister bringt etwas mit, das ein einzelner Freelancer strukturell nicht bieten kann: Redundanz. Es gibt nicht einen Menschen, der euer Setup kennt, sondern ein Team, Prozesse, Dokumentationsstandards und im besten Fall eine Vertretung, wenn einer krank ist.

Was ihr wirklich kauft

Bei einer Agentur zahlt ihr nicht für Klicks in Make. Ihr zahlt für Betriebssicherheit. Für die Tatsache, dass jemand Monitoring aufsetzt, bevor etwas produktiv geht. Dass Fehler auffallen, bevor der Kunde sie meldet. Dass es einen dokumentierten Zustand gibt, der nicht im Kopf einer einzelnen Person lebt. Ein guter Dienstleister verkauft euch nicht den Workflow, sondern die Gewissheit, dass der Workflow morgen noch läuft und dass jemand ihn versteht.

Ein Kunde aus der Logistik, rund 300 Mitarbeiter, hatte vorher zwei Jahre mit wechselnden Freelancern gearbeitet. Das Ergebnis war ein Flickenteppich aus dreißig Automatisierungen, die niemand mehr im Zusammenhang verstand, mit widersprüchlichen Namenskonventionen und ohne jede Übersicht, welcher Workflow welche Daten anfasst. Wir haben die erste Woche nur damit verbracht, das zu kartieren. Nicht zu bauen, zu verstehen. Das ist der Preis fehlender Kontinuität, und er wird später bezahlt, mit Zinsen.

Der Fehler, den auch Agenturen machen

Der große Vorbehalt gegen das Agenturmodell ist ein echter: Bauen ist nicht Betreiben. Viele Dienstleister sind hervorragend im Bauen und verlieren danach das Interesse. Sie liefern ein sauberes Projekt ab und verschwinden in den nächsten Auftrag, und ihr sitzt mit einem System da, das zwar gut dokumentiert, aber trotzdem verwaist ist. Wenn dann etwas bricht, ist der ursprüngliche Erbauer längst woanders, und ihr zahlt Stundensätze dafür, dass sich jemand neu einarbeitet in etwas, das eure Agentur selbst gebaut hat.

Deshalb ist bei der Auswahl einer Agentur die entscheidende Frage nicht "könnt ihr das bauen". Fast alle können bauen. Die entscheidende Frage ist "was passiert am Tag nach dem Go-Live". Gibt es einen Wartungsvertrag, eine definierte Reaktionszeit, einen benannten Ansprechpartner. Wenn die Antwort schwammig wird, kauft ihr ein Projekt, kein Betriebsmodell. Und ein Projekt löst euer eigentliches Problem nicht.

Eine Agentur ist die richtige Wahl, wenn Prozesse geschäftskritisch sind und ihr die Kompetenz nicht intern aufbauen wollt oder könnt. Der Wert liegt in der Betriebssicherheit, nicht im Bau. Prüft genau, ob der Dienstleister diesen Wert wirklich liefert oder nur baut und geht.

Modell 4: Intern aufbauen

Das vierte Modell ist die Einstellung oder Weiterbildung interner Leute, bis Automatisierung eine eigene Kompetenz im Haus ist. Bei größeren Organisationen ist das oft der Endzustand, ein internes Team oder zumindest eine benannte Rolle, die für Automatisierung zuständig ist. Volle Kontrolle, volles Wissen, sofort erreichbar.

Ab wann sich eine eigene Stelle rechnet

Die ehrliche Antwort ist rechnerisch. Eine interne Kraft, die sich hauptsächlich um Automatisierung kümmert, kostet voll gerechnet leicht 70.000 bis 90.000 Euro im Jahr. Das rechnet sich erst, wenn es genug zu tun gibt, um diese Person sinnvoll auszulasten, und wenn die Prozesse kritisch genug sind, dass sich schnelle interne Reaktionszeiten wirklich auszahlen.

Als grobe Faustregel: Unterhalb von etwa fünfzehn bis zwanzig produktiven, geschäftskritischen Automatisierungen ist eine dedizierte interne Stelle meistens überdimensioniert. Ihr zahlt dann ein volles Gehalt für jemanden, der die halbe Woche unterfordert ist. Oberhalb dieser Schwelle, und vor allem wenn Automatisierung ins Kerngeschäft einzahlt, wird die interne Lösung nicht nur wirtschaftlich, sie wird strategisch notwendig. Kritische Kompetenz gehört ins Haus.

Die Falle des einen Menschen

Auch intern lauert der Bus-Faktor. Wir sehen regelmäßig Organisationen, die stolz auf ihren "Automatisierungs-Menschen" sind, diesen einen begabten Kollegen, der alles gebaut hat und alles versteht. Das ist keine interne Kompetenz. Das ist ein Freelancer mit Festanstellung und dem gleichen Risiko. Geht dieser Mensch, geht das Wissen, nur dass ihr diesmal auch noch eine Kündigungsfrist und eine Nachbesetzung dazu bekommt.

Interne Kompetenz bedeutet mindestens zwei Menschen, die sich gegenseitig vertreten können, plus geschriebene Standards, an die sich beide halten. Alles darunter ist eine Ein-Personen-Abhängigkeit in schön. Wer intern aufbaut, muss von Anfang an in Redundanz denken, sonst hat er nur den teuersten aller Bus-Faktoren von eins geschaffen.

Internes Aufbauen ist die richtige Wahl bei hoher Kritikalität und ausreichendem Volumen. Es ist das teuerste Modell in der Anschaffung und das günstigste im Dauerbetrieb, aber nur, wenn es von Anfang an auf mehr als einer Person steht.

Die Kosten, die auf keiner Rechnung stehen

Jedes dieser Modelle hat einen sichtbaren Preis und einen unsichtbaren. Der sichtbare steht im Angebot: Tagessatz, Gehalt, Wartungspauschale. Der unsichtbare ist der, an dem die meisten Entscheidungen scheitern. Er besteht aus vier Posten.

Der erste ist die Reaktionszeit im Störfall. Wenn eine geschäftskritische Automatisierung um 22 Uhr an einem Freitag ausfällt, wie lange dauert es, bis jemand reagiert. Beim Selbstbauen und beim einmaligen Freelancer ist die Antwort oft: bis Montag. Bei einer Agentur mit Vertrag oder einem internen Team: Minuten bis Stunden. Diese Differenz kostet nichts, solange nichts passiert, und sehr viel in dem Moment, in dem etwas passiert.

Der zweite ist der Bus-Faktor. Wie viele Menschen verstehen das System. Bei eins ist jede Automatisierung eine Wette darauf, dass diese eine Person bleibt, gesund ist und Zeit hat. Diese Wette geht lange gut. Und irgendwann nicht.

Der dritte ist die Übergabefähigkeit. Existiert eine Dokumentation, die es einem Neuen erlaubt, das System zu übernehmen, ohne es zu reverse-engineeren. Fehlende Dokumentation ist ein Kredit, den ihr aufnehmt, ohne es zu merken, und der beim ersten Personalwechsel fällig wird.

Der vierte ist die strategische Abhängigkeit. Wenn euer gesamtes Automatisierungswissen extern liegt, gehört euch der Motor eures Betriebs nicht. Das muss kein Problem sein, solange die Beziehung gut ist. Es wird eins, wenn der Dienstleister die Preise erhöht, den Fokus wechselt oder schließt.

Die folgende Übersicht fasst zusammen, wie die vier Modelle auf diesen Dimensionen abschneiden.

Die Tabelle zeigt kein bestes Modell. Sie zeigt, dass jedes Modell auf einer anderen Achse gewinnt und verliert. Die Kunst ist nicht, das beste Modell zu wählen, sondern das passende für den jeweiligen Prozess.

Das Hybrid-Modell, das in der Praxis funktioniert

Die meisten reifen Setups, die ich kenne, sind keine reinen Modelle. Sie sind Mischungen, und die klügste Mischung trennt zwei Dinge, die oft in einen Topf geworfen werden: bauen und betreiben.

Was in der Praxis am besten funktioniert, ist eine klare Aufteilung nach Kritikalität. Unkritische, einfache Automatisierungen baut und betreibt das Team selbst. Wer eine Slack-Benachrichtigung will, soll sie sich bauen, dafür braucht es niemanden. Komplexe oder geschäftskritische Automatisierungen werden extern gebaut, mit sauberer Dokumentation, und dann bewusst intern übernommen oder unter Vertrag extern betreut. Das Bauen ist die teure, seltene Tätigkeit. Das Betreiben ist die günstige, dauerhafte.

Ein Muster, das wir oft empfehlen: extern bauen lassen, aber die Übergabe zur Bedingung machen. Ein guter Dienstleister baut nicht nur, er befähigt. Am Ende eines Projekts sitzt jemand aus eurem Haus mit am Tisch, versteht die Architektur, hat die Dokumentation und kann kleinere Änderungen selbst machen. Die Agentur bleibt für das Große und für den Notfall, aber ihr seid nicht mehr für jede Kleinigkeit abhängig. Das senkt die laufenden Kosten und den Bus-Faktor gleichzeitig.

Woran erkennt man einen Dienstleister, der das ernst meint? An seiner Haltung zur Übergabe. Wer euch bewusst abhängig hält, wer Dokumentation nur gegen Aufpreis liefert, wer Wissen als Druckmittel behandelt, der optimiert seinen eigenen Umsatz, nicht euren Betrieb. Wer euch dagegen aktiv befähigt, auch auf die Gefahr hin, dass ihr ihn seltener braucht, denkt langfristig. Genau den wollt ihr.

Eine praktische Entscheidungshilfe

Wie entscheidet man nun konkret? Zwei Fragen genügen für den ersten Schnitt: Wie kritisch ist der Prozess, und wie viele Automatisierungen betreibt ihr insgesamt.

Für Solo-Selbstständige und sehr kleine Teams mit einer Handvoll unkritischer Automatisierungen: selbst bauen, punktuell einen Freelancer für das, was euch überfordert. Ein internes Team wäre absurd, eine Agentur oft überdimensioniert. Investiert stattdessen in das eigene Verständnis.

Für wachsende Unternehmen mit einer zweistelligen Zahl an Automatisierungen, von denen einige geschäftskritisch sind: der klassische Punkt für einen kontinuierlichen Dienstleister oder einen festen Freelancer plus interne Grundkompetenz. Das Kritische extern absichern, das Einfache selbst machen, die Übergabe erzwingen.

Für größere Organisationen mit vielen kritischen Automatisierungen im Kerngeschäft: interne Kompetenz aufbauen, mindestens zwei Personen, mit einer Agentur als Verstärkung für Spitzen und Spezialfälle. Hier ist die interne Lösung nicht Luxus, sondern Risikomanagement.

Eine Frage, die uns oft gestellt wird: Sollte man geschäftskritische Automatisierung überhaupt jemals komplett auslagern? Die ehrliche Antwort ist: bauen ja, betreiben nur mit vertraglich gesicherter Reaktionszeit und niemals ohne interne Übergabe. Wer einen Prozess, von dem sein Geschäft abhängt, vollständig in fremde Hände legt, ohne selbst zu verstehen, wie er funktioniert, hat kein Automatisierungsproblem mehr, sondern ein Kontrollproblem. Die Automatisierung darf extern sein. Die Kontrolle darüber muss intern bleiben.

Was ich daraus gelernt habe

Nach Jahren in diesem Geschäft ist meine Überzeugung schlicht: Das Werkzeug ist selten die Ursache für gescheiterte Automatisierung. Das Betriebsmodell ist es fast immer. Ich habe saubere Systeme in Make sterben sehen, weil der eine Mensch ging, der sie verstand. Und ich habe unelegante n8n-Workflows über Jahre stabil laufen sehen, weil zwei Leute sie gemeinsam betreuten und beide wussten, was sie taten.

Zwei Dinge nehme ich aus jedem Projekt mit. Erstens, trennt bauen und betreiben in eurem Kopf, bevor ihr trennt, wer es bezahlt. Das Bauen ist ein Ereignis, das Betreiben ist ein Zustand, und die meisten Fehlentscheidungen kommen daher, dass jemand für das Ereignis bezahlt und den Zustand vergisst. Zweitens, bekämpft den Bus-Faktor von eins in jedem Modell, egal ob die eine Person intern oder extern sitzt. Ein System, das nur ein Mensch versteht, ist keine Automatisierung. Es ist eine Zeitbombe mit angenehmer Laufzeit.

Der Kunde aus Köln vom Anfang hat übrigens nicht das Tool gewechselt. Er ist bei Make geblieben. Geändert hat er das Modell: Wir haben das System dokumentiert, zwei interne Leute eingearbeitet und einen schlanken Wartungsrahmen mit uns aufgesetzt. Die Auftragsbestätigungen laufen seitdem wieder. Der Unterschied war nie das Werkzeug. Der Unterschied war die Antwort auf die Frage, die er anderthalb Jahre lang nicht gestellt hatte.

Wenn Sie unsicher sind, welches Modell zu Ihrem Betrieb passt, oder ob Ihre bestehenden Automatisierungen an einem einzelnen Menschen hängen, werfen Sie einen Blick in unseren kostenlosen Automations-Check. Wir schauen uns gemeinsam an, wie Ihre Automatisierungen betrieben werden, wo Ihr Bus-Faktor liegt und welches Modell für Ihre Größe und Kritikalität wirklich trägt.