Die Frage, die alle Vorstände gerade umtreibt
In Strategie-Workshops taucht in den letzten Monaten eine Variante derselben Frage immer wieder auf: „Warum dauert es bei uns sechs Monate, eine Idee in funktionierende Software zu bringen, während andere das in zwei Wochen schaffen?" Die Frage wird unterschiedlich formuliert, aber im Kern geht es immer um dasselbe: die Zeit zwischen „wir sollten X tun" und „X läuft in Produktion".
Diese Zeitspanne ist eine eigene Kennzahl geworden. Sie ist nicht Time-to-Market, sie ist nicht Time-to-Decision, sie ist nicht Cycle Time. Sie ist Time-to-Software: die Spanne, in der ein Unternehmen aus einer Geschäftsanforderung produktiv nutzbare Software macht. Und sie wird zur zentralen Wettbewerbsmetrik des kommenden Jahrzehnts.
Warum die alten Metriken nicht reichen
Time-to-Market war eine gute Metrik in einer Welt, in der Produkte einmal entwickelt und dann verkauft wurden. Ein Auto auf den Markt zu bringen, eine Versicherung zu launchen, eine Maschine zu zertifizieren – das waren einmalige Aufwände mit klarem Anfang und Ende.
Diese Welt schrumpft. In immer mehr Branchen ist das Produkt selbst keine fertige Sache mehr, sondern ein Bündel aus Hardware, Service und Software, das sich ständig weiterentwickelt. Ein modernes Auto erhält mehr Software-Updates als ein Smartphone vor zehn Jahren. Eine Versicherung wird über eine App definiert, deren Funktionen wöchentlich erweitert werden. Eine Maschine in der Produktion bekommt monatlich neue KI-gestützte Diagnose-Features.
In dieser Welt ist „Time-to-Market" eine Größe, die nur einmal misst. „Time-to-Software" misst kontinuierlich, wie schnell ein Unternehmen auf Anforderungen reagieren kann – aus dem Markt, aus der Regulierung, aus der eigenen Strategie.
Was Time-to-Software konkret meint
Time-to-Software lässt sich am sauberesten als Spanne zwischen zwei klar definierten Punkten messen: dem Moment, in dem eine Geschäftsanforderung formuliert ist („wir brauchen einen Workflow, der X tut"), und dem Moment, in dem genau dieser Workflow für die Nutzer verfügbar ist.
Das klingt einfach, ist aber ein scharfes Maß. Es schließt mit ein, was viele Unternehmen lieber ausblenden würden: die Zeit, in der die Anforderung in Backlogs liegt, in Architekturmeetings diskutiert wird, durch Approval-Prozesse läuft, auf Vendor-Releases wartet, durch Test-Stages wandert und schließlich in einem Wartungsfenster ausgerollt wird.
Ein konkretes Beispiel: Ein Versicherer will eine neue Bewertungslogik für ein Nischenprodukt einführen. Das Konzept ist nach zwei Wochen geklärt. Bis die Logik dann tatsächlich im System angekommen ist und Anträge danach bewertet werden, vergehen weitere acht Monate. Die Time-to-Software beträgt acht Monate – nicht acht Monate Entwicklungszeit, sondern acht Monate Gesamtdurchlauf. Der eigentliche Code wurde in drei Wochen geschrieben.
Genau diese Differenz – zwischen tatsächlicher Bauzeit und Gesamtdurchlauf – ist der Hebel.
Was Time-to-Software-Spitzenreiter anders machen
Unternehmen, die diese KPI auf Wochen statt Monate drücken, machen drei Dinge anders:
Sie haben eine Plattform, auf der man bauen kann. Keine isolierten Tools, keine zehn unterschiedlichen Datenbanken, keine Spaghetti-Integrationen. Stattdessen eine konsolidierte Plattform mit standardisierten Schnittstellen, Auth, Reporting und Deployment. Eine neue Anforderung trifft auf diese Plattform und muss nicht erst eine eigene Infrastruktur mitbringen.
Sie haben kleine, autonome Teams. Ein Team, das eine Anforderung von Anfang bis Ende verantwortet – Konzept, Bau, Betrieb –, ist um Größenordnungen schneller als drei aufeinanderfolgende Teams, die Übergaben mit Tickets und Spezifikationen jonglieren. Übergaben sind in praktisch jedem Unternehmen der größte einzelne Time-to-Software-Killer.
Sie haben Approval-Prozesse, die zur Geschwindigkeit passen. Genehmigungen, die in der alten Welt durch Komitees liefen, die einmal im Quartal tagten, werden in schnellen Unternehmen in Tagen abgearbeitet – mit klar definierten Befugnissen, klaren Eskalationspfaden und der Bereitschaft, kleine Risiken zu akzeptieren, statt jedes Detail vorab abzusichern.
Keiner dieser drei Punkte hat primär mit Technologie zu tun. Die Plattform ist erlernbar, autonome Teams sind ein Organisationsmodell, schlanke Approvals sind eine Kulturfrage. Das macht Time-to-Software gleichzeitig schwerer zu verbessern und strategisch wertvoller: Ein Wettbewerber kann die gleiche Cloud-Plattform kaufen, aber nicht die gleiche Organisations- und Entscheidungskultur.
Warum die KPI gerade jetzt wichtig wird
Drei Verschiebungen machen Time-to-Software zur zentralen Metrik:
Die Bauzeit selbst sinkt drastisch. Mit KI-gestützter Entwicklung dauert das tatsächliche Codieren oft nur noch ein Bruchteil dessen, was vor drei Jahren nötig war. Damit fällt die Bauzeit als bestimmender Faktor weg – die Wartezeiten drumherum werden zum eigentlichen Engpass und damit zum Hebel.
Wettbewerber bewegen sich schneller. In jeder Branche gibt es einzelne Akteure, die ihre Time-to-Software in den letzten drei Jahren mehr als halbiert haben. Sie setzen die neue Geschwindigkeitsnorm. Wer bei alten Durchlaufzeiten bleibt, fällt zurück – nicht weil der eigene Output schlechter wird, sondern weil der Markt sich an die schnelle Konkurrenz anpasst.
Regulatorische und technologische Veränderungen kommen häufiger. EU AI Act, NIS2, CRA, neue Authentifizierungsstandards, neue Foundation-Models – die Frequenz externer Anforderungen ist gestiegen. Wer für jede Anpassung sechs Monate braucht, kommt aus dem Reagieren nicht mehr heraus.
Wo Unternehmen ansetzen sollten
Die typischen Engpässe sind in praktisch jedem Unternehmen ähnlich verteilt:
Backlogs und Priorisierung. Anforderungen liegen oft Wochen oder Monate, bevor sie überhaupt einem Team zugeteilt werden. Dieser Stau entsteht durch zentrale Steuerung und unklare Priorisierungsregeln. Dezentrale Budgets und klare Owner verkürzen diese Phase drastisch.
Architektur-Reviews und Sicherheitsfreigaben. Jeder neue Workflow muss durch dieselben Gremien, oft mit denselben langen Wartezeiten. Standardisierte Architekturpfade und vorab geprüfte Komponenten – „guard rails" statt „gate keepers" – machen den Großteil dieser Reviews überflüssig.
Deployments und Test-Stages. In vielen Unternehmen vergehen zwischen „Code ist fertig" und „Code läuft beim Nutzer" Wochen. CI/CD-Pipelines, automatisierte Tests und Feature Flags reduzieren das auf Stunden. Die Technologie dafür ist seit Jahren reif – sie wird aber selten konsequent eingesetzt.
Vendor-Abhängigkeiten. Wenn jede Anpassung einen externen Anbieter erfordert, der erst einen Change Request prozessiert, wird Time-to-Software durch den Anbieter limitiert. Hier zahlen sich „Build the Buy"-Architekturen aus, in denen die letzten Meter im Eigenbau liegen.
Wir bei nh labs schauen in Beratungsprojekten regelmäßig genau auf diese vier Engpässe. In den meisten Fällen liegen 70 bis 80 Prozent der Time-to-Software in Wartezeiten, nicht in Arbeitszeiten. Das ist die schlechte Nachricht. Die gute: Wartezeiten lassen sich oft mit geringem Aufwand massiv reduzieren – wenn die Bereitschaft da ist, alte Entscheidungswege zu verändern.
Wie sich die KPI in Reportings verankert
Time-to-Software wird messbar, sobald ein Unternehmen den Punkt definiert, an dem eine Anforderung „beginnt" und „abgeschlossen" ist. Das ist die einzige schwierige Frage – alles danach ist reine Buchhaltung.
Sobald gemessen wird, entsteht Druck, die Zahl zu verbessern. In Unternehmen, die mit dieser KPI arbeiten, wird sie typischerweise in zwei Varianten ausgewiesen: als Median über alle Anforderungen (zeigt den Normalfall) und als 90er-Perzentil (zeigt die Ausreißer, die strategisch oft schmerzhafter sind als der Schnitt).
Diese beiden Zahlen pro Quartal, mit klarer Verantwortung und sichtbarer Entwicklung, verändern Verhalten. Plötzlich wird in Architekturmeetings nicht mehr nur über Eleganz diskutiert, sondern auch darüber, welche Architektur die Time-to-Software senkt. Plötzlich entstehen Standard-Pfade, weil sie schneller sind. Plötzlich werden Approval-Komitees umgebaut, weil sie zum sichtbaren Bottleneck werden.
Fazit
Time-to-Market war die richtige KPI für eine Welt aus diskreten Produktstarts. Sie wird nicht falsch, aber sie reicht nicht mehr. In einer Welt, in der Software kontinuierlich entsteht und kontinuierlich gefordert wird, entscheidet Time-to-Software über die strategische Beweglichkeit eines Unternehmens. Wer diese Metrik in den nächsten zwölf Monaten messbar macht, hat einen klaren Hebel, um Engpässe sichtbar zu machen und gezielt zu beseitigen. Wer sie ignoriert, wird die nächste Dekade aus dem Reagieren nicht herauskommen – während der schnellere Wettbewerber Quartal für Quartal ein paar Wochen Vorsprung aufbaut.