Rollout-Leitfaden: Claude im Unternehmen einführen

Die Lizenzen sind gekauft, die Rundmail ist raus: „Ab sofort steht euch Claude zur Verfügung, viel Spaß beim Ausprobieren.“ Vier Wochen später zeigt die Auswertung, dass zwölf Prozent der Sitze überhaupt einmal genutzt wurden, davon die Hälfte genau einmal. Im Lenkungskreis fällt dann der Satz, der jedes KI-Projekt beerdigt: „Anscheinend brauchen wir das doch nicht.“

Dabei war nie das Werkzeug das Problem. Ein Rollout, der aus Beschaffung und Zugangsdaten besteht, ist kein Rollout, sondern eine Verteilaktion. Dieser Leitfaden beschreibt, was stattdessen passiert: vier Wellen mit klaren Toren, ein Pilot, der eine belastbare Antwort liefert, und ein Enablement, das in Stunden statt in Schulungstagen rechnet. Zielgröße für ein mittelständisches Haus: von der Entscheidung bis zur Fläche etwa ein halbes Jahr, davon der größte Teil ohne Hektik.

Warum Rollouts scheitern — und zwar selten am Werkzeug

Das Gießkannen-Problem

Der häufigste Fehlstart ist gut gemeint: Alle bekommen gleichzeitig Zugang, damit sich niemand benachteiligt fühlt. Das Ergebnis ist vorhersehbar, weil eine neue Fähigkeit ohne Anlass in keinem Kalender Platz findet. Wer morgens dreißig Mails und zwei Termine vor sich hat, probiert kein neues Werkzeug aus, nur weil es da ist. Adoption entsteht nicht durch Verfügbarkeit, sondern durch eine konkrete Aufgabe, bei der das Werkzeug spürbar schneller ist als der bisherige Weg — und durch jemanden in Sichtweite, der zeigt, wie es geht.

Die drei echten Hürden

Wenn man Leute fragt, warum sie es nicht nutzen, kommen fast immer dieselben drei Antworten. Erstens: kein Anlass — sie wissen nicht, wofür genau in ihrem Alltag. Zweitens: Unsicherheit über die Erlaubnis — darf ich hier Kundendaten hineinschreiben, darf ich damit Angebote formulieren? Solange diese Frage offen ist, wählt der vorsichtige Teil der Belegschaft die sichere Variante und lässt es. Drittens: keine Lernzeit — die erste Woche mit einem Assistenten ist objektiv langsamer als der gewohnte Weg, und diese Investition macht niemand nebenbei. Ein guter Rollout beantwortet genau diese drei Punkte, und zwar in dieser Reihenfolge.

Das Wellenmodell

Welle 0: das Fundament

Vor dem ersten Nutzer steht die Startfreigabe. Dazu gehören der passende Plan und Vertrag, die Anbindung an euren Verzeichnisdienst samt Sitzverwaltung, die Datenschutzunterlagen, eine Nutzungsregel je Datenklasse und die Benennung der Zuständigen. Ebenfalls in diese Welle gehört, was später am häufigsten fehlt: die Ausgangswerte für eure Kennzahlen. Zwei bis vier Wochen sind realistisch, und der größte Teil davon ist Wartezeit auf Rückmeldungen, nicht Arbeit. Wichtig ist nur eines: Welle 0 ist kein Papierkram, den man parallel erledigen kann, sondern das Tor. Wer den Pilot startet, während die Erlaubnisfrage noch offen ist, bekommt genau die Zurückhaltung, die er später als mangelndes Interesse missdeutet.

Welle 1: der Pilot

Der Pilot umfasst zwei bis drei Teams aus unterschiedlichen Bereichen, insgesamt etwa fünfzehn bis dreißig Personen, und läuft vier bis sechs Wochen. Zwei bis drei Teams statt einem ist kein Luxus, sondern methodisch nötig: Ein einziges Team liefert einen Datenpunkt, und wenn dessen Leiter zufällig begeistert ist, wisst ihr hinterher nicht, ob der Nutzen am Werkzeug lag oder an der Person. Erst mehrere Teams zeigen, ob sich Ergebnisse wiederholen lassen. Am Ende steht kein Stimmungsbild, sondern eine Auswertung.

Welle 2: Abteilung für Abteilung

Jetzt wird übertragen, nicht neu erfunden. Die Anwendungsfälle, Vorlagen und Projektstrukturen aus dem Pilot gehen als fertiges Paket in die nächste Abteilung, begleitet von jemandem aus der Pilotgruppe. Diese Welle dauert am längsten, sechs bis zehn Wochen für ein mittelgroßes Haus, und sie ist die eigentliche Arbeit. Hier werden auch die Konnektoren gezielt freigegeben — nicht flächendeckend, sondern dort, wo eine Abteilung nachweislich damit arbeitet. Das hält die Berechtigungsdiskussion klein und überschaubar.

Welle 3: Fläche und Rhythmus

In der letzten Welle wird aus dem Projekt Betrieb: Selbstbedienung für alle übrigen, eine wöchentliche Sprechstunde, Onboarding neuer Mitarbeiter über den normalen Weg. Statt weitere Sitze zu kaufen, verteilt ihr zuerst die um, die seit drei Monaten unbenutzt sind — das ist der wirksamste Kostenhebel, und ihr habt die Zahlen dafür ohnehin im Dashboard. Und dann kommt der Teil, den fast alle vergessen: ein fester Quartalsrhythmus, in dem Nutzung, Kosten und Regeln angesehen werden. Ohne diesen Termin driftet jede Regelung, und nach einem Jahr weiß niemand mehr, warum welcher Konnektor freigegeben ist.

Abb.: Das Wellenmodell in der Detailfassung — Zielgruppe, Inhalt und Tor je Welle.

Wer den Rollout trägt

Ein Rollout, den „die IT macht“, wird als IT-Projekt wahrgenommen — und damit als etwas, das man erdulden statt nutzen muss. Tragfähig wird es mit vier klar benannten Rollen. Ein Sponsor aus der Geschäftsführung, der nicht nur zustimmt, sondern das Thema in seiner eigenen Kommunikation vorkommen lässt. Eine Projektleitung mit Zeitbudget, idealerweise aus einem Fachbereich statt aus der IT, weil sie die Anwendungsfälle besser beurteilt. Die IT für Anbindung, Sitze, Konnektoren und Betrieb. Und der Datenschutz früh am Tisch statt am Ende als Prüfinstanz — wer ihn in Welle 0 einbindet, bekommt Hinweise, wer ihn erst vor der Fläche fragt, bekommt Auflagen.

Dazu kommt die Mitbestimmung: Sobald Nutzungsdaten der Beschäftigten anfallen — und sie fallen an, sobald ihr ein Dashboard habt —, gehört der Betriebsrat einbezogen. Das ist kein Hindernis, sondern eine Terminfrage: Frühzeitig eingebunden, wird daraus eine Vereinbarung; spät konfrontiert, wird daraus eine Vollbremsung mitten in Welle 2. Und schließlich die Champions aus dem Pilot, die in Welle 2 die eigentliche Übertragungsarbeit leisten. Fünf Rollen, alle mit Namen im Projektplan — nicht mit Abteilungskürzeln.

Der Pilot: so wird er aussagekräftig

Wen ihr hineinnehmt

Die Versuchung ist groß, den Pilot mit Freiwilligen zu besetzen. Genau das macht ihn wertlos: Technikaffine Menschen kommen mit jedem Werkzeug zurecht und beweisen deshalb nichts über den Rest des Hauses. Nehmt stattdessen ganze Teams, so wie sie sind — mit dem skeptischen Sachbearbeiter und der Kollegin, die kurz vor der Rente steht. Zwei Kriterien sind dabei wichtig: ein Teamleiter, der es wirklich will, und eine Arbeit, die sich in wiederkehrenden Aufgaben beschreiben lässt. Und lasst die Teams ihre Anwendungsfälle selbst benennen, statt sie von oben zu verteilen — die Fachbereiche wissen besser, wo ihre Zeit versickert.

Drei Aufgaben statt einer Werkzeugtour

Der Pilot beginnt nicht mit einer Funktionsübersicht, sondern mit drei konkreten Aufgaben je Team: eine lange Analyse, eine wiederkehrende Fleißarbeit, eine Textaufgabe mit Qualitätsanspruch. Diese drei werden vier Wochen lang tatsächlich damit erledigt, nicht ausprobiert. Alles Weitere ergibt sich, und was sich nicht ergibt, war offenbar nicht wichtig. Ein wöchentlicher Termin von dreißig Minuten reicht, um Erkenntnisse einzusammeln, gute Prompts zu teilen und die Frage zu klären, die gerade alle beschäftigt.

Kennzahlen, die eine Entscheidung tragen

Messt auf vier Ebenen: reine Nutzung aus dem Dashboard, Bearbeitungszeit je definierter Aufgabe im Vorher-Nachher-Vergleich, Qualität in Form von Nacharbeit und Fehlern im Review, und wo möglich eine Geschäftskennzahl aus den Fachsystemen — Durchlaufzeit, Menge, Rückstand. Die Nutzungszahlen allein sagen wenig, sind aber die Pflichtbasis. Die entscheidende Regel steht am Anfang: Der Ausgangswert wird vor dem ersten Zugang erhoben. Zwei Stunden Aufwand in Welle 0 ersparen euch die halbe Diskussion in der Abschlussrunde, weil dann niemand mehr sagen kann, das sei ja alles Gefühl.

Was am Ende vorliegen muss

Der Pilot endet mit einem Dokument von zwei Seiten, nicht mit einer Präsentation und einem guten Gefühl. Darin stehen: die gemessenen Werte gegen den Ausgangswert, die Anwendungsfälle, die sich bewährt haben — jeweils mit dem Prompt oder der Vorlage, die dazu gehört —, die Fälle, die nicht funktioniert haben, samt Grund, und eine Empfehlung mit Zahl: wie viele Sitze für welche Bereiche in Welle 2. Der Teil, der am häufigsten fehlt, ist der zweite: Was im Pilot funktioniert hat, muss die nächste Abteilung am ersten Tag fertig vorfinden, sonst beginnt dort dieselbe Lernkurve von vorn. Genau diese Übertragbarkeit ist der Unterschied zwischen einem Pilot und einem netten Experiment.

Abb.: Pilot-Kennzahlen auf vier Ebenen — samt der Größen, die man besser nicht misst.

Enablement: was tatsächlich wirkt

90 Minuten, dann Erreichbarkeit

Die wirksamste Einführungsveranstaltung dauert anderthalb Stunden, und jeder bringt eine eigene Aufgabe mit, die er in der Sitzung durcharbeitet. Kein Folienvortrag über Funktionen, keine dreitägige Schulung — die hat niemand im Kalender, und nach zwei Wochen ist die Hälfte davon weg. Was danach zählt, ist Erreichbarkeit: eine wöchentliche offene halbe Stunde in den ersten sechs Wochen, in der man mit konkreten Fragen kommen kann. Diese Sprechstunde ist der billigste und wirksamste Baustein des gesamten Rollouts.

Champions statt Zentralsupport

Pro Abteilung zwei bis drei Ansprechpartner aus dem Fach, mit ein bisschen Zeitbudget ausgestattet und aus der Pilotgruppe rekrutiert — das schlägt jede zentrale Hotline. Der Grund ist banal: Die Frage „darf ich das hier reinschreiben?“ stellt man dem Kollegen nebenan, nicht einem Ticketsystem. Dazu gehört, dass die Ergebnisse des Pilots weitergegeben werden: geteilte Projekte, fertige Vorlagen, zehn gute Beispiele im Werkzeug selbst. Eine vierzigseitige Prompt-Sammlung im Intranet wird abgelegt und nie wieder geöffnet.

Abb.: Enablement — die Bausteine, die tragen, und die, die regelmäßig verpuffen.

Nach dem Rollout: der Betriebsrhythmus

Ein Rollout endet nicht, er geht in Betrieb über. Vier Termine reichen dafür. Monatlich ein Blick auf Nutzung und Ausgaben: Wer nutzt nicht, und warum — fehlt der Anlass, die Erlaubnis oder die Übung? Quartalsweise die Sitzumverteilung und ein kurzer Abgleich der Regeln mit der Wirklichkeit, denn Produkte und Funktionen ändern sich in diesem Markt schneller als eure Richtlinie. Halbjährlich die Überprüfung der Anbieterentscheidung und der Konnektorenfreigaben. Und jährlich der ehrliche Blick auf die Geschäftskennzahlen, mit denen ihr im Pilot gestartet seid.

Das klingt nach viel Verwaltung, ist aber in Summe ein halber Tag im Quartal — und der Unterschied zwischen einem Werkzeug, das nach zwei Jahren selbstverständlich dazugehört, und einer Lizenz, die niemand zu kündigen wagt, weil unklar ist, wer sie eigentlich braucht.

Häufige Fragen (FAQ)

Wie führt man Claude im Unternehmen ein?

In vier Wellen: erst das Fundament aus Vertrag, Identitätsanbindung, Datenschutzunterlagen und Nutzungsregeln, dann ein Pilot mit zwei bis drei Teams, dann die abteilungsweise Ausweitung mit Multiplikatoren aus der Pilotgruppe, zuletzt die Fläche mit Selbstbedienung und festem Betriebsrhythmus. Entscheidend sind die Tore zwischen den Wellen — keine Ausweitung ohne ausgewerteten Pilot. Für ein mittelständisches Haus ist ein halbes Jahr von der Entscheidung bis zur Fläche ein realistischer Rahmen.

Wie groß sollte der Pilot sein?

Zwei bis drei komplette Teams mit insgesamt etwa fünfzehn bis dreißig Personen, über vier bis sechs Wochen. Mehrere Teams sind wichtiger als viele Personen: Ein einzelnes Team liefert nur einen Datenpunkt, mehrere zeigen, ob sich der Nutzen wiederholen lässt oder an der Motivation einer einzelnen Führungskraft hing. Nehmt ganze Teams statt Freiwilliger, sonst testet ihr nur, ob technikaffine Menschen mit Software zurechtkommen.

Woran messen wir, ob sich die Einführung lohnt?

An vier Ebenen: Nutzung aus dem Verwaltungs-Dashboard, Bearbeitungszeit je definierter Aufgabe im Vorher-Nachher-Vergleich, Qualität über Nacharbeit und Fehler im Review sowie eine Geschäftskennzahl aus euren Fachsystemen. Die wichtigste Voraussetzung ist der Ausgangswert, erhoben vor dem ersten Zugang — ohne ihn bleibt jede spätere Zahl eine Behauptung. Finger weg von Prompt-Zählungen und persönlichen Ranglisten: Die messen Betriebsamkeit, nicht Nutzen.

Wie lange dauert ein Rollout?

Rechnet mit etwa einem halben Jahr von der Entscheidung bis zur Fläche: zwei bis vier Wochen Fundament, vier bis sechs Wochen Pilot, sechs bis zehn Wochen abteilungsweise Ausweitung, danach laufender Betrieb. Der Engpass ist selten die Technik — die Einrichtung ist an einem Tag erledigt —, sondern die Abstimmung mit Datenschutz, Mitbestimmung und Fachbereichen. Wer diese Gespräche parallel zur technischen Vorbereitung führt statt danach, spart die meiste Zeit.

Was tun, wenn die Nutzung nach dem Start einbricht?

Erst diagnostizieren, nicht nachschulen: In fast allen Fällen fehlt einer von drei Punkten — ein konkreter Anlass im Arbeitsalltag, Klarheit darüber, was erlaubt ist, oder schlicht Zeit zum Üben. Sprecht mit fünf Leuten, die aufgehört haben, und ihr wisst nach einer Stunde, welcher es ist. Gegenmittel sind entsprechend unterschiedlich: konkrete Anwendungsfälle je Rolle, eine kurze Erlaubnistabelle je Datenklasse oder eine begleitete Stunde am echten Vorgang.

Brauchen wir überhaupt Schulungen?

Ja, aber deutlich weniger, als die meisten planen: 90 Minuten je Person mit einer echten eigenen Aufgabe schlagen jede mehrtägige Werkzeugschulung. Wichtiger als der Umfang ist, was danach kommt — eine wöchentliche Sprechstunde in den ersten sechs Wochen und ansprechbare Champions in der Abteilung. Faustregel für die Planung: unter zwei Stunden Aufwand pro Person, dafür in den ersten sechs Wochen wirklich erreichbar sein.

Weiterlesen

Was vor dem Rollout entschieden sein muss — Lizenzmodell, Identität, Datenschutz, Microsoft-Umfeld — steht im Überblick Claude im Unternehmen. Und wenn ihr den Rollout lieber einmal richtig macht als zweimal halb: In der Beratung zu Claude und KI-Governance planen wir Wellen, Pilotdesign und Kennzahlen gemeinsam mit euren Fachbereichen — und begleiten die ersten beiden Wellen.