Neuaufbau des Liefersystems im B2B-SaaS-Bereich
Wie Intelvision das gesamte Produktbereitstellungssystem eines europäischen B2B-Softwareunternehmens von innen heraus umgestaltet hat
- Mehr als 90 % der User Stories haben keinen Bezug zu Geschäftsprozessen
- Ca. 10 % des jährlichen Umsatzes gehen durch Kosten aufgrund mangelnder Qualität verloren
- Mehr als 3 Jahre bestehende Partnerschaft vor Beginn des Audits
Das Produkt verkaufte sich gut, aber der geschäftliche Wert wurde immer schwieriger zu erkennen
Ein europäisches B2B-Softwareunternehmen mit einem komplexen, integrationsintensiven Produkt und einer langfristigen Vertriebsstrategie. Intelvision arbeitete bereits seit über drei Jahren mit diesem Kunden zusammen, wobei unsere Ingenieure direkt in die laufende Produktentwicklung eingebunden waren. Die Arbeit ging voran. Tickets wurden bearbeitet. Funktionen wurden diskutiert. Wir waren diejenigen, die das Problem als Erste erkannten.
Das Problem, das noch niemand benannt hatte
Der Kunde kam nicht mit dem Wunsch nach einer grundlegenden Umstrukturierung zu uns. Es gab keine Krisensituation, keinen gescheiterten Start, kein Ultimatum der Geschäftsleitung. Von außen betrachtet wirkte das Projekt aktiv.
Doch aus der Innenperspektive – nach drei Jahren intensiver Einbindung – konnten wir feststellen, dass sich die Entwicklungsaktivitäten stillschweigend von den Geschäftsergebnissen entkoppelt hatten. Das Team entwickelte Produkte. Es wurde zunehmend schwieriger zu erklären, welchen Wert diese Produkte hatten.
Diese Lücke, die nicht geschlossen wird, verschärft sich. Und sie verschärfte sich bereits.
Wir haben ein strukturiertes Audit eingeleitet. Der Kunde hatte nicht danach gefragt. Wir haben es getan, weil wir glaubten, dafür zu haben.
Was die Prüfung ergab
Die Mehrheit der User Stories schwebte frei
Das auffälligste Ergebnis: Mehr als 90 % der bestehenden User Stories waren nicht klar mit einer Geschäftsfähigkeit, einem Produktziel oder einer Roadmap-Priorität verknüpft.
Das Team war nicht untätig. Der Aufgabenbestand war voll. Doch die Arbeit bestand größtenteils aus isolierten Aufgaben – Tickets wurden zugewiesen, erledigt und geschlossen, ohne dass ein klarer Zusammenhang zur kommerziellen Ausrichtung des Produkts erkennbar war.
Wenn User Stories nicht mit den Geschäftsprozessen verknüpft sind, steht die Führungsebene vor einem anhaltenden und schwerwiegenden Problem: Sie sieht zwar, dass das Team beschäftigt ist, kann aber die wirklich wichtigen Fragen nicht beantworten.
- Welche Geschäftsfunktion haben wir in diesem Sprint weiterentwickelt?
- Welches Kundenproblem haben wir gelöst?
- Welchen Mehrwert haben wir im letzten Monat geschaffen?
- Lohnt sich die Investition in diese Funktion?
- Wo passt dieses Ticket in die Roadmap?
Das sind keine Fragen zur Berichterstattung. Es sind die Fragen, die fundierte Produktinvestitionsentscheidungen ermöglichen. Ohne Antworten basieren diese Entscheidungen auf Intuition.
Produktideen gingen verloren
Der Kunde verfügte über echtes Marktverständnis. Sein Führungsteam sprach regelmäßig mit Kunden, identifizierte Marktlücken und generierte einen stetigen Strom an Produktideen, die es wert waren, weiterverfolgt zu werden.
Diese Ideen wurden nicht erfasst, strukturiert oder systematisch weiterentwickelt. Es gab keinen definierten Weg von einem Gespräch im Verkaufsgespräch zu einer validierten Verkaufschance, von einer validierten Verkaufschance zu einer präzisierten Anforderung und von einer präzisierten Anforderung zu einer entwicklungsreifen User Story.
Ideen gelangten informell in das System und verloren oft ihren ursprünglichen Geschäftskontext, bis sie die Entwickler erreichten. Die Kluft zwischen strategischer Absicht und technischer Umsetzung war strukturell bedingt und nicht auf individuelle Leistungen zurückzuführen.
Qualitätsprobleme verursachten versteckte Geschäftskosten
Das Produkt wies wiederkehrende Qualitätsprobleme auf: Bugs, Nacharbeiten, unvollständige Implementierungen. Die sichtbaren Kosten bestanden in der ineffizienten Entwicklung: Zeit wurde für die Behebung von Fehlern aufgewendet, die eigentlich hätten korrekt sein sollen.
Die größeren Kosten waren weniger sichtbar: verzögerte Veröffentlichungen, langsamere Markteinführung, Zeitaufwand der Führungskräfte für die Überprüfung und Korrektur der Lieferungen sowie verpasste Verkaufszyklen, in denen ein potenzieller Kunde eine Funktion benötigte, an deren Überarbeitung das Team noch arbeitete.
Wir haben das finanzielle Risiko anhand dreier Dimensionen modelliert, ausgedrückt als Anteil des gesamten modellierten monatlichen Umsatzrisikos:
Diese Zahlen stellen ein modelliertes Risiko dar, keine garantierten Verluste. Sie haben jedoch den Fokus der Diskussion von „Wie viel Entwicklungsarbeit wird geleistet?“ zu „Wie viel Geschäftswert wird geschaffen oder vernichtet?“ verändert.
Systemtransparenz-Design & laufende Aufgaben
- Das Produkt basierte auf zahlreichen technischen Komponenten und Integrationen. Fehlerdiagnose gestaltete sich daher langwierig. Dem Kunden fehlte ein strukturierter Überblick über die Systemverfügbarkeit, Integrationsfehler, operative Engpässe und die Ursachen von Störungen. Die Führungsebene agierte reaktiv und erfuhr erst von Problemen, nachdem diese bereits Auswirkungen auf Benutzer oder Vertriebsgespräche hatten.
- Das Team hatte durchgehend mehr begonnene als abgeschlossene Aufgaben. In der Softwareentwicklung ist das kein Zeichen von Ehrgeiz, sondern ein Indiz dafür, dass der Arbeitsfluss gestört ist. Unvollständige Arbeit verursacht unnötige Kosten durch häufige Kontextwechsel, verschleiert den tatsächlichen Fortschritt und erschwert es, auf eine fertige Funktion zu verweisen und zu sagen: „Die wurde ausgeliefert und funktioniert.“
Wir haben aufgehört, Tickets als Aufgaben zu behandeln und die Leistungserbringung neu auf den Produktwert ausgerichtet
Ziel war es nicht, die Entwicklerleistung isoliert zu verbessern. Vielmehr ging es darum, Produktstrategie, Roadmap-Planung, Projektmanagement und technische Umsetzung zu einem einheitlichen, konsistenten Liefersystem zu verbinden. Wir haben das Liefermodell des Kunden auf drei Ebenen gleichzeitig neu aufgebaut.
Strategische Ebene: Klärung dessen, was am wichtigsten ist
Wir arbeiteten mit der Führungsebene zusammen, um die Produktstrategie zu formulieren, die Geschäftsmöglichkeiten abzubilden und kommerzielle Prioritäten festzulegen. Dies gab der Roadmap ein solides Fundament – klar definierte Ergebnisse, an denen die Entwicklungsarbeit ausgerichtet werden konnte.
Taktische Ebene – Strategieumsetzung in baubare Einheiten
Wir übersetzten strategische Prioritäten in Epics, Features und Releasepläne – jedes einzelne explizit mit einer Geschäftsfunktion verknüpft. Investitionsentscheidungen auf dieser Ebene wurden anhand des erwarteten Geschäftswerts und nicht nur der Entwicklungskosten bewertet.
Die Frage verlagerte sich von „Wie lange wird das dauern?“ zu „Was wird dadurch freigeschaltet, und lohnt es sich, es jetzt freizuschalten?“
Lieferebene – Neuausrichtung der Ausführung auf die gelieferten Ergebnisse
Wir haben den Sprint-to-Release-Zyklus so umstrukturiert, dass er sich auf den Abschluss und nicht auf die Aktivität konzentriert. Jede User Story musste sich auf ein Feature, eine Funktion und ein Geschäftsziel zurückführen lassen. Aufgaben, die diese Verbindung nicht herstellen konnten, wurden entweder umstrukturiert oder entfernt.
Was hat sich geändert?
1. Die Entwicklung wurde für das Unternehmen sichtbar
Vor der Transformation hatten über 90 % der User Stories keinen Bezug zu einem klaren Geschäftszweck. Nach der Transformation ließ sich jedes Backlog-Element zurückverfolgen auf:
- Eine Geschäftsfähigkeit
- Eine Roadmap-Priorität
- Ein Kundenbedürfnis
- Ein kommerzielles Ergebnis
Die Führungsebene konnte sich nun jeden Sprint ansehen und verstehen, was entwickelt wurde, warum es wichtig war und welcher Mehrwert geschaffen wurde.
2. Jira entwickelte sich von einem Aufgabenboard zu einem Produktlieferungssystem
Jira wurde in eine vollständige Produktlieferungshierarchie umstrukturiert:
- Ideen
- Chancen
- Geschäftsfähigkeiten
- Funktionen
- Benutzergeschichten
- Sprints
- Veröffentlichungen
Dadurch war die Lieferung von der strategischen Planung bis zur Produktionsfreigabe nachvollziehbar. Nichts blieb unstrukturiert, und jeder Artikel hatte seinen festen Platz im Produktsystem.
3. Investitionsentscheidungen konnten bereits vor Arbeitsbeginn bewertet werden
Der Kunde könnte die Kosten für die Entwicklung einer Funktion mit ihrem erwarteten Geschäftswert vergleichen, bevor er Entwicklungskapazitäten bindet.
Jede Initiative könnte nun wie folgt bewertet werden:
- Umsatzpotenzial
- Kundenauswirkungen
- Umsetzungsaufwand
- Technische Komplexität
- Bedeutung der Roadmap
Dies führte zu einer Verlagerung der Prioritäten von einer meinungsbasierten Bearbeitung des Auftragsbestands hin zu einer disziplinierteren Investitionsdiskussion.
4. Das Liefermodell wurde strukturiert und messbar
Wir haben ein proaktives Full-Stack-Audit und eine klar definierte Pipeline von der Idee bis zur Markteinführung eingeführt. Produktideen durchlaufen nun eine eindeutige Abfolge:
- Ideenerfassung
- Verfeinerung
- Entwicklung
- Testen
- Produktverantwortlichenprüfung
- Veröffentlichung
Die Transformation wurde anhand von drei operativen Kennzahlen gemessen: Erstausbeute, Systemverfügbarkeit und -transparenz sowie laufender Betrieb. Dies ermöglichte einen konkreten und nachvollziehbaren Vorher-Nachher-Vergleich.
5. Die Führungsebene erlangte proaktive Transparenz und Kontrolle über das finanzielle Risiko
Mit dem neuen Betriebsmodell konnte die Führungsebene erkennen, welche Ideen evaluiert, welche Funktionen verfeinert, welche Fähigkeiten entwickelt und welche Releases geplant waren.
Das finanzielle Risiko wurde auch dadurch beherrschbar:
- Weniger Nacharbeit
- Bessere Qualitätskontrolle
- Mehr Transparenz im Lieferprozess
- Stärkerer Zusammenhang zwischen Lieferaktivitäten und Umsatzpotenzialen
Die entscheidende Veränderung: Die Entwicklung hörte auf, eine Sammlung unzusammenhängender Tickets zu sein, und entwickelte sich zu einem für Unternehmen verständlichen Produktlieferungssystem.
