KI-Nutzen im Salesforce-Projekt messen

Den KI-Nutzen im Salesforce-Projekt messen Sie mit Ergebniskennzahlen gegen Ihre eigene Basislinie: Durchlaufzeit pro Story, Fehlerdurchschlupf, Nacharbeit und Change Fail Rate, erfasst bevor der erste Coding-Agent kommt. Eindrücke der Entwickler und Lizenzzahlen beweisen nichts. Die veröffentlichten Studien reichen von 55 Prozent schneller bis 19 Prozent langsamer, je nach Aufgabe und Codebasis. Eine gewachsene Org mit Jahren an Triggern, Flows und SAP-Schnittstelle liegt am schwierigen Ende dieser Spanne. Ob KI Ihr Programm schneller macht, beantwortet deshalb nur eine Zahl, die Sie selbst erhoben haben.

Was sagen die Studien zur Produktivität mit KI-Coding?

Fünf Quellen tauchen in jeder Diskussion auf, und sie messen sehr Unterschiedliches.

• GitHub, 2022. In einem kontrollierten Experiment1 schrieben 95 Entwickler einen HTTP-Server in JavaScript. Die Gruppe mit Copilot brauchte rund 1 Stunde 11 Minuten, die Kontrollgruppe 2 Stunden 41 Minuten: 55 Prozent schneller. Eine kleine, neue, klar umrissene Aufgabe.
• METR, 2025. In einer randomisierten Studie2 bearbeiteten 16 erfahrene Open-Source-Entwickler 246 echte Issues in ihren eigenen Projekten mit im Schnitt über einer Million Codezeilen. Mit KI brauchten sie 19 Prozent länger. Vorher erwarteten sie 24 Prozent Beschleunigung, hinterher glaubten sie immer noch, KI habe sie 20 Prozent schneller gemacht.
• METR, Februar 2026. Im Update3 schreibt METR, Entwickler würden mit heutigen Werkzeugen wahrscheinlich stärker beschleunigt, die Daten seien aber „only very weak evidence for the size of this increase“. Ein Grund: Mehr Entwickler wollten gar nicht mehr ohne KI arbeiten, und 30 bis 50 Prozent gaben an, Aufgaben zurückgehalten zu haben, die sie nicht ohne KI erledigen wollten.
• DORA, 2025. Für den State of AI-assisted Software Development4 wurden fast 5.000 Fachleute befragt. 90 Prozent nutzen KI im Job, mehr als 80 Prozent glauben, dass sie produktiver geworden sind. Mehr KI-Nutzung geht inzwischen mit höherem Durchsatz einher, aber weiterhin mit geringerer Stabilität der Auslieferung. DORA fasst es so zusammen: „AI doesn’t fix a team; it amplifies what’s already there.“
• McKinsey, August 2026. Eine Umfrage unter 334 Produkt- und Engineering-Verantwortlichen5 ergab im Schnitt 11,8 Prozent Zeitersparnis über den Entwicklungszyklus, aber nur 6,2 Prozent weniger Nacharbeit. 30 Prozent meldeten sinkende Produktivität im Team. Rund 80 Prozent der Entwickler gewannen etwa 3 Prozent, die besten 20 Prozent etwa 55 Prozent.

55 %

weniger Zeit mit Copilot bei einer kleinen, neuen JavaScript-Aufgabe (GitHub 2022)

19 %

mehr Zeit mit KI für erfahrene Entwickler in ihrer eigenen großen Codebasis (METR 2025)

20 %

Zeitgewinn, den dieselben Entwickler hinterher trotzdem vermuteten (METR 2025)

11,8 %

durchschnittliche Zeitersparnis über den Entwicklungszyklus (McKinsey 2026)

Meine Lesart: Die Beschleunigung ist für manche Personen und manche Aufgaben echt, der Durchschnitt aber deutlich kleiner als auf den Folien der Anbieter. Die Wahrnehmungslücke aus der METR-Studie würde ich jedem Lenkungsausschuss zeigen. Wenn sich die Leute, die die Arbeit machen, bei der eigenen Geschwindigkeit um fast 40 Punkte verschätzen, ist das „wir sind 30 Prozent schneller“ eines Partners eine Meinung.

Warum ähnelt eine Salesforce-Org eher METR als GitHub?

Die Org eines Herstellers nach fünf oder mehr Jahren ist eine große bestehende Codebasis mit viel implizitem Wissen. Garantielogik in Apex, ein Händlerportal auf Experience Cloud, Field Service für den Außendienst mit Ersatzteilreservierung, Auftragsdaten aus SAP oder proALPHA über eine Middleware, dazu ein oder zwei Managed Packages. Ein Agent, der einen neuen Trigger auf Case schreibt, muss die vier Automatisierungen kennen, die dort schon laufen. Das ist das METR-Umfeld, nicht das von GitHub.

Der zweite Grund ist, wo die Zeit hingeht. Nach meiner Einschätzung ist das Programmieren in einem typischen Salesforce-Programm der kleinere Teil der Durchlaufzeit einer Story. Der größere Teil ist Warten: auf ein Review, auf eine freie Sandbox, auf den Test der Serviceleitung in UAT, auf das nächste Release-Fenster. KI verkürzt den Bauschritt. Ändert sich sonst nichts, wartet die Story an der nächsten Stelle länger. Dazu passt McKinseys Befund, dass Unternehmen, die ihre Abläufe vor der KI-Einführung umgebaut haben, mehr als doppelt so oft Gewinne über 20 Prozent melden.

Welche Kennzahlen zeigen, ob KI Ihr Salesforce-Programm beschleunigt?

Ich würde fünf Zahlen verfolgen, getrennt nach Art der Story (Konfiguration, Apex, Schnittstelle), weil KI bei einer Flow-Änderung ganz anders hilft als bei einer SAP-Schnittstelle.

1. Durchlaufzeit pro Story, von „bereit zur Entwicklung“ bis Produktion, aufgeteilt in Bauen, Warten auf Review, Test und Warten auf UAT. Erst die Aufteilung zeigt, wo die Zeit geblieben ist.
2. Fehlerdurchschlupf (Defect Escape Rate): Fehler nach dem Release geteilt durch alle Fehler zu diesen Stories. Daran sehen Sie, ob Tempo mit Qualität bezahlt wird.
3. Nacharbeit: Stories, die nach „fertig“ wieder geöffnet werden, plus das, was DORA Deployment Rework Rate nennt, den Anteil der Deployments, die ungeplant Fehler beheben.
4. Change Fail Rate und Change Lead Time. Zwei der fünf DORA-Metriken6. Sie kommen aus der Pipeline, nicht aus einer Umfrage; eine Open-Source-Option, die sie ausweist, beschreibe ich in sfdx-hardis als Einstieg in Salesforce DevOps.
5. Größe der Pull Requests und Wartezeit im Review. KI macht große Änderungen billig. DORA zählt Arbeiten in kleinen Paketen7 zu den sieben Fähigkeiten, die den Nutzen von KI verstärken, und ich erwarte, dass genau diese Disziplin als Erstes nachlässt, wenn Agenten den Code schreiben.

Als Erfolgsmaß weglassen würde ich Codezeilen, den Anteil KI-generierten Codes, Lizenzen und Prompt-Volumen. McKinsey weist darauf hin, dass Nutzungskennzahlen nur zeigen, ob die Werkzeuge benutzt werden, nicht ob Releases schneller oder zuverlässiger werden, und 86 Prozent der Spitzenreiter in der Umfrage messen stattdessen Ergebnisse. Token-Kosten pro Story sind für das Budget nützlich, dazu mehr in was KI-Coding im Salesforce-Projekt kostet.

Rechenbeispiel: zwei Zahlen, zwei Geschichten

Nehmen wir einen Maschinenbauer mit Sales Cloud, Service Cloud und Field Service, einer SAP-Anbindung über Middleware und zwei Umsetzungspartnern mit zusammen acht Entwicklern. Alle Zahlen sind Annahmen, die das Vorgehen zeigen sollen. Partner A schlägt Coding-Agenten vor und verspricht „rund 30 Prozent schneller“.

Die Programmleitung zieht zuerst drei Monate Historie aus Jira und Git. Angenommen sind rund 40 Stories im Monat und eine mittlere Durchlaufzeit von 18 Arbeitstagen: 4 Tage Bauen, 3 Tage Warten auf Review, 6 Tage Warten auf die UAT-Abnahme durch den Service und 5 Tage für Test und Release-Fenster. Fehlerdurchschlupf 12 Prozent, Nacharbeit 8 Prozent.

Nach drei Monaten mit Agenten sinkt der Bauschritt angenommen von 4 auf 2,5 Tage. Das ist das gute Drittel, das die Entwickler spüren. Die Pull Requests sind aber doppelt so groß geworden, also steigt die Review-Wartezeit von 3 auf 4 Tage. UAT wartet weiter 6 Tage, weil das Serviceteam zweimal pro Woche testet. Die Durchlaufzeit sinkt von 18 auf 17,5 Tage, weniger als 3 Prozent. Die Nacharbeit steigt von 8 auf 11 Prozent.

Beide Zahlen stimmen. Das Programmieren ist schneller, das Programm kaum. Nützlich ist die Erkenntnis, wo Sie ansetzen: kleinere Pull Requests mit automatischen Prüfungen, feste tägliche UAT-Termine mit der Serviceleitung und ein Reviewer auf Kundenseite, der dafür eingeplant ist. Ohne Basislinie hätte der Lenkungsausschuss nur die 30 Prozent gehört.

Den Status-Workflow aufräumen, bevor die Werkzeuge kommen

Fangen Sie an, bevor die Werkzeuge kommen, denn eine Basislinie lässt sich nicht aus dem Gedächtnis rekonstruieren.

1. 01

   Status-Workflow aufräumen

   In Jira oder Azure DevOps, sodass „bereit“, „im Review“, „in UAT“ und „fertig“ Zeitstempel haben. Die meisten Programme haben schon drei Monate brauchbare Historie.

2. 02

   Definitionen festlegen

   Mit allen Partnern: wann die Durchlaufzeit beginnt, was als durchgerutschter Fehler zählt, was als Nacharbeit. Das gehört ins Governance-Modell, nicht in den Bericht jedes einzelnen Partners.

3. 03

   KI-Pull-Requests kennzeichnen

   Damit Sie Gleiches mit Gleichem vergleichen. Die Offenlegung von KI-Nutzung ist ein Vertragsthema, siehe Regeln für Partner mit KI-Coding.

4. 04

   Monatlich als Trend berichten

   Nie als Rangliste von Teams oder Partnern. Wer gerankt wird, optimiert die Zahl.

5. 05

   Prüftermin vereinbaren

   Etwa nach drei Monaten, und dann entscheiden, ob sich Setup, Prozess oder Vertragsmodell ändern. Liefert ein Partner wirklich schneller, sollte sich das im Preis zeigen. Das ist die Frage hinter Festpreis statt Aufwand.

Für den ersten Bericht genügen Durchlaufzeit und Nacharbeit, die übrigen Zahlen kommen dazu, sobald die Definitionen stehen. So setze ich Projektsteuerung für Salesforce-Programme auf, und das Ganze steht auf einer funktionierenden Pipeline, wie in warum DevOps über Salesforce-Großprojekte entscheidet beschrieben.

Quellen7

1. 1kontrollierten Experiment (öffnet in einem neuen Tab)github.blog
2. 2randomisierten Studie (öffnet in einem neuen Tab)metr.org
3. 3Update (öffnet in einem neuen Tab)metr.org
4. 4State of AI-assisted Software Development (öffnet in einem neuen Tab)cloud.google.com
5. 5Umfrage unter 334 Produkt- und Engineering-Verantwortlichen (öffnet in einem neuen Tab)mckinsey.com
6. 6DORA-Metriken (öffnet in einem neuen Tab)dora.dev
7. 7Arbeiten in kleinen Paketen (öffnet in einem neuen Tab)dora.dev