KI im Enterprise-Umfeld: Schnellere Entwicklung braucht andere Prozesse

Diesen Beitrag anhören (15 Min.)

Wenn die Implementierung statt fünf Tagen nur noch zwei dauert, die Änderung danach aber zwölf Tage auf Reviews, Freigaben und ein gemeinsames Testfenster wartet, ist das Produkt kaum früher beim Nutzer. Die lokale Arbeit wurde schneller. Der Gesamtprozess nicht.

Genau diese Verschiebung macht KI in großen Unternehmen sichtbar. Ein Entwickler kann Code, Tests und eine erste Dokumentation in einem Bruchteil der bisherigen Zeit vorbereiten. In Forschung und Entwicklung (R&D) lassen sich Hypothesen schneller prüfen und Prototypen früher zeigen. Gleichzeitig bleiben Abhängigkeiten zwischen Teams, widersprüchliche Dokumentation und gewachsene Freigaberunden unverändert. Der Engpass rückt aus der Implementierung in die Organisation.

Das ist kein Argument gegen große Unternehmen. Ihre Formalitäten sind selten aus reiner Freude an Bürokratie entstanden. Regulierung, Produkthaftung, wechselnde Mitarbeiter, verteilte Systeme und jahrzehntelang betriebene Software brauchen Nachvollziehbarkeit. Problematisch wird es, wenn niemand mehr unterscheiden kann, welche Formalität ein echtes Risiko beherrscht und welche nur eine frühere Unsicherheit verwaltet.

KI verstärkt den vorhandenen Arbeitsfluss

Die Zahlen zur Produktivität passen nur auf den ersten Blick nicht zusammen. Drei Feldexperimente bei Microsoft, Accenture und einem weiteren Fortune-100-Unternehmen mit insgesamt 4.867 Entwicklern ergaben für Nutzer eines Coding-Assistenten rund 26 Prozent mehr erledigte Aufgaben; die Wirkung unterschied sich nach Erfahrung und Kontext. Eine randomisierte METR-Studie mit erfahrenen Open-Source-Entwicklern kam dagegen für frühe 2025er-Werkzeuge auf 19 Prozent längere Bearbeitungszeiten. Im Februar 2026 berichtete METR von Hinweisen auf bessere Ergebnisse mit neueren agentischen Werkzeugen, hielt die Daten wegen Auswahleffekten aber selbst für zu unsicher, um die Größe des Nutzens zu beziffern.

Die Befunde widersprechen sich weniger, als es scheint. Aufgabe, Codebasis, Erfahrung, Werkzeug und Abnahmekriterium verändern das Ergebnis. Der DORA-Report 2025 fasst den organisatorischen Teil treffend zusammen: KI wirkt als Verstärker. Gute Feedbackschleifen, gepflegte interne Daten und kleine Änderungen profitieren. Unklare Zuständigkeiten und schwerfällige Abläufe werden ebenfalls verstärkt.

In dieselbe Richtung weist ein Befragungsergebnis aus dem Atlassian State of Developer Experience Report 2025: Entwickler berichteten dort von Zeitersparnis durch KI und zugleich von wöchentlichen Zeitverlusten durch organisatorische Reibung. Solche Selbstauskünfte sind keine Stoppuhr. Als Diagnose sind sie trotzdem nützlich: Schnellerer Code beseitigt keine Wartezeit.

Der Ticketbaum ist nicht das Produkt

In einem großen Unternehmen kann aus einer Produktidee zunächst eine Initiative werden, darunter ein Epic, mehrere Features, Stories und Subtasks. Die Fachbeschreibung liegt in Confluence, eine Architekturentscheidung in einem Kommentar, die Abnahmebedingung in einem Ticket und die tatsächliche Regel im Code. Jede Ebene ist für sich nachvollziehbar. Zusammen entstehen mehrere Wahrheiten.

Daraus entsteht häufig ein halb agiles, halb wasserfallartiges Vorgehen. Das Team arbeitet in Sprints, muss den Inhalt aber Monate vorher für Budget, Abhängigkeiten und Gremien festlegen. Rückfragen landen als Ticketkommentare, weil das gesprochene Wort nicht als belastbar gilt. Also wird mehr geschrieben, ohne dass die Dokumentation dadurch konsistenter wird. Bei der Integration mehrerer Systeme wächst die Zahl der Abstimmungen schneller als die Zahl der fachlichen Entscheidungen.

KI sollte diesen Apparat nicht automatisch befüllen. Sonst entstehen nur mehr Epics, längere Zusammenfassungen und noch überzeugender klingende Kommentare. Der bessere Ansatz beginnt mit einer einzigen, kleinen Beschreibung der Absicht. Alles Weitere wird daraus abgeleitet und bleibt mit der Änderung versioniert.

change:
  id: customer-address-v2
  outcome: reduce failed deliveries
  constraints:
    - preserve existing API clients
    - keep customer consent auditable
  owners:
    product: customer-experience
    technical: customer-platform
  evidence:
    - contract-tests
    - migration-report
    - rollback-plan
  risk: medium

Das ist kein neues Pflichtformular. Es ist ein Beispiel für ein kleines, versioniertes Änderungsartefakt, über das man sinnvoll streiten kann. Mit lesendem Zugriff auf einen indexierten Code- und Entscheidungsbestand darf ein Agent daraus betroffene Repositories, frühere Entscheidungen, Verträge und Tests zusammensuchen. Er darf einen Plan, Akzeptanzbeispiele und Dokumentationsänderungen vorschlagen. Outcome, Einschränkungen, Risiko und Eigentümer bestimmt weiterhin das Team.

Der Unterschied zum Ticketbaum liegt in der Richtung: Menschen pflegen nicht fünf Darstellungen derselben Änderung. Die unterschiedlichen Sichten werden aus wenigen versionierten Quellen erzeugt. Das Ticket verweist auf das Artefakt, der Pull Request zeigt den Diff, und die Dokumentation verweist auf die Entscheidung. Eine Zusammenfassung für das Management darf anders aussehen als die technische Sicht, aber beide müssen auf denselben Stand zurückführbar sein.

Integration braucht Verträge statt mehr Abstimmung

Komplexe Integration wird durch KI nicht automatisch einfach. Ein Agent kann einen unbekannten Service schnell lesen und trotzdem eine fachliche Annahme übersehen, die nur das betreibende Team kennt. Gerade deshalb sollte die Zusammenarbeit weniger von Prosa und stärker von überprüfbaren Verträgen abhängen.

Beim Beispiel der geänderten Kundenadresse könnte das relevante Ereignis als Schema vorliegen:

{
  "$id": "CustomerAddressChanged.v2",
  "type": "object",
  "required": ["customerId", "address", "consentId"],
  "properties": {
    "customerId": { "type": "string" },
    "address": { "$ref": "Address.v2.json" },
    "consentId": { "type": "string" }
  }
}

Die KI kann im Code nach Produzenten und Konsumenten suchen, einen Kompatibilitätsbericht erstellen, Contract Tests ergänzen und Testdaten vorbereiten. Der Kompatibilitätsbericht muss für jede Aussage Repository, Revision und Fundstelle ausweisen – etwa dafür, dass das CRM consentId bereits liefert, der Versandservice das Feld ignoriert und ein alter Export mit Address.v1 arbeitet. So lässt sich die Recherche prüfen, bevor daraus eine Entscheidung entsteht.

Entscheiden muss sie nicht. Ob eine alte Adresse noch verarbeitet werden darf, ist eine fachliche Frage. Ob beide Versionen parallel laufen oder ein Adapter nötig ist, ist eine Architekturentscheidung. Der Agent sammelt Evidenz; die beteiligten Teams verantworten den Vertrag. Genau dafür sind ADRs und ausführbare Spezifikationen wertvoll: Sie halten nicht jedes Gespräch fest, sondern das Ergebnis und seine Gründe.

Dokumentation wird abgeleitet, nicht abgeschafft

Confluence bleibt für Erklärungen, Einstiegspunkte und Übersichten nützlich. Es sollte nur nicht länger die dritte manuell gepflegte Kopie dessen sein, was Ticket und Code ebenfalls beschreiben. Eine Seite braucht einen benannten Eigentümer, einen überprüfbaren Bezug zu Vertrag, ADR oder Repository und ein sichtbares Aktualisierungsdatum. Fehlt diese Verbindung, darf ein Agent die Seite als möglicherweise veraltet markieren, aber nicht stillschweigend zur Wahrheit erklären.

KI kann aus einer freigegebenen Änderung verschiedene Sichten erzeugen: Release Notes für Nutzer, einen technischen Integrationshinweis und eine kurze Zusammenfassung für das Portfolio. Der jeweilige Text bleibt überprüfbar, weil er auf dieselben Artefakte verweist. Menschen müssen dann nicht jeden Satz dreimal schreiben. Sie prüfen, ob die abgeleitete Sicht für ihre Leser stimmt. Die Dokumentation wird dadurch konsistenter und die Pflicht zugleich kleiner: Festgehalten werden Entscheidung, Vertrag und Betriebsfolge – nicht jede Zwischenstufe der Diskussion.

flowchart LR
  Idea[Produktidee] --> Ticket[Ticket-Hierarchie]
  Ticket --> Docs[Separate Dokumentation]
  Docs --> Meetings[Abstimmungsrunden]
  Meetings --> Build[Große Umsetzung]
  Build --> Test[Gemeinsames Testfenster]
  Test --> Approval[Externe Freigabe]

  Intent[Versionierte Absicht] --> SmallChange[Kleine Änderung]
  SmallChange --> Evidence[Tests, Vertrag und Diff]
  Evidence --> Review[Peer Review]
  Review --> Release[Release]
  Release --> Feedback[Nutzer- und Betriebssignal]
  Feedback --> Intent

Agil wird man durch die Kosten einer Änderung

Agilität ist kein bestimmtes Board und keine Zahl von Meetings. Das ursprüngliche Agile Manifesto stellt funktionierende Software über umfassende Dokumentation und die Reaktion auf Veränderung über das Befolgen eines Plans. Beide Aussagen verlangen keine Sorglosigkeit. Sie verlangen, dass neue Information den Arbeitsstand tatsächlich verändern kann.

Ob KI Recherche, Prototyping oder Testentwurf in einem konkreten Wertstrom verkürzt, muss dort gemessen werden. Wenn das gelingt, sinken die Kosten kleiner Experimente. R&D kann dann stärker mit Hypothesen arbeiten: Was wollen wir lernen, welches kleinste Experiment liefert Evidenz, und welches Ergebnis würde unsere Richtung ändern? Produktentwicklung kann denselben Rhythmus nutzen.

Die Voraussetzung sind kleine Batches. Mehr parallel erzeugter Code verschlechtert den Fluss, wenn die Review-Kapazität gleich bleibt. Die Folge wäre eine neue Form von Lagerbestand – halbfertige Pull Requests statt halbfertiger Tickets. Wie bei Developer Productivity zählt deshalb nicht die Tippgeschwindigkeit, sondern die Zeit bis zu belastbarem Feedback. DORA-Metriken helfen beim Diagnostizieren; sie dürfen nicht zum Ziel für einzelne Mitarbeiter werden.

Governance ohne pauschale Warteschlange

Kontrolle bleibt nötig, aber nicht jede Änderung verdient denselben Weg. Eine Textkorrektur, eine rückwärtskompatible API-Erweiterung und ein neues Berechtigungsmodell haben verschiedene Schadenspotenziale. Gute Governance macht diesen Unterschied ausführbar. Das NIST AI Risk Management Framework verfolgt denselben Gedanken auf der Ebene der KI-Systeme selbst: Es strukturiert Risikomanagement über Governance, Messung und laufende Steuerung statt über eine einzelne pauschale Freigabe.

approval_policy:
  - risk: low
    requires: [tests, policy-checks, peer-review]
    decision: peer-approved
  - risk: medium
    requires: [tests, contract-checks, owner-review, rollback-plan]
    decision: peer-approved
  - risk: high
    requires: [security-review, compliance-review, business-owner, audit-record]
    decision: manually-approved

Auch diese YAML-Datei ist nur eine Skizze, keine fertige Policy-Sprache. Automatisierte Kontrollen erzeugen bei jeder Änderung dieselbe Evidenz. Menschen prüfen dort, wo Kontext, Haftung oder schwer rückbaubare Wirkung hinzukommen. DORA empfiehlt, schwere externe Change Approvals durch Peer Review, kontinuierliche Tests, Monitoring und gezielte Zusatzprüfung riskanter Änderungen zu ersetzen. Das ist weniger Bürokratie und zugleich präzisere Kontrolle.

flowchart TD
  Change[Änderung mit Evidenz] --> Risk{Risikoklasse}
  Risk -->|niedrig| Guardrails[Automatische Guardrails]
  Guardrails --> Peer[Peer Review]
  Peer --> Release[Release]
  Risk -->|mittel| Owner[Fachlicher und technischer Owner]
  Owner --> Release
  Risk -->|hoch| Specialist[Security, Compliance und Business]
  Specialist --> Approval{Freigabe}
  Approval -->|ja| Release
  Approval -->|nein| Rework[Überarbeiten oder verwerfen]

Der EU AI Act macht eine zweite Unterscheidung wichtig. Artikel 4 der Verordnung (EU) 2024/1689 zur KI-Kompetenz gilt seit dem 2. Februar 2025: Anbieter und Betreiber müssen Maßnahmen treffen, damit Menschen, die in ihrem Auftrag mit KI-Systemen arbeiten, über ein ausreichendes Maß an KI-Kompetenz verfügen. Anhang III Nr. 4 der Verordnung erfasst – abhängig vom bestimmungsgemäßen Verwendungszweck – unter anderem Systeme, die Beschäftigte bewerten oder überwachen oder Aufgaben anhand persönlichen Verhaltens oder persönlicher Merkmale zuweisen. Ein Produktivitätsranking aus Prozessdaten fällt nicht automatisch darunter. Wird es jedoch für Personalentscheidungen, Leistungsbewertung oder Aufgabenzuweisung genutzt, liegt es in einem rechtlich besonders sensiblen Bereich. Governance soll die Arbeit absichern, nicht Menschen unter Generalverdacht stellen.

Die Organisation muss dem Arbeitsfluss folgen

Ein neuer Assistent allein ändert kein Organigramm. Auf Dauer passt aber eine Organisation mit vielen Übergaben schlecht zu einer Arbeitsweise, die in kurzen Schleifen lernen soll. Für Wertströme mit häufigen teamübergreifenden Änderungen werden drei Strukturen wichtiger:

langlebige, funktionsübergreifende Produktteams, die eine Wirkung von der Idee bis zum Betrieb verantworten und kleine Änderungen selbst freigeben können
eine interne Plattform, die sicheren Zugriff auf Code, Dokumentation, Testumgebungen und freigegebene KI-Modelle als Standardweg anbietet
Governance-, Security- und Architekturgruppen, die Regeln, Referenzlösungen und Ausnahmen gestalten, statt jede normale Änderung einzeln durchzuwinken

Das entspricht dem Muster, das ich schon bei einfacherem Entwurf und weniger Prozess beschrieben habe: Erst die Änderung klein und ihre Erwartungen explizit machen, dann den Prozessschritt entfernen, der dadurch überflüssig wird. Eine lokal gemessene Zeitersparnis ersetzt diese Architekturarbeit nicht.

Für die beteiligten Rollen verschiebt sich der Schwerpunkt:

Rolle	Neuer Schwerpunkt
Entwickler	Aufgaben schneiden, Kontext bereitstellen, generierte Änderungen prüfen, Tests und Betriebssignale entwerfen
Architekten	Systemverträge, automatisierte Architekturregeln, Rückbaubarkeit und sichere Standardwege gestalten
Product Owner	Outcomes, Akzeptanzbeispiele und Nutzerfeedback schärfen, statt den Ticketbestand zu verwalten
Projektmanagement	Abhängigkeiten, Risiken, Wartezeiten und Work in Progress verringern, statt Tätigkeiten im Detail vorzuplanen

Keine dieser Rollen verschwindet. Im Gegenteil: Je billiger die Erzeugung von Vorschlägen wird, desto wertvoller werden Auswahl, Urteil und Verantwortung. Das Ergebnis eines einzelnen KI-Power-Users lässt sich nicht einfach auf ein Enterprise übertragen. Teams brauchen gemeinsame Prüfkriterien, Lernzeit und einen Arbeitsfluss, der Unterschiede sichtbar macht.

Klein anfangen und den Gesamtzyklus messen

Ein unternehmensweites Transformationsprogramm wäre ein widersprüchlicher Anfang. Besser ist ein einzelner Wertstrom mit einer wiederkehrenden Änderung, deren Risiko bekannt ist. Dort lässt sich der heutige Weg vom Wunsch bis zum Betrieb aufzeichnen: Wie lange wird gearbeitet, wie lange gewartet, wie oft wird dieselbe Information übertragen, und an welcher Stelle entsteht Nacharbeit?

Für einen ersten Versuch reichen wenige Schritte:

ein versioniertes Änderungsartefakt und die führenden Quellen festlegen
der KI nur lesenden Zugriff geben und ihren Kontext nachvollziehbar protokollieren
Tests, Contract Checks und Dokumentations-Diffs automatisch als Evidenz erzeugen
zunächst ausschließlich kleine, reversible Änderungen durch den neuen Pfad schicken
Lead Time, Wartezeit, Zahl der Übergaben, Nacharbeit, Change Fail Rate und Zeit bis zum Nutzerfeedback vergleichen

Nicht messen würde ich erzeugte Codezeilen, geschlossene Tickets oder individuelle Prompt-Aktivität. Solche Zahlen belohnen Volumen. Messen würde ich den Bestand halbfertiger Arbeit, den Anteil einer vorab festgelegten Dokumentstichprobe, der einem benannten Vertrag, ADR oder Repository-Stand widerspricht, und die Zeit vom Öffnen einer Review-Anfrage bis zur ersten Freigabe oder konkreten Änderungsanforderung. Der Anteil der Releases, die über den kontrollierten Pfad laufen, misst die Prozessabdeckung und nicht die Wirkung.

Fazit

Die schwerfälligen Abläufe großer Unternehmen sind kein Naturgesetz, aber auch nicht bloß Dummheit aus der Vergangenheit. Sie bewahren Zuständigkeit, Wissen und Kontrolle dort, wo technische Mittel lange nicht ausgereicht haben. KI verändert diese Rechnung, weil sie Kontext schneller zusammentragen, Evidenz vorbereiten und wiederkehrende Prüfungen unterstützen kann.

Der Gewinn entsteht erst, wenn die Organisation die frei werdende Zeit nicht mit mehr Output füllt. Dann werden Änderungen kleiner, Verträge ersetzen einen Teil der Abstimmung und versionierte Artefakte vermeiden widersprüchliche Kopien. Freigaben richten sich nach dem Risiko statt nach einer pauschalen Warteschlange. Menschen behalten die Entscheidungen, bei denen Fachlichkeit, Haftung und Folgen zählen.

So kann KI Entwicklung und R&D tatsächlich agiler machen: nicht indem sie den alten Prozess schneller ausfüllt, sondern indem sie hilft, seine Umwege überflüssig zu machen.

Weiterführende Quellen

Wie fandest du diesen Beitrag?