Die Organisation wollte bei KI-gestützter Engineering-Arbeit schneller vorankommen, aber jede ernsthafte Diskussion wurde zu einer bereichsübergreifenden Debatte.
Engineering wollte Klarheit über Tools. Die Sicherheit wollte Grenzen für den Umgang mit Daten und Secrets. Die Rechtsabteilung wollte tragfähige Formulierungen zu KI-Kompetenz und Aufsicht. Der Einkauf wollte einen belastbaren Beschaffungsweg. Die Führung wollte eine praktische Antwort statt einer weiteren Gremienschleife.
Das Risiko bestand darin, dass ein festes Enablement-Paket für das tatsächliche Entscheidungssystem zu klein gewesen wäre.
Ausgangslage
Die Lage des Kunden war komplex genug, dass am Anfang nicht eine Schulung stehen sollte, sondern das Sortieren der Entscheidungen (Routing).
| Stakeholder-Gruppe | Kernfrage | Warum sie den Fortschritt blockierte |
|---|---|---|
| Engineering | Für welche Workflows können Teams KI nutzen? | Tool-Entscheidungen waren ohne Workflow-Grenzen unmöglich |
| Sicherheit | Welche Daten und Repositories liegen außerhalb des Scope? | Teams benötigten klarere operative Guardrails |
| Recht und Risiko | Wie weisen wir Kompetenz und menschliche Aufsicht nach? | Generische Richtlinienformulierungen ließen sich nicht auf die Engineering-Arbeit übertragen |
| Einkauf | Welcher Tool-Pfad sollte unterstützt werden? | Die Lieferantenfreigabe hing vom Scope ab, nicht von der Begeisterung |
Die Organisation musste wissen, welche Entscheidungen zusammengehören und welche sequenziert werden können.
Was .consulting getan hat
Wir haben nicht damit begonnen, einen Multi-Team-Rollout zu versprechen.
Wir sind zunächst einen Executive-Scoping-Pfad durchlaufen, der eine gemeinsame Entscheidungs-Map erstellt hat:
- Inventar aktueller Tools und Workflows
- Stakeholder-Bedenken nach Entscheidungstyp
- genehmigte, ausgeschlossene und ungeklärte Workflow-Kategorien
- Mindestanforderungen an Kompetenz und Review
- Rollout-Routen für Pilot-, Flagship- und Enterprise-Geltungsbereich
Das Ergebnis half der Führung bei der Entscheidung, ob die Organisation bereit für das Enablement war oder ob die Kontrollfunktionen noch auf eine Linie gebracht werden mussten.
Entscheidungsarchitektur
Der entscheidende Schritt besteht darin, drei verschiedene Diskussionen zu trennen, die oft miteinander vermischt werden.
| Entscheidung | Verantwortung | Ergebnis |
|---|---|---|
| Workflow-Genehmigung | Engineering-Führung | Benannte Task-Muster und Grenzen |
| Kontrollgrenze | Partner aus Sicherheit, Recht und Risiko | Vorgaben zu Daten, Repository, Lieferanten und Aufsicht |
| Rollout-Route | Executive Sponsor | Pilot-, Flagship- oder Enterprise-Delivery-Pfad |
Werden diese Entscheidungen vermischt, werden die Meetings länger, ohne dass die Klarheit zunimmt.
KPI-Auswahl
Wir haben zwei KPIs gewählt, weil das eigentliche Problem nicht das Schulungsvolumen war, sondern die Entscheidungslatenz.
| KPI | Warum wir ihn gewählt haben | Ergebnis |
|---|---|---|
| Ausgerichtete Stakeholder-Gruppen | Der Rollout konnte erst weitergehen, wenn sich Engineering, Sicherheit, Recht und Einkauf auf die Route geeinigt hatten | Vier Gruppen gaben einen gemeinsamen Entscheidungspfad frei |
| Executive-Entscheidungspfad | Die Führung brauchte eine konkrete Route statt einer weiteren ergebnisoffenen Gremienschleife | Freigabe der Route in neun Arbeitstagen erreicht |
Resultierendes Betriebsmodell
Der Kunde verließ die Scoping-Phase mit:
- einer gemeinsamen Entscheidungs-Map für das Executive-Review
- einer Shortlist von Workflows, die zuerst starten können
- Kontrollfragen, die vor dem Enablement beantwortet werden müssen
- einer klaren Begründung, warum ein festes Paket angemessen ist oder eben nicht
- einer phasenweisen Rollout-Route, die an die Bereitschaft der Stakeholder gekoppelt ist
Das schützt beide Seiten. Der Kunde erhält einen Entscheidungspfad, und das Engagement tut nicht so, als könnte ein kleines Paket die Komplexität eines Enterprise-Umfelds auffangen.
Warum dieser Fall relevant ist
Regulierte Organisationen scheitern oft nicht daran, dass sie gegen KI sind. Sie scheitern, weil sie eine Delivery-Entscheidung treffen wollen, bevor der Governance-Weg klar nachvollziehbar ist.
Die geschäftliche Aufgabe besteht darin, die Entscheidungsarchitektur sichtbar zu machen.
Sobald sie steht, kann das Enablement mit weniger Reibung vorankommen, weil jeder Stakeholder weiß, welche Frage gerade beantwortet wird.
