Was Teilnehmende öffentlich posten
Kein poliertes Testimonial-Deck, sondern echte Posts direkt nach den Hackathons.
Die Beiträge werden von LinkedIn geladen, das dabei eigene Daten und Cookies verarbeiten kann. Sie laden erst, wenn du sie hier anforderst.
Die Adoptionslücke, die das schließt
Die meisten Enablement-Programme enden am Zertifikat, und die Nutzung bricht eine Woche später ab. Dieser Abfall ist die Adoptionslücke, und sie ist ein Übungs- und kein Wissensproblem. Menschen nutzen ein Tool nicht deshalb weiter, weil sie einen Vortrag verstanden haben. Sie nutzen es weiter, weil sie gespürt haben, was es an ihrer eigenen Arbeit leistet, und weil etwas läuft, das sie zurückzieht. Vier Kräfte weiten die Lücke, wenn ein Programm bei der Anwesenheit endet.
Es ist kein Verhaltenswechsel eingebaut. Ein Kurs behandelt Konzepte und endet. Am folgenden Montag ist nichts anders, also setzt sich der alte Workflow wieder durch.
Der Pilot hat keinen Owner. Ein Tool, das alle nutzen dürfen und für das niemand verantwortlich ist, fällt leise aus der Routine.
Es gibt nichts, zu dem man zurückkehrt. Ohne ein laufendes Artefakt verschwindet die Erinnerung, das Tool zu nutzen, mit den Folien.
Adoption wird nie gemessen. Wenn niemand verfolgt, ob das Tool genutzt wird, bemerkt niemand, dass es aufgegeben wurde, und das nächste Programm wiederholt dieselbe Form.
Enablement schließt die Lücke, indem es Verhalten aufbaut statt Awareness. Eine Woche echtes Arbeiten hinterlässt eine Gewohnheit, die etwas hat, das sie stützt.
Ziele des Enablement-Sprints
Das Ziel ist Arbeitsfähigkeit, kein warmes Gefühl am Freitag. Nach dem Sprint sollten eure Teams Dinge tun, die sie eine Woche vorher nicht konnten, ohne auf eine zentrale Expertenrunde zu warten.
Weitere Nutzung der Tools in den Wochen danach, weil ein laufendes Artefakt die Leute zurückzieht.
Weniger manuelle Updates, schnellere Antworten und bessere interne Suche, gebunden an einen Workflow, den euer Team jetzt besitzt.
Ein benannter Owner je Artefakt mit nächstem Schritt, damit der Pilot nicht verdampft.
Eine dokumentierte KI-Kompetenzmaßnahme als Baustein für den EU AI Act (Art. 4).
Was das Programm umfasst
Ein Enablement-Hackathon ist ein begleiteter Arbeitssprint für Teams, die nicht programmieren können und auch nicht müssen. Teilnehmer arbeiten mit Cursor, Lovable, n8n, Gamma, Figma Make, Claude Code, Custom GPTs und NotebookLM an ihren eigenen Daten, und die Moderation hält jedes Team auf einem eng gefassten Problem, damit am Ende etwas Nutzbares und Besitzbares steht. Enablement fügt eine Sache hinzu, die ein Bootcamp auslässt, einen bewussten Handoff, damit das Artefakt weiterläuft und das Verhalten weitergeht.
Ein typischer Sprint hat vier ineinandergreifende Teile:
- Challenge-Zuschnitt entlang einer Routine. Jede Gruppe nimmt eine echte, wiederkehrende Aufgabe mit benanntem Nutzer und gewünschtem Output, damit das Artefakt von Tag eins an einen Platz in der Wochenroutine hat.
- Tool-Workshop. Bevor gebaut wird, lernt jede Gruppe genau den Stack, den ihre Challenge braucht, damit die gewählten Tools auch die später genutzten sind.
- Bau-Phase. Die Teams bauen mit einem Facilitator daneben, der den Prototyp in einer Grenze hält, die nach der Woche auch betrieben werden kann.
- Pitch, Handoff und Adoptionsplan. Jedes Team zeigt sein Ergebnis, benennt Risiken und übergibt das Artefakt an einen Owner mit nächstem Schritt und einer einfachen Art zu sehen, ob es noch genutzt wird.
Leistungen und Deliverables
Vorab-Scoping mit einer Challenge je Team, gebunden an eine echte Routine.
Kuratierter Toolstack pro Challenge inklusive Zugängen.
Moderierter Bau-Sprint mit Coach während der gesamten Zeit.
Mindestens ein funktionierender Prototyp je Team (Automatisierung, Dashboard, Custom GPT, App-Prototyp oder Workflow), den ein Owner betreiben kann.
Handoff-Dokument je Prototyp mit Owner, Zugängen, offenen Risiken, Abnahmekriterium und nächstem Schritt.
Ein schlanker Adoptionsplan, damit ihr seht, ob das Tool nach 30 Tagen noch genutzt wird.
Dokumentation der KI-Kompetenzmaßnahme für die Teilnehmer.
Für wen es passt, und für wen nicht
Ehrliche Passung spart beiden Seiten Zeit. Enablement ist der stärkere Hebel, wenn diese Punkte zutreffen. Wenn nicht, sagen wir das.
| Passt gut, wenn | Passt eher nicht, wenn |
|---|---|
| euch die Nutzung in den Wochen danach wichtig ist, nicht nur der Tag selbst | eine einmalige inspirierende Session wirklich alles ist, was ihr wollt |
| ein benannter Owner das Artefakt betreibt und Adoption beobachtet | niemand nach der Woche Verantwortung übernehmen kann |
| Daten und Toolzugänge grundsätzlich freigegeben werden können | echte Daten aus rechtlichen Gründen unter keinen Umständen berührt werden dürfen |
| ihr Arbeitsfähigkeit wollt, die man im Workflow sieht | ein Zertifikat in der Akte das Ziel schon erfüllt |
Klassisches Training vs. Enablement-Hackathon
| Kriterium | Klassisches Training oder E-Learning | AI Hackathons Enablement-Hackathon |
|---|---|---|
| Output | Zertifikat oder Anwesenheitsnachweis | funktionierender Prototyp, den euer Team betreibt |
| Was es ändert | Wissen am Tag | Verhalten in den Wochen danach |
| Adoption nach 30 Tagen | unklar ohne Messung | eingeplant und über einen schlanken Plan beobachtet |
| Verantwortung danach | selten geklärt | benannter Owner mit nächstem Schritt |
| Nutzen-Nachweis | kaum belegbar | greifbares Artefakt als Ausgangspunkt für eure eigene Messung |
| Zeit bis erstem Ergebnis | Wochen bis Monate | startklar in 1 Woche, Ergebnis je nach Scope |
Die Tabelle vergleicht Arbeitsweisen, nicht Anbieter, und enthält bewusst keine erfundenen Prozentzahlen. Belastbare Adoptionswerte entstehen erst aus eurer eigenen Messung über die Zeit. Eine Armee mit hundert Leuten, die alle mit den Tools umgehen können, schlägt eine mit tausend, von denen nur zehn kämpfen können, genau deshalb misst Enablement die Nutzung, nicht die Anwesenheit.
So kann sich der Nutzen rechnen (Modell, keine Kundenzahl)
Eine ehrliche Betrachtung der Amortisation nutzt eure eigenen Größen, nie eine geliehene Fallzahl. Das Modell hat drei Eingaben und eine Formel.
Zeit pro Woche, die eine Person für eine wiederkehrende Aufgabe braucht, die das Artefakt berührt, etwa das Beantworten wiederkehrender Kundenfragen.
Anteil, den das Tool realistisch abnimmt, sobald es wirklich adaptiert ist.
Interner Stundensatz mal Zahl der Personen, die es weiter nutzen.
Formel: gesparte Stunden pro Woche × Stundensatz × 45 Arbeitswochen × Personen, die es weiter nutzen − einmalige Kosten des Sprints und der Nachverfolgung. Setzt eure Zahlen ein. Nur als illustratives Modell: Wenn wiederkehrende Antworten je Person vier Stunden pro Woche kosten und ein adaptierter Assistent die Hälfte abnimmt, sind das zwei Stunden über, sagen wir, zwölf Personen und ein Jahr, aber nur für die Personen, die es wirklich weiter nutzen, weshalb Adoption der wichtigste Begriff in dieser Formel ist. Diese Rechnung machen wir im Discovery Call mit euren echten Werten, nicht mit unseren.
Interaktiver Rechner: /de/tools/ki-enablement-readiness/.
Passt das zu eurem Ziel? Entscheidet mit einem Menschen, oder lest zuerst.
Social Proof
Teams von Adobe, YOYABA, Onventis und NavVis haben mit uns gearbeitet.
Case Studies ansehen
Discovery Call buchen