Die Organisation setzte bereits aktiv KI ein. Entwickler nutzten Coding-Assistenten, Chat-Tools und lokale Prompt-Gewohnheiten zur Unterstützung von Implementierung, Tests, Dokumentation und Pull-Request-Arbeit.
Das Problem war nicht mangelndes Interesse. Das Problem war, dass der KI-Einsatz skalierte, ohne dass ein vereinbartes Betriebsmodell vorlag.
Die Manager konnten zwar eine zunehmende Nutzung erkennen, aber sie konnten die entscheidenden Fragen nicht beantworten, die sich stellen, sobald KI in der täglichen Engineering-Arbeit zum Einsatz kommt:
- Welche Workflows sind tatsächlich genehmigt?
- Welchen Tool-Pfad sollten Teams standardmäßig wählen?
- Was soll ein Reviewer validieren?
- Wer verantwortet die Verankerung nach dem Kickoff?
- Welche Nachweise belegen, dass die Adoption funktioniert und sich nicht nur ausbreitet?
Ausgangslage
Das Führungsteam hatte drei sichtbare Spannungsfelder.
| Bereich | Ausgangslage | Risiko bei Nichtbehebung |
|---|---|---|
| Tooling | Teams nutzten unterschiedliche Assistenten und Prompt-Gewohnheiten | Einkauf und Sicherheit konnten unterstützte Nutzung nicht von bloß geduldeter unterscheiden |
| Review | Menschliches Review existierte, doch die Erwartungen unterschieden sich je Team | Die Review-Qualität hing vom individuellen Urteil ab statt von einem gemeinsamen Standard |
| Messung | Anekdotische Nutzungsangaben lagen vor, doch die Adoptions-Nachweise waren schwach | Die Führung konnte Begeisterung mit operativer Reife verwechseln |
Der Käufer brauchte keinen weiteren motivierenden KI-Workshop. Er brauchte ein eng gefasstes Betriebsmodell, das realem Delivery-Druck standhalten würde.
Was .consulting getan hat
Wir begannen damit, die tatsächliche Engineering-Arbeit zu erfassen, statt abstrakten KI-Bedarf abzufragen.
In der ersten Phase ermittelten wir, wo KI bereits in wiederkehrenden Workflows auftauchte: Unterstützung bei ersten Implementierungsentwürfen, Entwurf von Testfällen, Zusammenfassung von Pull Requests, technische Erläuterungen und Aktualisierungen der Dokumentation.
In der zweiten Phase wählten wir die Workflows aus, die eine formale Genehmigung wert sind. Drei Workflows wurden zu den ersten genehmigten Kandidaten:
- interne Implementierungsunterstützung für nicht sensiblen Service-Code
- Entwurf von Testfällen für bestehendes Verhalten
- Zusammenfassung von Pull Requests für ausgewählte Repositories
In der dritten Phase definierten wir die operativen Regeln:
- genehmigter Tool-Pfad
- ausgeschlossene Repositories oder Datenklassen
- erforderliche menschliche Validierungsschritte
- Erwartungen an Reviewer
- Eskalationsweg, wenn das Ergebnis Zweifel aufwirft
- Rhythmus der Verankerung durch Manager
Enablement-Modell
Das Programm schulte nicht jeden Entwickler auf jeden denkbaren Anwendungsfall.
Es befähigte drei Gruppen auf unterschiedliche Weise:
| Gruppe | Enablement-Schwerpunkt |
|---|---|
| Technische Führungskräfte | Scope, Verantwortung, Rollout-Logik und Adoptions-Checkpoint |
| Engineering-Manager | Sprache zur Verankerung, Team-Rituale und Ausnahmebehandlung |
| Reviewer und Entwickler | Workflow-Grenzen, Validierungsstandards und Beispiele akzeptabler Nutzung |
Diese Unterscheidung ist wichtig. Ein CTO, ein Manager, ein Reviewer und ein Entwickler brauchen nicht dieselbe Session. Sie brauchen eine gemeinsame Sprache rund um unterschiedliche Verantwortlichkeiten.
KPI-Auswahl
Wir wählten von Anfang an zwei KPIs, weil sie zeigten, ob das Modell das tatsächliche Delivery-Verhalten verändert:
| KPI | Warum wir ihn gewählt haben | Ergebnis |
|---|---|---|
| Review-Handoff-Zeit | An der Review-Verzögerung wurden inkonsistente Erwartungen zuerst sichtbar | 31 % schnellerer Handoff bei ausgewählten KI-unterstützten Pull Requests |
| Nutzung genehmigter Workflows | Die Führung musste sanktionierte Nutzung von informellem Experimentieren trennen | 78 % der erfassten KI-unterstützten Arbeit folgten bis zum Review-Checkpoint dem genehmigten Modell |
Resultierendes Betriebsmodell
Am Ende des Engagements verfügte der Kunde über:
- eine genehmigte KI-Workflow-Map
- ein Entscheidungsprotokoll für Tool und Review
- drei Teams, die auf dasselbe Modell hin befähigt sind
- benannte Verantwortliche für die Verankerung
- ein 90-Tage-Adoptions-Review mit bereits definierten Nachweisfragen
Das stärkste Ergebnis ist keine spektakuläre Produktivitätsbehauptung. Das stärkere Ergebnis ist, dass die Führung das Betriebsmodell nun beschreiben kann, ohne zu improvisieren.
Warum dieser Fall relevant ist
Das ist in vielen SaaS-Engineering-Teams verbreitet: Die Nutzung ist bereits da, doch Governance und Messung kommen zu spät.
Der kommerzielle Wert der Arbeit besteht nicht darin, Entwickler für KI zu begeistern. Das sind sie bereits.
Der Wert besteht darin, verstreute Nutzung in ein genehmigtes Workflow-System zu überführen, das Manager verankern können und dem Reviewer vertrauen können.
