Sourcing-Bedarf besprechen
Sourcing-Bedarf besprechen
Insight

KI-Readiness von Engineering-Partnern prüfen: 7 Fragen zur Partnerauswahl.

Prüfen Sie mit sieben Fragen, wie Software Engineering Partner KI nutzen, Delivery-Modelle anpassen und konkreten Kundennutzen nachweisen.

Peter Helfenstein
Drei Dimensionen der KI-Readiness: Tool Adoption, Delivery Adaptation und Commercial Adaptation.

KI-Tools allein machen einen Software Engineering Partner noch nicht AI-ready. Entscheidend ist, wie der Anbieter seine Arbeitsweise, sein Delivery-Modell und sein Angebot verändert – und welchen konkreten Nutzen das für den Kunden bringt.

Generative KI verändert, wie Software entwickelt wird. Code lässt sich schneller erstellen, Prototypen werden zugänglicher und neue Produktideen können mit weniger Anfangsaufwand untersucht werden.

Doch für Tech Buyer entsteht daraus eine andere Frage als die nach der Geschwindigkeit einzelner Entwickler:

Hat sich auch das Leistungsangebot des Software Engineering Partners verändert – oder arbeitet er im Wesentlichen wie bisher, nur mit neuen Werkzeugen?

Diese Frage wird wichtig, wenn Unternehmen ihren externen Engineering-Bedarf neu bestimmen, bestehende Partner beurteilen oder eine Shortlist erstellen. Im Mittelpunkt steht deshalb nicht die allgemeine Frage, was AI-Native Engineering bedeutet, sondern wie Tech Buyer konkrete Veränderungen im Angebot eines Providers prüfen können.

Schnellere Entwicklung ist nicht automatisch bessere Delivery

Dass KI die Softwareentwicklung beeinflusst, steht ausser Frage. Wie stark die Vorteile ausfallen, hängt jedoch von Aufgabe, Team und Entwicklungsumgebung ab.

Der DORA Report 2025 von Google Cloud fand einen positiven Zusammenhang zwischen KI-Nutzung und Software-Delivery-Durchsatz, gleichzeitig aber einen negativen Zusammenhang mit der Delivery-Stabilität. Der Bericht unterstreicht die Bedeutung funktionierender Prozesse, Tests und Feedback-Schleifen.

Eine 2026 veröffentlichte Untersuchung von Demirer, Musolff und Yang zeigte ebenfalls, dass starke Zuwächse bei Coding-Aktivitäten nicht im gleichen Umfang in tatsächlich veröffentlichte Software übergehen. Review, Integration, Testing und Release bleiben relevante Engpässe.

Ein anderes Bild liefert eine kontrollierte METR-Studie aus dem Jahr 2025: Erfahrene Entwickler benötigten bei den untersuchten Aufgaben mit damaligen KI-Werkzeugen im Durchschnitt länger. Eine Aktualisierung von 2026 deutete mögliche Verbesserungen an, erlaubte aber keine zuverlässige neue Gesamtschätzung.

Diese Ergebnisse widersprechen sich nicht zwingend. Sie untersuchen unterschiedliche Aufgaben, Werkzeuge und Ergebnisgrössen.

Für die Partnerauswahl ist gerade das entscheidend: Ein Produktivitätsversprechen braucht einen klaren Bezug dazu, was gemessen wurde – und was beim Kunden tatsächlich ankommt.

Die Aufgabenverteilung zwischen Kunde und Partner kann sich verschieben

Unternehmen können zunehmend selbst experimentieren, Prototypen entwickeln und bestimmte Entwicklungsaufgaben erledigen. Damit verändert sich möglicherweise der Punkt, an dem sie externe Expertise benötigen.

Ein Kunde, der einen funktionsfähigen Prototyp mit KI-Unterstützung erstellt hat, sucht beispielsweise nicht unbedingt ein Team, das nochmals bei null beginnt.

Er benötigt vielleicht zunächst:

  • eine unabhängige Beurteilung von Architektur und technischem Risiko;
  • die Überprüfung von Security, Datenverarbeitung und Compliance;
  • die Integration in bestehende Systeme;
  • ein belastbares Testing- und Qualitätssicherungskonzept;
  • Unterstützung beim Übergang in den produktiven Betrieb;
  • spezifische Engineering-Kompetenz, die intern fehlt.

Der externe Beitrag kann dadurch fokussierter werden. In anderen Situationen bleibt ein umfassendes, langfristiges Delivery-Team die richtige Lösung.

Entscheidend ist nicht, dass ein Modell das andere ablöst. Entscheidend ist, dass der Partner seinen Beitrag an den tatsächlichen Sourcing Need anpassen kann.

Drei Ebenen einer glaubwürdigen Anpassung

Ein Anbieter kann KI einsetzen, ohne sein Geschäfts- und Delivery-Modell wesentlich zu verändern. Deshalb lohnt es sich, drei Ebenen getrennt zu untersuchen.

1. Tool Adoption: Wie setzt der Partner KI ein?

Auf dieser Ebene geht es um die Engineering-Praxis.

Welche Tätigkeiten werden durch KI unterstützt? Wie prüft das Team die Ergebnisse? Welche Regeln bestehen für vertrauliche Informationen, Intellectual Property, Security und die Nutzung von KI-generiertem Code?

Der Einsatz aktueller Tools ist ein relevantes Signal. Er ist aber noch kein Nachweis für bessere Delivery.

Tech Buyer sollten verstehen, wie der Partner Qualität, Nachvollziehbarkeit und Verantwortlichkeit sicherstellt.

2. Delivery Adaptation: Was hat sich an der Zusammenarbeit verändert?

Hier wird die Anpassung für den Kunden sichtbarer.

Kann der Anbieter mit einem intern entwickelten Prototyp starten, anstatt einen vollständigen Entwicklungsprozess vorauszusetzen? Kann er kleinere, seniorigere Teams oder fokussierte Spezialisten bereitstellen? Kann er Discovery, Engineering, Validierung und Übergabe passend kombinieren?

Wenn sich der Umfang einzelner Aufgaben reduziert, können kürzere Engagements sinnvoll werden. Es können aber auch neue, längerfristige Formen der Zusammenarbeit entstehen – beispielsweise für kontinuierliche Modernisierung, Integration oder die Betreuung eines Portfolios kleinerer Initiativen.

In beiden Fällen muss das Operating Model passen: Rollen, Zusammenarbeit, technische Governance und Verantwortungsgrenzen.

Besonders wichtig wird die Frage, wer unter welchen Voraussetzungen Verantwortung für Qualität, Sicherheit und Weiterentwicklung von Code übernimmt, den der Kunde bereits selbst oder mit KI-Unterstützung erstellt hat.

3. Commercial Adaptation: Was gewinnt der Kunde?

Die dritte Ebene betrifft den wirtschaftlichen Nutzen.

Wenn bestimmte Engineering-Aufgaben weniger Aufwand erfordern, muss dieser Vorteil nicht automatisch in einer pauschalen Senkung von Stundensätzen sichtbar werden. Er kann sich auch in kürzeren Projektlaufzeiten, weniger benötigter Kapazität, zusätzlichem Leistungsumfang oder besserer Qualität zeigen.

Für den Kunden muss jedoch nachvollziehbar sein, wie die Vorteile entstehen und gemessen werden.

Das wirft Fragen nach dem Engagement-Modell auf:

  • Passt Time and Materials weiterhin, und wie wird Produktivität darin transparent gemacht?
  • Ist ein klar abgegrenztes Projekt mit vereinbarten Deliverables besser geeignet?
  • Sind hybride oder teilweise ergebnisorientierte Vereinbarungen sinnvoll?
  • Kann der Partner auch wirtschaftlich tragfähige kleinere Engagements anbieten?
  • Wie werden Änderungen, Risiken und Verantwortlichkeiten zwischen den Parteien verteilt?

Kein kommerzielles Modell ist für alle Situationen überlegen. Aber ein Anbieter, der seine Engineering-Praxis modernisiert, sollte auch erklären können, welche Konsequenzen das für sein Angebot und den Kundennutzen hat.

Sieben Fragen für die Partner Evaluation

Tech Buyer können die drei Ebenen mit sieben konkreten Fragen prüfen.

EvaluationsfrageWorauf es bei der Antwort ankommt
1. Was hat sich durch KI in Ihrer Engineering-Praxis tatsächlich verändert?Konkrete Prozesse, Einsatzbereiche, Kontrollen und nachvollziehbare Ergebnisse statt einer Tool-Liste
2. Wie messen Sie die Wirkung auf die gesamte Delivery?Durchlaufzeit, Qualität, Nacharbeit, Release-Fähigkeit und geeignete Vergleichswerte – nicht nur Code-Output
3. Wie arbeiten Sie mit Entwicklungsergebnissen, die der Kunde selbst erstellt hat?Fähigkeit zur Übernahme, technischen Prüfung, Integration sowie klare Verantwortungsgrenzen
4. Welche Team- und Engagement-Modelle bieten Sie heute an?Flexible Teamgrössen, fokussierte Spezialisten, sinnvoller Senioritätsmix und passende Zusammenarbeit
5. Wie stellen Sie Qualität, Security und Governance bei KI-gestützter Entwicklung sicher?Teststrategie, Review, Nachvollziehbarkeit, Daten- und IP-Schutz, Zuständigkeiten
6. Wie profitieren Ihre Kunden wirtschaftlich von den Veränderungen?Transparenz über Aufwand, Geschwindigkeit, Scope, Qualität sowie passende kommerzielle Modelle
7. Welche Nachweise belegen diese Anpassungen?Vergleichbare Engagements, nachprüfbare Outcomes, Kundenreferenzen und Beispiele tatsächlich veränderter Delivery

Die Antworten müssen zum konkreten Sourcing Need passen. Eine glaubwürdige Fallstudie zu einem kleinen, KI-gestützten Produktprojekt beweist beispielsweise nicht automatisch, dass derselbe Anbieter eine komplexe regulierte Plattformmodernisierung beherrscht.

Ebenso ist ein neues Angebot zunächst ein Claim. Erst relevante Erfahrung, konkrete Ergebnisse oder andere geeignete Nachweise machen daraus belastbare Evidence.

Zwei Anbieter, zwei unterschiedliche Antworten

Ein Unternehmen hat intern einen KI-unterstützten Prototyp entwickelt. Nun soll daraus ein sicherer, wartbarer und integrierter produktiver Service werden.

Anbieter A bietet ein umfassendes Entwicklungsteam an, das die Lösung nach einer klassischen Discovery-Phase weitgehend neu aufbauen soll.

Anbieter B schlägt zunächst ein begrenztes Architecture-, Security- und Production-Readiness-Assessment vor. Danach soll ein kleines Team gezielt die notwendigen Anpassungen, Integrationen und Tests umsetzen.

Für diesen Ausgangspunkt könnte Anbieter B der passendere Partner sein. Das gilt jedoch nur, wenn die vorgeschlagene Vorgehensweise tragfähig ist und Architektur, Codequalität, Sicherheitsrisiken, IP-Rechte, Tests, Abnahmekriterien und die Übernahme von Verantwortung geklärt sind.

Bei einer grossen, langfristigen Plattformmodernisierung könnte das umfassendere Modell von Anbieter A wiederum besser passen.

Der entscheidende Unterschied ist nicht, welcher Anbieter moderner klingt, sondern welcher Beitrag im konkreten Kontext den grösseren Wert schafft.

Auch die Wirtschaftlichkeit der Provider verändert sich

Aus Sicht der Software Engineering Provider entsteht eine zusätzliche Herausforderung.

Wenn bestimmte Projekte kleiner oder kürzer werden, können Vertrieb, Angebotsentwicklung, Onboarding und Account Management im Verhältnis zum Auftragsvolumen stärker ins Gewicht fallen.

Ein Unternehmen, das bisher vor allem auf grosse Team-Engagements ausgerichtet war, kann nicht ohne Weiteres dieselbe Kostenstruktur auf zahlreiche kleine Aufträge übertragen.

Mögliche Antworten sind klar definierte Assessment-Angebote, wiederverwendbare Delivery-Ansätze, schlankere Angebotsprozesse, kontinuierliche Kundenbeziehungen oder neue Kombinationen aus Beratungs- und Engineering-Leistungen.

Gleichzeitig können sinkende Umsetzungskosten zusätzliche Ideen wirtschaftlich interessant machen und neue Nachfrage erzeugen.

Beide Entwicklungen sind plausibel. Weder ein genereller Rückgang externer Engineering-Nachfrage noch ein automatischer Wachstumsgewinn für Provider ist damit bewiesen.

Für Tech Buyer zählt vor allem, ob das Geschäftsmodell des Partners die benötigte Zusammenarbeit zuverlässig unterstützt.

Was bedeutet das für die Auswahl eines Software Engineering Partners?

Die Bewertung eines AI-ready Engineering Partners sollte nicht mit der Frage beginnen, welche KI-Produkte das Unternehmen verwendet.

Sie beginnt mit dem eigenen Bedarf:

Was können und wollen wir intern übernehmen? Welche externe Expertise, welche Delivery-Capability und welche Verantwortung benötigen wir weiterhin?

Daraus lassen sich geeignete Evaluationskriterien ableiten. Die sieben Fragen helfen, die Antworten möglicher Partner in Bezug auf tatsächlichen Kundennutzen, Delivery Fit und Evidence zu prüfen. Die Kriterien zur Bewertung von Software Engineering Partnern bieten dazu einen breiteren Rahmen.

ValueLeap unterstützt Tech Buyer dabei, ihren Sourcing Need zu strukturieren, passende Software Engineering Partner zu identifizieren und die relevanten Unterschiede im Leistungsangebot, Delivery-Modell und Commercial Fit zu beurteilen.

Fazit

KI kann die Softwareentwicklung produktiver machen. Für die Partnerauswahl genügt diese Feststellung aber nicht.

Ein Software Engineering Partner sollte zeigen können, wie sich seine Arbeitsweise verändert hat, wie er mit den wachsenden internen Fähigkeiten seiner Kunden zusammenarbeitet und welche wirtschaftlichen und operativen Vorteile daraus entstehen.

Die zentrale Frage lautet deshalb:

Was hat dieser Partner aufgrund von KI an seiner Arbeitsweise und seinem Angebot verändert – und welchen konkreten Nutzen bringt uns das?

Sie möchten beurteilen, wie gut Ihre Engineering-Partner auf KI-bedingte Veränderungen vorbereitet sind? ValueLeap kann Sie bei der Einordnung von Fähigkeiten, Delivery-Modellen und kommerzieller Eignung anhand Ihres konkreten Sourcing Needs unterstützen. Partnerauswahl besprechen.

Weiterführende ValueLeap Insights

Quellen zur Marktentwicklung und Produktivität