Was kostet eine Anforderung wirklich?

 Warum Requirements-, Varianten- und Portfoliomanagement zusammengehören – und warum das teuerste Wort im B2B-Geschäft manchmal „Ja“ ist

 „Der Kunde braucht noch eine weitere Variante.“

 Wer im technischen B2B-Geschäft arbeitet, kennt solche Sätze. Eine zusätzliche Länge. Eine andere Schutzart. Ein spezieller Stecker. Eine weitere Zulassung. Eine zusätzliche Softwarefunktion.

 Für sich genommen wirkt jeder dieser Wünsche erst einmal überschaubar.

 Also fragen wir die Entwicklung: Geht das? Was müssen wir ändern? Wie lange dauert es? Was kostet die Entwicklung?

 Ich glaube, dass wir damit häufig zu kurz greifen. Denn eigentlich müssten wir fragen:

 Welchen Wert schafft diese Anforderung – und welche Komplexität kaufen wir uns damit über den gesamten Produktlebenszyklus ein?

 Aus einer Anforderung wird schnell ein Netzwerk

 Bei einem einfachen Produkt kann man sich die Wirkungskette noch einigermaßen linear vorstellen:

 Kundenbedürfnis → Requirement → Feature → Komponente → Variante → Test

 Bei modularen Produkten wird es interessanter.

 Ein Requirement kann mehrere Funktionen betreffen. Die Funktionen stecken in unterschiedlichen Modulen. Ein Modul wird vielleicht in fünf Produktfamilien eingesetzt. Dahinter hängen unterschiedliche Konfigurationen, Stücklisten, Tests und Dokumentationen. Vielleicht auch unterschiedliche Lieferanten oder Fertigungsprozesse.

 Aus einer kleinen Änderung wird so schnell ein Netzwerk.

 Requirements Management versucht, genau diese Zusammenhänge nachvollziehbar zu machen. Über Traceability wird eine Anforderung mit daraus abgeleiteten Anforderungen, Entwicklungsobjekten und Tests verknüpft.

 IBM beschreibt für DOORS Next ausdrücklich, dass sich über diese Beziehungen die Auswirkungen einer Änderung analysieren lassen. Dabei geht es nicht nur um technische Abhängigkeiten. IBM spricht in diesem Zusammenhang auch von den „hidden costs of change“.[1]

 PTC verfolgt mit Windchill einen ähnlichen Ansatz. Die Change Impact Analysis soll zeigen, welche Objekte von einer Änderung betroffen sind. Dabei können sowohl vor- als auch nachgelagerte Beziehungen berücksichtigt werden, einschließlich verknüpfter Requirements.[2]

 Das beantwortet schon einmal eine ziemlich wichtige Frage: Was hängt eigentlich alles an dieser Anforderung?

 Modularisierung hilft – macht Änderungen aber nicht automatisch harmlos

 Ich bin ein großer Freund modularer Produktarchitekturen. Sie ermöglichen es, unterschiedliche Kundenbedürfnisse mit standardisierten Bausteinen abzudecken, statt für jeden Kunden ein neues Produkt zu bauen.

 Aber Modularisierung hat einen interessanten Nebeneffekt: Je häufiger ein Modul verwendet wird, desto weiter kann sich eine Änderung an diesem Modul durch das Portfolio ziehen.

 Das ist kein Argument gegen Modularisierung. Im Gegenteil. Es ist ein Argument dafür, die Zusammenhänge zu kennen.

 Variantenmanagementsysteme bilden deshalb nicht nur fertige Artikelnummern ab, sondern die Logik dahinter: Welche Module gibt es? Welche Optionen? Welche Kombinationen sind erlaubt?

 PTC Windchill verwaltet beispielsweise konfigurierbare Module, Optionen und Auswahlregeln und kann daraus Variantenstrukturen erzeugen.[3]

 Siemens geht mit dem Polarion Variant Configurator auf der Requirements-Seite einen ähnlichen Weg. Features können Varianten zugeordnet und daraus die jeweils geltenden Requirements abgeleitet werden. Auch unzulässige Kombinationen lassen sich erkennen.[4]

 Damit lässt sich zumindest prinzipiell eine Kette herstellen:

 Marktanforderung → Requirement → Feature → Modul → Komponente → Variante → Test

 Und jetzt wird es für mich als Produktmanager interessant.

 Traceability zeigt mir den Impact. Aber lohnt sich die Änderung?

 Nehmen wir an, ein Kunde fordert eine höhere Schutzart. Die Impact Analysis zeigt:

• Drei Module müssen betrachtet werden.

• Zwölf bestehende Varianten sind betroffen.

• Vier Tests müssen angepasst oder ergänzt werden.

• Zwei Dokumentationen ändern sich.

 Sehr gut. Aber würde ich deshalb die Änderung freigeben? Mir fehlt noch die wirtschaftliche Perspektive. Ich möchte wissen:

• Welchen zusätzlichen Deckungsbeitrag ermöglicht die Anforderung – und über welchen Zeitraum?

• Braucht das nur dieser eine Kunde? Oder sehen wir dahinter ein relevantes Marktbedürfnis?

• Können wir die Lösung in anderen Produktfamilien wiederverwenden?

• Verhindern wir damit den Verlust bestehenden Geschäfts?

• Und vor allem: Welche Folgekosten holen wir uns damit ins Haus?

 Denn vielleicht kostet die Entwicklung nur 20.000 Euro. Wenn ich dafür aber eine zusätzliche Variante erzeuge, die zehn Jahre lang in ERP, PLM, Einkauf, Fertigung, Qualität, Dokumentation, Lager und Service mitläuft, erzählen mir diese 20.000 Euro nur einen kleinen Teil der Geschichte.

 Vereinfacht gesagt:

• Requirements Management zeigt: Welche Anforderungen und Entwicklungsobjekte sind betroffen?

• Variantenmanagement ergänzt: In welchen Konfigurationen und Produktfamilien wirkt sich die Änderung aus?

• Portfoliomanagement muss am Ende die unangenehme Frage stellen: Lohnt sich das?

 Markt- und Produktsicht gehören zusammen

 Dass diese beiden Welten zusammengeführt werden müssen, ist kein neuer Gedanke. PwC beschreibt beispielsweise bei der METUS-Methodik die Verbindung von Markt- und Produktsicht. Anforderungen und Funktionen werden mit Komponenten und Modulen der Produktarchitektur verknüpft. Ziel ist unter anderem die Optimierung von Produkten und Portfolio.[5]

 Genau diese Verbindung finde ich spannend. Denn ich kann die klassische technische Traceability weiterdenken:

 Requirement → technischer Impact → Varianten-Impact → Komplexitäts-Impact → wirtschaftlicher Impact

 Für eine Entscheidung brauche ich dann mindestens drei Perspektiven:

• Business Value: Welchen zusätzlichen oder gesicherten Deckungsbeitrag erwarten wir über den Lebenszyklus? Welche Kunden und Marktsegmente erreichen wir? Können wir die Lösung mehrfach nutzen? Welche strategische Bedeutung hat sie?

• Implementation Cost: Was kosten Engineering, Werkzeuge, Tests, Zertifizierung und Industrialisierung einmalig?

• Complexity Impact: Was passiert danach? Welche Varianten, Komponenten, Stücklisten, Lieferanten, Prüfungen, Dokumentationen, Ersatzteile und Pflegeaufwände kommen hinzu – und welche können entfallen?

 Gerade der letzte Punkt geht in Business Cases gerne unter.

 Was kostet die 27. Variante?

 Eine aktuelle Untersuchung von Grønvald, Nørgaard, Christensen und Mortensen von der Technischen Universität Dänemark (DTU) liefert dazu interessante Ergebnisse. Die Autoren untersuchten in vier Industrieunternehmen, wie Produktvielfalt auf Gemeinkosten wirkt. Betrachtet wurden unterschiedliche Produktionsumfelder, darunter Engineer-to-Order, Make-to-Order und Configure-to-Order sowie ein hybrides Configure-to-Order-/Make-to-Stock-Umfeld.[6]

 Das Ergebnis ist für Produktmanager durchaus unangenehm: Die Kostenwirkung zusätzlicher Vielfalt steckt eben nicht nur im Material. Engineering muss Daten anlegen und pflegen. Der Einkauf muss zusätzliche Teile und Lieferanten beherrschen. Planung und Qualität bekommen weitere Aufgaben. Stückzahlen verteilen sich auf mehr Varianten.

 Zwei Fälle aus der Untersuchung finde ich besonders anschaulich.

 Bei einem Hersteller von Lüftungsgeräten wurde der Einsatz eines teureren, aber stärker standardisierten Wärmepumpenmoduls untersucht. Im betrachteten Szenario sank die Zahl der Modulvarianten von 38 auf 21. Das Material wurde teurer. Trotzdem verbesserte sich das Gesamtergebnis im Modell.

 Warum? Weil Aufwände in Engineering, Datenpflege, Robotik-Programmierung und Einkauf sanken und gleichzeitig Skaleneffekte durch höhere Stückzahlen je Modul entstanden. Die Autoren weisen einen positiven jährlichen Effekt von rund 120.000 Euro aus. Die veröffentlichten Geldbeträge wurden aus Vertraulichkeitsgründen skaliert; die proportionalen Beziehungen bleiben jedoch erhalten.[6]

 Der zweite Fall zeigt die andere Richtung. Eine neue Variante war bei den direkten Kosten deutlich günstiger als eine bestehende Lösung. Eigentlich ein klarer Fall. Bis zusätzlich Einkauf, Planung, Qualifizierung, Lager und verlorene Skaleneffekte berücksichtigt wurden. Danach lag die neue Variante im Modell rund 0,5 Millionen Euro schlechter. Auch hier handelt es sich um die von den Autoren skalierten Werte.[6]

 Das ist für mich die entscheidende Botschaft:

 Eine Variante kann beim Stückpreis günstiger und für das Unternehmen trotzdem teurer sein.

 Und eine technisch kleine Anforderungsänderung kann deshalb wirtschaftlich eine ziemlich große Entscheidung sein.

 Klassische Kostenrechnung hilft dabei nur bedingt

 Das Problem wird dadurch verschärft, dass viele dieser Kosten gar nicht sauber beim verursachenden Produkt landen. Die DTU-Studie beschreibt genau diesen Effekt: Gemeinkosten werden in klassischen Kostenrechnungssystemen häufig so verteilt, dass komplexe Varianten mit geringen Stückzahlen wirtschaftlich attraktiver erscheinen können, als sie tatsächlich sind.[6]

 Wer einen Exoten im Portfolio hat, sieht dessen tatsächlichen Aufwand deshalb möglicherweise gar nicht in dessen Produktkalkulation.

 Die Studie bildet außerdem nicht alle Kosten über den Lebenszyklus ab. After-Sales-Service, Ersatzteillogistik, Sicherheitsbestände, Lagerhaltungskosten und zukünftige Entwicklungsaufwände wurden nicht explizit modelliert. Also genau jene Dinge, die uns mit einer zusätzlichen Variante noch Jahre später beschäftigen können. Die Ergebnisse sind deshalb als Teil-Business-Cases zu verstehen, nicht als vollständige Lebenszyklusrechnung.[6]

 Vom Change Request zum Requirement Business Case

 Ich würde deshalb bei größeren Anforderungsänderungen einen zusätzlichen Schritt einbauen. Nicht bei jeder Schraube und nicht als neues Bürokratiemonster. Aber immer dann, wenn eine Anforderung Architektur, Varianten oder Portfolio beeinflusst. Nennen wir es einen Requirement Business Case.

 Nehmen wir wieder die höhere Schutzart. Wir wissen: Drei Module müssen betrachtet werden, zwölf Varianten sind betroffen, vier Tests müssen angepasst oder ergänzt werden und zwei Dokumentationen ändern sich. Entwicklungs- und Prüfaufwände sind notwendig.

 Jetzt ergänzen wir die Marktseite: Ein konkreter Kunde braucht die Änderung. Zwei weitere Opportunities haben dieselbe Anforderung. Das Marktsegment ist strategisch interessant. Die Lösung könnte außerdem in einer zweiten Produktfamilie eingesetzt werden.

 Damit haben wir plötzlich mehrere echte Optionen:

• Ablehnen: Der zusätzliche Nutzen rechtfertigt den Aufwand nicht.

• Sonderlösung: Wir erfüllen die Anforderung für einen konkreten Kunden und bepreisen die entstehende Komplexität entsprechend.

• Portfolio-Option: Wir nehmen die Funktion bewusst als zusätzliche Option ins Portfolio auf.

• Plattformstandard: Wir erhöhen den Standard für alle und versuchen im Gegenzug, bestehende Varianten zu eliminieren.

 Gerade die vierte Möglichkeit wird gerne vergessen. Manchmal ist ein technisch teurerer Standard wirtschaftlich günstiger als mehrere billige Varianten. Genau diesen Zusammenhang zeigt auch der Lüftungsgeräte-Fall der DTU-Studie.[6]

 Und jetzt drehen wir die Analyse um

 Bis hierher haben wir eine neue Anforderung betrachtet. Aber eigentlich wird es jetzt erst richtig spannend: Was passiert, wenn wir dieselbe Logik auf unser bestehendes Portfolio anwenden?

 Dann würde ich gerne wissen:

• Welche Requirements verursachen heute die größte Variantenvielfalt?

• Wegen welcher historischen Kundenanforderung pflegen wir noch immer 25 Varianten?

• Welche Requirements ziehen besonders viele Teile, Prüfungen und Sonderprozesse nach sich?

• Und welchen relevanten Deckungsbeitrag erzielen wir heute noch mit dem Geschäft, das diese Anforderungen bedienen?

 Vielleicht stellen wir dann fest:

 Wenn Requirement R-187 entfällt, könnten wir 18 Varianten, sieben Teile, drei Prüfabläufe und eine Lieferantenbeziehung eliminieren – sofern diese nicht für andere Anforderungen, Produkte oder bestehende Liefer- und Serviceverpflichtungen benötigt werden.

 Das wäre eine ziemlich interessante Information für eine Portfolioentscheidung. Requirements Management wäre dann nicht mehr nur Entwicklungsdokumentation. Es würde zum Datenlieferanten für Varianten-, Komplexitäts- und Portfoliomanagement.

 Der Haken: Wir brauchen die Daten

 Natürlich funktioniert das nicht auf Knopfdruck. Gerade bei historisch gewachsenen Portfolios fehlt häufig die Traceability zwischen Kundenanforderung, Requirement, Feature, Modul und Variante. Auch die DTU-Studie weist darauf hin, dass Unternehmen Schwierigkeiten haben, Konfigurationen mit den tatsächlich verursachten Aufwänden zu verbinden.[6]

 Das ist aber kein Argument gegen den Ansatz. Es ist ein Argument dafür, bei neuen Anforderungen damit anzufangen. Nicht alles rückwirkend perfekt modellieren. Sondern bei jeder relevanten neuen Anforderung die Verbindung sauber herstellen:

• Warum machen wir das?

• Wer braucht es?

• Welche Module und Varianten sind betroffen?

• Was kostet es einmalig?

• Welche laufende Komplexität entsteht – und welche kann entfallen?

• Und welchen wirtschaftlichen Wert erwarten wir?

 So entsteht Schritt für Schritt eine Datenbasis, die heute in vielen Unternehmen schlicht fehlt.

 Das teuerste Wort ist manchmal „Ja“

 Die technischen Bausteine dafür gibt es längst. Requirements-Systeme schaffen Traceability. Variantenmanagement bildet Konfigurationen und Wiederverwendung ab. PLM verbindet Produktstrukturen und Änderungen. Komplexitätsmanagement versucht, Markt- und Produktsicht zusammenzubringen. Und neuere Forschung zeigt Möglichkeiten, auch die indirekten Kosten von Produktvielfalt besser sichtbar zu machen. [1–7]

 Was mir häufig fehlt, ist die Managementlogik darüber. Vereinfacht:

 Wirtschaftlicher Beitrag der Änderung = zusätzlicher oder gesicherter Deckungsbeitrag über den Lebenszyklus – einmalige Umsetzungskosten – zusätzliche laufende Komplexitätskosten + Einsparungen durch reduzierte Komplexität

 Verglichen wird dabei immer mit dem Szenario ohne Änderung. Und natürlich dürfen Kosten, die bereits im Deckungsbeitrag berücksichtigt sind, nicht ein zweites Mal abgezogen werden.

 Dazu kommt die strategische Bewertung, die sich nicht sinnvoll auf zwei Nachkommastellen berechnen lässt.

 Das ist keine neue Controllingformel und auch keine vollständige Investitionsrechnung. Es ist vor allem eine Erinnerung daran, wo wir rechnen müssen: nicht nur im Entwicklungsprojekt, sondern über den Produktlebenszyklus.

 Denn Komplexität entsteht nicht erst, wenn wir irgendwann feststellen, dass unser Portfolio zu groß geworden ist. Sie beginnt viel früher. Manchmal mit einem Satz wie:

 „Der Kunde braucht noch eine weitere Variante.“

 Und mit dem vermutlich teuersten Wort im B2B-Geschäft:

 „Ja.“

 Wie geht ihr in euren Unternehmen mit solchen Anforderungen um – gibt es einen Requirement Business Case, oder entscheidet am Ende doch der Entwicklungsaufwand?

 Quellen

 [1] IBM Engineering Lifecycle Management / DOORS Next: Dokumentation zu Traceability und Impact Analysis.

 [2] PTC Windchill 13.1.2 Help Center: Change Impact Analysis.

 [3] PTC Windchill 13.1.2 Help Center: Windchill Options and Variants Capabilities.

 [4] Siemens Digital Industries Software: Polarion Variant Configurator.

 [5] PwC Deutschland: METUS – Winning Products: Modulare Produktplattformen.

 [6] Grønvald, J. M.; Nørgaard, M.; Christensen, C. K. F.; Mortensen, N. H. (2026): „Quantifying the overhead impact of product variety: a multi-case analysis“. Production Engineering 20, Article 79. DOI: 10.1007/s11740-026-01458-y. https://link.springer.com/article/10.1007/s11740-026-01458-y 

 [7] ElMaraghy, H.; Schuh, G.; ElMaraghy, W.; Piller, F.; Schönsleben, P.; Tseng, M.; Bernard, A. (2013): „Product variety management“. CIRP Annals 62(2), 629–652. DOI: 10.1016/j.cirp.2013.05.007.

 Natürlich habe ich bei der Erstellung, Überprüfung und Gestaltung dieses Artikels KI genutzt.