Zusammenarbeit, Rollen und Governance

Zusammenarbeit, Rollen und Governance

0:00 Es gibt in fast jedem Unternehmen, das n8n einsetzt, einen bestimmten Workflow. Er liegt im persönlichen Bereich einer Person, er läuft seit anderthalb Jahren, und irgendwann hat sich der Betrieb daran gewöhnt. Niemand außer dieser einen Person kann ihn öffnen. Und wenn sie kündigt, kündigt der Prozess mit. Dieses Modul handelt davon, wie man das verhindert — mit Projekten, Rollen und einer Frage, die klingt wie Bürokratie und in Wahrheit Betriebssicherheit ist: Wer ist eigentlich zuständig?

Zusammenarbeit, Rollen und Governance

0:29 Das letzte Modul des dritten Tages, und es ist das am wenigsten technische. Trotzdem gehört es hierher, denn die Antworten wirken unmittelbar auf die Technik: Projekte trennen Ressourcen, Rollen begrenzen Zugriffe, Freigaben regeln, wer etwas produktiv schalten darf. Wir sehen uns die Rollenebenen an, sprechen über Verantwortung und Nachweise — und zum Schluss über eine Gruppe, die man entweder einbindet oder gegen sich hat: die Kolleginnen und Kollegen aus den Fachbereichen.

Projekte, Ordner und Teilen

0:55 Fangen wir beim Ort an. Wo ein Workflow liegt, entscheidet darüber, wer ihn sehen und ändern kann — und das ist keine Ordnungsfrage, sondern eine Frage der Verfügbarkeit. Projekte trennen Workflows, Variablen und Credentials in eigene Gruppen. Sie bündeln, was zusammengehört, und grenzen es gegen anderes ab. Und eine Eigenschaft ist dabei besonders praktisch: Eine Person kann in verschiedenen Projekten verschiedene Rollen haben.

1:21 Sie dürfen also im Projekt Ihres eigenen Teams bauen und im Projekt der Buchhaltung nur zusehen. Der Vergleich, der hier trägt, ist die Abteilung in einem Bürogebäude: Jede hat ihre Räume, ihre Schlüssel und ihre Ablage — und der Hausmeister kommt überall rein, aber nicht jeder ist Hausmeister. Vier Elemente, und beim ersten steckt die eigentliche Aussage. Workflows eines fachlichen Zusammenhangs — nicht einer Person.

1:47 Das ist der Bruch mit dem Naheliegenden: Man schneidet nicht nach „gehört Frau Meier", sondern nach „gehört zum Serviceprozess". Dazu die Credentials, die genau diese Workflows brauchen. Die Data Tables, die zwischen ihnen vermitteln — Sie erinnern sich, die sind projektgebunden. Und die Personen, die für diesen Zusammenhang verantwortlich sind. Wenn Sie so schneiden, ist die Rechtevergabe hinterher fast von selbst richtig.

2:13 Der erste Punkt ist der Fall aus meiner Einleitung: Der produktive Workflow bleibt im persönlichen Bereich seiner Erbauerin. Der zweite ist ein Schnittfehler, der sich rächt: Ein Projekt wird nach Abteilung geschnitten, obwohl der Prozess quer dazu läuft — dann braucht jeder Zugriff auf jedes Projekt, und die Trennung war umsonst.

2:31 Der dritte ist ein Verwaltungsproblem: Credentials werden einzeln geteilt, statt sie ins Projekt zu legen; das entzieht man später nur mühsam. Und der vierte ist die Rechnung, die am Ende kommt: Beim Ausscheiden einer Person fällt auf, dass niemand sonst Zugriff hat.

Rollen und Least Privilege

2:47 Jetzt zu den Rollen. n8n hat davon zwei Ebenen, und das ist keine Verkomplizierung — es ist die Voraussetzung dafür, dass jemand in einem Projekt bauen und in einem anderen nur lesen kann. Zwei Ebenen. Instanzrollen bestimmen, was jemand in der gesamten Instanz darf: Owner, Admin und Member, dazu eigene Instanzrollen. Projektrollen bestimmen, was jemand in einem bestimmten Projekt darf. Der Unterschied ist wichtig, weil die beiden Ebenen verschiedene Fragen beantworten.

3:16 Die Instanzrolle sagt: Darfst du die Plattform verwalten? Die Projektrolle sagt: Darfst du in diesem Prozess arbeiten? Jemand kann also einfaches Mitglied der Instanz sein und trotzdem Admin eines Projekts — und das ist meistens genau die richtige Kombination. Drei Rollen, und sie bilden eine klare Abstufung. Der Project Admin verwaltet Einstellungen und Mitglieder und darf alles ändern.

3:40 Der Project Editor darf Workflows, Credentials und Ausführungen ändern, aber nicht über Mitglieder entscheiden. Und der Project Viewer darf ausschließlich lesen — und, das ist die wichtige Feinheit, keine Workflows manuell ausführen. Ein Viewer kann also nichts auslösen, auch nicht versehentlich. Achten Sie auf die Fußzeile: Editor setzt Cloud Pro oder Enterprise voraus, Viewer sogar Enterprise.

4:04 Wer auf einer kleineren Stufe arbeitet, hat diese Abstufung schlicht nicht. Vier Sätze, und der erste ist der, an dem sich die Diskussion entzündet: Nicht jede Person, die baut, muss auch veröffentlichen dürfen. Das fühlt sich beim ersten Mal nach Misstrauen an und ist in Wahrheit Entlastung — wer nicht veröffentlichen kann, kann auch nicht versehentlich veröffentlichen.

4:26 Zweitens: Wer nur nachsehen soll, bekommt Viewer und kann nichts auslösen. Drittens: Die Trennung von Entwicklung, Freigabe und Betrieb beginnt hier, nicht erst beim Prozess. Und viertens der Merksatz: Rechte werden für Aufgaben vergeben, nicht für Personen. Personen wechseln die Aufgabe, Rechte wandern dann mit. Der erste Punkt ist der ehrlichste: Alle bekommen Admin, weil die Rollenvergabe im Alltag stört. Das ist eine bewusste Entscheidung, die man dann aber auch so benennen sollte.

4:55 Der zweite ist ein Wartungsproblem: Die Rolle wird beim Wechsel der Aufgabe nie wieder angepasst — Rechte wachsen über Jahre nur in eine Richtung. Der dritte ist eine Folge der Editionsfrage: Projektrollen fehlen mangels Plan, und dann bleibt es beim Alles-oder-nichts. Und der vierte hebelt alles aus: Der persönliche Bereich umgeht jede Projektregel.

Verantwortung und Nachweis

5:16 Kommen wir zu einer Frage, die man am besten beantwortet, bevor sie gestellt wird: Wer ist zuständig, wenn dieser Workflow um drei Uhr nachts scheitert? Vier Angaben, und keine davon ist technisch. Ein Name, der den fachlichen Zweck nennt, nicht die Technik — „Störungsannahme Notdienst", nicht „Webhook 3". Eine zuständige Person und eine benannte Vertretung; ohne Vertretung ist Urlaub ein Betriebsrisiko. Der Hinweis, ob und von wem eine Änderung freigegeben werden muss.

5:45 Und ein Eintrag, der die Änderung nachvollziehbar macht. Diese vier passen auf eine Sticky Note — aber besser in Ihre Betriebsdokumentation, denn Sticky Notes verschwinden beim Umbau. Der Aufwand ist minimal, der Nutzen zeigt sich genau einmal, und dann richtig. Das Audit-Protokoll hält fest, was auf der Instanz geschieht. Und hier eine Feinheit, die zu Verwirrung führt: Zwei Ereignisgruppen klingen ähnlich und meinen Verschiedenes.

6:11 Die Ereignisse rund um installierte Pakete betreffen Community Nodes auf der Instanz. Die Ereignisse mit dem Namen n8n package betreffen die übertragbaren Workflow-Archive aus dem letzten Modul. Wenn Sie also im Protokoll nach einer bestimmten Änderung suchen und die falsche Gruppe erwischen, finden Sie nichts — und das liegt nicht am Protokoll.

6:31 Der erste Punkt ist der, vor dem ich gerade gewarnt habe: Zuständigkeit steht in einer Sticky Note, die beim Umbau verschwindet. Der zweite ist eine Frage der Verbindlichkeit: Die Freigabepflicht existiert als Absprache, nicht als Einstellung — und Absprachen halten genau so lange wie der Termindruck es zulässt. Der dritte ist ein verbreiteter Selbstbetrug: Das Protokoll wird eingeschaltet, aber nie ausgewertet.

6:55 Und der vierte ist die Folge davon: Nach einem Vorfall lässt sich nicht rekonstruieren, wer wann was geändert hat.

Citizen Development steuern

7:03 Zum Abschluss die Gruppe, um die es in Governance-Diskussionen eigentlich geht: die Kolleginnen und Kollegen aus den Fachbereichen, die selbst automatisieren wollen. Verbieten erzeugt Schatten-IT. Leitplanken erzeugen Nachfrage. Community Nodes sind von Dritten entwickelte Bausteine, die auf der Instanz nachinstalliert werden. Sie erweitern n8n erheblich — und sie bringen fremden Code in Ihre Umgebung.

7:27 Deshalb lassen sie sich instanzweit steuern: vollständig abschalten, aus einer privaten Registry beziehen oder beim Start nicht laden. Die letzte Möglichkeit ist ein praktischer Notausgang, den man kennen sollte: Wenn ein fehlerhafter Baustein die Instanz am Hochfahren hindert, können Sie das Laden abschalten und kommen wieder herein.

7:46 Merken Sie sich das — im Ernstfall sucht man danach nicht gern. Fünf Schritte, und sie beschreiben ein Angebot, kein Verbot. Legen Sie fest, welche Prozesse ohne Freigabe automatisiert werden dürfen — es gibt solche, und das zu sagen schafft Vertrauen. Richten Sie ein Projekt je Fachbereich ein statt persönlicher Bereiche.

8:06 Stellen Sie Vorlagen und geprüfte Sub-Workflows als Bausteine bereit; das ist der wirksamste Hebel, denn gute Bausteine werden benutzt. Beschreiben Sie den Weg, auf dem ein Workflow produktiv wird. Und sehen Sie regelmäßig durch, was entstanden ist — und übernehmen Sie das Gute. Ein Workflow-Katalog macht aus Einzellösungen wiederverwendbare Bausteine.

8:27 Der erste Punkt ist ein Lieferkettenrisiko: Community Nodes werden freigegeben, ohne den Herausgeber zu prüfen — dazu am fünften Tag mehr. Der zweite ist die Situation, die man vermeiden will: Der Fachbereich baut produktive Prozesse ohne jede Freigabe. Der dritte ist der Grund dafür, und er liegt selten beim Fachbereich: Es gibt Regeln, aber keinen Weg, auf dem ein Workflow sie erfüllen kann.

8:50 Wer Freigabe verlangt, muss auch sagen, bei wem. Und der vierte ist eine verpasste Chance: Niemand sieht sich an, was im Fachbereich tatsächlich entstanden ist — dabei stecken dort oft die besten Ideen.

Übung

9:03 Jetzt entwerfen Sie das Modell für Kesselwerk. Kein technischer Aufbau diesmal, sondern eine Organisationsentscheidung — die aber unmittelbar in Einstellungen mündet. Bei Kesselwerk bauen vier Personen Workflows: zwei aus der IT, eine Disponentin, ein Servicetechniker. Produktiv laufen drei Prozesse — Störungsannahme, Ersatzteilnachbestellung und der nächtliche Abgleich mit Kundenkreis.

9:27 Und dann kommt der Satz, der die Übung erst interessant macht: Bisher liegt alles im persönlichen Bereich der IT. Das ist keine Fahrlässigkeit, das ist der Normalzustand nach einem erfolgreichen Pilotprojekt. Genau an diesem Punkt entscheidet sich, ob daraus ein Betrieb wird. Das Lernziel: Zugriffsrechte aus den Aufgaben eines Prozesses ableiten statt aus der Bequemlichkeit des Alltags.

9:50 Erfolgreich sind Sie, wenn jeder produktive Workflow in einem Projekt liegt, eine zuständige Person und eine Vertretung hat und für jede Rolle begründet ist, warum sie nicht weniger Rechte bekommt. Achten Sie auf diese Formulierung — die Begründungslast liegt bei den Rechten, nicht bei ihrer Einschränkung. Wer früh fertig ist, beschreibt, was beim Ausscheiden der zuständigen Person geschieht. Das ist die Frage, mit der ich dieses Modul eröffnet habe.

10:16 Fünfzig Minuten, fünf Schritte. Gruppieren Sie die drei produktiven Workflows nach fachlichem Zusammenhang — vielleicht sind es drei Projekte, vielleicht eines, das sollen Sie entscheiden. Legen Sie je Gruppe ein Projekt fest und verschieben Sie die Ressourcen dorthin. Ordnen Sie den vier Beteiligten Projektrollen zu und begründen Sie die Wahl; der Servicetechniker ist dabei der interessante Fall.

10:38 Legen Sie fest, welche Workflows eine Freigabe brauchen und von wem. Und schreiben Sie die Regeln für den Fachbereich in fünf Sätzen auf — fünf, nicht fünfzig. Vier Fallen. Erstens: Rollen werden nach Hierarchie vergeben statt nach Aufgabe — der Abteilungsleiter bekommt Admin, weil er Abteilungsleiter ist. Zweitens: Die Vertretung wird benannt, hat aber keinen Zugriff; das ist schlimmer als keine Vertretung, weil es sich nach Absicherung anfühlt.

11:06 Drittens: Die Freigabepflicht gilt für alles und wird deshalb umgangen — Regeln, die nicht praktikabel sind, erzeugen Umgehungen, nicht Sicherheit. Und viertens der Klassiker: Das Modell entsteht auf Papier und wird in der Instanz nie eingerichtet.