Messung von Wertflüssen in der Softwarebereitstellung mit dem Wertsystemschema

Volltext

1 Einleitung

Softwareteams werden genau vermessen: Velocity, Durchsatz, Durchlaufzeit, Deployment-Frequenz und Änderungsfehlerrate werden automatisch erhoben. Dennoch lassen diese Zahlen eine Frage offen: Welchen Wert hat das Team geliefert, für wen, und zu welchem Preis in Form von Verlusten?

Dieser Beitrag schlägt eine Methode vor, diese Frage mit dem Wertsystemschema (Value System Schema, VSS) zu beantworten, der Modellierungsnotation der Æilus-Methodik, wie sie im auf aeilus.tech veröffentlichten VSS Editor umgesetzt ist. Er ist der fünfte Beitrag der Reihe "Æilus for Business". Er verwendet das Vokabular, das im ersten Beitrag der Reihe, "Value, Anti-Value and Value Flows: A Working Vocabulary for Practitioners" (Bolshakov, ÆVRI, 2026), definiert wurde, und wiederholt diese Definitionen nicht. Die formale Behandlung des Wertes als messbare Währung (Æ) findet sich in "Value Management Theory and Employee-Centric Competitive Advantage: A System-Level Perspective" (Bolshakov, ÆVRI, 2026).

Der Beitrag beschreibt, wie eine Delivery-Organisation ein Schema ihres Wertsystems aufbauen, geplanten und realisierten Wert an Releases anbinden, Flusswiderstand und Abfluss lokalisieren, gemeinsam genutzte technische Knoten bewerten und den Zyklus mit klaren Rollen und einem festen Takt betreiben kann. Er stützt sich auf die VMT-Axiome A1, A2, A4, A5, A6, A7, A11 und A13 sowie auf die Theoreme T3, T4, T5, T6, T8, T9, T15, T16 und T17. Er enthält keine Messdaten. Das Praxisbeispiel in Abschnitt 9 ist synthetisch.

2 Was Delivery-Metriken messen und was nicht

Delivery-Metriken beschreiben die Bewegung von Arbeit. Die Velocity zählt den abgeschlossenen geschätzten Aufwand; der Durchsatz zählt fertiggestellte Einträge. Die vier von Forsgren, Humble und Kim (Accelerate, 2018) popularisierten Schlüsselmetriken, nämlich Deployment-Frequenz, Durchlaufzeit für Änderungen, Zeit bis zur Wiederherstellung des Dienstes und Änderungsfehlerrate, beschreiben die Geschwindigkeit und Stabilität der Delivery-Pipeline. Diese Forschung verknüpft solche Fähigkeiten mit der Leistung von Organisationen, und dieser Beitrag stellt das nicht in Frage. Seine Behauptung ist enger gefasst: Diese Metriken beschreiben die Pipeline, nicht den Wert, der durch sie hindurchfließt.

Daraus ergeben sich drei Lücken.

• Aufwand ist kein Wert. Ein Sprint mit hoher Velocity kann Funktionen liefern, die niemand nutzt. In der Sprache des Product Value System Decks gilt: "Features sind kein Wert" und "Metriken sind kein Wert": Ein Feature ist eine Annahme über Wert, und eine Metrik ist eine Interpretation davon.
• Geschwindigkeit ist keine Richtung. Eine kurze Durchlaufzeit liefert eine falsche Hypothese schneller aus.
• Stabilität ist nicht die Abwesenheit von Anti-Wert. Eine niedrige Änderungsfehlerrate sagt nichts über Verzögerung, Verwirrung, Nacharbeit auf der Nutzerseite oder Vertrauensverlust aus, die durch eine Änderung verursacht werden, die genau wie vorgesehen funktioniert hat.

Aus Sicht der Wertmanagement-Theorie (Value Management Theory, VMT) ist die Lücke strukturell. Wert existiert nur innerhalb eines definierten Wertsystems und wird von dessen Akteuren interpretiert (A1, A2). Er wird im Moment des Verbrauchs realisiert (A6), und geplanter und realisierter Wert unterscheiden sich in der Regel (A4, T3). Pipeline-Metriken werden vor dem Verbrauch auf der Senderseite erhoben und beschreiben daher bestenfalls die Auslieferung von geplantem Wert. Wenn solche Metriken zu Zielvorgaben werden, tritt der von Goodhart (1975) beschriebene Effekt auf: Teams optimieren den Zähler. Die VMT formuliert dasselbe Risiko in Systembegriffen: Lokale Optimierung garantiert keine globale Verbesserung (T5).

3 Die Notation des Wertsystemschemas

3.1 Elemente der Notation

In der Æilus-Methodik ist das Wertsystemschema das erste zentrale Artefakt: eine formale Beschreibung des Wertsystems, seiner Akteure, Flüsse, Transformatoren und Schlüsselaustausche, die dazu dient, Systemgrenzen festzulegen und unsichtbare externe Abhängigkeiten zu verhindern. Ein VSS kann auf der Ebene der Transformatoren oder auf der Systemebene gezeichnet werden.

Der im Dezember 2025 auf aeilus.tech veröffentlichte VSS Editor ist ein browserbasierter visueller Editor für solche Schemata. Seine Notation besteht aus wenigen Elementen.

• Konverter. Ein Konverter (converter) ist die Æilus-Bezeichnung für eine Transformatorrolle in einem Schema: ein funktionaler Block, etwa ein Team, ein Dienst oder ein Subsystem, der Wertelemente empfängt, umwandelt und neue erzeugt. In Konvertern wird Wert geschaffen, verstärkt oder vernichtet.
• Flüsse. Ein Fluss ist eine gerichtete Verbindung zwischen Konvertern oder zwischen einem Konverter und der Außenwelt. Er trägt eine Menge an Wert oder Anti-Wert in Æ. Ein Fluss ist extern eingehend (Wert tritt in das System ein), extern ausgehend (Wert verlässt das System) oder intern (Wert zwischen Konvertern).
• Eingänge und Ausgänge. Externe Zu- und Abflüsse markieren, wo Wert eintritt und austritt. Zusammen legen sie die Systemgrenze fest.
• Wertelemente. Elementtypen beschreiben, was genau durch einen Fluss bewegt wird: Kundenwert, Umsatz, Kosten, Risiken, technische Schulden und Ähnliches. In einem gespeicherten Schema hat jedes Element eine Art (Wert oder Anti-Wert), ein Vorzeichen, eine Menge und eine Einheit (Æ).
• Anti-Wert. Anti-Wert steht für Verluste und negative Effekte: Verzögerungen, Nacharbeit, Fehler, Bürokratie, Risiko, Burnout, vergeudeten Aufwand. Im Schema ist er ein explizites Element mit negativem Vorzeichen, nicht die Abwesenheit von Wert (A5).

3.2 Das Schema als maschinenlesbares Modell

Der Editor speichert ein Schema als strukturiertes JSON mit Knoten (Konvertern), Flüssen und Elementen. Das Schema kann daher zusammen mit dem Produkt versioniert und später von Analysen gelesen werden, die geplante und realisierte Mengen je Fluss vergleichen. Solche Analysen sind als künftige Arbeit angekündigt und werden hier nicht vorausgesetzt.

3.3 Was das Schema nicht ist

Der VSS Editor ist ausdrücklich kein KPI-Dashboard, kein BI-Werkzeug, keine Simulations-Engine und kein Ersatz für die Finanzbuchhaltung. Er stellt Klarheit vor Berechnung. Daraus folgt die empfohlene Modellierungsreihenfolge: die Grenze definieren, nur die wichtigsten Konverter hinzufügen, sie mit benannten Flüssen verbinden (Namen vor Zahlen, Richtung vor Präzision) und dann den Anti-Wert markieren, ein Schritt, der oft die meisten Erkenntnisse liefert.

4 Wessen Wert: das System und seine Grenze

Eine Wertmessung ist bedeutungslos, solange sie nicht angibt, wessen Wert gemessen wird (A1, T1). Die gewählte Grenze verändert außerdem die Schlussfolgerungen, ohne dass sich die Realität ändert (T15). Dieser Beitrag legt das Wertsystem daher vor jeder Messung fest.

Das hier modellierte Wertsystem ist das Produktwertsystem eines einzelnen Softwareprodukts innerhalb einer Produktorganisation. Nach dem Product Value System Deck sind seine Akteure die Produktfunktion, das Entwicklungsteam, der Betrieb, das Produkt in der Produktion, die Nutzer und das Unternehmen als Empfänger des von den Nutzern zurückgegebenen Wertes. Die Finanzabteilung ist ein externer ermöglichender Zufluss (Gehälter).

Zwei realisierte Interpretationen werden gemessen: der Wert für die Nutzer, interpretiert von den Nutzern oder anhand ihres beobachtbaren Verhaltens, und der Wert für das Unternehmen, interpretiert vom Unternehmen als Empfänger des Rückflusses (Umsatz, Bindung, reduzierte Kosten oder Risiken). Der geplante Wert ist die Interpretation des Senders vor dem Release. Der Wert desselben Releases für einen Partner oder eine Aufsichtsbehörde liegt außerhalb der Grenze, sofern sie nicht ausdrücklich erweitert wird.

5 Von der Produkthypothese zum realisierten Wert: die Wertschleife

Das Product Value System Deck fasst Produktarbeit als Schleife auf, in der Werthypothesen erstellt, umgesetzt, validiert und aufrechterhalten werden. In Schemabegriffen hat die Schleife die folgenden Konverter und Flüsse.

1. Investition in die Produktfunktion. Die Produktfunktion wandelt Ressourcen und Nutzersignale in Hypothesen um, die geplanten Wert tragen.
2. Produktfunktion zur Entwicklung. Hypothesen werden zu Backlog-Einträgen mit geplantem Wert. Das Deck nennt zwei Erwartungen: Der geplante Wert einer Hypothese sollte während ihrer Umsetzung nicht sinken, und der gelieferte Wert sollte nicht stark vom geplanten Wert abweichen.
3. Entwicklung zum Betrieb. Die Entwicklung verbraucht Aufwand und erzeugt funktionierende Änderungen, zusammen mit Anti-Wert (technische Schulden, Fehler, Verzögerung).
4. Betrieb zur Produktion. Änderungen werden zu laufender Software; Release-Fehler und Ausfallzeiten erscheinen als Anti-Wert.
5. Produktion zu den Nutzern. Wert wird nur in der Nutzung realisiert (A6), daher ist dies der erste Punkt, an dem realisierter Wert beobachtet werden kann.
6. Nutzer zum Unternehmen. Die Nutzer geben Umsatz, Bindung und Vertrauen zurück. Der Kanalbeitrag des Autors vom Januar 2022 nennt dies einen geschlossenen Fluss: Der an den Kunden gelieferte Wert wird durch zurückfließenden Wert ausgeglichen, oft, aber nicht nur in Form von Geld.

Die Schleife macht das Transformationsaxiom konkret (A7): Jeder Konverter realisiert, was er empfängt, und erzeugt neuen geplanten Wert für den nächsten. Sie zeigt auch, warum Pipeline-Metriken nur die Schritte 3 und 4 abdecken. Die Schritte 1, 2, 5 und 6, in denen Wert geplant, realisiert und zurückgegeben wird, liegen außerhalb der Pipeline.

Die Präsentation listet außerdem beobachtbare Elementtypen für interne und externe Produkte auf. Zu den Wertelementen gehören eingesparte Zeit, weniger Betriebsfehler, Cashflow, Risikominderung, geringere kognitive Belastung, Vorhersagbarkeit, neue Fähigkeiten und Vertrauen. Zu den Anti-Wert-Gegenstücken gehören verlorene Zeit, Nacharbeit, wachsende Betriebskosten, technische Schulden, Unvorhersagbarkeit, manuelle Behelfslösungen, Vertrauensverlust und verschlechterter Kundenservice. Diese Typologie ist der Ausgangspunkt eines Wertelement-Registers für die Lieferung.

6 Geplanter und realisierter Wert pro Release, Widerstand und Abfluss

6.1 Das Release als Vergleichseinheit

Die Vergleichseinheit ist das Release oder, wenn Releases klein sind, das Backlog-Element. Für jedes erfasst die Methode in Æ:

• geplanter Wert: die Schätzung des Senders, erfasst vor Beginn der Entwicklung und nur durch eine ausdrückliche, protokollierte Entscheidung aktualisiert;
• realisierter Wert und realisierter Anti-Wert: die Interpretation des Empfängers, nachdem das Release über einen vereinbarten Beobachtungszeitraum im Einsatz war;
• retrospektiver Wert: eine spätere Neubewertung, sobald Effekte zweiter Ordnung (Supportaufwand, Abwanderung, technische Schulden) sichtbar geworden sind.

Die Präsentation schlägt eine gestufte Einführung vor: zuerst der geplante Wert für jedes Backlog-Element, dann der realisierte Wert und Anti-Wert für jedes ausgelieferte Element, dann der retrospektive Wert. Ohne geplanten Wert gibt es keine Lücke, die sich messen ließe; ohne realisierten Wert bleibt der Plan eine Hypothese.

6.2 Flusswiderstand in der Lieferung

Der Flusswiderstand (flow resistance) ist die Lücke zwischen geplantem und realisiertem Wert plus der Anti-Wert, der in einem Fluss entsteht. VMT betrachtet eine von null verschiedene Lücke als normal (T3), geht aber davon aus, dass sich Widerstand historisch akkumuliert (T4) und die Fähigkeit verringert, künftigen Wert zu realisieren (T6). In der Lieferung geht Wert verloren bei der Umsetzung (gekürzter Umfang, falsch verstandene Hypothese), beim Release (Defekte, Rollbacks), bei der Adoption (Nutzer können die Änderung nicht finden oder nutzen) und durch Verzögerung. In Anlehnung an das Konzept der Verzögerungskosten (Reinertsen, 2009) wird Verzögerung als Anti-Wert auf dem verspäteten Fluss modelliert, nicht als separate Kennzahl.

Wenn jeder Fluss seine eigenen geplanten und beobachteten Größen trägt, zeigt das Schema, in welchem Konverter der Verlust aufgetreten ist. Dies ist der Zweck des Flusswiderstandsregisters und des Berichts zur Lücke zwischen geplantem und realisiertem Wert im Artefaktsatz von Æilus.

6.3 Abfluss

Ein Abfluss (leakage) ist ein anhaltender Überschuss an realisiertem Wert, der das System verlässt, gegenüber dem Wert, der in es eintritt (A11). In einem Wertsystem für Produkte sind zwei Formen verbreitet. In der ersten profitieren die Nutzer, aber der Rückfluss deckt den ermöglichenden Zufluss nicht. In der zweiten verbraucht das Team Investitionen, während Hypothesen aufgebaut, aber nie realisiert werden. In beiden Fällen kann der Durchsatz gesund aussehen; das Schema zeigt beide, weil Zuflüsse und Abflüsse auf einer Grenze liegen.

7 Gemeinsame Knoten: Bewertung über alle Flüsse

Einige Konverter in einem Softwaresystem erzeugen keinen Wert, den ein Nutzer benennen würde, und doch durchläuft jeder Wertfluss sie. Der Kanalbeitrag des Autors vom September 2025 und der zugehörige Artikel auf aeilus.tech verwenden die Autorisierung als Beispiel: Sie erzeugt für sich genommen keinen Wert, aber ohne sie kommt jedes Szenario zum Stillstand. Ein API-Gateway oder eine CI-Pipeline ist von derselben Art.

Isoliert bewertet, zeigt ein solcher Knoten Kosten und keinen Output und lädt zu Kostensenkungen ein. Im Schema erscheint er auf vielen Flüssen gleichzeitig, und seine Effizienz wird erst durch den aggregierten Wert aller Flüsse erkennbar, die er unterstützt. Die Methode weist einem gemeinsamen Knoten daher Folgendes zu:

• die Menge der Flüsse, die ihn durchlaufen, aus dem Schema abgelesen;
• den Anti-Wert, den er jedem dieser Flüsse hinzufügt (Latenz, Ausfälle, fehlgeschlagene Anmeldungen, Integrationsdefekte);
• seinen verbrauchten Wert (Teamaufwand, Infrastruktur).

Seine Effizienz ist der gelieferte Wert abzüglich des Anti-Werts über alle seine Flüsse, im Verhältnis zum verbrauchten Wert, gemäß der Definition der Prozesseffizienz im selben Artikel. Eine Verschlechterung in einem gemeinsamen Knoten ist nie ein lokaler Vorfall; sie ist Widerstand, der jedem von ihm bedienten Fluss hinzugefügt wird. Theorem T8 fügt ein Nachhaltigkeitsargument hinzu: Stabilität geht verloren, wenn eine Transformationsrolle nicht ausgeübt werden kann, und Redundanz der Rolle erhöht die Stabilität.

8 Was ein Teamleiter gewinnt

Der Kanalbeitrag des Autors vom Februar 2022 listet auf, was der Ansatz einem Team und seinem Leiter bietet. In den Begriffen dieser Arbeit neu formuliert:

• Gelieferter Wert als Feedback. Für jeden Zeitraum sieht das Team den von ihm gelieferten Wert in Æ, von den Empfängern bestätigt, anstelle des indirekten Signals der Velocity.
• Ein von der Prozessmethodik unabhängiges Wirksamkeitsmaß. Unabhängig von der Praktik ist das Maß der realisierte Wert pro verbrauchtem Wert, und Praktiken werden nach ihrer Wirkung darauf ausgewählt oder abgeschafft (P7).
• Transparenz für das Business. Technische Arbeit wird durch die Flüsse erklärbar, die sie unterstützt.
• Backlog-Priorität aus dem Wert. Die Priorität lässt sich aus dem geplanten Wert, seiner Konfidenz und seinen Verzögerungskosten ableiten, statt vom lautesten Stakeholder.
• Verzögerungskosten und Produktionsfehler als Anti-Wert. Das Business kann zeigen, wie der Wert sinkt, wenn eine Änderung verspätet oder fehlerhaft ist, und das Team sieht, wie die Nützlichkeit seiner Arbeit von Timing und Produktionsqualität abhängt.
• Argumente für gemeinsame Ressourcen. Wo Administratoren und DevOps-Ingenieure geteilt werden, erklärt die wertbasierte Priorität, warum die Arbeit eines Teams zugunsten der eines anderen zurückgestellt wurde, in beide Richtungen.

Diese Gewinne gelten nur, wenn der realisierte Wert von seinen Empfängern validiert wird. Wenn das Team seinen eigenen Wert schätzt und bestätigt, wird das Maß zu einem weiteren selbstberichteten Zähler, und T17 greift: Interpretationen einflussreicher Quellen, die nicht durch Realisierung bestätigt werden, akkumulieren Anti-Wert.

9 Ein ausgearbeitetes Schema eines synthetischen Produkts

Dieser Abschnitt beschreibt ein synthetisches, illustratives Produkt. Er ist keine Fallstudie, beschreibt keine reale Organisation und enthält keine gemessenen Zahlen.

Das synthetische Produkt ist eine Web-Anwendung im Abonnement, über die kleine Dienstleistungsunternehmen Buchungen ihrer Kunden annehmen. Sein Wertsystem folgt der in Abschnitt 4 definierten Grenze. Zwei gemeinsame Knoten, ein Autorisierungsdienst und ein API-Gateway, bedienen alle nutzerseitigen Flüsse. Die Finanzabteilung stellt den ermöglichenden Zufluss bereit. Das Unternehmen erhält Abonnementeinnahmen und Kundenbindung als Rückfluss.

Das Schema wird im VSS Editor in vier Durchgängen aufgebaut: die Grenze mit einem externen Zufluss (Investitionen und Gehälter) und den externen Abflüssen zu den Nutzern; sieben Konverter; Flüsse, benannt nach den Wertelementen, die sie tragen; und Anti-Wert-Elemente. Die Größen bleiben bis zur ersten Schätzungssitzung leer.

Betrachten wir ein hypothetisches Release: eine Erinnerungsfunktion, die verpasste Termine reduzieren soll. Vor der Entwicklung erfasst der Product Owner den geplanten Wert pro Element (eingesparte Zeit, weniger verpasste Buchungen, erwartete Wirkung auf die Kundenbindung). Nach einem vereinbarten Beobachtungszeitraum liefern die Produktanalytik und eine Stichprobe von Geschäftsanwendern den realisierten Wert, und das Team erfasst den realisierten Anti-Wert: ein verspätetes Release, einen Fehler, der doppelte Erinnerungen versandt hat, zusätzliche Last auf dem API-Gateway. Die Differenz ist der Widerstand dieses Releases. Der Fehler und die Gateway-Last liegen auch auf Flüssen, die andere Szenarien bedienen, daher werden sie zusätzlich den gemeinsamen Knoten zugeordnet. Ein Quartal später zeigt der retrospektive Wert, ob sich die Kundenbindung überhaupt verändert hat. In einer realen Anwendung stammen die Größen aus den im Folgenden beschriebenen Sitzungen.

10 Wie man es durchführt

10.1 Wer schätzt und wer validiert

Die Æilus-Regel aus dem Beitrag von 2025 ist kurz: Der Ausgabewert eines Prozesses muss von demjenigen bewertet werden, der ihn konsumiert, und jemand anderes sollte diese Bewertung prüfen. Auf die Lieferung angewandt ergibt das eine klare Aufteilung.

• Der geplante Wert wird vom Sender geschätzt. Bei Hypothesen ist das der Product Owner in der Rolle des Eigentümers des Werttransformators (Value Transformer Owner, VTO) des Produkt-Wertwandlers. Beim Entwicklungs-Wertwandler ist es der Teamleiter als VTO.
• Der realisierte Wert wird vom Empfänger interpretiert: von den Nutzern, beobachtet über Produkt- oder Webanalytik, und vom Unternehmen für den Rückfluss. Die Präsentation schlägt als vorübergehende Maßnahme vor, dass die Produktanalytik die Nutzerseite vertritt, bis eine direkte Validierung etabliert ist.
• Die Validierung der Interpretation erfolgt durch eine zweite Partei: den Eigentümer des Wertsystems (Value System Owner, VSO), der für die Nachhaltigkeit auf Systemebene verantwortlich ist, oder einen Flusseigentümer bei einem kritischen Fluss.
• Die methodische Integrität wird von einem Æilus Master unterstützt (in der Präsentation ein Æilus-Champion, den ein Projektmanager innehat), der die Berichte zur Wertlieferung, zum Soll-Ist-Vergleich und zum Flusswiderstand erstellt.

10.2 Rhythmus

Æilus schreibt keinen Kalender vor. Ein minimaler Rhythmus für ein Liefer-Team, der mit den von der Methodik empfohlenen Ereignissen übereinstimmt, sieht wie folgt aus.

• Pro Backlog-Refinement: Neuen Einträgen wird anhand des Element-Registers ein geplanter Wert zugewiesen.
• Pro Release, nach dem Beobachtungszeitraum: Realisierter Wert und Anti-Wert werden erfasst und validiert; eine kurze Wert-Retrospektive bespricht die Lücke.
• Monatlich oder pro Quartal: ein Flusswiderstands-Review über das Schema, einschließlich der gemeinsamen Knoten; retrospektiver Wert für früher veröffentlichte Einträge.
• Pro Quartal oder bei strukturellen Änderungen: ein Wertsystem-Review der Grenzen, Werttransformator und Abhängigkeiten, wobei die Schemadatei aktualisiert und versioniert wird.

10.3 Disziplin

Jedes Artefakt braucht einen Eigentümer, einen Aktualisierungskreislauf und einen Entscheidungszweck; andernfalls erzeugt es durch Wartungskosten und falsche Sicherheit Anti-Wert. Für diese Methode sind die Entscheidungszwecke die Backlog-Priorität, die Zuteilung gemeinsamer Ressourcen, der Zeitpunkt des Releases und die Investition in gemeinsame Knoten. Ein Wachstum des geplanten Werts ist nur zulässig, wenn die Fähigkeit des Teams, ihn zu realisieren, bestätigt ist (P9). Den geplanten Wert schneller zu skalieren als den realisierten Wert ist der durch T16 beschriebene Fehlermodus.

11 Einschränkungen und was eine empirische Studie benötigen würde

Dieser Beitrag ist konzeptionell und wurde nicht an Messdaten erprobt. Daraus ergeben sich mehrere Einschränkungen.

• Schätzqualität. Werte in Æ sind Interpretationen, deren Verlässlichkeit von den Schätzenden und ihrer Kalibrierung abhängt.
• Teilweise Vergleichbarkeit. Eingesparte Zeit, Umsatz und Vertrauen sind nur teilweise vergleichbar (A13). Um sie in einer Währung auszudrücken, ist eine Wertaggregationsrichtlinie erforderlich, die dieser Beitrag voraussetzt, aber nicht definiert.
• Zuordnung. Realisierter Wert ergibt sich oft aus mehreren Releases und äußeren Faktoren; das Schema zeigt die Struktur, kann aber den Beitrag eines einzelnen Releases nicht isolieren.
• Verborgene Flüsse. Wenn das Schema die beobachtete Stabilität oder den beobachteten Niedergang des Systems nicht erklären kann, gibt es latente Flüsse oder die Grenze ist falsch (T9). Ein Schema ist eine Hypothese über die Struktur und muss überarbeitet werden.
• Kosten der Methode. Sitzungen, die keine Entscheidungen hervorbringen, machen die Methode selbst zu Anti-Wert.

Eine empirische Studie würde mindestens Folgendes benötigen: mehrere Liefer-Teams, die die Methode über einen ausreichend langen Zeitraum anwenden, um retrospektiven Wert zu erfassen; ein stabiles Element-Register und eine vor der Datenerhebung vereinbarte Aggregationsrichtlinie; eine unabhängige Validierung des realisierten Werts durch die Empfänger statt durch die Teams; die parallele Erhebung herkömmlicher Liefermetriken, damit die Beziehung zwischen diesen Metriken und dem realisierten Wert untersucht werden kann; sowie einen Vergleich der Entscheidungen, die mit und ohne das Schema getroffen wurden. Nur eine solche Studie könnte zeigen, ob eine wertbasierte Priorisierung den gelieferten Wert verändert und unter welchen Bedingungen.

12 Fazit

Liefermetriken beschreiben, wie Arbeit durch eine Pipeline fließt, nicht, was sie für ihre Empfänger verändert hat; unter der VMT können sie das nicht, da Wert kontextabhängig ist, nur in der Nutzung realisiert wird und geplanter und realisierter Wert auseinanderlaufen. Das Wertsystemschema (Value System Schema), wie es im VSS Editor umgesetzt ist, ermöglicht es Software-Teams, den Produktwertkreislauf von der Hypothese bis zum realisierten Wert und zurück zum Unternehmen zu zeichnen. Die Erfassung von geplantem, realisiertem und retrospektivem Wert pro Release macht den Kreislauf zu einer Messung: Widerstand und Abfluss werden sichtbar, gemeinsame Knoten werden über jeden Fluss bewertet, den sie bedienen, und Teamleiter erhalten gelieferten Wert, wertbasierte Priorität sowie die Kosten von Verzögerung und Fehlern als Rückmeldung. Die Methode bleibt nur dann ehrlich, wenn die Systemgrenze benannt ist, Empfänger den realisierten Wert validieren und jedes Artefakt einer Entscheidung dient. Ob sie in der Praxis den gelieferten Wert verbessert, ist eine empirische Frage, die dieser Beitrag formuliert, aber nicht beantwortet.

Literatur

• Bolshakov, V. Value Management Theory and Employee-Centric Competitive Advantage: A System-Level Perspective. ÆVRI, 2026.
• Bolshakov, V. Value, Anti-Value and Value Flows: A Working Vocabulary for Practitioners. ÆVRI, 2026.
• Bolshakov, V. Value Management Theory (VMT), version 1.4. 2026.
• Bolshakov, V. Value Management Methodology Æilus, v2.0. 2026.
• Bolshakov, V. VMT, Æilus v2.0 and the Product Value System (presentation). 2026.
• Bolshakov, V. New Tool Released: Value System Schema Editor (VSS Editor). aeilus.tech, 2025.
• Bolshakov, V. Assessing the Value of Processes: Efficiency, Risks, and Anti-Value. aeilus.tech, 2025.
• Bolshakov, V. Artifacts and Reports. Æilus methodology, aeilus.tech/methodology/artifacts-and-reports/. 2026.
• Bolshakov, V. Æilus channel posts on value flows, team leadership and the VSS Editor (auf Russisch). 2022-2025.
• Forsgren, N., Humble, J., Kim, G. Accelerate: The Science of Lean Software and DevOps. 2018.
• Goodhart, C. Problems of Monetary Management: The U.K. Experience. 1975.
• Reinertsen, D. The Principles of Product Development Flow. 2009.