# Eine neue Copilot-Funktion oder ein neues Modell in Ihrem Unternehmen pilotieren

Pilotieren Sie ein neues Copilot Feature oder Modell, um die Einführung zu überprüfen, Kosten zu steuern und Nachweise für ein breiteres Rollout zu sammeln.

Dieses Tutorial führt Sie Schritt für Schritt durch die vollständige Durchführung eines Piloten: das Festlegen eines Budgets, das Aktivieren der Funktion für eine begrenzte Gruppe, das Überwachen der Ergebnisse sowie die Nutzung der gewonnenen Erkenntnisse, um eine Go-/No-Go-Entscheidung zu treffen und zu kommunizieren.

## Bevor Sie ihr Pilotprojekt starten

Bevor Sie etwas aktivieren, stellen Sie sicher, dass Sie das Feature oder Modell ausgewertet und bestätigt haben, dass es Ihre Complianceanforderungen erfüllt. Siehe [Vorbereiten neuer Features und Modelle](/de/copilot/concepts/preparing-for-new-features-and-models).

Wenn Sie nicht sicher sind, ob ein Feature oder Modell sicher zu aktivieren ist, wenden Sie sich an Sicherheits- und Complianceteams in Ihrem Unternehmen, bevor Sie mit dem Pilotprojekt beginnen.

### Definieren, wie erfolgreich aussehen soll

Legen Sie vor dem Start fest, wie ein „Go“ aussieht, damit Sie das Pilotprojekt anhand eines Plans bewerten statt im Nachhinein. Notieren Sie sich einige konkrete Erfolgskriterien, die die Einführung abdecken (z. B. einen Mindestanteil an aktiven Benutzern), Kosten (bleiben Sie innerhalb der von Ihnen festgelegten Obergrenze) und qualitatives Feedback (z. B. die meisten Teilnehmer würden die Funktion empfehlen). Sie vergleichen die tatsächlichen Ergebnisse des Piloten anhand dieser Kriterien in [Treffen einer Go-/No-Go-Entscheidung](#make-a-go-or-no-go-decision).

Planen Sie auch, wie lange das Pilotprojekt ausgeführt wird. Budgets und der gemeinsame Pool von AI credits werden in jedem Abrechnungszyklus zurückgesetzt. Planen Sie daher, dass das Pilotprojekt mindestens einen vollständigen Abrechnungszyklus umfasst, in der Regel vier bis sechs Wochen; bei einer kürzeren Laufzeit liegen möglicherweise zu wenige Kosten- und Akzeptanzdaten vor, um eine belastbare Schlussfolgerung zu ziehen.

### Auswählen, wer in Ihre Pilotgruppe aufgenommen werden soll

Da Funktionen und Modelle auf Organisationsebene aktiviert sind, erhält jeder, der seine Copilot-Lizenz über diese Organisation erhält, Zugriff, nicht nur eine gezielt ausgewählte Teilgruppe, und auch nicht unbedingt jeder, der ihr angehört. Suchen Sie also anstelle der Auswahl von Einzelpersonen nach einer Organisation, deren lizenzierte Bevölkerung bereits die folgenden Kriterien widerspiegelt:

* **Entwickler, die echte, sinnvolle Arbeit leisten.** Pilotteilnehmer sollten das Feature für die Sprachen, Frameworks und Repositorys verwenden, die für Ihre Organisation von Bedeutung sind, und nicht für Wegwerfprojekte. Nutzungs- und Kostensignale sind nur vertrauenswürdig, wenn sie von echter Arbeit stammen.
* **Eine Mischung aus Fähigkeiten und Seniorenstufen.** Beziehen Sie sowohl erfahrene Ingenieure als auch Personen ein, die mit Ihrer Codebasis oder mit Copilot noch nicht vertraut sind. Verschiedene Erfahrungsebenen verwenden das Feature unterschiedlich und entdecken unterschiedliche Werte und verschiedene Probleme.
* **Eine Reihe von Teams und Workflows.** Ein Feature, das dem Workflow eines Teams hilft, hilft möglicherweise nicht bei anderen. Wenn Sie mehrere Teams einbeziehen, erhalten Sie ein verlässlicheres Bild davon, wo die Funktion Mehrwert schafft und wo nicht.
* **Personen, die bereit sind, Feedback zu geben.** Ein Großteil des Werts eines Pilotprojekts kommt aus qualitativem Feedback, nicht nur aus Metriken. Wählen Sie Teilnehmer aus, die interagieren, melden, was funktioniert und was nicht, und antworten Sie, wenn Sie ihre Eingabe anfordern.

Wenn keine Ihrer Organisationen beispielsweise passt, wenn die richtige Mischung aus Personen in mehreren Organisationen verteilt ist oder Ihre Organisationen zu groß sind, um als enthaltenes Pilotprojekt zu dienen, können Sie eine dedizierte Organisation erstellen und nur Ihre ausgewählten Benutzer hinzufügen. Dadurch können Sie genau steuern, wer enthalten ist, aber es bedeutet, den Repositoryzugriff für diese Benutzer zu migrieren oder zu duplizieren, und es funktioniert möglicherweise nicht gut für Features wie Copilot-Cloud-Agent diese, die von einem tiefen Kontext auf Repositoryebene abhängen. In diesem Lernprogramm wird davon ausgegangen, dass Sie eine vorhandene Organisation verwenden; Wenn Sie die dedizierte Organisationsroute durchlaufen, behandeln Sie das Einrichten und Hinzufügen von Mitgliedern als zusätzlichen Schritt, bevor [Sie das Feature für Ihre Pilotgruppe aktivieren](#enable-the-feature-for-your-pilot-group).

### Kosten schätzen und eine Budgetobergrenze festlegen

Viele der Features und Modelle, die Sie testen möchten, werden über die Nutzung in Rechnung gestellt, sodass die Ausgaben nicht durch die Anzahl der Lizenzen festgelegt werden, die Sie zuweisen.

Eine Handvoll aktiver Entwickler, die ein Grenzmodell oder ein agentisches Feature verwenden, könnte mehr verbrauchen, als Sie erwarten würden. Ermitteln Sie eine grobe Schätzung der Kosten des Pilotprojekts, und entscheiden Sie sich für eine Obergrenze, die Sie ausgeben möchten, bevor Sie das Feature aktivieren.

Beginnen Sie, indem Sie verstehen, wie das Feature oder Modell in Rechnung gestellt wird. Nutzungsbasierte Features verbrauchen GitHub AI Credits, und die Kosten für jede Interaktion hängen vom Modell und der Anzahl der verbrauchten Token ab. Um zu verstehen, welche Funktionen auf die Nutzung angerechnet werden, wie enthaltene Guthaben unternehmensweit zusammengefasst werden und wie Mehrnutzung berechnet wird, siehe [Nutzungsbasierte Abrechnung für Organisationen und Unternehmen](/de/copilot/concepts/billing/usage-based-billing-for-organizations-and-enterprises).

Um eine Schätzung zu erstellen, kombinieren Sie drei Zahlen:

* **Die Anzahl der Personen in Ihrer Pilotgruppe**, die Sie im vorherigen Abschnitt definiert haben.
* **Wie stark Sie davon ausgehen, dass sie das Feature verwenden.** Sie werden dies erst wissen, wenn die Benutzer es tatsächlich verwenden. Wählen Sie daher eine absichtlich hohe Schätzung aus, anstatt sie genau vorherzusagen. Wenn Sie bereits ein vergleichbares Feature oder Modell eingeführt haben, verwenden Sie die tatsächliche Verwendung als Referenzpunkt. Wenn nicht, gehen Sie davon aus, dass sie häufig pro Entwickler verwendet werden, da agentische Features und Grenzmodelle pro Interaktion mehr kosten als eine Frage des schnellen Chats. Eine kleine Gruppe, die intensiv arbeitet, kann mehr kosten als eine große Gruppe, die die Funktion nur gelegentlich nutzt.
* **Das enthaltene Kontingent, auf das Sie zurückgreifen können.** Jede zugewiesene Lizenz enthält einen monatlichen Betrag, AI credits der auf Unternehmensebene zusammengefasst ist, sodass einige der Nutzungen des Pilotprojekts abgedeckt werden können, bevor eine Überlastung in Rechnung gestellt wird.

Verwenden Sie diese, um eine Obergrenze festzulegen: Das Maximum, das Sie für das Pilotprojekt ausgeben möchten, bevor Sie anhalten und neu bewerten möchten. Wählen Sie eine Zahl aus, die dem Pilotraum die Möglichkeit gibt, aussagekräftige Nutzungsdaten zu generieren, während Sie Ihre Exposition abstellen, wenn der Verbrauch höher ist als erwartet. Wenn Sie ihre Pilotgruppengröße später anpassen, lesen Sie diese Schätzung erneut.

Zum Beispiel: Angenommen, Sie pilotieren eine agentenbasierte Funktion mit 20 Entwicklern auf Copilot Business. Jede Lizenz beinhaltet 1,900AI credits pro Monat, sodass Ihre Pilotgruppe zunächst auf einen gemeinsamen Pool von 20 × 1,900 enthaltenen AI credits zurückgreift, bevor nutzungsbasierte Gebühren anfallen. Wenn Sie eine hohe Nutzung von etwa 3.000 AI credits pro Entwickler in diesem Monat erwarten, schätzen Sie die Gesamtnutzung als 20 × 3.000. Subtrahieren Sie den einbezogenen Pool, um die getaktete Nutzung zu schätzen, und multiplizieren $0.01 USD Sie dann, um die Überlastungskosten zu schätzen und Ihre Obergrenze etwas darüber festzulegen. Sie erstellen das Budget, das diese Obergrenze erzwingt, nachdem Sie das Feature aktiviert haben, in ["Budget festlegen", um die Kosten des Pilotprojekts zu decken](#set-a-budget-to-cap-the-pilots-costs).

## Aktivieren des Features für Ihre Pilotgruppe

Nachdem Sie nun die Kosten abgeschätzt und entschieden haben, wen Sie einbeziehen möchten, können Sie die Funktion kontrolliert aktivieren. Ziel ist es, Ihrer Pilotgruppe eine echte, ordnungsgemäß geregelte Erfahrung zu geben und gleichzeitig den Rest Ihres Unternehmens unberührt zu halten.

Führen Sie dies in vier Schritten aus:

1. Bestätigen Sie die Organisationsmitgliedschaft und Lizenzzuweisung.
2. Konfigurieren Sie die Richtlinien, die das Feature steuern.
3. Aktivieren Sie das Feature nur für diese Organisation.
4. Legen Sie ein Budget fest, um die Kosten des Pilotprojekts zu senken.

### Bestätigen der Organisationsmitgliedschaft und Lizenzzuweisung

Allein die Mitgliedschaft reicht nicht aus: Die meisten Copilot Richtlinien gelten danach, welche Organisation die Copilot-Lizenz eines Benutzers zuweist, nicht einfach danach, welchen Organisationen er angehört. Wenn jemand zu mehreren Organisationen gehört, bestätigen Sie, dass ihre Lizenz speziell über die Pilotorganisation zugewiesen wird. Wenn die Zuweisung auf andere Weise erfolgt, gelten die Richtlinien der Pilotorganisation nicht für ihren Zugriff, und die Aktivierung der Funktion in dieser Anleitung gilt nicht für sie.

Wenn einige Ihrer Pilotbenutzer noch keine Mitglieder sind oder ihre Lizenz über eine andere Stelle erhalten, fügen Sie sie der Pilotorganisation hinzu und weisen Sie ihnen ihre Copilot-Lizenz über diese zu, bevor Sie fortfahren.

### Konfigurieren von Richtlinien vor dem Aktivieren des Features

Copilot Richtlinien steuern, auf welche Features und Modelle Ihre Benutzer zugreifen können und wie ihre Daten verarbeitet werden. Konfigurieren Sie diese Richtlinien für die Pilotorganisation *bevor* Sie die Funktion aktivieren, damit Pilotbenutzer ab ihrer allerersten Interaktion ein korrekt gesteuertes Nutzungserlebnis erhalten, anstatt dass es eine kurze Phase gibt, in der die Funktion ohne die von Ihnen beabsichtigten Leitplanken verfügbar ist.

Entscheiden Sie, welche Features und Modelle das Pilotprojekt zulassen soll, und legen Sie die Richtlinien auf Organisationsebene fest, sodass sich die Änderung nur auf Ihre Pilotorganisation auswirkt. Richtlinien, die auf Unternehmensebene festgelegt sind, gelten für jede Organisation in Ihrem Unternehmen. Wenn Ihre Unternehmensrichtlinie organisationen nicht erlaubt, ihren eigenen Wert festzulegen, muss ein Unternehmensbesitzer dies ändern, bevor Sie fortfahren können. Informationen dazu, wie Richtlinien von der Unternehmens- an die Organisationsebene weitergegeben werden und wer Einstellungen auf den einzelnen Ebenen außer Kraft setzen kann, finden Sie unter [GitHub Copilot-Richtlinien für Unternehmen und Organisationen](/de/copilot/concepts/policies).

### Aktivieren des Features für eine einzelne Organisation

Aktivieren Sie als Besitzer der Organisation die spezifische Funktion oder das Modell nur für die Pilotorganisation in den Richtlinieneinstellungen der Copilot Organisation. Die vollständigen Schritte finden Sie unter [Verwalten von Richtlinien und Features für GitHub Copilot in Ihrer Organisation](/de/copilot/how-tos/administer-copilot/manage-for-organization/manage-policies). Vergewissern Sie sich, dass die Einstellung für die Pilotorganisation und nicht für das Gesamte gilt, bevor Sie sie speichern.

### Legen Sie ein Budget fest, um die Kosten des Pilotprojekts zu senken

Früher haben Sie beschlossen, eine Ausgabenobergrenze für das Pilotprojekt zu wählen. Jetzt erstellen Sie das Budget, das es erzwingt.

Verstehen Sie zunächst, was ein Organisationsbudget tut. Sie begrenzt nur *nutzungsabhängige* Gebühren und wird erst dann aktiv, nachdem der gemeinsam genutzte Pool von AI credits erschöpft ist. Die Gesamtausgaben werden nicht begrenzt. Legen Sie daher den Grenzwert auf den Betrag fest, den Sie über das enthaltene Kontingent hinaus zahlen möchten, nicht auf die Gesamtkosten des Pilotprojekts. Wichtig ist: Ein Budget ist **standardmäßig kein harter Stopp**; Kosten fallen auch über dieses Limit hinaus weiter an, sofern Sie beim Erstellen nicht **Nutzung beenden, wenn der Budgetgrenzwert erreicht ist** aktivieren.

Erstellen Sie als Organisationsbesitzer oder Abrechnungsmanager ein Budget für die Pilotorganisation, legen Sie deren Grenzwert auf die von Ihnen ausgewählte Obergrenze fest, und aktivieren Sie **"Nutzung beenden", wenn der Budgetgrenzwert erreicht ist**.

Wenn Sie verhindern möchten, dass ein einzelner Pilotnutzer den Verbrauch in die Höhe treibt, legen Sie auch ein allgemeines Budget auf Benutzerebene fest. Dies ist die einzige Kontrolle, die immer zu einem harten Stopp führt, und sie rechnet den Verbrauch eines Benutzers sowohl aus dem gemeinsamen Pool als auch aus der verbrauchsabhängigen Nutzung auf dasselbe Limit an. Legen Sie ihn auf einen moderaten Betrag fest, der es den Teilnehmenden ermöglicht, echte Arbeit zu leisten, aber verhindert, dass ein einzelner Benutzer einen unverhältnismäßig großen Anteil des Pilotbudgets verbraucht.

Informationen dazu, wie Budgets die Nutzung auf Benutzer-, Organisations- und Unternehmensebene ermitteln und blockieren, finden Sie unter [Budgets für nutzungsbasierte Abrechnung](/de/copilot/concepts/billing/budgets-for-usage-based-billing).

## Überwachen des Pilotprojekts

Während des gesamten Pilotprojekts verfolgen Sie die Einführung, sammeln Sie Entwicklerfeedback und beobachten Sie Kosten- und agentische Aktivitäten anhand der Erfolgskriterien, die Sie zu Beginn definiert haben. Zusammen helfen Ihnen diese Signale bei der Entscheidung, ob das Feature erweitert werden soll.

### Nachverfolgen der Einführung und Nutzung mit Copilot Metriken

Verwenden Sie Copilot Nutzungsmetriken, um zu sehen, wie viele Ihrer Pilotbenutzer aktiv sind, wie oft sie das Feature verwenden und wie diese Zahlen im Pilotzeitraum trenden. Eine Annahme, die stabil bleibt oder zunimmt, ist ein starkes Signal; eine Nutzung, die sprunghaft ansteigt und dann wieder abflaut, kann bedeuten, dass die Funktion nicht zu den tatsächlichen Workflows der Entwickler passt.

* Informationen dazu, was die Metriken abdecken und wie sie interpretiert werden, finden Sie unter [GitHub Copilot Nutzungsmetriken](/de/copilot/concepts/copilot-usage-metrics/copilot-metrics).
* Um das Dashboard für Ihre Organisation oder Ihr Unternehmen anzuzeigen, siehe [Anzeigen des Dashboards für Copilot-Nutzungsmetriken](/de/copilot/how-tos/administer-copilot/view-usage-and-adoption).

### Sammeln von Entwicklerfeedback aus Ihrer Pilotgruppe

Metriken geben Ihnen an, *ob* Personen das Feature verwenden, aber nicht *, warum* oder wie gut es für sie funktioniert. Sammeln Sie qualitatives Feedback, um diese Lücke zu füllen. Führen Sie kurze Umfragen aus, halten Sie regelmäßige Check-Ins oder richten Sie einen dedizierten Kanal ein, in dem Pilotbenutzer melden können, was funktioniert und was nicht.

Hier machen sich die Teilnehmer bezahlt, die Sie aufgrund ihrer Bereitschaft ausgewählt haben, Feedback zu geben. Stellen Sie spezifische Fragen: Wo das Feature Zeit gespeichert hat, wo es schlechte Ergebnisse erzeugt hat und ob die Funktionsweise geändert wurde. Dieses Feedback zeigt häufig Probleme und Chancen, die die Zahlen allein nicht offenlegen, und es gibt Ihnen konkrete Beispiele, die Sie später mit Führung teilen können.

### Achten Sie auf Kosten und Agentenaktivitäten in Budgets und im Überwachungsprotokoll

Behalten Sie während des gesamten Pilotprojekts die Ausgaben im Verhältnis zu dem von Ihnen für das Pilotprojekt festgelegten Budget im Auge, nicht nur am Ende. Wenn die Nutzung sich Ihrer Obergrenze früher als erwartet annähert, ist das ein hilfreicher früher Hinweis darauf, welche Kosten ein breiterer Rollout verursachen würde. Informationen dazu, wie Sie nachverfolgen können, wie viel Sie im Vergleich zum Budget ausgegeben haben, finden Sie unter [Überwachung Ihrer GitHub AI Credits-Nutzung](/de/copilot/how-tos/manage-and-track-spending/monitor-ai-usage). Zum Nachverfolgen von Ausgaben im Zeitverlauf siehe [Verwalten der Ausgaben Ihres Unternehmens für GitHub Copilot](/de/copilot/how-tos/manage-and-track-spending/manage-company-spending).

Achten Sie neben den Kosten auch darauf, ob die Funktion sicher verwendet wird. Dies ist die dritte Frage, die Führung stellen wird, und das Pilotprojekt ist Ihre Chance, sie mit Beweisen zu beantworten, anstatt Zusicherungen. Überprüfen Sie bei agentenbasierten Funktionen die Agentensitzungen, um zu verstehen, was die Funktion tatsächlich für Ihre Entwickler tut, und um unerwartetes oder unerwünschtes Verhalten zu erkennen; das Überwachungsprotokoll zeichnet auf, wann die Funktion aktiviert oder deaktiviert wird, erfasst jedoch nicht diesen Detaillierungsgrad. Vergewissern Sie sich, dass die von Ihnen festgelegten Richtlinien und Budgets wie beabsichtigt funktionieren, und vermerken Sie alles, was bei größerem Maßstab engere Leitplanken erfordern würde. Siehe [Überwachung agentischer Tätigkeiten in Ihrem Unternehmen](/de/copilot/how-tos/administer-copilot/manage-for-enterprise/manage-agents/monitor-agentic-activity).

## Treffen Sie eine Go-/No-Go-Entscheidung

Überprüfen Sie am Ende des Pilotprojekts Ihre Ergebnisse anhand der Erfolgskriterien, die Sie im Vorfeld definiert haben, und entscheiden Sie, ob Sie die Funktion ausweiten, sie vorerst beibehalten und weitere Daten sammeln oder ein Rollback durchführen. Treffen Sie die Entscheidung bewusst, und dokumentieren Sie die zugrunde  liegende Beweislage.

### Bestätigen Sie, dass Sie genügend Nachweise haben, um zu entscheiden

Bevor Sie sich entscheiden, überprüfen Sie, ob das Pilotprojekt für die von Ihnen geplante Dauer ausgeführt wurde und genügend Daten erstellt hat, um einen defensiblen Abschluss zu unterstützen.

Die Pilotnutzung wird zunächst aus dem gemeinsamen Pool gedeckt (ohne zusätzliche Kosten), bevor die nutzungsabhängige Abrechnung beginnt. Daher sind Ausgaben von 0 $ zu Beginn des Piloten zu erwarten, und eine kürzere Laufzeit kann die Kostendaten irreführend erscheinen lassen.

Sie sind bereit, eine Entscheidung zu treffen, wenn Sie Folgendes haben:

* Adoptionsmetriken, die ein stabiles Muster statt eines einzelnen frühen Ausschlags zeigen.
* Aktuelle Kostendaten, die mindestens einen Abrechnungszyklus umfassen, die Sie mit Ihrer Schätzung vergleichen können.
* Feedback aus einer repräsentativen Palette Ihrer Pilotbenutzer.

Wenn die Evidenz in einem dieser Bereiche noch dürftig ist, zum Beispiel weil die Nutzung weiterhin steigt oder sich nur wenige Teilnehmende beteiligt haben, sollten Sie erwägen, die Pilotphase zu verlängern, anstatt auf Grundlage unvollständiger Erkenntnisse eine Entscheidung zu treffen. Eine Entscheidung, die Sie mit Daten belegen können, lässt sich gegenüber der Führung wesentlich leichter vertreten und muss deutlich seltener revidiert werden.

## Bericht an die Führungsebene

Um Ihre Entscheidung zu rechtfertigen und einen Fall für einen breiteren Rollout zu erstellen, melden Sie die Ergebnisse des Pilotprojekts der Führung.

### Identifizieren der zu teilenden Daten

Ziehen Sie die Signale zusammen, die Sie während des Pilotprojekts gesammelt haben:

* **Einführungsmetriken**, die zeigen, wie viele Pilotbenutzer aktiv waren und wie die Nutzung im Laufe der Zeit im Trend war.
* **Ist-Kosten im Vergleich zum Budget**, ein Vergleich zwischen den Ausgaben des Piloten, der von Ihnen festgelegten Obergrenze und Ihrer ursprünglichen Schätzung.
* **Feedback-Themen**, die zusammenfassen, wo die Teilnehmenden einen Mehrwert sahen und wo sie auf Probleme stießen.
* **Sicherheits- und Governancebeobachtungen**, einschließlich alles, was Sie aus dem Überwachungsprotokoll gelernt haben, oder aus der Funktionsweise von Richtlinien und Budgets.

### Akzeptanz, Kosten und Sicherheit im Verhältnis zum ROI darstellen

Stellen Sie die Daten in Geschäftsbedingungen statt als Rohdaten dar. Setzen Sie Akzeptanz und Feedback in Beziehung zu dem Mehrwert, den die Funktion geliefert hat, etwa in Form von eingesparter Zeit, beseitigten Arbeitsblockaden oder verbesserter Qualität, und stellen Sie dem die tatsächlichen Kosten sowie alle Governance- oder Risikoaspekte gegenüber, die Sie beobachtet haben.

Schließen Sie mit einer klaren Empfehlung ab: ausweiten, beibehalten oder stoppen – und welche Kosten für eine breitere Einführung anfallen würden. Wird das Pilotprojekt unter den Gesichtspunkten Return on Investment, vorhersehbarer Kosten und kontrollierbaren Risikos dargestellt, erhält die Führungsebene die Grundlage, die sie benötigt, um eine breitere Einführung mit Zuversicht zu genehmigen.

## Reagieren Sie auf Ihre Entscheidung

Führen Sie den nächsten Schritt basierend auf den gesammelten Nachweisen und der getroffenen Entscheidung aus.

### Erweitern Sie den Rollout im gesamten Unternehmen

Wenn der Nachweis einen Schritt unterstützt, erweitern Sie den Rollout in Phasen und nicht alle gleichzeitig. Erweitern Sie die Feature-Richtlinie zunächst auf weitere Organisationen und erst dann auf das restliche Unternehmen, wenn jede Phase erfolgreich verläuft. Wenn Sie mehr Nutzer hinzufügen, erhöhen Sie Budgets oder fügen Sie neue hinzu, damit Ihre Ausgabenkontrollen mit der wachsenden Nutzerzahl mitwachsen, und überwachen Sie bei jedem Schritt weiterhin Nutzung und Kosten.

Eine umfassendere Anleitung zum Verwalten eines Rollouts in Ihrem Unternehmen finden Sie unter [Rollout von GitHub Copilot im großen Maßstab](/de/copilot/tutorials/roll-out-at-scale).

### Die Funktion sauber zurücknehmen und deaktivieren

Wenn die Hinweise darauf hindeuten, dass es ein No-Go ist, deaktivieren Sie die Funktion sauber, damit keine laufenden Kosten entstehen und keine Verwirrung bleibt. Deaktivieren Sie die Funktions- oder Modellrichtlinie für die Pilotorganisation, und teilen Sie den Teilnehmenden mit, dass das Pilotprojekt beendet ist und warum, damit sie sich nicht fragen, warum die Funktion verschwunden ist.

Vergewissern Sie sich, dass keine verbleibende Nutzung vorhanden ist, die weiterhin mit Ihrem Budget in Rechnung gestellt werden kann, und überprüfen oder entfernen Sie das Pilotbudget, sodass sie sich nicht auf die zukünftige Berichterstellung auswirkt. Bewahren Sie die gesammelten Daten und Rückmeldungen auf: Auch ein No-Go ist ein nützliches Ergebnis, das Sie mit der Führungsebene teilen können, und es kann in eine spätere Neubewertung einfließen, wenn das Feature ausgereifter ist.