Methodologische artikelen · DevOps
Van kostenplaats naar waardeomzetter: de omzetting van anti-waarde in technische ondersteuning
Automatische vertaling. Oorspronkelijke taal: Engels. Lees het origineel
Korte samenvatting van de waarde
Technische ondersteuning wordt meestal beheerd als kostenplaats, wat de waarde verbergt die zij creëert voor klanten en het product. Dit artikel herformuleert het Æilus-model van ondersteuning als een keten van transformatoren die anti-waarde omzetten in waarde, geeft de twee coëfficiënten van de bron (VAM en ACM) minimale formules, legt vast wiens waarde zij meten en stelt een meetprotocol voor dat een ondersteuningsorganisatie zou kunnen overnemen.
Belangrijkste bevindingen en hun waarde
- De kostenblik is een grenskeuze. Support is kosten binnen het financiële waardesysteem van het bedrijf en verwijdering van anti-waarde binnen dat van de klant (A1, T2, T15). Waarde: leiders kunnen zien wat een bezuiniging op het supportbudget werkelijk wegneemt voordat ze die doorvoeren.
- Support is het ingangspunt van de anti-waardestroom. Incidenten, gebreken, verwarring en teleurgestelde verwachtingen komen hier binnen, en onbeheerde wachtrijen stapelen anti-waarde op (A5, T4). Waarde: de leeftijd van de wachtrij wordt een waardesignaal, niet alleen een serviceniveau.
- VAM en ACM hebben een benoemd waardesysteem nodig. Dit artikel meet hun tellers als gerealiseerde waarde in het waardesysteem van de klant en telt geplande waarde pas na oplevering (A4, A6, T16). Waarde: de coëfficiënten kunnen niet worden opgeblazen door roadmapbeloften.
- De coëfficiënten van de bron zijn hypothesen. De nominale x1-1.5, x10 en x100 per lijn zijn ordes van grootte die per cohort getoetst moeten worden, geen resultaten. Waarde: een pilot heeft een heldere, falsifieerbare voorspelling om te controleren.
- Domeinen bepalen wat als conversie telt. Een oplossing die het beleid voor beschikbaarheid, beveiliging of architectuur schendt, is nieuwe anti-waarde, en aggregatie over domeinen heen vraagt om een expliciet VSO-beleid (A13). Waarde: beschermt de maat tegen lokale optimalisatie en Goodhart-effecten.
Hoe het onderzoek is uitgevoerd
Conceptuele analyse en methodologieontwerp. Het Æilus-artikel over technische ondersteuning werd herformuleerd in VMT-termen, aan de verbale definities van VAM en ACM werden minimale verhoudingsformules gegeven, en een meetprotocol werd afgeleid uit de axioma's en stellingen van de VMT (A1, A2, A4-A7, A12, A13, T2, T4, T5, T9, T14-T16) en uit de rollen en domeinbeleidsregels van Æilus. Een hypothetisch uitgewerkt voorbeeld illustreert het protocol.
Beperkingen. Er zijn geen empirische gegevens gebruikt en er bestaan er geen in de bronnen. De coëfficiënten per lijn zijn voorstellen van de bron, de formules zijn de lezing van de verbale definities door dit artikel, en Æ-schattingen zijn afhankelijk van interpretatie. Validatie vereist een pilot die een consistente Æ-schatting laat zien, cohort-ACM geordend per lijn zoals voorspeld, door de klant bevestigde gerealiseerde waarde, een dalende instroom van anti-waarde zonder manipulatie, en extra informatie ten opzichte van conventionele ondersteuningsmaten.
Materiaal / gegevens
Gebaseerd op het artikel van aeilus.tech "Technical Support Service - Anti-Value Conversion" (2025), de methodologiepagina's van Æilus over domeinen en beleid en over rollen, en de axioma's en stellingen van de VMT zoals samengevat in de referentienotities van de auteur over VMT en Æilus. Er zijn geen datasets gebruikt.
Deel 3 van 8 in de ÆVRI-serie "Æilus for Business".
Volledige tekst
1 Inleiding
In de meeste productorganisaties wordt technische ondersteuning als kostenplaats geboekt. Het budget is zichtbaar, de output wordt geteld in afgesloten tickets en de gebruikelijke vraag is hoe het goedkoper kan. Dit artikel betoogt dat deze framing onvolledig is en dat wat zij weglaat precies het deel van de ondersteuning is dat het belangrijkst is voor het product.
Het betoog gebruikt de terminologie van de Theorie van Waardemanagement (VMT) en de Æilus-methodologie. Waarde, anti-waarde, waardestroom, waardesysteem, waardetransformator en geplande, gerealiseerde en retrospectieve waarde worden gebruikt zoals gedefinieerd in het eerste artikel van deze reeks. De formele behandeling van Æ, de waardevaluta, is te vinden in Bolshakov (2026) en wordt hier niet herhaald.
De belangrijkste bron is het Æilus-artikel "Technical Support Service - Anti-Value Conversion" (Bolshakov, 2025). Het beschrijft ondersteuning als een keten van waardetransformatoren die anti-waarde van de klant ontvangen en omzetten in waarde, met coëfficiënten die op elke lijn groter worden, en stelt twee coëfficiënten voor die in elke fase gemeten moeten worden. Dit artikel geeft het model opnieuw weer, maakt de coëfficiënten operationeel, benoemt wiens waarde zij meten en stelt een meetprotocol voor. Het bevat geen veldgegevens; alle getallen in het uitgewerkte voorbeeld zijn illustratief.
Het artikel steunt op de VMT-axioma's A1 (contextualiteit), A2 (meervoudige interpretaties), A4 (asymmetrie van plan en feit), A5 (onafhankelijkheid van anti-waarde), A6 (realisatie bij consumptie), A7 (transformatie), A12 (geen behoud van waarde) en A13 (gedeeltelijke commensurabiliteit), en op de stellingen T2 (omkering van stromen), T4 (accumulatie van weerstand), T5 (lokale optimalisatie), T9 (verborgen stromen), T14 (niet-geïnterpreteerde waarde gaat verloren), T15 (grensafhankelijkheid) en T16 (schaling door interpretatie zonder realisatie).
2 Waarom ondersteuning als kostenplaats wordt behandeld en wat dat verbergt
2.1 De kostenblik is een grenskeuze
De kostenplaatsblik is het gevolg van het trekken van de grens van het waardesysteem rond de financiële stromen van het bedrijf. Binnen die grens verbruikt ondersteuning salarissen en tools en levert zij geen omzetregel op. Volgens A1 bestaat waarde alleen binnen een waardesysteem, en volgens T15 verandert een andere grens de conclusie zonder de werkelijkheid te veranderen. De kostenblik is een juiste lezing van één waardesysteem, geen beschrijving van wat ondersteuning doet.
T2 stelt dat één stroom in verschillende systemen tegengestelde interpretaties kan dragen. Een ondersteuningscontact dat door het bedrijf als kosten wordt geboekt, is voor de klant het wegnemen van anti-waarde: een storing die ophoudt pijn te doen, een vraag die het werk niet langer blokkeert. De bron noemt tien soorten klantwaarde die ondersteuning levert, van vermindering van de anti-waarde van incidenten en tijdsbesparing tot risicovermindering en vertrouwen. Geen daarvan komt voor in een kostenrapport.
2.2 Wat de kostenblik verbergt
- Waarde aan de klantzijde. Ondersteuning herstelt de waardestroom van de klant. Als zij dat niet meer doet, komt de deelnamevoorwaarde (A8) van de klant in gevaar, en T7 voorspelt dat de klant vertrekt of de vorm van deelname wijzigt.
- Interne waarde. De bron noemt drie interne stromen: informatie over incidenten, verzoeken om functies die concurrenten hebben en oorspronkelijke suggesties van klanten. Volgens T9 is een structuur die in stand wordt gehouden door stromen die het model niet toont, verkeerd gemodelleerd of slecht begrensd. Een kostenmodel van ondersteuning is zo'n model.
- Conversie. De bron stelt dat ondersteuning anti-waarde omzet in waarde en dat het resultaat de oorspronkelijke anti-waarde met ordes van grootte kan overtreffen wanneer een kwestie diepere lijnen en het product bereikt. A12 staat dit toe: één opgeloste grondoorzaak neemt de anti-waarde weg voor elke klant, niet alleen voor degene die het meldde.
3 Ondersteuning als instappunt van de anti-waardestroom
Elk product levert zowel waarde als anti-waarde. Volgens A5 is anti-waarde een onafhankelijke categorie: een klant kan echte waarde van een product ontvangen en in dezelfde week echte anti-waarde van een storing. Ondersteuning is de plek waar het grootste deel van die anti-waarde het bedrijf binnenkomt als waarneembare stroom. Dit artikel groepeert haar in vier soorten, in overeenstemming met de beschrijving van de intake op de eerste lijn in de bron:
- Incidenten. Iets werkte en is gestopt met werken.
- Defecten. Iets werkte nooit zoals bedoeld; de anti-waarde wordt zichtbaar wanneer een klant ermee in aanraking komt.
- Verwarring. Het product werkt, maar de klant kan er geen waarde uit halen.
- Beschaamde verwachtingen. Geplande en gerealiseerde waarde verschillen. A4 stelt dat dit normaal is; ondersteuning is waar de kloof wordt gemeld.
Een vijfde invoer is potentiële waarde: verzoeken en suggesties. De bron behandelt die apart en beschrijft het volume ervan als onbeperkt. Zij deelt hetzelfde kanaal, dus de meting moet haar gescheiden houden van anti-waarde om te voorkomen dat twee noemers door elkaar worden gehaald.
Het instappunt is van belang vanwege T4: weerstand accumuleert. Anti-waarde die in een wachtrij blijft liggen, groeit uit tot verlies van vertrouwen en, volgens T6, tot een verminderd vermogen om toekomstige waarde te realiseren. De dynamiek van wachtrijen in productontwikkeling is goed beschreven (Reinertsen, 2009); de VMT-lezing voegt eraan toe dat wat in een ondersteuningswachtrij wacht, zich opstapelende anti-waarde in het waardesysteem van de klant is.
4 De conversieketen
Volgens A7 betekent transformatie dat een actor binnenkomende waarde realiseert, of hier binnenkomende anti-waarde absorbeert, en nieuwe geplande waarde voortbrengt. De bron behandelt elke ondersteuningslijn als zo'n transformator, elk met een eigen Eigenaar Waardetransformator (VTO).
4.1 Eerste lijn
De bron wijst aan de eerste lijn toe: de intake van de anti-waardestroom in gestructureerde tickets, snelle demping van anti-waarde bij het eerste contact, het in stand houden van de ononderbroken waardestroom, routering, gegevensverzameling, het beheren van klantverwachtingen en het beoordelen van de diepte van de anti-waarde. Haar rol is die van filter, schokdemper en versneller. Meestal herstelt zij de eerdere toestand van de klant, en daarom kent de bron haar de laagste coëfficiënt toe. Het beheren van verwachtingen verdient aandacht: statusupdates lossen niets op, maar verminderen wel de anti-waarde van onzekerheid, een direct geval van A5.
4.2 Tweede lijn
De tweede lijn neemt complexe anti-waarde op zich: lastige bugs, integraties, prestaties. De belangrijkste verschuiving in de bron is die van het onderdrukken van een probleem naar het wegnemen van de grondoorzaak, en van één klant naar alle klanten, aangezien oplossingen en bijgewerkte instructies zich door het klantenbestand verspreiden. De tweede lijn bouwt ook de kennisbank op die de capaciteit van de eerste lijn vergroot, voert terugkerende incidenten naar de backlog en vermindert verborgen anti-waarde zoals technische schuld.
4.3 Derde lijn
De bron noemt de derde lijn een transformator op strategisch niveau die werkt aan anti-waarde die is geworteld in architectuur, code, protocollen en kernlogica. Haar output bestaat uit wijzigingen in functionaliteit en architectuur, en uit nieuwe transformatoren: tools, scripts, monitoring en geautomatiseerde controles die anti-waarde blijven omzetten. Zij stelt ook de regels voor de lagere lijnen vast, waaronder hoe waarde en anti-waarde in complexe gevallen worden gemeten. De bron merkt op dat de toename moeilijk te kwantificeren is totdat wijzigingen de klant bereiken, wat A6 in operationele termen is.
4.4 Product Owner
De bron plaatst het Product Owner-team als de volgende transformator en als waardesynthesizer. Het prioriteert de stroom van alle lijnen, stemt die af op de strategie, beoordeelt waar de klantwaarde het hoogst is bij de laagste anti-waarde in kosten, tijd en risico, en voegt potentiële waarde uit marktbehoeften toe. De output is een leveringsplan dat bestaande waarde schaalt en nieuwe waarde creëert. De bron koppelt dit aan PDCA: Plan op basis van ondersteuningsgegevens, Do door leveringsteams, Check op incidenten en waardemetrieken, Act op strategie en product. Het bijgewerkte product levert vervolgens opnieuw waarde, de ondersteuning vangt de volgende stroom op en de cirkel is rond.
5 De in de bron voorgestelde coëfficiënten
5.1 Nominale coëfficiënten per lijn
De samenvatting van de gesloten kring in de bron stelt dat anti-waarde die op de eerste lijn is opgevangen, kan worden omgezet in waarde met een coëfficiënt van x1 tot x1,5; op de tweede lijn x10; op de derde lijn x100. Suggesties van klanten gaan naar de tweede en derde lijn met een volume dat als onbeperkt wordt beschreven, en de waarde die de Product Owner aan de klant teruggeeft, wordt beschreven als potentieel vrijwel onbeperkt. Het patroon: hoe groter het probleem, hoe hoger de lijn die het bereikt, en hoe hoger de lijn, hoe hoger de coëfficiënt. De bron biedt deze aan als ordes van grootte, niet als metingen. Dit artikel behandelt ze als hypothesen.
5.2 VAM en ACM
De bron concludeert dat in elke fase twee parameters gemeten moeten worden:
- Value Amplification Multiplier (VAM), de waardeoverdrachtscoëfficiënt: "Hoeveel waarde is ontvangen en aan de klant geleverd".
- Anti-Value Conversion Multiplier (ACM), de conversiecoëfficiënt van anti-waarde naar waarde: hoeveel anti-waarde is ontvangen en hoeveel daarvan is omgezet in waarde voor de klant.
De bron formuleert deze in woorden en geeft geen formules. De hier voorgestelde minimale ratio-interpretatie, voor een fase s (eerstelijns, tweedelijns, derdelijns, Product Owner) over een beoordelingsperiode, is:
VAM_s = V_delivered,s / V_received,s
ACM_s = V_converted,s / AV_received,s
V_received,s is de waarde die de fase binnenkomt (suggesties of gedeeltelijk getransformeerde potentiële waarde); V_delivered,s is de gerealiseerde klantwaarde die aan de output van de fase kan worden toegeschreven; AV_received,s is de anti-waarde die de fase binnenkomt; V_converted,s is de gerealiseerde klantwaarde die daaruit is voortgebracht. Alle termen zijn in Æ.
Uit de bewoordingen van de bron volgen twee lezingen. De tellers zijn waarde voor de klant, dus plannen, tickets en backlog-items tellen pas mee zodra de klant ze heeft gerealiseerd (A6). En de twee coëfficiënten hebben verschillende noemers: de ene volgt de versterking van waarde, de andere de conversie van anti-waarde. Een coëfficiënt op ketenniveau is ACM_chain = sum of V_converted,s / AV_received,1, met de anti-waarde bij binnenkomst als noemer en waarbij elke eenheid gerealiseerde waarde aan slechts één fase wordt toegeschreven.
6 Wiens waarde wordt gemeten
Onder A1 en A2 is een coëfficiënt zonder benoemd waardesysteem zinloos. De keten raakt vier waardesystemen:
| Waardesysteem | Interpretator | Wat een ondersteuningsgebeurtenis daar betekent |
|---|---|---|
| Klant | De klant | Anti-waarde weggenomen, tijd bespaard, risico verminderd, vermogen verworven |
| Ondersteuningslijnen | De VTO van elke lijn | Anti-waarde ontvangen, inspanning geleverd, output doorgegeven |
| Product | Product-VTO | Stroom van potentiële waarde; wijzigingen in backlog en roadmap |
| Bedrijf | Value System Owner (VSO) | Ondersteuningskosten afgewogen tegen retentie, groei en productverbetering |
Dit artikel legt de meting als volgt vast. De tellers van VAM en ACM worden gemeten in het waardesysteem van de klant, omdat gerealiseerde waarde de interpretatie van de ontvanger is. De noemers worden gemeten op de grens tussen klant en ondersteuning: anti-waarde zoals de klant die ervaart en meldt, vastgelegd door de eerstelijns. De ondersteunings- en productsystemen gebruiken de coëfficiënten; het bedrijfssysteem weegt ze af tegen de kosten. De VSO is eigenaar van het aggregatiebeleid om deze lezingen te vergelijken, die slechts gedeeltelijk onderling meetbaar zijn (A13). Als de ondersteuning zichzelf zou meten vanuit het eigen waardesysteem, zou zij inspanning en geplande waarde rapporteren. De definities van de bron wijzen naar buiten, en het protocol houdt ze daar.
7 Een meetprotocol
Het onderstaande protocol is een voorstel, niet getest in de praktijk, ontworpen om te werken met bestaande ticketing- en backlogtools.
7.1 Vast te leggen gegevens
- Bij binnenkomst: de klant en het productgebruik; het soort invoer (incident, defect, verwarring, onbeantwoorde verwachting, suggestie); een schatting van de anti-waarde in Æ op een gedeelde schaal, waar mogelijk bevestigd met de klant; betrokken domeinen.
- Bij elke overdracht: de ontvangende fase en de reden; het type oplossing (toestand hersteld, opgelost voor deze klant, grondoorzaak weggenomen, nieuwe transformator gecreëerd, backlog-item aangemaakt); koppelingen van tickets naar backlog-items en releases; geplande waarde van voorgestelde wijzigingen, gescheiden gehouden van gerealiseerde waarde.
- Na oplevering: gerealiseerde waarde in Æ, bevestigd door de klant of een overeengekomen proxy; aantal bereikte klanten; een latere retrospectieve herwaardering.
7.2 Wie de gerealiseerde waarde valideert
De transformator die de eer opeist, valideert niet zelf zijn gerealiseerde waarde. De klant interpreteert die, via expliciete bevestiging of vooraf overeengekomen proxy's (het incident keert niet terug, de functie wordt gebruikt). De VTO van elke lijn stelt schattingen voor en is eigenaar van de kwaliteit van het logboek. De Product-VTO bevestigt welke geleverde wijzigingen herleidbaar zijn tot welke ondersteuningsinput. De VSO beslecht geschillen over toerekening. Geplande waarde wordt vastgelegd maar komt nooit in een teller, conform A4 en T16: een waardeclaim opschalen op basis van interpretatie alleen is structureel onstabiel. De x100 van de bron voor de derdelijns is zo'n claim totdat de wijziging de klanten bereikt.
7.3 Beoordelingsritme
- Per ticket, bij afsluiting: schatting bij binnenkomst, type oplossing, gerealiseerde waarde van de eerstelijns.
- Per lijn, op een korte vaste cyclus: ACM en VAM voor afgeronde items, leeftijd van openstaande anti-waarde in wachtrijen (T4), redenen voor escalatie.
- Per systeem, op een langere cyclus: de VSO en de Product-VTO beoordelen geleverde wijzigingen, retrospectieve herwaarderingen, de totale instroom van anti-waarde, en of de coëfficiënten per lijn de volgorde volgen die de bron voorspelt.
Omdat realisatie vertraagd optreedt, moeten coëfficiënten per cohort worden gerapporteerd, namelijk de periode waarin de anti-waarde is ontvangen.
7.4 Valkuilen
Goodhart (1975) merkte op dat een statistische regelmaat de neiging heeft in te storten zodra ze voor sturing wordt gebruikt. In VMT-termen is dit T5: lokale optimalisatie garandeert geen globale verbetering.
- Ticketaantallen manipuleren. Een probleem opsplitsen in meerdere tickets blaast de doorvoer op. VAM en ACM zijn Æ-ratio's, geen aantallen, maar het aantal tickets mag niet naast ze als doel worden gesteld.
- Instroom deflateren. Het onderschatten van anti-waarde verhoogt ACM. Schattingen bij binnenkomst hebben een gedeelde schaal en steekproefsgewijze klantbevestiging nodig.
- Overmatige escalatie. Als hogere lijnen hogere coëfficiënten laten zien, is escalatie verleidelijk. Ze moet worden beoordeeld aan de hand van de escalatieregels die de derdelijns hanteert.
- Dubbeltelling. Dezelfde gerealiseerde waarde kan door meerdere fasen worden opgeëist. Elke eenheid wordt één keer toegewezen.
- Instroom verbergen. Het beste resultaat is minder anti-waarde die de ondersteuning bereikt, wat ACM niet kan zien. De totale instroom moet naast de coëfficiënten worden gerapporteerd, en een daling moet als resultaat worden gelezen.
- Signalen laten vallen. Onder T14 gaat waarde zonder interpretatie verloren. Het logboek moet laten zien hoeveel suggesties en patronen tot een productbeslissing hebben geleid.
8 Relatie met servicedomeinen
De Æilus-methodologie definieert een domein als een waarde-interpretatiecontext die eisen stelt aan toelaatbare praktijken en uitkomsten. Domeinen creëren geen waarde; ze voorkomen niet-toelaatbare anti-waarde. De ondersteuning raakt meerdere typische domeinen:
- Beschikbaarheid en Continuïteit. Een incident is voor de klant een schending van deze context. De plicht van de eerstelijns om een continue waardestroom te handhaven is de operationele kant ervan, en routering moet het domeinbeleid voor kritiekheid volgen.
- Beveiliging. De methodologie merkt op dat waarde kan worden afgewezen omdat ze de context schendt die nodig is voor veilige deelname. Een workaround die de beveiliging verzwakt, wordt vastgelegd als nieuwe anti-waarde, niet als conversie.
- Architectuur. De bron vereist dat beslissingen van de derdelijns worden gecontroleerd op architectonische integriteit, schaalbaarheid, prestaties en beveiliging.
- Kennismanagement en Continue verbetering. De kennisbank van de tweedelijns en de PDCA-cyclus zijn praktijken in deze domeinen.
Hieruit volgen twee consequenties. Gerealiseerde waarde die in ACM wordt meegeteld, moet toelaatbaar zijn in elk relevant domein. En ACM aggregeert waarde over gedeeltelijk onderling meetbare domeinen (A13), dus het heeft het expliciete aggregatiebeleid nodig dat de methodologie aan de VSO toewijst, waarbij het domeinbeleid in handen is van de Domain Owners. Zonder dat, waarschuwt de methodologie, ontaardt optimalisatie in lokale voorkeur of het manipuleren van metrieken.
9 Illustratief uitgewerkt voorbeeld
Dit voorbeeld is hypothetisch. Het product, de klanten en de getallen zijn verzonnen en bewust rond gekozen. Het zijn geen bevindingen en ze toetsen de coëfficiënten van de bron niet.
Een product heeft een terugkerende storing in een integratie voor gegevensimport. In één periode melden tien klanten dit.
- Intake. De anti-waarde (anti-value) van elke klant wordt geschat op 10 Æ, dus
AV_received,1 = 100 Æ. - Eerste lijn. Een bekende work-around en statusupdates herstellen het werk; klanten bevestigen 120 Æ gerealiseerde waarde.
ACM_1 = 120 / 100 = 1.2, binnen het nominale bereik van de bron. - Tweede lijn. Er wordt een grondoorzaak in de configuratie gevonden; een gecorrigeerde standaardwaarde en een artikel in de kennisbank bereiken de meldende klanten en anderen. Bevestigde gerealiseerde waarde: 400 Æ.
ACM_2 = 400 / 100 = 4, onder de nominale x10. In het protocol is dit een resultaat om te onderzoeken, geen fout die gecorrigeerd moet worden. - Derde lijn en product. Het importprotocol blijkt fragiel te zijn; een herontwerp en een geautomatiseerde controle komen op de roadmap met een geplande waarde van 5.000 Æ. Er is nog niets opgeleverd, dus
ACM_3 = 0voor dit cohort. De 5.000 Æ wordt vastgelegd en uitgesloten. - Suggesties. Twee klanten vragen om geplande imports. Dit is potentiële waarde op het VAM-spoor en telt niet mee in ACM.
Bij deze review is ACM_chain = (120 + 400 + 0) / 100 = 5.2. Als het herontwerp later wordt opgeleverd en klanten waarde bevestigen, wordt het cohort van de derde lijn met terugwerkende kracht bijgewerkt; als het een regressie veroorzaakt, wordt die anti-waarde ten laste van de derde lijn geboekt. Het voorbeeld laat zien wat een pilot moet observeren: het verschil tussen plan en feit in het diepste stadium (A4, A6), de vertraging in realisatie en mogelijke afwijking van de nominale coëfficiënten.
10 Beperkingen
Er zijn hier noch in de bron veldgegevens. De coëfficiënten x1 tot x1,5, x10 en x100 zijn voorgestelde ordegroottes, aannemelijk op basis van het beschreven mechanisme (één oplossing opgeschaald naar veel klanten, nieuwe transformators gecreëerd) maar niet gemeten. De formules zijn de lezing van dit artikel van verbale definities; andere lezingen zijn mogelijk. Schattingen in Æ hangen af van interpretatie, wat onder A2 een eigenschap van waarde is, maar vergelijking tussen teams vereist toch een gekalibreerde gedeelde schaal die dit artikel niet biedt. Toerekening over de stadia heen wordt zonder regel aan de VSO toegewezen.
Een pilot die het model zou kunnen ondersteunen of verzwakken, zou moeten aantonen:
- dat verschillende mensen consistente schattingen in Æ maken voor dezelfde tickets;
- dat het ACM van een cohort over meerdere reviewcycli de voorspelde volgorde per lijn volgt, ongeacht de absolute waarden;
- dat gerealiseerde waarde is bevestigd door klanten of overeengekomen proxy's, niet door de claimende lijnen;
- dat het gebruik van de coëfficiënten werd gevolgd door een lagere totale instroom van anti-waarde, zonder de manipulatie die in sectie 7.4 wordt genoemd;
- dat de coëfficiënten informatie toevoegen bovenop conventionele maten zoals de tijd tot herstel van de dienst (Forsgren, Humble en Kim, 2018).
11 Conclusie
Support alleen als kostenpost beschouwen is een keuze van afbakening. In het financiële systeem van het bedrijf is support een kostenpost; in het systeem van de klant is het het wegnemen van anti-waarde; in het systeem van het product is het de meest directe informatie over waar het product tekortschiet. Het bronmodel beschrijft een keten van transformators waarvan de hefboomwerking groeit van de eerste lijn naar de derde lijn en naar het Product Owner-team, waarmee een PDCA-lus terug naar de klant wordt gesloten, en stelt VAM en ACM voor om dit te meten. Dit artikel heeft de coëfficiënten minimale formules gegeven, hun tellers verankerd in het waardesysteem van de klant, alleen gerealiseerde en voor het domein toelaatbare waarde meegeteld, en een protocol voorgesteld voor registratie, validatie, review en bescherming tegen manipulatie. Of de ordegroottes uit de bron standhouden, is een vraag die alleen een pilot kan beantwoorden.
Referenties
- 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.
Dit werk citeren
Bolshakov, V. (2026). From Cost Centre to Value Converter: Anti-Value Conversion in Technical Support. Aeilus Value Research Institute (ÆVRI). https://aeilus.institute/research/anti-value-conversion-in-technical-support/
Hoe waardevol was dit voor u?
Uw leestijd telt als uw evaluatie. Inloggen om zelf een reactie te kiezen.
Hoe waarde wordt geëvalueerd
Reactie toevoegen
Inloggen om een reactie achter te laten.