netzstrategen AI Operations.
Insights Glossar Ressourcen English Self-Check
← Alle Beiträge
Enablement

Built with the Team: AI-Systeme, die wirklich genutzt werden

Veröffentlicht am 18.6.2026 · André Hellmann

Built with the Team Enablement Change Management AI Adoption

Jede AI-Einführung ist eine Investitionsentscheidung — auch wenn sie selten so behandelt wird. Was extern gebaut wird, veraltet mit dem Vertrag. Was im Team aufgebaut wird, verzinst sich mit jedem Use Case. Built with the Team ist deshalb keine Methodenfrage, sondern eine Renditefrage. Dieser Artikel zeigt, wie Co-Creation und AI Enablement aus Projektbudget bleibendes Können machen.

Standortbestimmung

Den nächsten Schritt im kostenlosen Diagnose-Call besprechen. Termin buchen →

Inhalt

Was extern gebaut wird, veraltet mit dem Vertrag

Zwei Unternehmen geben dasselbe Budget für AI aus. Das erste kauft ein fertiges System: Spezialist:innen bauen, übergeben, verabschieden sich. Das zweite baut langsamer — aber gemeinsam mit dem eigenen Team.

Nach einem Jahr trennt die beiden mehr als ein Tool. Im ersten Fall endet der Wert mit dem Vertrag. Das System läuft noch, aber niemand im Haus kann es weiterentwickeln. Jede Anpassung kostet ein neues Angebot.

Im zweiten Fall ist etwas entstanden, das auf keiner Rechnung steht: Können. Das Team versteht seine Workflows, passt sie an und baut den nächsten selbst.

Dieses Können kündigt nicht mit dem Dienstleister. Es bleibt — und genau hier setzt Built with the Team an: Der bleibende Wertträger ist nicht das System. Es ist das Team.

Built with the Team als Investitionsentscheidung

Es gibt zwei Arten, ein AI-Budget auszugeben. Die erste ist Einkauf: Ein fertiges System wird geliefert und übergeben. Die zweite ist Aufbau: Das System entsteht gemeinsam mit den Menschen, die es täglich nutzen.

Einkauf wirkt schneller und planbarer. Doch eingekaufte Lösungen verhalten sich wie Maschinen in der Bilanz: Sie verlieren ab dem ersten Tag an Wert. Modelle veralten, Anforderungen verschieben sich, der Wartungsvertrag läuft aus.

Aufbau folgt einer anderen Kurve. Jede gemeinsame Iteration zahlt doppelt ein — in das System und in die Menschen. Diese zweite Einzahlung ist die Lernkurve. Sie bleibt, auch wenn das Tool wechselt.

McKinsey nennt das Redesign von Arbeitsabläufen als den größten einzelnen Treiber für messbaren Effekt (Quelle: McKinsey Global Survey on AI, 2024). Doch ein Workflow, den niemand im Haus besitzt, wird nicht weiterentwickelt — er wird nur verwaltet. Eigentümerschaft entsteht beim Bauen, nicht bei der Übergabe.

Built with the Team entscheidet nicht, ob die AI funktioniert. Es entscheidet, ob das Können im Haus bleibt — oder mit dem Vertrag geht.

So gelesen ist Co-Creation kein weicher Faktor, sondern Kapitalbildung. Ein für das Team gebautes System ist ein Kostenpunkt mit Abschreibung. Ein mit dem Team gebautes System ist eine Anlage, die sich verzinst — der ökonomische Kern jeder gelungenen AI Adoption.

Co-Creation in der Praxis: Wer macht was?

Co-Creation scheitert, wenn Rollen unklar bleiben. “Gemeinsam bauen” darf nicht bedeuten, dass alle alles tun. Es braucht klare Verantwortungen entlang des gesamten Prozesses.

In der Praxis arbeiten wir mit einem einfachen Rollen-Modell. Es trennt fachliche Hoheit von technischer Umsetzung — und hält Endnutzer durchgehend im Zentrum.

Die zentralen Rollen

  • Endnutzer: definieren reale Aufgaben, testen früh, geben kontinuierlich Feedback.
  • Fach-Owner: entscheiden über Priorität und fachliche Korrektheit der Lösung.
  • Solution-Team: baut, integriert und übersetzt Anforderungen in funktionierende Abläufe.
  • Sponsor: sichert Zeit, Budget und Rückendeckung aus der Führung.

Entscheidend ist die Frequenz der Beteiligung. Endnutzer kommen nicht erst zur Abnahme ins Spiel. Sie sind ab der ersten Skizze dabei und prüfen jede Iteration.

So entsteht Ownership nicht nachträglich, sondern von Beginn an. Wer mitgebaut hat, verteidigt das Ergebnis später nicht — er nutzt es selbstverständlich. Das ist der praktische Kern von Built with the Team.

Cockpit-Design mit Endnutzern

Co-Creation wird am sichtbarsten beim Bau der Cockpits. Ein Cockpit bündelt die täglichen Aufgaben an einem Ort. Es entscheidet, ob ein System leicht oder mühsam wirkt.

Genau deshalb darf ein Cockpit nie am grünen Tisch entstehen. Wir entwerfen es mit den Menschen, die es jeden Tag öffnen. Sie zeigen uns, welche Schritte sie wirklich brauchen — und welche stören.

Das Ergebnis ist ein klarer Fokus auf Joy of Use. Ein Cockpit, das sich gut anfühlt, wird zur Gewohnheit. Eines, das Reibung erzeugt, wird umgangen.

Damit zielt Co-Creation direkt auf die Gewohnheits-Dimension der Adoption. Wie sehr diese Dimension über Erfolg entscheidet, vertiefen wir in unserer Analyse zum People-Process Gap. Das Cockpit ist die Brücke zwischen Können und Tun.

Enablement: die Lernkurve als Rendite

Ein gutes System reicht nicht. Es braucht AI Enablement — und Enablement ist keine Schulungskosten-Position, sondern der Teil der Investition mit der längsten Laufzeit. Ein Training endet. Eine Lernkurve verzinst sich.

Die meisten Studien nennen Talent, Vertrauen und organisatorische Faktoren als zentrale Hürden (Quelle: Deloitte Global AI Survey / Stanford HAI AI Index, 2024). Genau diese Faktoren lassen sich nicht einkaufen. Sie müssen im eigenen Team wachsen.

Champions: die Zinsträger im Team

Wirksames Enablement ist ein Programm, kein Event. Es begleitet Teams über Wochen, nicht über Stunden. Drei Bausteine tragen dieses Programm:

  • Kontextnahes Lernen: an echten Aufgaben statt an Demo-Beispielen.
  • Champions im Team: geschulte Kolleg:innen als erste Anlaufstelle vor Ort.
  • Wiederkehrende Rituale: kurze, feste Termine für Fragen und neue Use Cases.

Champions sind dabei mehr als Multiplikator:innen. Sie sind der Ort, an dem sich die Investition verzinst. Jede gelöste Frage macht die nächste schneller lösbar. Jeder dokumentierte Use Case senkt die Kosten des folgenden.

Engagement Step 05: die eigentliche Investitionsentscheidung

In unseren Engagement Steps ist Engagement Step 05 deshalb kein Prozessschritt am Ende. Er ist die eigentliche Investitionsentscheidung: Hier entscheidet sich, ob eine Lösung als Fremdleistung endet — oder als Fähigkeit im Team weiterlebt. Wir bringen Lösungen gemeinsam mit den operativen Teams in die Routine und übergeben damit nicht nur ein System, sondern die Eigentümerschaft am Workflow.

Messung: Adoption-Metriken nach 30/60/90 Tagen

Was Sie nicht messen, können Sie nicht steuern. Lizenzzahlen messen Verfügbarkeit, nicht Nutzung. Built with the Team braucht eigene Adoption-Metriken in einem 30/60/90-Tage-Rhythmus.

Tag 30 — Aktivierung

In den ersten 30 Tagen zählt nicht perfekte Nutzung, sondern der erste echte Kontakt. Messen Sie die Aktivierungsrate.

  • Anteil der Mitarbeitenden mit mindestens einer sinnvollen Nutzung
  • Zeit bis zum ersten erfolgreichen Ergebnis
  • Zahl der dokumentierten Use Cases pro Team

Tag 60 — Gewöhnung

Nach 60 Tagen zeigt sich, ob aus Neugier Routine wird. Jetzt zählt die Wiederkehrrate. Einmalige Nutzung ist kein Erfolg.

  • Wöchentlich aktive Nutzer im Verhältnis zum Gesamtteam
  • Anteil der Aufgaben, die über das neue System laufen
  • Rückgang der Nutzung von Altsystemen

Tag 90 — Wertschöpfung

Nach 90 Tagen geht es um Wirkung. Sparen Teams messbar Zeit? Verbessert sich die Qualität? Hier schließt sich der Kreis zum Geschäftswert.

  • Eingesparte Zeit pro Prozess und Woche
  • Qualitäts- oder Fehlerquote vor und nach der Einführung
  • Zufriedenheit der internen Nutzer
Kernbotschaft

Lizenzen messen Verfügbarkeit. Erst Aktivierung, Wiederkehrrate und eingesparte Zeit zeigen, ob ein System wirklich genutzt wird.

Long-term: AI Learning als Unternehmens-Asset

Adoption ist kein Endzustand. Modelle ändern sich, Aufgaben wandeln sich, neue Use Cases entstehen. Wer einmal einführt und dann stehen bleibt, fällt zurück.

Deshalb ist das eigentliche Ziel von Built with the Team nicht ein einzelnes System. Es ist die Fähigkeit der Organisation, immer wieder mit AI zu lernen. Diese Lernfähigkeit wird zum dauerhaften Unternehmens-Asset.

Sie entsteht genau dort, wo Teams selbst mitgebaut haben. Wer einmal Ownership erlebt hat, baut beim nächsten Mal schneller. Aus einem Projekt wird eine Kompetenz.

Damit wird Built with the Team zur Grundlage des AI Operations Betriebsmodells. Die Frage lautet nicht mehr, ob ein Tool genutzt wird. Sie lautet, wie schnell Ihr Team das nächste meistert — eine zentrale Führungsaufgabe in der AI-Transformation.

Häufige Fragen zu Built with the Team

Was bedeutet Built with the Team genau?

Built with the Team ist ein Designprinzip: AI-Systeme entstehen gemeinsam mit den Menschen, die sie täglich nutzen, statt für sie. Endnutzer sind ab der ersten Skizze beteiligt und prüfen jede Iteration. So entsteht Ownership von Beginn an — und damit eine deutlich höhere Nutzung.

Worin unterscheidet sich Built with the Team von klassischem Change Management?

Klassisches Change Management versucht oft, ein fertiges Ergebnis nachträglich zu vermitteln. Built with the Team verlagert die Beteiligung an den Anfang und macht Vermittlung weitgehend überflüssig. Wer mitgebaut hat, muss nicht überzeugt werden.

Wie schnell zeigt sich der Effekt von Built with the Team?

Erste Signale zeigen sich bereits nach 30 Tagen an der Aktivierungsrate, belastbare Effekte nach 60 bis 90 Tagen. Entscheidend ist der Rhythmus aus Messung und Anpassung. Im kostenlosen Diagnose-Call zeigen wir, welche Rolle zuerst besetzt werden sollte.

Quellen

So geht es weiter