n8n verabschiedet sich beim internen Automatisierungsteam vom Service-Desk-Modell

Wo das Service-Desk-Modell an seine Grenzen stößt

Da Costa argumentiert, ein zentrales Automatisierungsteam löse ein reales Problem, doch genau die gute Lösung schaffe ein neues. Der Rest der Organisation verlasse sich auf das Team, der Engpass werde also nicht beseitigt. In ihren Worten wird er nach unten verlagert. Sei der Rückstau erst abgearbeitet, bleibe eine Frage, für die niemand Budget eingeplant habe: Wer pflegt all das, was das Team gebaut hat?

Bei n8n wurde das Team gegründet, um ein klares Problem zu lösen. Laut da Costa versanken die Mitarbeitenden in manueller Arbeit, und niemand im Unternehmen hatte genug Überblick, um das systematisch zu beheben. Deshalb wurden Entwickler eingestellt, die Workflows bauen. Sie nennt das damals die richtige Entscheidung und sagt, das Team habe seine Aufgabe bemerkenswert gut erfüllt. Anfang dieses Jahres übernahm sie die Leitung der Funktion und stellte fest, dass das Modell an seine Grenze gekommen war. n8n habe "somewhere north of 12,000 internal workflows", schreibt sie, und kein Team könne all diese bauen und warten.

Vom Bauen von Automatisierungen zum Aufbau einer Kultur

Laut da Costa hat sich die Leitfrage geändert. Es gehe nicht mehr darum, wie sich mehr Automatisierungen bauen lassen, sondern darum, "how do I build a company where every team can think and act like automation engineers?" Nach der alten Frage bemisst sich Erfolg am Durchsatz. Nach der neuen daran, wie viele Teams das Automatisierungsteam gar nicht mehr brauchen.

Sie geht auch auf das Argument ein, einfacheres Bauen mache ein zentrales Team überflüssig. Workflows, Agenten und interne Tools zu bauen, werde für Menschen ohne Entwicklerhintergrund deutlich zugänglicher, stellt sie fest. Ihrer Ansicht nach macht das die Aufgabe wichtiger, wenn auch anders. Knapp werde die Fähigkeit zu beurteilen, ob etwas gebaut werden sollte, woran man erkennt, dass es funktioniert hat, welches Tool passt und wer die Verantwortung trägt, wenn es ausfällt.

Die Prinzipien in der Praxis

Da Costa zufolge hat sich der Wandel zu vier Prinzipien verdichtet. Der vorliegende Auszug behandelt die ersten drei ausführlich.

• Die Bauenden befähigen, nicht nur die Bauwerke liefern. Das Team stellt Enablement über das Ausliefern von Workflows. Ein Entwickler saß in diesem Quartal bei einer Kollegin, während sie ihre eigene Automatisierung debuggte, statt sie für sie zu schreiben. Auf Abteilungsebene umfasst der Ansatz Schulungen, wiederverwendbare Workflows, Sprechstunden und ein Netzwerk technischer Champions, je eine Person pro Abteilung, die die Prozesse des Teams versteht und dessen Tools verantwortet. Auf Unternehmensebene erarbeitet n8n ein AI-Fluency-Framework mit gemeinsamen Standards für den verantwortungsvollen Einsatz von KI.
• Vor dem Bauen eine Ausgangsbasis verlangen. Da Costa beschreibt einen KI-Agenten, der in einem Monat eine sechsstellige Summe an Pipeline erzeugte. Als sie fragte: "Compared to what?", erwies sich der Vergleich als vertrackt. Der Agent läuft rund um die Uhr, und die menschlichen SDRs bearbeiteten inzwischen überwiegend schwierigere, eskalierte Fälle, die der Agent bereits vorgefiltert hatte. Bevor ein Projekt startet, fragt ihr Team das anfragende Team deshalb, wie oft die Arbeit anfällt, wie lange sie dauert, wie viele Personen daran beteiligt sind, was dabei herauskommt und was als spürbare Verbesserung gelten würde. Schätzungen sind erlaubt.
• Das Tool passend zum Problem wählen. Das Team plädiert oft für Kaufen statt Bauen, was da Costa zufolge angesichts des Firmennamens n8n manche überrascht. Als Faustregel gilt bei ihr: Ein bewährtes, spezialisiertes Tool, das seit einem Jahr oder länger am Markt ist, ist meist die bessere Wahl. Wer intern baut, übernimmt auf unbestimmte Zeit Wartung und Sicherheitsangriffsfläche, während ein Anbieter entlang seiner eigenen Roadmap weiterliefert.

Was das für andere Organisationen bedeutet

Da Costa betont, das Muster sei nicht auf n8n beschränkt, und sie halte es nicht für einen Fehler. Sie erwartet, dass die meisten Organisationen, vor allem große Konzerne, nach dem Aufbau eines zentralen Teams und dem Abarbeiten des Rückstaus zu einer ähnlichen Erkenntnis gelangen. Ihr Rat an alle, die eine vergleichbare Rolle übernehmen: den natürlichen Verlauf bewusst unterbrechen, besonders wenn das Ziel eine hochautomatisierte, KI-first ausgerichtete Organisation ist.

Die praktische Lehre aus ihrem Bericht ist ein Wechsel dessen, woran ein Automatisierungsteam gemessen wird. Ausgelieferte Workflows und geschlossene Tickets treten zurück hinter die Frage, wie gut andere Teams selbstständig arbeiten können, gestützt auf Champions, gemeinsame Standards und eine klare Ausgangsbasis vor Projektbeginn. Der Auszug endet mitten im dritten Prinzip, das vierte wird hier daher nicht behandelt.