Nach einer Übernahme mussten zwei Engineering-Organisationen als ein gemeinsames Delivery-System arbeiten.
Beide Gruppen nutzten bereits KI. Sie hatten unterschiedliche Tool-Präferenzen, unterschiedliche Review-Erwartungen und eine unterschiedliche Toleranz für informelles Experimentieren. Keiner dieser Unterschiede war ungewöhnlich. Die Schwierigkeit war, dass die Führung nun eine gemeinsame operative Sprache brauchte.
Ohne diese Sprache drohte die KI-Adoption zu einer weiteren Quelle der Fragmentierung nach der Übernahme zu werden.
Ausgangslage
Die Integrationsherausforderung war teils technisch und teils organisatorisch.
| Dimension | Gruppe A | Gruppe B |
|---|---|---|
| Tool-Gewohnheiten | Stärkere Präferenz für zentralisiertes Tooling | Mehr lokale Autonomie |
| Review-Erwartungen | Umfangreicheres architektonisches Review | Schnelleres Review auf Team-Ebene |
| Dokumentation | Formale Entscheidungsprotokolle | Eher informelle Team-Notizen |
| KI-Haltung | Vorsichtige Ausweitung | Aktives Experimentieren |
Es ging nicht darum, eine Kultur für richtig und die andere für falsch zu erklären. Es ging darum, das gemeinsame operative Minimalmodell zu definieren.
Was .consulting getan hat
Wir begannen mit einem integrationsorientierten Audit der KI-Nutzung.
Das Audit verglich:
- aktive KI-Tools
- wiederkehrende Engineering-Workflows
- Review-Standards
- Erwartungen der Kontrollfunktionen
- Verankerungsmuster der Führungskräfte
- aktuell verfügbare Adoptions-Nachweise
Auf dieser Grundlage definierten wir eine gemeinsame Adoptions-Baseline: die kleinste Menge an Workflow-, Review- und Ownership-Regeln, die beide Gruppen einhalten mussten.
Ausrichtungsarbeit
Im Rahmen des Mandats entstand eine praxisnahe Integrations-Map.
| Arbeitsstrang | Ergebnis |
|---|---|
| Workflow-Vergleich | Welche KI-gestützten Workflows in beiden Gruppen existieren |
| Tool-Pfad-Abgleich | Welche Tools unterstützt, toleriert oder außerhalb des Scope sind |
| Review-Modell | Gemeinsame Erwartungen an die menschliche Validierung |
| Verankerung durch Führungskräfte | Gemeinsame Sprache für Team-Leads |
| Adoptions-Baseline | Nachweise, die nach dem Rollout zu prüfen sind |
Das gibt der Führung eine neutrale Diskussionsgrundlage. Das Gespräch dreht sich weniger um Präferenzen und mehr um operative Entscheidungen.
KPI-Auswahl
Wir wählten Integrations-KPIs, weil der Käufer weniger Drift brauchte und keinen generischen Enablement-Score.
| KPI | Warum wir ihn gewählt haben | Ergebnis |
|---|---|---|
| Ausgerichtete Engineering-Gruppen | Die Führung brauchte ein gemeinsames Minimalmodell über beide Organisationen hinweg | Zwei Gruppen akzeptierten eine gemeinsame Baseline |
| Nicht unterstützter Tool-Drift | Die Tool-Varianz war ein praktischer Indikator für die Fragmentierung des Betriebsmodells | 42 % Reduktion nicht unterstützter Tool-Pfade nach Einführung der Baseline |
Resultierendes Betriebsmodell
Der Käufer ging mit Folgendem aus dem Mandat:
- eine gemeinsame KI-Betriebs-Baseline
- eine Workflow-Shortlist für den Rollout
- ein Review-Modell, das von beiden Engineering-Gruppen akzeptiert wird
- eine Reihe offener Entscheidungen für das Executive-Follow-up
- einen Adoptions-Checkpoint für die Prüfung nach der Integration
Es geht nicht um sofortige Harmonisierung. Es geht darum, vermeidbare Drift zu reduzieren, solange die Organisation noch in der Integration steckt.
Warum dieser Fall relevant ist
Engineering-Arbeit nach einer Übernahme bringt ohnehin schon genug Unklarheit mit sich. Die KI-Adoption kann diese Unklarheit entweder verstärken oder zum Auslöser für klarere operative Entscheidungen werden.
Der Unterschied liegt darin, ob die Führung KI als Tool-Rollout behandelt oder als Gespräch über das Betriebsmodell.
