Vom Kostenzentrum zum Wertwandler: Umwandlung von Anti-Wert im technischen Support

Volltext

1 Einleitung

In den meisten Produktorganisationen wird der technische Support als Kostenstelle geführt. Sein Budget ist sichtbar, sein Ergebnis wird in geschlossenen Tickets gezählt, und die übliche Frage lautet, wie er günstiger werden kann. Dieser Beitrag legt dar, dass diese Sichtweise unvollständig ist und dass das, was sie auslässt, der für das Produkt wichtigste Teil des Supports ist.

Die Argumentation verwendet das Vokabular der Theorie des Wertmanagements (VMT) und der Æilus-Methodik. Wert, Anti-Wert, Wertfluss, Wertsystem, Werttransformator sowie geplanter, realisierter und retrospektiver Wert werden so verwendet, wie sie im ersten Beitrag dieser Reihe definiert sind. Die formale Behandlung von Æ, der Wertwährung, findet sich in Bolshakov (2026) und wird nicht wiederholt.

Die Hauptquelle ist der Æilus-Artikel "Technical Support Service - Anti-Value Conversion" (Bolshakov, 2025). Er beschreibt den Support als eine Kette von Werttransformatoren, die Anti-Wert vom Kunden aufnehmen und in Wert umwandeln, mit Koeffizienten, die mit jeder Linie wachsen, und er schlägt zwei Koeffizienten vor, die in jeder Stufe zu messen sind. Dieser Beitrag fasst das Modell neu, macht die Koeffizienten operationalisierbar, legt fest, wessen Wert sie messen, und schlägt ein Messprotokoll vor. Er enthält keine Felddaten; alle Zahlen im durchgerechneten Beispiel sind illustrativ.

Der Beitrag stützt sich auf die VMT-Axiome A1 (Kontextualität), A2 (Mehrfachinterpretationen), A4 (Asymmetrie von Plan und Ist), A5 (Unabhängigkeit des Anti-Werts), A6 (Realisierung beim Konsum), A7 (Transformation), A12 (keine Werterhaltung) und A13 (partielle Kommensurabilität) sowie auf die Theoreme T2 (Flussinversion), T4 (Akkumulation von Widerstand), T5 (lokale Optimierung), T9 (verborgene Flüsse), T14 (nicht interpretierter Wert geht verloren), T15 (Grenzabhängigkeit) und T16 (Skalierung durch Interpretation ohne Realisierung).

2 Warum der Support als Kostenstelle behandelt wird und was dies verbirgt

2.1 Die Kostensicht ist eine Grenzwahl

Die Kostenstellensicht ergibt sich daraus, dass die Grenze des Wertsystems um die Finanzflüsse des Unternehmens gezogen wird. Innerhalb dieser Grenze verbraucht der Support Gehälter und Werkzeuge und erzeugt keine Umsatzzeile. Nach A1 existiert Wert nur innerhalb eines Wertsystems, und nach T15 ändert eine Verschiebung der Grenze die Schlussfolgerung, ohne die Realität zu ändern. Die Kostensicht ist eine korrekte Lesart eines Wertsystems, aber keine Beschreibung dessen, was der Support leistet.

T2 besagt, dass ein Fluss in verschiedenen Systemen gegensätzliche Interpretationen tragen kann. Eine Support-Interaktion, die das Unternehmen als Kosten bucht, ist für den Kunden die Beseitigung von Anti-Wert: eine Störung, die aufhört zu schmerzen, eine Frage, die aufhört, die Arbeit zu blockieren. Die Quelle nennt zehn Arten von Kundenwert, die der Support liefert, von der Verringerung des Anti-Werts von Vorfällen und Zeitersparnis bis hin zu Risikominderung und Vertrauen. Keine davon erscheint in einem Kostenbericht.

2.2 Was die Kostensicht verbirgt

• Kundenseitiger Wert. Der Support stellt den Wertstrom des Kunden wieder her. Hört er damit auf, ist die Teilnahmebedingung des Kunden (A8) gefährdet, und T7 sagt voraus, dass der Kunde geht oder die Form seiner Teilnahme ändert.
• Interner Wert. Die Quelle nennt drei interne Flüsse: Informationen über Vorfälle, Anfragen nach Funktionen, die Wettbewerber haben, und originelle Kundenvorschläge. Nach T9 ist eine Struktur, die von Flüssen getragen wird, die das Modell nicht zeigt, falsch modelliert oder schlecht abgegrenzt. Ein Kostenmodell des Supports ist ein solches Modell.
• Umwandlung. Die Quelle behauptet, dass der Support Anti-Wert in Wert umwandelt und dass das Ergebnis den ursprünglichen Anti-Wert um Größenordnungen übersteigen kann, wenn ein Problem tiefere Linien und das Produkt erreicht. A12 erlaubt dies: Eine behobene Grundursache beseitigt den Anti-Wert für jeden Kunden, nicht nur für den Melder.

3 Der Support als Eintrittspunkt des Anti-Wert-Stroms

Jedes Produkt liefert sowohl Wert als auch Anti-Wert. Nach A5 ist Anti-Wert eine unabhängige Kategorie: Ein Kunde kann von einem Produkt echten Wert erhalten und in derselben Woche echten Anti-Wert durch einen Ausfall. Der Support ist die Stelle, an der der größte Teil dieses Anti-Werts als beobachtbarer Fluss in das Unternehmen gelangt. Dieser Beitrag gliedert ihn in vier Arten, im Einklang mit der Beschreibung der Erstaufnahme in der Quelle:

• Vorfälle. Etwas funktionierte und hat aufgehört zu funktionieren.
• Defekte. Etwas hat nie wie vorgesehen funktioniert; der Anti-Wert wird sichtbar, wenn ein Kunde darauf trifft.
• Verwirrung. Das Produkt funktioniert, aber der Kunde kann daraus keinen Wert ziehen.
• Enttäuschte Erwartungen. Geplanter und realisierter Wert weichen voneinander ab. A4 besagt, dass dies normal ist; der Support ist die Stelle, an der die Lücke gemeldet wird.

Eine fünfte Eingabe ist potenzieller Wert: Anfragen und Vorschläge. Die Quelle behandelt ihn gesondert und beschreibt sein Volumen als unbegrenzt. Er teilt sich den Kanal, daher muss die Messung ihn vom Anti-Wert getrennt halten, um zu vermeiden, dass zwei Nenner vermischt werden.

Der Eintrittspunkt ist wegen T4 wichtig: Widerstand akkumuliert sich. Anti-Wert, der in einer Warteschlange liegen bleibt, summiert sich zu Vertrauensverlust und, nach T6, zu einer verringerten Fähigkeit, künftigen Wert zu realisieren. Die Dynamik von Warteschlangen in der Produktentwicklung ist gut beschrieben (Reinertsen, 2009); die VMT-Lesart ergänzt, dass das, was in einer Support-Warteschlange wartet, sich akkumulierender Anti-Wert im Wertsystem des Kunden ist.

4 Die Umwandlungskette

Nach A7 bedeutet Transformation, dass ein Akteur eingehenden Wert realisiert, oder hier eingehenden Anti-Wert aufnimmt, und neuen geplanten Wert erzeugt. Die Quelle behandelt jede Support-Linie als einen solchen Transformator, jeweils mit einem eigenen Eigentümer des Werttransformators (VTO).

4.1 Erste Linie

Die Quelle weist der ersten Linie die Aufnahme des Anti-Wert-Stroms in strukturierte Tickets, die schnelle Dämpfung des Anti-Werts beim Erstkontakt, die Aufrechterhaltung des kontinuierlichen Wertstroms, das Routing, die Datenerhebung, das Management der Kundenerwartungen und die Einschätzung der Tiefe des Anti-Werts zu. Ihre Rolle ist die eines Filters, eines Stoßdämpfers und eines Beschleunigers. Meist stellt sie den früheren Zustand des Kunden wieder her, weshalb die Quelle ihr den niedrigsten Koeffizienten zuweist. Das Management der Erwartungen verdient Beachtung: Statusmeldungen beheben nichts, verringern aber den Anti-Wert der Ungewissheit, ein direkter Fall von A5.

4.2 Zweite Linie

Die zweite Linie übernimmt komplexen Anti-Wert: schwierige Fehler, Integrationen, Leistung. Die entscheidende Verschiebung in der Quelle geht von der Unterdrückung eines Problems zur Beseitigung seiner Grundursache und von einem Kunden zu allen Kunden, da sich Korrekturen und aktualisierte Anleitungen über den gesamten Kundenstamm verbreiten. Die zweite Linie baut außerdem die Wissensdatenbank auf, die die Kapazität der ersten Linie erhöht, speist wiederkehrende Vorfälle in das Backlog ein und verringert verborgenen Anti-Wert wie technische Schulden.

4.3 Dritte Linie

Die Quelle bezeichnet die dritte Linie als Transformator auf strategischer Ebene, der an Anti-Wert arbeitet, der in Architektur, Code, Protokollen und Kernlogik wurzelt. Ihre Ergebnisse sind Änderungen an Funktionalität und Architektur sowie neue Transformatoren: Werkzeuge, Skripte, Überwachung und automatisierte Prüfungen, die weiterhin Anti-Wert umwandeln. Sie legt auch die Regeln für die unteren Linien fest, einschließlich der Frage, wie Wert und Anti-Wert in komplexen Fällen gemessen werden. Die Quelle merkt an, dass der Zuwachs schwer zu quantifizieren ist, bis die Änderungen den Kunden erreichen, was A6 in operativer Form ist.

4.4 Product Owner

Die Quelle platziert das Product-Owner-Team als nächsten Transformator und als Wertsynthesizer. Es priorisiert den Strom aller Linien, richtet ihn an der Strategie aus, bewertet, wo der Kundenwert bei geringstem Anti-Wert in Kosten, Zeit und Risiko am höchsten ist, und fügt potenziellen Wert aus Marktbedürfnissen hinzu. Das Ergebnis ist ein Lieferplan, der bestehenden Wert skaliert und neuen Wert schafft. Die Quelle verknüpft dies mit PDCA: Plan aus Support-Daten, Do durch die Liefer-Teams, Check anhand von Vorfällen und Wertmetriken, Act anhand von Strategie und Produkt. Das aktualisierte Produkt liefert dann erneut Wert, der Support erfasst den nächsten Strom, und der Kreis schließt sich.

5 Die in der Quelle vorgeschlagenen Koeffizienten

5.1 Nominale Koeffizienten je Linie

Die Zusammenfassung des geschlossenen Kreislaufs in der Quelle besagt, dass in der ersten Linie erfasster Anti-Wert mit einem Koeffizienten von x1 bis x1,5 in Wert umgewandelt werden kann; in der zweiten Linie mit x10; in der dritten Linie mit x100. Kundenvorschläge gehen an die zweite und dritte Linie, mit einem Volumen, das als unbegrenzt beschrieben wird, und der Wert, den der Product Owner an den Kunden zurückgibt, wird als potenziell praktisch unbegrenzt beschrieben. Das Muster: Je größer das Problem, desto höher die Linie, die es erreicht, und je höher die Linie, desto höher der Koeffizient. Die Quelle bietet diese als Größenordnungen an, nicht als Messungen. Dieser Beitrag behandelt sie als Hypothesen.

5.2 VAM und ACM

Die Quelle folgert, dass zwei Parameter in jeder Stufe gemessen werden müssen:

• Value Amplification Multiplier (VAM), der Koeffizient der Wertübertragung: "Wie viel Wert wurde empfangen und an den Kunden geliefert".
• Anti-Value Conversion Multiplier (ACM), der Koeffizient der Umwandlung von Anti-Wert in Wert: wie viel Anti-Wert empfangen wurde und wie viel davon für den Kunden in Wert umgewandelt wurde.

Die Quelle formuliert diese in Worten und gibt keine Formeln an. Die hier vorgeschlagene minimale Lesart als Verhältnis für eine Stufe s (erste Linie, zweite Linie, dritte Linie, Product Owner) über einen Betrachtungszeitraum lautet:

VAM_s = V_delivered,s / V_received,s

ACM_s = V_converted,s / AV_received,s

V_received,s ist der in die Stufe eintretende Wert (Vorschläge oder teilweise umgewandelter potenzieller Wert); V_delivered,s ist der realisierte Kundenwert, der der Ausgabe der Stufe zugeordnet werden kann; AV_received,s ist der in die Stufe eintretende Anti-Wert; V_converted,s ist der daraus erzeugte realisierte Kundenwert. Alle Größen sind in Æ angegeben.

Aus dem Wortlaut der Quelle ergeben sich zwei Lesarten. Die Zähler sind Wert für den Kunden, daher zählen Pläne, Tickets und Backlog-Einträge erst, wenn sie vom Kunden realisiert wurden (A6). Und die beiden Koeffizienten haben unterschiedliche Nenner: Einer erfasst die Verstärkung von Wert, der andere die Umwandlung von Anti-Wert. Ein Koeffizient auf Ketten-Ebene ist ACM_chain = sum of V_converted,s / AV_received,1, mit dem Anti-Wert beim Eingang als Nenner, wobei jede Einheit realisierten Werts nur einer Stufe zugeordnet wird.

6 Wessen Wert gemessen wird

Nach A1 und A2 ist ein Koeffizient ohne benanntes Wertsystem bedeutungslos. Die Kette berührt vier Wertsysteme:

Dieses Papier legt die Messung wie folgt fest. Die Zähler von VAM und ACM werden im Wertsystem des Kunden gemessen, da realisierter Wert die Interpretation des Empfängers ist. Die Nenner werden an der Grenze zwischen Kunde und Support gemessen: Anti-Wert, wie ihn der Kunde erlebt und meldet, erfasst von der ersten Linie. Die Support- und Produktsysteme nutzen die Koeffizienten; das Unternehmenssystem wägt sie gegen die Kosten ab. Der VSO verantwortet die Aggregationsrichtlinie für den Vergleich dieser Lesarten, die nur teilweise vergleichbar sind (A13). Würde sich der Support aus seinem eigenen Wertsystem heraus messen, würde er Aufwand und geplanten Wert melden. Die Definitionen der Quelle weisen nach außen, und das Protokoll hält sie dort.

7 Ein Messprotokoll

Das folgende Protokoll ist ein Vorschlag, im Feld nicht erprobt, und so gestaltet, dass es mit vorhandenen Ticketing- und Backlog-Werkzeugen funktioniert.

7.1 Zu protokollierende Daten

• Bei der Aufnahme: der Kunde und die Produktnutzung; die Art der Eingabe (Störung, Defekt, Verwirrung, enttäuschte Erwartung, Vorschlag); eine Anti-Wert-Schätzung in Æ auf einer gemeinsamen Skala, wo möglich mit dem Kunden bestätigt; betroffene Domänen.
• Bei jeder Übergabe: empfangende Stufe und Grund; Art der Lösung (Zustand wiederhergestellt, für diesen Kunden behoben, Grundursache beseitigt, neuer Transformator geschaffen, Backlog-Eintrag angelegt); Verknüpfungen von Tickets mit Backlog-Einträgen und Releases; geplanter Wert der vorgeschlagenen Änderungen, getrennt vom realisierten Wert geführt.
• Nach der Lieferung: realisierter Wert in Æ, bestätigt vom Kunden oder einem vereinbarten Stellvertreter-Indikator; Anzahl der erreichten Kunden; eine spätere retrospektive Neubewertung.

7.2 Wer realisierten Wert validiert

Der Transformator, der die Anerkennung beansprucht, validiert seinen eigenen realisierten Wert nicht. Der Kunde interpretiert ihn, durch ausdrückliche Bestätigung oder im Voraus vereinbarte Stellvertreter-Indikatoren (die Störung tritt nicht erneut auf, die Funktion wird genutzt). Die VTO jeder Linie schlägt Schätzungen vor und verantwortet die Qualität des Protokolls. Die Produkt-VTO bestätigt, welche gelieferten Änderungen auf welche Support-Eingaben zurückgehen. Der VSO entscheidet über Streitfälle bei der Zuordnung. Geplanter Wert wird erfasst, geht aber nie in einen Zähler ein, gemäß A4 und T16: Eine Wertbehauptung allein durch Interpretation zu skalieren ist strukturell instabil. Das x100 der Quelle für die dritte Linie ist eine solche Behauptung, bis die Änderung die Kunden erreicht.

7.3 Überprüfungsrhythmus

• Pro Ticket, beim Abschluss: Schätzung bei der Aufnahme, Art der Lösung, realisierter Wert der ersten Linie.
• Pro Linie, in einem kurzen regelmäßigen Zyklus: ACM und VAM für abgeschlossene Vorgänge, Alter des offenen Anti-Werts in Warteschlangen (T4), Eskalationsgründe.
• Pro System, in einem längeren Zyklus: Der VSO und die Produkt-VTO prüfen gelieferte Änderungen, retrospektive Neubewertungen, den gesamten Zufluss an Anti-Wert und ob die Koeffizienten der einzelnen Linien der von der Quelle vorhergesagten Reihenfolge folgen.

Da die Realisierung verzögert eintritt, sollten Koeffizienten nach Kohorte berichtet werden, also nach dem Zeitraum, in dem der Anti-Wert empfangen wurde.

7.4 Fallstricke

Goodhart (1975) stellte fest, dass eine statistische Regelmäßigkeit dazu neigt, zusammenzubrechen, sobald sie zur Steuerung verwendet wird. In VMT-Begriffen ist dies T5: Lokale Optimierung garantiert keine globale Verbesserung.

• Manipulation der Ticketzahlen. Das Aufteilen eines Problems in mehrere Tickets bläht den Durchsatz auf. VAM und ACM sind Verhältnisse in Æ, keine Zählwerte, doch die Ticketzahl sollte nicht als Zielgröße neben ihnen festgelegt werden.
• Abwertung der Aufnahme. Eine Unterschätzung des Anti-Werts erhöht ACM. Schätzungen bei der Aufnahme brauchen eine gemeinsame Skala und stichprobenartige Bestätigung durch den Kunden.
• Übermäßige Eskalation. Wenn höhere Linien höhere Koeffizienten zeigen, ist Eskalation verlockend. Sie sollte an den Eskalationsregeln gemessen werden, die die dritte Linie festlegt.
• Doppelzählung. Derselbe realisierte Wert kann von mehreren Stufen beansprucht werden. Jede Einheit wird nur einmal zugeordnet.
• Verbergen des Zuflusses. Das beste Ergebnis ist, dass weniger Anti-Wert den Support erreicht, was ACM nicht erfassen kann. Der gesamte Zufluss muss neben den Koeffizienten berichtet und ein Rückgang als Ergebnis gelesen werden.
• Verwerfen von Signalen. Nach T14 geht Wert ohne Interpretation verloren. Das Protokoll sollte zeigen, wie viele Vorschläge und Muster eine Produktentscheidung erreicht haben.

8 Bezug zu Service-Domänen

Die Æilus-Methodik definiert eine Domäne als Kontext der Wertinterpretation, der Anforderungen an zulässige Praktiken und Ergebnisse stellt. Domänen schaffen keinen Wert; sie verhindern nicht zulässigen Anti-Wert. Der Support berührt mehrere typische Domänen:

• Verfügbarkeit und Kontinuität. Eine Störung ist für den Kunden eine Verletzung dieses Kontexts. Die Pflicht der ersten Linie, einen kontinuierlichen Wertstrom aufrechtzuerhalten, ist dessen operative Seite, und die Weiterleitung sollte der Domänenrichtlinie zur Kritikalität folgen.
• Sicherheit. Die Methodik merkt an, dass Wert abgelehnt werden kann, weil er den für eine sichere Teilnahme erforderlichen Kontext verletzt. Eine Umgehungslösung, die die Sicherheit schwächt, wird als neuer Anti-Wert erfasst, nicht als Umwandlung.
• Architektur. Die Quelle verlangt, dass Entscheidungen der dritten Linie auf architektonische Integrität, Skalierbarkeit, Leistung und Sicherheit geprüft werden.
• Wissensmanagement und Kontinuierliche Verbesserung. Die Wissensdatenbank der zweiten Linie und der PDCA-Zyklus sind Praktiken in diesen Domänen.

Zwei Folgerungen ergeben sich. Der in ACM gezählte realisierte Wert muss in jeder relevanten Domäne zulässig sein. Und ACM aggregiert Wert über teilweise vergleichbare Domänen hinweg (A13), daher braucht es die ausdrückliche Aggregationsrichtlinie, die die Methodik dem VSO zuweist, wobei die Domänenrichtlinien bei den Domain Owners liegen. Ohne sie, so warnt die Methodik, degeneriert die Optimierung zu lokaler Präferenz oder Metrikmanipulation.

9 Veranschaulichendes durchgespieltes Beispiel

Dieses Beispiel ist hypothetisch. Das Produkt, die Kunden und die Zahlen sind erfunden und bewusst gerundet. Sie sind keine Befunde und prüfen nicht die Koeffizienten der Quelle.

Ein Produkt hat einen wiederkehrenden Fehler in einer Integration für den Datenimport. In einem Zeitraum melden ihn zehn Kunden.

• Aufnahme. Der Anti-Wert jedes Klienten wird auf 10 Æ geschätzt, also AV_received,1 = 100 Æ.
• Erste Ebene. Eine bekannte Umgehungslösung und Statusmeldungen stellen die Arbeitsfähigkeit wieder her; die Klienten bestätigen 120 Æ realisierten Wert. ACM_1 = 120 / 100 = 1.2, innerhalb des nominalen Bereichs der Quelle.
• Zweite Ebene. Eine Konfigurationsursache wird gefunden; ein korrigierter Standardwert und ein Wissensdatenbank-Artikel erreichen die meldenden Klienten und weitere. Bestätigter realisierter Wert: 400 Æ. ACM_2 = 400 / 100 = 4, unterhalb des nominalen x10. Im Protokoll ist dies ein zu untersuchendes Ergebnis, kein zu korrigierender Fehler.
• Dritte Ebene und Produkt. Das Importprotokoll erweist sich als fragil; eine Neugestaltung und eine automatisierte Prüfung kommen mit einem geplanten Wert von 5.000 Æ auf die Roadmap. Es wurde nichts ausgeliefert, daher gilt ACM_3 = 0 für diese Kohorte. Die 5.000 Æ werden erfasst und ausgeschlossen.
• Vorschläge. Zwei Klienten bitten um geplante Importe. Das ist potenzieller Wert auf dem VAM-Pfad und fließt nicht in ACM ein.

Bei diesem Review ergibt sich ACM_chain = (120 + 400 + 0) / 100 = 5.2. Wenn die Neugestaltung später ausgeliefert wird und Klienten Wert bestätigen, wird die Kohorte der dritten Ebene rückwirkend aktualisiert; verursacht sie eine Regression, wird dieser Anti-Wert der dritten Ebene zugeordnet. Das Beispiel zeigt, was ein Pilot beobachten muss: die Plan-Ist-Lücke auf der tiefsten Stufe (A4, A6), die Realisierungsverzögerung und mögliche Abweichungen von den nominalen Koeffizienten.

10 Einschränkungen

Weder hier noch in der Quelle liegen Felddaten vor. Die Koeffizienten x1 bis x1.5, x10 und x100 sind vorgeschlagene Größenordnungen, plausibel aufgrund des beschriebenen Mechanismus (eine Korrektur, die auf viele Klienten skaliert, neu geschaffene Transformatoren), aber nicht gemessen. Die Formeln sind die Lesart dieses Beitrags von verbalen Definitionen; andere Lesarten sind möglich. Æ-Schätzungen hängen von der Interpretation ab, die unter A2 eine Eigenschaft des Werts ist, doch der teamübergreifende Vergleich erfordert dennoch eine kalibrierte gemeinsame Skala, die dieser Beitrag nicht liefert. Die Zuordnung über die Stufen hinweg wird dem VSO ohne Regel zugewiesen.

Ein Pilot, der das Modell stützen oder schwächen könnte, müsste Folgendes zeigen:

• dass verschiedene Personen für dieselben Tickets konsistente Æ-Schätzungen abgeben;
• dass die Kohorten-ACM über mehrere Review-Zyklen hinweg unabhängig von den absoluten Werten der vorhergesagten Rangfolge nach Ebenen folgt;
• dass der realisierte Wert von Klienten oder vereinbarten Stellvertretergrößen bestätigt wurde, nicht von den beanspruchenden Ebenen;
• dass auf die Verwendung der Koeffizienten ein geringerer gesamter Anti-Wert-Zufluss folgte, ohne das in Abschnitt 7.4 aufgeführte Gaming;
• dass die Koeffizienten Informationen über herkömmliche Kennzahlen wie die Zeit bis zur Wiederherstellung des Dienstes hinaus liefern (Forsgren, Humble und Kim, 2018).

11 Fazit

Support nur als Kostenstelle zu behandeln, ist eine Entscheidung über die Systemgrenze. Im Finanzsystem des Unternehmens ist Support ein Kostenfaktor; im System des Klienten ist er die Beseitigung von Anti-Wert; im System des Produkts ist er die direkteste Information darüber, wo das Produkt versagt. Das Quellmodell beschreibt eine Kette von Transformatoren, deren Hebelwirkung von der ersten Ebene über die dritte Ebene bis in das Product-Owner-Team wächst und einen PDCA-Kreislauf zurück zum Klienten schließt, und schlägt VAM und ACM vor, um sie zu messen. Dieser Beitrag hat den Koeffizienten minimale Formeln gegeben, ihre Zähler im Wertsystem des Klienten verankert, nur realisierten und domänenzulässigen Wert gezählt und ein Protokoll für Erfassung, Validierung, Review und Schutz vor Gaming vorgeschlagen. Ob die Größenordnungen der Quelle Bestand haben, kann nur ein Pilot beantworten.

Literatur

• Bolshakov, V. Technical Support Service - Anti-Value Conversion. aeilus.tech, 2025.
• Bolshakov, V. Domains and Policies. Æilus methodology, aeilus.tech, 2026.
• Bolshakov, V. Roles. Æilus methodology, aeilus.tech, 2026.
• 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.
• Forsgren, N., Humble, J. and Kim, G. Accelerate: The Science of Lean Software and DevOps. 2018.
• Goodhart, C. A. E. Problems of Monetary Management: The U.K. Experience. 1975.
• Reinertsen, D. G. The Principles of Product Development Flow. 2009.