Teams, die selbst bauen: 15 Monate KI-Transformation bei der celebrate company

Benedikt Peine ist AI Officer bei celebrate company. In dieser Episode zeigt er, wie sich eine KI-Initiative innerhalb von 15 Monaten mehrfach weiterentwickelt hat: von einem Ambassador-Netzwerk über Agentic Enabler bis zu einer dezentralen Builder-Community.

Im Gespräch geht es nicht um das nächste Tool, sondern um die organisatorischen Voraussetzungen für Wirkung: echte Kapazitäten, ein klares Mandat, portablen Kontext, systematisch priorisierte Use Cases und eine Infrastruktur, mit der Teams selbst bauen können.

Über den Gast

Benedikt Peine ist seit Juli 2025 AI Officer bei celebrate company. Er arbeitet seit mehr als zehn Jahren im Unternehmen und kommt ursprünglich aus Marketing und Customer Service. Sechs Jahre lang leitete er die Service Unit – ein Umfeld, in dem Prozesse, Automatisierung und Skalierung schon früh eine zentrale Rolle spielten.

celebrate company entwickelt und produziert personalisierte Papeterie- und Fotoprodukte. Zum Unternehmen gehören Marken wie kartenmacherei, Rosemood, faireparterie und mintkind. Das stark saisonale Geschäft stellt hohe Anforderungen an effiziente Prozesse, zuverlässige Systeme und die Fähigkeit, Nachfrage-Peaks zu bewältigen.

Vom KI-Tool zum persönlichen Betriebssystem

Benedikt nutzt Claude heute als zentrale Arbeitsumgebung. Dafür hat er in einem lokalen Repository Kontext zu seiner Rolle, seiner Arbeitsweise, seinen Zielen, zur Organisation und zu laufenden Projekten aufgebaut. Meeting-Transkripte, Slack und Linear ergänzen diesen Kontext kontinuierlich.

Der entscheidende Hebel ist für ihn nicht mehr die perfekte Prompt-Formulierung. Wichtig ist, dass das System versteht, wer er ist, mit wem er arbeitet und welche Ziele er verfolgt. So können erste Entwürfe für Board-Updates, Präsentationen oder Projektentscheidungen bereits auf dem vorhandenen Wissen aufbauen.

Gleichzeitig soll der Kontext nicht an ein einzelnes Tool gebunden sein. celebrate bereitet relevante Informationen so auf, dass sie künftig auch mit anderen Modellen oder Oberflächen genutzt werden können. Das reduziert die Abhängigkeit vom aktuellen Tool-Stack.

Von Ambassadors zu Agentic Enablern

Die KI-Initiative startete mit einem Netzwerk von etwa 30 bis 35 Ambassadors. In jedem Team sollte eine Person Grundlagen vermitteln, Anwendungsfälle identifizieren und Kolleg:innen unterstützen. Vorgesehen waren rund 30 Prozent Arbeitszeit für diese Rolle.

In der Praxis zeigte sich schnell, dass ein solches Modell ohne konsequente Priorisierung an Grenzen stößt. Das Tagesgeschäft blieb dominant, und nicht alle Ambassadors bekamen den notwendigen Freiraum. Dort, wo Leads aktiv unterstützten und Kapazität schützten, entstand deutlich mehr Wirkung.

celebrate entwickelte das Modell deshalb weiter. Die neuen Agentic Enabler erhielten mindestens 50 Prozent, teilweise sogar 100 Prozent ihrer Arbeitszeit für KI-Themen. Ihre Aufgabe ist nicht nur, Wissen weiterzugeben. Sie sollen Systeme und Anwendungen bauen, Fachkontext strukturieren und konkrete Use Cases innerhalb ihrer Units vorantreiben.

„Du lernst nur, wenn du selber baust und dir die Zeit dafür nimmst.“

Aus den Agentic Enablern entsteht inzwischen organisch eine breitere Builder-Community. Damit entwickelt sich das, was sich durch ein formales Ambassador-Programm nur begrenzt erzeugen ließ, zunehmend aus den Teams selbst.

Das zentrale AI-Team baut nicht für die Teams

Parallel zum Rollenmodell wuchs auch das zentrale AI-Team. Benedikt startete allein. Später kamen eine AI Enablement Managerin, ein Engineering Manager und mehrere AI Automation Engineers hinzu.

Die klare Leitlinie lautet trotzdem: Das zentrale Team baut nicht dauerhaft für die Fachbereiche. Sonst würde es schnell zum Bottleneck werden. Stattdessen schafft es Standards, Infrastruktur und Orientierung, unterstützt bei technischen Blockern und hilft den Teams, eigene Lösungen produktiv zu machen.

„Klare Maßgabe ist nicht: Wir bauen für die Teams, sondern die Teams bauen selber.“

Dieses Modell verbindet dezentrales Domänenwissen mit zentraler technischer Unterstützung. Fachbereiche behalten Ownership für ihre Prozesse, während das AI-Team die Voraussetzungen schafft, damit sie handlungsfähig werden.

Engineering als Vorbild für Knowledge Work

Ein wichtiger Impuls kam aus der Softwareentwicklung. Dort entwickelte das Engineering-Team ein Claude-Code-Plugin, das den Weg von der Problemdefinition über das Scoping bis zur Implementierung unterstützt. Dadurch verschiebt sich Arbeit: Weniger Zeit fließt in das reine Schreiben von Code, mehr Zeit in die präzise Definition des Problems und in Qualitätssicherung.

celebrate überträgt dieses Systemdenken auf Wissensarbeit. Ein CRM-Prozess besteht beispielsweise aus Themenplanung, Text, Assets, Versand, Auswertung und der Rückführung von Performance-Daten in die nächste Kampagne. Der Prozess wird nicht nur an einzelnen Stellen beschleunigt, sondern als lernende Schleife betrachtet.

Der Mensch bleibt vor allem dort im Loop, wo Entscheidungen, Geschmack oder Verantwortung gefragt sind. Wiederholbare, regelbasierte Schritte sollen dagegen weitgehend automatisiert werden.

Use Cases priorisieren: vom Interview zum RICE Score

Zu Beginn führte celebrate Interviews mit Ambassadors aus vielen Teams. Daraus entstanden rund 700 Seiten Transkript mit Pain Points, repetitiven Aufgaben und möglichen Anwendungsfällen.

Die Use Cases wurden geclustert und nach dem RICE-Modell bewertet: Reach, Impact, Confidence und Effort. So konnte celebrate nicht nur auf Unternehmensebene, sondern auch innerhalb einzelner Teams nachvollziehbar priorisieren.

Dabei gilt: Ein bestehender, schlechter Prozess wird nicht einfach mit KI überzogen. Das Team hinterfragt zuerst, warum ein Prozess überhaupt existiert, welche Schritte wirklich notwendig sind und wie er grundlegend anders gestaltet werden könnte.

Build vs. Buy und konkrete Anwendungen

celebrate baut viele Lösungen selbst, um flexibel zu bleiben und langfristige Abhängigkeiten von spezialisierten SaaS-Produkten zu vermeiden. Gleichzeitig gibt es klare Ausnahmen. Im Customer Service arbeitet das Unternehmen beispielsweise mit einem Technologiepartner an Voice-, E-Mail- und Chatbots.

Zu den intern umgesetzten Beispielen gehören ein Data Bot, automatisierte CRM-Schritte, ein Bot für fehlende Reisebelege, ein HR-Assistent für wiederkehrende Mitarbeitendenfragen und Workflows für Recruiting-Briefings. Die Anwendungen werden schrittweise aufgebaut und entlang ihrer elementaren Bestandteile zusammengesetzt.

Das Ziel ist nicht, überall möglichst viel KI einzubauen. Teilweise nutzt celebrate KI nur zur Erstellung eines Workflows. Der laufende Prozess selbst ist anschließend deterministisch.

„Wir nutzen eigentlich nur noch KI, um Workflows zu erstellen, in denen dann in den allermeisten Fällen gar keine KI mehr selber vorkommt.“

Für solche Abläufe setzt das Unternehmen auf n8n. Ein internes Launchpad-Plugin kennt die Infrastruktur, die Standards und die eigene Builder-Plattform. Anwendungen können dort mit Zugriffs- und Berechtigungsmanagement für die gesamte Organisation veröffentlicht werden.

Wissen als lebendes System

Für Aufgaben und Business-Ziele nutzt celebrate Linear. Unternehmens- und Teamwissen wird in Outline dokumentiert. Nach Meetings analysiert ein Workflow das Transkript, verdichtet relevante Inhalte, entfernt personenbezogene Informationen und schlägt neue oder aktualisierte Wissensartikel vor.

Aktuell prüft ein Mensch die vorgeschlagenen Änderungen. Zusätzlich sollen ausgewählte Slack-Kanäle als Wissensquelle angebunden werden. Das System soll nicht nur neue Inhalte speichern, sondern auch widersprüchliche oder veraltete Informationen erkennen und den verantwortlichen Personen oder Teams zur Klärung vorlegen.

Dabei unterscheidet celebrate zwischen individuellem Wissen, Teamwissen und unternehmensweitem Wissen. Für jede Ebene gibt es eigene Freigabewege und Verantwortlichkeiten. So wird Wissensmanagement zu einem kontinuierlichen Prozess statt zu einer statischen Ablage.

Hackathons mit klarem Scope

Die ersten Hackathons starteten offen: Teilnehmende mussten zunächst Zugänge einrichten, Ideen auswählen und den Arbeitsmodus verstehen. Dadurch ging viel Zeit verloren.

Heute werden die Formate deutlich stärker vorbereitet. Scope, Ziel, Use Cases und Verantwortlichkeiten stehen vor dem Start fest. Das AI-Team prüft, ob ein Vorhaben im verfügbaren Zeitraum realistisch ist und hilft dabei, zu große Ideen kleiner zu schneiden.

In der Regel dauern Hackathons zwei bis drei Tage. Zu Beginn stellen alle ihre Vorhaben vor. Am Ende jedes Tages folgt ein gemeinsamer Checkout. Abgeschlossen wird das Format mit einer Show-and-Tell-Session, in der Ergebnisse und Learnings geteilt werden – auch dann, wenn ein Prototyp noch nicht funktioniert.

Der wichtigste Erfolgsfaktor ist geschützte Zeit. Während des Hackathons haben die Teilnehmenden das Mandat, Slack, Termine und Tagesgeschäft auszuschalten und sich vollständig auf das Bauen zu konzentrieren.

Wirkung messen statt KI-Weltmeister werden

celebrate betrachtet Tool-Nutzung und aktive User als Basiskennzahlen, aber nicht als eigentliches Ziel. Entscheidend ist, ob KI dabei hilft, strategische Businessziele zu erreichen.

Auf Teamebene können das Kennzahlen wie Cost per Order im Service oder die Zahl neuer Designs im Produktbereich sein. Auf Unternehmensebene diskutiert celebrate Größen wie Revenue oder EBIT per Employee. Benedikt betont zugleich, dass solche Kennzahlen immer von mehreren Faktoren beeinflusst werden.

„Wir machen AI nicht, weil wir AI-Weltmeister werden wollen, sondern um unsere Businessziele zu erreichen.“

Kernaussagen

1. Zeit schlägt Titel: Ambassador-Rollen entfalten nur Wirkung, wenn Führungskräfte echte Kapazität schützen.
2. Teams müssen selbst bauen: Domänenwissen bleibt dezentral; das zentrale AI-Team schafft Standards und räumt Blocker aus dem Weg.
3. Kontext ist portabler als Tools: Wer Wissen strukturiert und unabhängig speichert, kann den Modell-Stack leichter wechseln.
4. Systeme brauchen Feedback-Loops: Prozesse werden stärker, wenn Ergebnisse ausgewertet und als neuer Kontext zurückgeführt werden.
5. KI ist nicht immer Teil der Laufzeit: Sie kann deterministische Workflows bauen, die anschließend zuverlässig und kostengünstig ohne Modellaufruf laufen.
6. Hackathons brauchen Vorbereitung: Klarer Scope, realistische Use Cases und geschützte Zeit sind wichtiger als Pizza und offene Ideenlisten.
7. Business-Impact ist die Zielgröße: Adoption ist die Basis; entscheidend bleibt der Beitrag zu den Zielen des Unternehmens.

Fazit und Takeaways

Für Unternehmen mit KI-Ambitionen

• Rollen mit Kapazität ausstatten: Wer Transformation neben dem Tagesgeschäft erwartet, bekommt meist nur punktuelle Experimente.
• Use Cases systematisch priorisieren: Ein transparentes Modell wie RICE hilft, Reichweite, Wirkung, Sicherheit und Aufwand gegeneinander abzuwägen.
• Kontext unabhängig halten: Wissen sollte nicht in einem einzelnen Modell oder Tool eingeschlossen sein.

Für AI- und Transformationsteams

• Enablement mit Engineering verbinden: Schulungen schaffen Grundlagen; technische Unterstützung bringt Use Cases in den Betrieb.
• Nicht zum Bottleneck werden: Standards, Plugins und Plattformen sollten Teams befähigen, selbst Lösungen zu entwickeln.
• Build und Buy bewusst entscheiden: Strategisch relevante, differenzierende Prozesse können intern entstehen; Commodity-Funktionen müssen nicht neu gebaut werden.

Für Führungskräfte

• Priorität sichtbar machen: KI-Transformation braucht klare Entscheidungen darüber, was dafür nicht mehr gemacht wird.
• Businessziele in den Mittelpunkt stellen: Token-Nutzung und aktive User erklären Adoption, aber nicht den wirtschaftlichen Wert.
• Lernen durch Bauen ermöglichen: Geschützte Zeit, konkrete Probleme und schnelle Feedback-Loops entwickeln nachhaltige Kompetenz.

celebrate zeigt, dass KI-Transformation kein linearer Rollout ist. Rollen, Tools und Methoden müssen sich weiterentwickeln, sobald ihre Grenzen sichtbar werden. Entscheidend ist eine Organisation, in der Menschen Kontext strukturieren, Systeme bauen und aus Ergebnissen lernen können.