Wird geladen
In dieser LektionAm Ende kannst du
  • Beschreibe die Anpassungen, die du steuerst (Skills und Plugins, Projekte und Organisationsanweisungen)
  • Erkläre, warum Anpassungen Governance benötigen und wie die Einstellungen, die eine Haltung durchsetzen, zusammenwirken
  • Wähle deine Governance-Haltung, einschließlich der Frage, ob eine Haltung die gesamte Organisation abdeckt, und erkenne die Signale, dass sie nicht passt

Dies ist die dritte der fünf Entscheidungen: Governance. Du hast festgelegt, worauf Claude zugreifen kann. Jetzt lernst du die Anpassungen kennen, die verändern, wie Claude arbeitet, und wie sich diese Änderungen in deiner gesamten Organisation fortpflanzen können. Skills, gemeinsam genutzte Setups und die dauerhaft aktive Anleitung, die deine Organisation Claude gibt, gehören alle hierher, weil sie eine Frage auf unterschiedlichen Ebenen beantworten: Wie viel von dem, was ein Mitglied einrichtet, kann andere erreichen?

Benutzeranpassungen und Organisationsanweisungen

Diese Lektion konzentriert sich auf drei Arten von Anpassungen. Die folgenden Abschnitte erläutern jede einzelne und behandeln dann die Haltung (die Regel deiner Organisation dafür, wer sie erstellen, teilen und skalieren darf), die steuert, wie weit sie sich verbreiten.

  1. Skills und Plugins

    Ein Skill ist ein Ordner mit Anweisungen, Skripten und Ressourcen, den Claude lädt, wenn eine Aufgabe dies erfordert. In der Praxis verpackt er einen Workflow, sodass Claude ihn jedes Mal auf die gleiche Weise ausführt: ein erster Vertragsprüfer, den dein Rechtsteam anhand seines eigenen Playbooks laufen lässt, ein Zusammenfassungs-Formatierer, der in deinem Stil schreibt, oder ein Vorfall-Postmortem in deiner Vorlage. Mit einem Skill kennt Claude deine Konventionen bereits, sodass niemand sie in jedem Gespräch erneut erklären muss.

    Ein Plugin bündelt Skills mit anderen Komponenten (Konnektoren, Sub-Agenten), sodass ein ganzes Toolkit auf einmal installiert wird; dieselbe Haltung gilt für Skills und Plugins, daher verwendet der Rest dieser Lektion „Anpassungen" für diese Familie. Ein Plugin kann einem Mitglied keinen Konnektor oder keine Fähigkeit geben, die seine Gruppen nicht enthalten; es arbeitet mit dem, was bereits vorhanden ist.

  2. Projekte

    Ein Projekt ist ein Arbeitsbereich mit eigenem Kontext und eigenen Dateien, die für alle, die darin arbeiten, erhalten bleiben. Das Teilen von Projekten entscheidet, ob ein Projekt, das ein Mitglied erstellt, mit anderen in deiner Organisation geteilt werden kann und wie weit. Wenn du „Öffentliche Projekte" ausschaltest, werden alle öffentlichen Projekte privat, sodass jeder, der nicht zu einem hinzugefügt wurde, den Zugriff verliert. Niemand kann ein neues Projekt öffentlich machen, das Teilen mit namentlich genannten Personen oder Gruppen läuft jedoch weiter. Das Teilen eines Projekts mit einer Gruppe befindet sich in der Beta-Phase, sodass die Granularität, die du siehst, von der einer anderen Organisation abweichen kann; die Einstellung selbst ist die Haltungsentscheidung.

  3. Organisationsanweisungen

    Organisationsanweisungen sind ein Block von Anleitungen, der in die Gespräche deiner Mitglieder mit Claude auf den Oberflächen einbezogen wird, die dies unterstützen: der dauerhaft aktive Kontext deiner Organisation. Nutze ihn, um Claude feststehende Fakten und feststehende Anweisungen zu geben: wer deine Organisation ist und wie sie strukturiert ist, den Ton für kundenorientiertes Schreiben oder eine Regel für jede Sitzung, etwa das Zitieren des Quelldokuments, wann immer Claude internes Material zitiert. Plutos Version erscheint später in dieser Lektion.

Warum Anpassungen Governance benötigen

Die Möglichkeit, Anpassungen zu teilen, bringt einen echten Mehrwert für die Erfahrung der Mitglieder bei der Arbeit mit Claude. Ein Skill, den ein Mitglied erstellt, kann einen Workflow kodifizieren, den ein Team bereits ausführt, sodass er sich in einer einheitlicheren und oft schnelleren und qualitativ hochwertigeren Form verbreitet. Mitglieder können auch Workflows erstellen, die es vor Claude nicht gab, und diese in deiner gesamten Organisation skalieren.

Die Kehrseite ist Wildwuchs: Ohne Governance könnte deine Organisation am Ende Dutzende nahezu identischer Skills haben, ungetestete Workflows, die sich auf Teams ausbreiten, die annehmen, sie seien überprüft worden, oder sensible Daten, die durch das organisationsweite Teilen eines Projekts zugänglich gemacht werden. Governance ist die Art und Weise, wie du die Verbreitung bewusst steuerst, und die Entscheidung, wem du erlaubst, Anpassungen zu erstellen und zu skalieren, ist der Kern davon.

Governance läuft auf drei Fragen hinaus:

  1. Was dürfen Anpassungen tun, wenn sie ausgeführt werden?
  2. Wer kann sie erstellen, und wer kann sie nutzen?
  3. Wie gelangen sie von dem Mitglied, das sie erstellt hat, zu allen anderen?

Was Anpassungen tun können, wenn sie ausgeführt werden

Was ein Skill tun darf, wenn er ausgeführt wird, hängt von Fähigkeiten ab: Manche Skills führen Code aus, manche durchsuchen das Web, manche lesen Dateien. Ein Skill wird nur ausgeführt, wenn die Fähigkeit, die er benötigt, aktiviert ist. Wenn du also eine Fähigkeit aktivierst, prüfe beide Schalter zusammen: die Fähigkeit und die Skills deiner Teams, die darauf angewiesen sind. Skills erfordern Codeausführung: In den Organisationseinstellungen aktivierst du die Einstellung „Cloud-Codeausführung und Dateierstellung" (in manchen Konsolen noch als „Codeausführung und Dateierstellung" angezeigt) sowie „Skills", bevor Mitglieder überhaupt einen Skill nutzen können. Lässt du eine Fähigkeit, von der ein Skill abhängt, organisationsweit ausgeschaltet, steht der Skill, den dein Finanzteam möchte (etwa ein Recherche-Zusammenfasser), überhaupt nicht zur Verfügung.

Wer sie erstellen und nutzen kann

Ob Mitglieder Skills erstellen und nutzen können, ist eine organisationsweite Einstellung. Sie gehört zu der Handvoll Einstellungen, die über deinen Gruppen stehen, statt an eine einzelne gebunden zu sein, wobei die Fähigkeit „Skills erstellen" einer benutzerdefinierten Rolle entscheidet, wer bauen darf, und ihre Freigabefähigkeiten entscheiden, wer teilen darf. Die Verteilung kann jedoch an eine Gruppe gebunden sein: Ein Skill, der in ein Plugin gebündelt ist, kann einer bestimmten Gruppe zugewiesen werden, sodass nur diese Gruppe ihn sieht.

Wie sie zu allen anderen gelangen

Wie sich ein Skill verbreitet, wird durch vier separate Verteilungskontrollen gesteuert, die zusammen deine Haltung bilden:

  1. Owner-Bereitstellung: Ein Owner lädt einen Skill hoch, und er erreicht die Skill-Liste jedes Mitglieds, standardmäßig aktiviert (Mitglieder können ihn für sich selbst ausschalten). Nur Owner und alle, deren Rolle „Bibliotheken" auf „Kann verwalten" gesetzt hat, können diese hinzufügen oder entfernen.
  2. Skill-Freigabe (standardmäßig aktiviert, sofern deine Organisation keine Skills-Präferenz festgelegt hat): Mitglieder teilen einen Skill oder ein von ihnen erstelltes Plugin direkt mit bestimmten Kolleginnen und Kollegen, die ihn nutzen, aber nicht bearbeiten können.
  3. Mit Gruppen teilen (standardmäßig deaktiviert): Mitglieder teilen einen Skill oder ein Plugin mit einer ganzen Gruppe, bei der „Ressourcen mit dieser Gruppe teilen" aktiviert ist.
  4. Veröffentlichung („Aus", „Erfordert Überprüfung" oder „Offen"): Mitglieder reichen einen Skill oder ein Plugin bei der Organisationsbibliothek ein, wo er die gesamte Organisation erreichen kann (bei der Überprüfung entscheidet der Genehmiger, ob alle oder bestimmte Gruppen ihn erhalten). Bei „Aus" können Mitglieder nichts einreichen, Owner können jedoch weiterhin direkt Skills für die gesamte Organisation hinzufügen. Bei „Erfordert Überprüfung" wartet jede Einreichung und jede spätere Version darauf, dass ein Owner oder jemand, dessen Rolle „Bibliotheken" auf „Kann verwalten" gesetzt hat, sie genehmigt; niemand kann seine eigene genehmigen. Bei „Offen" können Einreichungen ohne Überprüfung veröffentlicht werden. Hat niemand in deiner Organisation einen Wert für die Veröffentlichung festgelegt, gilt ein Standardwert, und der ist nicht für jede Organisation derselbe, prüfe also, welchen Wert du hast.

Plutos Governance

Pluto fährt eine geteilte Haltung: Mitglieder in den meisten Gruppen bauen frei und teilen innerhalb ihrer Gruppe, und alles, was über die Gruppe hinausgehen soll, durchläuft einen benannten Prüfer in dieser Gruppe; Payments & Trust fährt strenger, sodass dort nichts Erstelltes überhaupt geteilt wird, bevor es genehmigt ist (Genehmigung zuerst), eine Regel, die Pluto über seinen Prüfer und seine Richtlinie durchsetzt; eine benutzerdefinierte Rolle kann außerdem die Skill-Freigabe und die Projekt-Freigabe für die Mitglieder einer Gruppe ausschalten, falls du möchtest, dass das Produkt einen Teil einer solchen Regel übernimmt. Plutos Organisationsanweisungen nennen Pluto, seine fünf Geschäftsbereiche und seinen Hausstil für kundenorientiertes Schreiben. Sie lauten: „Du unterstützt Pluto, ein Fintech-Unternehmen mit fünf Geschäftsbereichen: Retail, B2B, Payments & Trust, Platform und Ops. Kundenorientiertes Schreiben ist einfach und kurz, im Hausstil von Pluto."

Das interaktive Widget unten verfolgt einen Skill durch den Build-Review-Publish-Zyklus: Wechsle zwischen den Haltungen — Plutos offenes Bauen mit überprüfter Verbreitung für die meisten Gruppen, Genehmigung zuerst für Payments & Trust — und beobachte, wo das Prüf-Gate liegt.

Wird geladen

1 · Deine Entscheidung

Deine Anpassungs-Haltung: Wie frei erstellen und teilen Mitglieder Skills, Plugins und Projekte, und deckt eine Haltung die gesamte Organisation ab?

2 · Die Wahlmöglichkeiten, die du hast

Es gibt hier keine einzige Haltung, die die meisten Unternehmen teilen; die Haltung richtet sich danach, wie dein Unternehmen bereits mit den Tools umgeht, die seine eigenen Mitarbeiter bauen. Drei Haltungen decken die meisten Fälle ab:

Die WahlWann du sie wählen würdestWas sie bedeutet und welche Auswirkungen sie hat
Offenes Bauen, überprüfte VerbreitungDu möchtest, dass Mitglieder frei experimentieren und bauen können, und du hast ein CoE oder eine Champions-Gruppe, die prüfen kann, was über den Ersteller hinaus verbreitet wird.Jeder kann Anpassungen für sich selbst bauen, aber die Beförderung einer Anpassung zur gesamten Organisation durchläuft zunächst eine Überprüfung. Mitglieder experimentieren weiterhin frei, und da die Veröffentlichung auf „Erfordert Überprüfung" gesetzt ist, erreicht nichts, was ein Mitglied einreicht, die Organisationsbibliothek, bevor ein Prüfer es genehmigt hat.
Einstellungen: Skill-Freigabe aktiviert, Veröffentlichung auf „Erfordert Überprüfung" gesetzt.
ZentralisiertEin besetztes zentrales Team verantwortet bereits, wie die Tools, die deine Mitarbeiter bauen, erstellt und skaliert werden, und du möchtest, dass Claude-Anpassungen darüber laufen.Ein besetztes Team baut und prüft alles; Mitglieder installieren aus dem, was für die Organisation veröffentlicht wurde. Alles, was genutzt wird, erfüllt deine Standards; der Kompromiss ist eine langsamere Verbreitung.
Einstellungen: Skill-Freigabe deaktiviert, Veröffentlichung auf „Aus" gesetzt; nur Owner-Bereitstellung.
Vollständig offenEine kleine oder vertrauensstarke Organisation, in der Mitglieder die Arbeit der anderen ohnehin gegenseitig prüfen würden und eine formale Überprüfung sie nur verlangsamen würde.Jeder baut, teilt und installiert; die Prüfung erfolgt sozial statt prozedural. Nichts bremst die Verbreitung.
Einstellungen: alle Freigaben aktiviert, Veröffentlichung auf „Offen" gesetzt.

3 · Wenn du das später änderst

Die meisten Haltungseinstellungen sind frei umkehrbar: Änderst du eine, gilt sie ab diesem Zeitpunkt, ohne dass Rückgängigmachen nötig ist. Die beiden Richtungen sind jedoch nicht gleichwertig. Lockern ist kostenlos — erlaube mehr Bauen und Teilen, und Mitglieder gewinnen Spielraum. Verschärfen ist die Richtung, bei der du bewusst vorgehen solltest, und zwei Einstellungen verhalten sich gegensätzlich. Das Ausschalten von „Öffentliche Projekte" wirkt sich auf das bereits Vorhandene aus: Öffentliche Projekte werden privat und bleiben privat, wenn du es wieder einschaltest. Eine strengere Veröffentlichungseinstellung entfernt nichts bereits Veröffentlichtes, das in der Organisationsbibliothek bleibt, bis ein Owner es entfernt, also überprüfe die stark genutzten Skills anhand der neuen Regel und entferne alle, die ihr nicht entsprechen.

Ressourcen einrichten

Wenn du die Entscheidung getroffen hast: Die Einstellungen für Erstellen und Teilen, Codeausführung, Projekt-Freigabe und Organisationsanweisungen befinden sich in den Organisationseinstellungen.

Lektionsaktivität

Was du deinem Governance-Verantwortlichen und deiner Sicherheitsleitung mitbringen solltest: die Haltung, die du gewählt hast, den Prüfer für Anpassungen, bevor sie sich organisationsweit verbreiten, und für welche Gruppen, sowie ob die Codeausführung aktiviert bleibt und für wen. Wenn die Haltung nicht allein von dir festgelegt wird, ist dies das Briefing für sie.

Bevor du eine Haltung festhältst, prüfe sie anhand von drei Fragen, die du bereits beantworten kannst:

  1. Welche der drei Haltungen entspricht dem, wie dein Unternehmen heute mit den Tools umgeht, die seine eigenen Mitarbeiter bauen, und benötigt eine regulierte Gruppe eine strengere Haltung als der Rest?
  2. Wenn deine Haltung ein Prüf-Gate hat, wer ist der Prüfer, und für welche Gruppen?
  3. Was sollten deine Organisationsanweisungen sagen: die zwei oder drei Zeilen, die jedes Gespräch darüber tragen sollte, wer du bist und welche Standards Claude befolgen soll?

→ Halte dies im Begleitmaterial zum Mitarbeiten fest, Abschnitt Lektion 8.

Downloads

  • Work-along companion (Word)

    The editable Word version of the rollout plan you fill in lesson by lesson.

    Herunterladen
  • Work-along companion (PDF)

    The same rollout plan as a fillable PDF.

    Herunterladen

Was kommt als Nächstes

Mitglieder können jetzt innerhalb der von dir festgelegten Grenzen bauen und teilen. Das nächste Modul, Ausgaben, widmet sich dem, was diese Aktivität kostet: wo Ausgabenobergrenzen in deiner Organisation liegen und wer jeweils verantwortlich ist, wenn ein Mitglied sie erreicht.