Mehr Software, weniger Service-Stunden? Das Innovator’s Dilemma im Markt für Software Engineering Services.

Um 2006 begegnete ich erstmals Clayton Christensens Theorie der disruptiven Innovation. Was mir im Gedächtnis blieb, war nicht nur, dass neue Technologien etablierte Unternehmen verdrängen können. Es war seine Erklärung dafür, weshalb erfolgreiche etablierte Anbieter oft rational auf eine disruptive Entwicklung reagieren – und ihre Position dennoch verlieren.

Dieses Muster erscheint mir für den Markt für Software Engineering Services zunehmend relevant.

KI verbessert die Art und Weise, wie Software konzipiert, entwickelt, getestet und gewartet wird. Software Engineering Partner führen Copilots, Agents und KI-gestützte Delivery-Methoden ein. Tech Buyer tun dasselbe innerhalb ihrer eigenen Organisationen.

Die strategische Frage lautet jedoch nicht nur, ob KI Entwickler produktiver macht. Entscheidend ist, ob AI-Native Engineering das Delivery-Modell, die wirtschaftliche Logik und letztlich den Bedarf des Kunden an externen Services verändert.

Das mögliche Ergebnis klingt paradox:

Unternehmen könnten mehr Software entwickeln und gleichzeitig weniger externe Engineering-Stunden einkaufen.

Wenn dies eintritt, kann die Nachfrage nach Software-Ergebnissen weiter wachsen, während der traditionelle Markt für den Verkauf von Entwicklungskapazität zunehmend unter Druck gerät.

KI ist nicht automatisch eine disruptive Innovation

Christensens Theorie wird häufig auf die Vorstellung reduziert, jede bedeutende neue Technologie sei «disruptiv». Das besagt die Theorie jedoch nicht.

Disruptive Innovation beschreibt einen Wettbewerbsprozess. Ein einfacheres, zugänglicheres oder günstigeres Angebot richtet sich zunächst an Menschen, die die etablierte Lösung nicht nutzen konnten, oder an Kunden, deren Anforderungen sie übererfüllt. Gemessen an den traditionellen Kriterien des etablierten Marktes kann das neue Angebot anfangs schlechter abschneiden. Danach verbessert es sich und bewegt sich in Richtung anspruchsvollerer Anwendungen.

Das Clayton Christensen Institute macht dieselbe Unterscheidung ausdrücklich für KI: KI ist nicht von sich aus disruptiv oder erhaltend. Entscheidend sind das Geschäftsmodell, in dem sie eingesetzt wird, und ihre Wettbewerbswirkung auf einen bestimmten Produkt- oder Servicemarkt.

Diese Unterscheidung ist für Software Engineering Services wichtig.

Stattet ein etablierter Provider seine Entwickler mit KI-Tools aus, verkauft aber weiterhin ähnliche Teams über dasselbe Time-and-Materials-Modell, ist KI primär eine erhaltende Innovation oder Effizienzinnovation. Die Delivery kann schneller oder profitabler werden, das grundlegende Kundenangebot bleibt jedoch weitgehend unverändert.

Die stärker disruptive Möglichkeit entsteht, wenn KI ein anderes Modell ermöglicht:

• Kleinere Teams können Ergebnisse liefern, für die zuvor deutlich grössere Teams erforderlich waren.
• Business- oder Technologie-Teams können bestimmte Anwendungen erstellen, ohne ein konventionelles Entwicklungsprojekt auszulagern.
• Bisher unwirtschaftliche Softwarebedürfnisse werden bezahlbar.
• Neue Provider können ohne die Staffing-Pyramide und Auslastungsanforderungen etablierter Serviceunternehmen operieren.
• Softwareentwicklung kann als Ergebnis, Managed Capability oder zugängliche Entwicklungsumgebung statt als Engineering-Stunden verkauft werden.

In diesem Szenario ist KI der technologische Enabler. Die potenzielle Disruption liegt im AI-Native Delivery- und Geschäftsmodell.

Wo könnte die Disruption beginnen?

Disruptive Modelle beginnen normalerweise nicht damit, das komplexeste und anspruchsvollste Angebot eines etablierten Anbieters zu ersetzen. Sie finden dort einen Einstieg, wo die etablierte Lösung zu teuer, zu schwerfällig oder schlicht nicht verfügbar ist.

Bei der Softwareentwicklung könnten solche Einstiegspunkte sein:

• Anwendungen für einzelne Abteilungen und interne Workflows;
• Prototypen und kurzlebige Anwendungen;
• kleine Integrationen und Datenverarbeitungsaufgaben;
• Testerstellung, Dokumentation und Fehlerbehebung;
• vernachlässigte Wartungs- und Modernisierungs-Backlogs;
• Anwendungen, die nie gebaut wurden, weil sich ein konventionelles Projekt nicht rechtfertigen liess.

Frühe KI-erstellte Lösungen können bei Architektur, Wartbarkeit, Sicherheit, Integration und betrieblicher Zuverlässigkeit Schwächen aufweisen. Etablierte Provider können mit gutem Grund argumentieren, dass diese Lösungen die Anforderungen komplexer Enterprise-Umgebungen noch nicht erfüllen.

Damit könnten sie recht haben – und die Entwicklung dennoch unterschätzen.

Agents, automatisierte Verifikation, reichhaltigerer Unternehmenskontext, Architekturkontrollen und bessere Entwicklungsumgebungen können den Arbeitsbereich, den AI-Native Ansätze abdecken, schrittweise erweitern. Die relevante Frage ist deshalb nicht nur, was ein Ansatz heute liefern kann. Entscheidend ist, ob er in anspruchsvollere Aufgaben vordringen kann, ohne die vollständigen Kosten und die Komplexität des Modells nachzubilden, das er herausfordert.

Nicht jedes AI-Engineering-Angebot wird diesem Pfad folgen. Einige bleiben nützliche Tools, andere ergänzen etablierte Services und wieder andere werden scheitern. Christensens Theorie sollte als Linse dienen, um einen möglichen Wettbewerbsprozess zu erkennen – nicht als Beweis dafür, dass jedes KI-Entwicklungsprodukt zum Disruptor wird.

Mehr Software bedeutet nicht zwingend mehr Serviceumsatz

Die Wirkung auf den Gesamtmarkt lässt sich anhand von drei Variablen verstehen:

Nachfrage nach externen Services = Nachfrage nach Software-Ergebnissen × externer Delivery-Anteil × Serviceaufwand und Kosten pro Ergebnis

AI-Native Engineering kann alle drei Variablen beeinflussen.

1. Die Nachfrage nach Software-Ergebnissen könnte steigen

Wenn Software schneller und günstiger erstellt werden kann, werden mehr Bedürfnisse wirtschaftlich tragfähig. Unternehmen können kleinere Prozessprobleme lösen, vernachlässigte Anwendungen modernisieren, häufiger experimentieren und Software in mehr Produkte und Abläufe integrieren.

Die insgesamt entwickelte Softwaremenge könnte deshalb deutlich wachsen.

2. Der externe Delivery-Anteil könnte sinken

Tech Buyer kaufen nicht nur KI-gestützte Services ein. Sie bauen ihre eigenen Engineering-Systeme rund um Agents, Repositories, Unternehmenskontext, Architekturregeln, automatisierte Tests und interne Plattformen auf.

Mit zunehmender Reife dieser Fähigkeiten können Kunden mehr Softwareentwicklung intern durchführen. Externe Partner bleiben relevant, doch die Grenze zwischen interner und externer Verantwortung verschiebt sich.

3. Der erforderliche Aufwand pro Ergebnis könnte sinken

Ein kompaktes, KI-gestütztes Team könnte Aufgaben übernehmen, für die zuvor eine wesentlich grössere Delivery-Organisation notwendig war. Selbst wenn die Arbeit extern bleibt, kann die erforderliche Zahl verrechenbarer Stunden oder Vollzeitäquivalente sinken.

Der Nettoeffekt auf den gesamten Marktumsatz ist nicht vorbestimmt. Er hängt teilweise davon ab, ob die zusätzliche Softwarenachfrage schneller wächst, als Produktivität und Internalisierung den externen Aufwand reduzieren.

Für das traditionelle Kapazitätsmodell ist die Richtung jedoch klarer: Ausgelieferte Software, Provider-Umsatz und Engineering-Headcount wachsen möglicherweise nicht mehr gemeinsam wie in der Vergangenheit.

Weshalb etablierte Provider rational – und zu langsam – reagieren könnten

Christensens Dilemma der etablierten Anbieter beruhte nicht primär auf schlechter Führung oder der Unfähigkeit, Technologie zu erkennen. Etablierte Organisationen treffen häufig vernünftige Entscheidungen auf Basis der Kunden, der wirtschaftlichen Logik und der Leistungskriterien, die sie erfolgreich gemacht haben.

Viele Software Engineering Partner sind ausgerichtet auf:

• verrechenbaren Headcount;
• Auslastungsziele;
• Rate Cards und Personenmonate;
• Verkaufsanreize, die grössere Engagements begünstigen;
• eine Staffing-Pyramide mit vielen Junior- und Mid-Level-Entwicklern;
• Delivery Center, die skalierbare Kapazität bereitstellen;
• Umsatzprognosen, die mit Teamgrösse und Vertragsdauer verknüpft sind.

Ein AI-Native Modell, das deutlich kleinere Teams und weniger verrechenbare Stunden verspricht, steht im Widerspruch zu dieser wirtschaftlichen Logik. Selbst wenn der Provider die Technologie versteht, können seine bestehenden Prozesse ihn dazu bewegen, KI auf eine Weise einzusetzen, die das aktuelle Modell schützt.

Die wahrscheinliche Reaktion besteht deshalb nicht zwingend darin, KI abzulehnen. Sie kann darin bestehen, KI in das etablierte Angebot zu integrieren:

Unsere bestehenden Teams nutzen jetzt KI. Deshalb bleibt das bestehende Delivery- und Commercial-Modell gültig.

Das kann echte Verbesserungen bringen. Es beantwortet jedoch nicht die disruptive Frage.

Ein etablierter Anbieter könnte sich zudem auf grössere, komplexere und margenstärkere Engagements zurückziehen, wenn einfachere Arbeit weniger attraktiv wird. Kurzfristig ist dies wirtschaftlich sinnvoll. Christensens Beispiele zeigen dennoch, weshalb es gefährlich werden kann, wenn sich das neue Modell weiter verbessert und dem etablierten Anbieter in zunehmend anspruchsvolle Marktsegmente folgt.

Der Kundenbedarf verschiebt sich von Produktionskapazität zu ergänzendem Wert

Der historische Kundenbedarf wurde häufig als Kapazitätsproblem formuliert:

Wir haben nicht genügend Entwickler. Stellt uns ein Team bereit.

Eine AI-Native Kundenorganisation könnte den Bedarf anders formulieren:

Ergänzt unsere Engineering-Umgebung um Fähigkeiten, Absicherung oder Verantwortung, die wir selbst nicht zuverlässig bereitstellen können.

Damit verschwindet die Rolle von Software Engineering Partnern nicht. Die Quelle ihres Werts verändert sich.

Zu den Fähigkeiten, die relativ an Bedeutung gewinnen dürften, gehören:

• tiefe Branchen- und Domänenexpertise;
• komplexe Architektur und Systemintegration;
• Cybersecurity, Datenschutz und regulatorische Absicherung;
• Modernisierung schwieriger Legacy-Umgebungen;
• unabhängige Verifikation KI-erstellter Systeme;
• Verantwortung für produktive Ergebnisse;
• Forward Deployed Engineers, die eng mit dem geschäftlichen und technischen Kontext des Kunden arbeiten;
• Betrieb und Governance komplexer Systeme;
• temporärer Zugang zu knapper Spezialistenexpertise.

Kapazität bleibt wichtig, insbesondere bei grossen Transformationen, dringenden Programmen oder vorübergehenden Nachfragespitzen. Der Zugang zu kompetenten Entwicklern wird jedoch als eigenständiges Differenzierungsmerkmal schwächer, wenn Kunden und Wettbewerber KI einsetzen können, um den Ausführungsaufwand zu komprimieren.

Der Provider-Markt könnte sich stärker polarisieren

Wenn sich diese Entwicklung fortsetzt, könnte der Markt für Software Engineering Services zunehmend eine Hantelstruktur annehmen.

Am einen Ende können grosse integrierte Provider Verantwortung für komplexe Transformationen, regulierte Umgebungen und langfristige Managed Operations übernehmen. Ihre Skalierung, ihr Enterprise-Zugang und ihre Fähigkeit, Verantwortung zu tragen, bleiben wertvoll.

Am anderen Ende können spezialisierte Unternehmen und einzelne Experten knappe Domänen-, Architektur-, Security- oder Plattformfähigkeiten über kleine Senior-Teams bereitstellen.

Die breite Mitte könnte am stärksten unter Druck geraten: Provider, deren zentrales Angebot kompetente Engineering-Kapazität, attraktive Preise, skalierbare Teams und bequeme Delivery Locations kombiniert, aber über die Ausführung hinaus nur begrenzte Differenzierung bietet.

Mögliche Marktfolgen sind:

• kleinere Delivery-Teams und kürzere Engagements;
• weniger Junior-lastige Projekte;
• Druck auf Provider, die von Staff Augmentation und zeitbasierter Preisgestaltung abhängig sind;
• Konsolidierung unter mittelgrossen Generalisten;
• Übernahmen spezialisierter Unternehmen durch grössere Provider;
• Wachstum von AI-Native Boutiquen, Expertennetzwerken und Fractional Roles;
• eine stärkere Trennung zwischen Softwareentwicklung und unabhängiger Absicherung;
• mehr ergebnisorientierte, Fixed-Price- und Managed-Capability-Angebote;
• eine engere Integration externer Experten in das eigene Engineering-System des Kunden.

Dies ist eine Markthypothese und keine gesicherte Prognose. Etablierte Provider können noch über Jahre erfolgreich bleiben, insbesondere solange Enterprise-Nachfrage, Transformations-Backlogs und bestehende Verträge stark bleiben. Erste Anzeichen einer Disruption müssen nicht in sinkenden Branchenumsätzen sichtbar werden. Sie könnten sich in Teamzusammensetzung, Engagement-Dauer, Preisgestaltung, Einstellungsmustern und der Verlagerung der Engineering-Orchestrierung zum Kunden zeigen.

Was sollten Tech Buyer überdenken?

Für Tech Buyer besteht die praktische Konsequenz nicht darin, jeden etablierten Partner durch einen AI-Native Anbieter zu ersetzen. Es geht darum, Annahmen zu überprüfen, die möglicherweise nicht mehr gelten.

1. Die Sourcing-Grenze neu beurteilen

Welche Fähigkeiten sollte die Organisation intern aufbauen und kontrollieren? Welche Arbeiten können interne Teams heute mit AI-Native Methoden ausführen? Wo bleiben externe Expertise oder Verantwortung wertvoller als interne Umsetzung?

Diese Entscheidung sollte vor der Suche nach einem Provider getroffen werden.

2. Das Softwareportfolio segmentieren

Routinearbeit, klar abgegrenzte Aufgaben und Arbeiten mit geringerem Risiko sollten nicht automatisch über dasselbe Modell bezogen werden wie komplexe Kernsysteme, regulierte Anwendungen oder grosse Modernisierungsprogramme.

Unterschiedliche Teile des Portfolios können verschiedene Kombinationen aus interner Entwicklung, Spezialistenunterstützung, Project Outsourcing und Managed Responsibility erfordern.

3. Das Betriebsmodell des Providers bewerten – nicht sein KI-Vokabular

Fast jeder Provider kann behaupten, KI einzusetzen. Buyer benötigen Evidence dafür, was sich tatsächlich verändert hat:

• Hat der Provider Durchlaufzeit oder Teamgrösse reduziert?
• Wie haben sich Qualität, Nacharbeit und Zuverlässigkeit im produktiven Betrieb entwickelt?
• Teilt das Commercial-Modell Produktivitätsgewinne mit dem Kunden?
• Kann sich der Provider in die Engineering-Umgebung des Kunden integrieren?
• Welche Verantwortung übernimmt er für KI-generierte Ergebnisse?
• Bleibt der Ansatz auch bei zunehmender Komplexität wirtschaftlich anders?

KI-Nutzung ist ein Signal. Sie ist für sich allein keine Evidenz für ein AI-Native Delivery-Modell.

4. Die kommerzielle Einheit überdenken

Steigt die Produktivität, während der Buyer weiterhin Personenmonate einkauft, kann der Provider den grössten Teil des wirtschaftlichen Vorteils für sich behalten.

Das bedeutet nicht, dass jedes Engagement sofort auf Fixed Price umgestellt werden sollte. Unsicherheit, sich verändernder Scope und geteilte Verantwortung bleiben relevant. Buyer sollten jedoch prüfen, ob Stunden, Teamgrösse und Rate Cards weiterhin die passende Grundlage für den Wert darstellen – oder ob Deliverables, Outcomes, Managed Capabilities und ausdrücklich übernommene Verantwortung besser geeignet sind.

5. Kontrolle über Kontext und Governance behalten

Repositories, Domänenwissen, Architekturregeln, Test-Assets und operatives Feedback des Kunden werden zu immer wichtigeren Bestandteilen einer AI-Native Engineering-Umgebung.

Buyer sollten bewusst entscheiden, wer diesen Kontext kontrolliert, wie externe Partner darauf zugreifen, wie Ergebnisse verifiziert werden und wie einfach sich das Betriebsmodell übertragen oder ändern lässt. Eine neue Abhängigkeit von einer Provider-kontrollierten KI-Umgebung könnte die bisherige Form des Lock-ins ersetzen, statt sie zu beseitigen.

6. Die Entwicklungsperspektive ebenso wie die aktuelle Leistung bewerten

Ein neues Modell kann anfangs für kritische produktive Anwendungen ungeeignet sein. Das ist ein berechtigter Grund, es heute nicht für solche Arbeiten einzusetzen. Es ist jedoch kein Grund, die Geschwindigkeit zu ignorieren, mit der sich seine Fähigkeiten und seine wirtschaftliche Logik verändern.

Klar begrenzte Experimente können Buyern helfen festzustellen, wo AI-Native Delivery bereits tragfähig ist, welche Absicherung sie weiterhin benötigt und welche Sourcing-Annahmen vor der nächsten wichtigen Partnerentscheidung überprüft werden sollten.

Die Sourcing-Frage hinter der Disruption

Der Markt für Software Engineering Services wird kaum verschwinden. Der Softwarebedarf dürfte weiter wachsen, und externe Partner bleiben überall dort wichtig, wo Kunden knappe Expertise, unabhängige Absicherung, temporäre Beschleunigung oder verantwortliche Delivery benötigen.

Was sich verändert, ist das Verhältnis zwischen Softwarenachfrage und Nachfrage nach externer Arbeitsleistung.

AI-Native Engineering kann ermöglichen, mit weniger Ausführungsaufwand mehr Software zu erstellen. Es kann dem Kunden auch erlauben, einen grösseren Anteil dieser Ausführung zu internalisieren. Das Ergebnis könnte eine wachsende Softwareökonomie neben einem langsamer wachsenden – oder irgendwann schrumpfenden – Markt für konventionelle Entwicklungskapazität sein.

Die wichtigste Frage für Tech Buyer lautet deshalb nicht:

Welcher Provider hat die meisten KI-Tools eingeführt?

Sondern:

Was sollte intern bleiben, was sollte extern bezogen werden, und welchen unverwechselbaren Wert und welche Verantwortung sollte der externe Partner in einem AI-Native Engineering-Modell übernehmen?

Diese Entscheidung über die Sourcing-Grenze prägt die erforderlichen Capabilities, Evidence, das Engagement-Modell und die Governance. Sie sollte neu beurteilt werden, bevor lediglich eine effizientere Version des bereits bestehenden Delivery-Modells beschafft wird.

Häufig gestellte Fragen

Disruptiert KI selbst den Markt für Software Engineering Services?

Nicht zwingend. Wird KI eingesetzt, um ein bestehendes Delivery-Modell zu verbessern, handelt es sich hauptsächlich um eine erhaltende Innovation oder Effizienzinnovation. Die potenziell disruptive Entwicklung ist ein AI-Native Delivery- und Geschäftsmodell, das Software mit weniger Menschen, geringerem Anfangsaufwand und einer anderen wirtschaftlichen Logik produziert.

Wird KI die Gesamtnachfrage nach Software Engineering Services reduzieren?

KI wird wahrscheinlich den externen Aufwand reduzieren, der für jedes Software-Ergebnis erforderlich ist. Ob der Gesamtmarkt schrumpft, hängt davon ab, ob die zusätzliche Softwarenachfrage schneller wächst, als Produktivität und Internalisierung das externe Servicevolumen verringern.

Welche Software Engineering Services sind am stärksten betroffen?

Routineimplementierung, Junior-lastige Delivery, manuelles Testing, Dokumentation und undifferenzierte Entwicklungskapazität erscheinen besonders exponiert. Komplexe Architektur, Domänenexpertise, Security, Modernisierung, unabhängige Absicherung und verantwortlicher Betrieb könnten relativ an Wert gewinnen.

Werden etablierte Software Engineering Partner überflüssig?

Nein. Ihre Rolle könnte sich jedoch von der Bereitstellung von Produktionskapazität hin zur Ergänzung der Engineering-Umgebung des Kunden mit knapper Expertise, Absicherung, Integration und Ergebnisverantwortung verschieben.

Was sollten Tech Buyer zuerst überdenken?

Die Sourcing-Grenze: Was die Organisation intern ausführen und kontrollieren sollte, wo weiterhin externe Unterstützung erforderlich ist und welche unverwechselbare Verantwortung ein externer Partner übernehmen sollte.

ValueLeap-Perspektive

Beurteilen Sie Ihre Sourcing-Grenze oder ein bestehendes Partner-Setup neu?

ValueLeap unterstützt Tech Buyer dabei, Software-Engineering-Sourcing und Partnerentscheidungen zu strukturieren, zu validieren und zu steuern – einschliesslich der Auswirkungen von AI-Native Engineering auf interne Fähigkeiten, externe Verantwortlichkeiten und Engagement-Modelle.

Besprechen Sie Ihre Sourcing-Grenze mit ValueLeap.

Quellen und weiterführende Literatur

• Clayton M. Christensen, The Innovator’s Dilemma: When New Technologies Cause Great Firms to Fail, Harvard Business School Press. Buchübersicht des Christensen Institute
• Clayton M. Christensen, Michael E. Raynor und Rory McDonald, «What Is Disruptive Innovation?», Harvard Business Review, Dezember 2015. PDF der Harvard Business School
• Clayton Christensen Institute, «Disruptive Innovation Theory». Übersicht zur Theorie
• Michael B. Horn, «What does Disruptive Innovation Theory have to say about AI?», Clayton Christensen Institute, 3. Juni 2024. Artikel