跳到正文
ÆVRI,Aeilus Value Research Institute

方法论论文 · DevOps

从成本中心到价值转换器:技术支持中的反价值转换

机器翻译。原文语言:英语。 阅读原文

价值简述

技术支持通常被当作成本中心来管理,这掩盖了它为客户和产品所创造的价值。本文将 Æilus 的支持模型重新表述为一条把反价值转化为价值的转换器链,为来源中的两个系数(VAM 和 ACM)给出最简公式,确定它们衡量的是谁的价值,并提出一套支持组织可以采用的测量协议。

主要发现及其价值

  • 成本视角是一种边界选择。支持在公司的财务价值系统内是成本,在客户的价值系统内则是反价值的消除 (A1, T2, T15)。价值:领导者在削减支持预算之前,可以看清这一削减实际上消除了什么。
  • 支持是反价值流的入口。事件、缺陷、困惑和落空的期望都从这里进入,无人处理的队列会累积反价值 (A5, T4)。价值:队列时长成为价值信号,而不仅仅是服务水平。
  • VAM 和 ACM 需要一个明确指定的价值系统。本文将它们的分子衡量为客户价值系统中已实现的价值,并且仅在交付之后才计入计划价值 (A4, A6, T16)。价值:系数不会被路线图承诺夸大。
  • 来源的系数是假设。每条线名义上的 x1-1.5、x10 和 x100 是需要按队列检验的数量级,而不是结果。价值:试点有一个清晰、可证伪的预测可供检验。
  • 领域决定什么算作转化。违反可用性、安全或架构策略的解决方案是新的反价值,跨领域的聚合需要明确的 VSO 策略 (A13)。价值:保护该度量免受局部优化和 Goodhart 效应的影响。

研究是如何开展的

概念分析与方法论设计。Æilus 关于技术支持的文章用 VMT 术语重新表述,其对 VAM 和 ACM 的文字定义被赋予最简比率公式,并根据 VMT 公理和定理(A1、A2、A4-A7、A12、A13、T2、T4、T5、T9、T14-T16)以及 Æilus 的角色和领域政策推导出一套测量协议。一个假设的演算示例说明了该协议。

局限。未使用任何实证数据,来源中也不存在此类数据。各线路系数是来源的提议,公式是本文对文字定义的解读,Æ 估计取决于解释。验证需要一项试点,显示出一致的 Æ 估计、按线路顺序排列且符合预测的队列 ACM、客户确认的已实现价值、无操纵的反价值流入下降,以及相对于传统支持指标的额外信息。

材料/数据

基于 aeilus.tech 的文章 "Technical Support Service - Anti-Value Conversion"(2025)、Æilus 方法论中关于领域与政策以及关于角色的页面,以及作者的 VMT 与 Æilus 参考笔记中概述的 VMT 公理和定理。未使用任何数据集。

ÆVRI 系列 "Æilus for Business" 第 3 篇,共 8 篇。

全文

1 引言

在大多数产品型组织中,技术支持被记作成本中心。其预算清晰可见,其产出以已关闭的工单数量来计算,通常的问题是如何让它变得更便宜。本文认为,这种框架并不完整,而它所遗漏的,恰恰是支持工作中对产品最为重要的部分。

本论证使用价值管理理论(Theory of Value Management,VMT)和 Æilus 方法论的术语。价值、反价值、价值流、价值系统、价值变换器,以及计划价值、实现价值和回溯价值,均按本系列第一篇论文中的定义使用。关于价值货币 Æ 的形式化论述见 Bolshakov (2026),此处不再重复。

主要来源是 Æilus 文章 "Technical Support Service - Anti-Value Conversion" (Bolshakov, 2025)。该文将支持描述为一条价值变换器链:这些变换器接收来自客户的反价值并将其转换为价值,转换系数随每一线逐级增大,并提出应在每个阶段测量两个系数。本文重新陈述该模型,使这些系数可操作化,说明它们衡量的是谁的价值,并提出一套测量协议。本文不包含现场数据;工作示例中的所有数字均仅作示意。

本文依赖 VMT 公理 A1(情境性)、A2(多重解释)、A4(计划与事实的不对称)、A5(反价值的独立性)、A6(消费时实现)、A7(变换)、A12(价值不守恒)和 A13(部分可通约性),以及定理 T2(流的反转)、T4(阻力的累积)、T5(局部优化)、T9(隐藏流)、T14(未被解释的价值会丢失)、T15(边界依赖)和 T16(未经实现的解释式扩展)。

2 为什么支持被视为成本中心,以及这掩盖了什么

2.1 成本视角是一种边界选择

成本中心视角源于将价值系统的边界划在公司的财务流周围。在该边界之内,支持消耗薪资和工具,而不产生收入条目。根据 A1,价值只存在于价值系统之内;根据 T15,改变边界会改变结论,却不会改变现实。成本视角是对某一个价值系统的正确解读,而不是对支持所做之事的描述。

T2 指出,同一个流在不同系统中可以承载相反的解释。一次支持互动,在公司看来记作成本,而对客户而言则是反价值的消除:一个不再造成损害的故障,一个不再阻碍工作的问题。来源文章列出了支持所交付的十类客户价值,从事件反价值的减少和时间节省,到风险降低和信任。这些在成本报告中一项也没有出现。

2.2 成本视角所掩盖的内容

  • 客户侧价值。支持恢复客户的价值流。如果它不再这样做,客户的参与条件(A8)就会面临风险,而 T7 预测客户将离开或改变参与形式。
  • 内部价值。来源文章指出了三种内部流:事件信息、对竞争对手已有功能的需求,以及客户的原创建议。根据 T9,一个由模型未显示的流所维系的结构,要么被错误建模,要么边界划分不当。支持的成本模型正是这样一种模型。
  • 转换。来源文章主张,支持将反价值转换为价值,并且当问题触及更深的层级和产品本身时,结果可以超出原始反价值若干个数量级。A12 允许这一点:一个被修复的根本原因会为每一位客户消除反价值,而不仅仅是报告者。

3 支持作为反价值流的入口

每个产品既交付价值,也交付反价值。根据 A5,反价值是一个独立的范畴:客户可以从产品中获得真实的价值,并在同一周内因一次停机而承受真实的反价值。支持是大部分此类反价值作为可观察的流进入公司的地方。本文将其分为四类,与来源文章对第一线受理的描述一致:

  • 事件。某物原本正常运行,后来停止运行。
  • 缺陷。某物从未按预期运行;当客户遇到它时,反价值才变得可见。
  • 困惑。产品可以运行,但客户无法从中获得价值。
  • 落空的期望。计划价值与实现价值不一致。A4 指出这是正常的;支持正是报告这一差距的地方。

第五类输入是潜在价值:需求和建议。来源文章对其单独处理,并将其数量描述为不受限制。它与前述反价值共用同一渠道,因此测量时必须将二者区分开,以避免混用两个分母。

入口之所以重要,是因为 T4:阻力会累积。滞留在队列中的反价值会不断叠加,演变为信任的丧失,并根据 T6,演变为实现未来价值的能力下降。产品开发中的队列动态已有充分论述 (Reinertsen, 2009);VMT 的解读则补充指出,在支持队列中等待的,是客户价值系统中不断累积的反价值。

4 转换链

根据 A7,变换意味着一个行动者实现传入的价值,或在此处吸收传入的反价值,并产生新的计划价值。来源文章将每一条支持线视为这样的变换器,各自拥有自己的价值变换器负责人(Value Transformer Owner,VTO)。

4.1 第一线

来源文章赋予第一线的职责包括:将反价值流受理为结构化工单,在首次接触时迅速抑制反价值,维持持续的价值流,路由,数据收集,管理客户期望,以及评估反价值的深度。其角色是过滤器、减震器和加速器。它主要是恢复客户先前的状态,这也是来源文章赋予它最低系数的原因。管理期望值得一提:状态更新并不修复任何问题,却能减少不确定性带来的反价值,这是 A5 的直接例证。

4.2 第二线

第二线处理复杂的反价值:疑难缺陷、集成、性能。来源文章的关键转变是从抑制问题转向消除其根本原因,从服务一位客户转向服务所有客户,因为修复和更新后的说明会在整个客户群中传播。第二线还构建知识库以提升第一线的能力,将反复出现的事件送入待办列表,并减少技术债务等隐藏的反价值。

4.3 第三线

来源文章称第三线为战略层面的变换器,处理根植于架构、代码、协议和核心逻辑的反价值。其产出是对功能和架构的变更,以及新的变换器:持续转换反价值的工具、脚本、监控和自动化检查。它还为下层各线制定规则,包括在复杂情况下如何测量价值和反价值。来源文章指出,在变更触达客户之前,提升幅度难以量化,这就是 A6 在操作层面的体现。

4.4 产品负责人

来源文章将产品负责人(Product Owner)团队置于下一个变换器的位置,并视其为价值合成者。它对来自所有各线的流进行优先级排序,使其与战略保持一致,评估在成本、时间和风险方面反价值最低而客户价值最高之处,并加入来自市场需求的潜在价值。其产出是一份交付计划,既扩展现有价值,又创造新价值。来源文章将此与 PDCA 联系起来:Plan 基于支持数据,Do 由交付团队执行,Check 针对事件和价值指标,Act 作用于战略和产品。更新后的产品再次交付价值,支持捕获下一个流,闭环由此形成。

5 来源文章提出的系数

5.1 各线的名义系数

来源文章对闭环的总结指出,在第一线捕获的反价值可以按 x1 至 x1.5 的系数转换为价值;在第二线为 x10;在第三线为 x100。客户建议传递至第二线和第三线,其数量被描述为不受限制,而产品负责人返还给客户的价值被描述为潜在地几乎无限。其规律是:问题越大,所到达的线越高,线越高,系数越高。来源文章将这些作为数量级给出,而非测量值。本文将其视为假设。

5.2 VAM 与 ACM

来源文章得出结论,必须在每个阶段测量两个参数:

  • 价值放大乘数(Value Amplification Multiplier,VAM),即价值传递系数:"已向客户接收并交付了多少价值"。
  • 反价值转化乘数(Anti-Value Conversion Multiplier,ACM),即反价值向价值的转化系数:接收了多少反价值,其中又有多少被转化为客户的价值。

原始文献以文字形式陈述了这些系数,并未给出公式。针对某一阶段 s(一线、二线、三线、Product Owner)在某一评审周期内,此处提出的最简比率解读如下:

VAM_s = V_delivered,s / V_received,s

ACM_s = V_converted,s / AV_received,s

V_received,s 是进入该阶段的价值(建议或部分转化的潜在价值);V_delivered,s 是可归因于该阶段产出的已实现客户价值;AV_received,s 是进入该阶段的反价值;V_converted,s 是由其产生的已实现客户价值。所有项均以 Æ 为单位。

从原始文献的措辞可得出两点解读。第一,分子是客户的价值,因此计划、工单和待办事项只有在客户实现后才计入(A6)。第二,这两个系数的分母不同:一个追踪价值的放大,另一个追踪反价值的转化。链条层面的系数为 ACM_chain = sum of V_converted,s / AV_received,1,以接入时的反价值为分母,且每个单位的已实现价值只归属于一个阶段。

6 衡量谁的价值

根据 A1 和 A2,未指明价值系统的系数毫无意义。该链条涉及四个价值系统:

价值系统解释者支持事件在其中的含义
客户客户消除的反价值、节省的时间、降低的风险、获得的能力
支持线各线的 VTO接收的反价值、投入的精力、向下传递的产出
产品产品 VTO潜在价值流;待办事项和路线图的变更
公司价值系统所有者(Value System Owner,VSO)支持成本与客户留存、增长和产品改进之间的权衡

本文对衡量方式作如下规定。VAM 和 ACM 的分子在客户的价值系统中衡量,因为已实现的价值是接收方的解释。分母在客户与支持的边界处衡量:即客户所体验并报告的反价值,由一线记录。支持系统和产品系统使用这些系数;公司系统则将其与成本进行权衡。VSO 负责制定用于比较这些读数的汇总策略(policy),因为这些读数仅部分可通约(A13)。如果支持部门从自身的价值系统进行衡量,它报告的将是投入的精力和计划价值。原始文献的定义是指向外部的,而本协议使其保持这一指向。

7 衡量协议

以下协议是一项提案,尚未经过实地检验,其设计目的是配合现有的工单和待办事项工具使用。

7.1 需记录的数据

  • 接入时:客户及产品使用情况;输入类型(事故、缺陷、困惑、落空的期望、建议);在共享尺度上以 Æ 表示的反价值估计,可能时与客户确认;受影响的领域。
  • 每次移交时:接收阶段及原因;解决类型(状态已恢复、已针对该客户修复、已消除根本原因、已创建新的转换器、已提出待办事项);工单与待办事项及发布版本之间的链接;所提议变更的计划价值,与已实现价值分开保存。
  • 交付后:由客户或约定的替代指标确认的以 Æ 表示的已实现价值;所触达的客户数量;后续的回顾性重新评估。

7.2 谁来验证已实现价值

声称功劳的转换器不得验证其自身的已实现价值。由客户通过明确确认或事先约定的替代指标(事故不再复发、功能被使用)来解释。各线的 VTO 提出估计并负责日志质量。产品 VTO 确认哪些已交付的变更可追溯到哪些支持输入。VSO 裁定归属争议。计划价值会被记录,但绝不进入分子,依据 A4 和 T16:仅凭解释来放大价值主张在结构上是不稳定的。在变更触达客户之前,原始文献中三线的 x100 就属于这样的主张。

7.3 评审节奏

  • 每张工单,在关闭时:接入估计、解决类型、一线的已实现价值。
  • 每条支持线,以较短的固定周期:已完成事项的 ACM 和 VAM、队列中未处理反价值的滞留时间(T4)、升级原因。
  • 每个系统,以较长的周期:VSO 和产品 VTO 评审已交付的变更、回顾性重新评估、反价值总流入量,以及各线系数是否遵循原始文献所预测的顺序。

由于价值的实现存在滞后,系数应按队列(cohort)报告,即按接收反价值的时期划分。

7.4 陷阱

Goodhart (1975) 观察到,一旦将某种统计规律用于控制,它往往就会失效。用 VMT 的话来说,这就是 T5:局部优化并不保证全局改进。

  • 操纵工单数量。将一个问题拆分为多张工单会虚增吞吐量。VAM 和 ACM 是 Æ 的比率,而非计数,但不应在它们之外再把工单数量设为目标。
  • 压低接入量。低估反价值会抬高 ACM。接入估计需要共享尺度和抽样的客户确认。
  • 过度升级。如果更高的支持线显示出更高的系数,升级就会变得诱人。应依据三线制定的升级规则来加以判断。
  • 重复计算。同一已实现价值可能被多个阶段同时主张。每个单位只分配一次。
  • 隐藏流入量。最佳结果是到达支持的反价值减少,而 ACM 无法看到这一点。必须在系数旁同时报告总流入量,并将其下降视为一项成果。
  • 丢弃信号。根据 T14,没有解释的价值会丢失。日志应显示有多少建议和模式进入了产品决策。

8 与服务领域的关系

Æilus 方法论将领域定义为一种价值解释情境,它对可接受的实践和结果提出要求。领域不创造价值;它们阻止不可接受的反价值。支持涉及若干典型领域:

  • 可用性与连续性。事故对客户而言就是对这一情境的破坏。一线维持持续价值流的职责是其运营层面,路由应遵循针对关键程度的领域策略。
  • 安全。方法论指出,价值可能因违反安全参与所需的情境而被拒绝。削弱安全性的变通办法应记为新的反价值,而不是转化。
  • 架构。原始文献要求检查三线的决策是否具备架构完整性、可扩展性、性能和安全性。
  • 知识管理与持续改进。二线的知识库和 PDCA 循环是这些领域中的实践。

由此得出两点结论。第一,ACM 中计入的已实现价值必须在每一个相关领域内都是可接受的。第二,ACM 汇总了部分可通约的领域(A13)之间的价值,因此它需要方法论交由 VSO 负责的明确汇总策略,而领域策略则由领域所有者(Domain Owners)掌握。方法论警告说,没有这一策略,优化就会退化为局部偏好或指标操纵。

9 示例性的演算实例

此示例是假设性的。其中的产品、客户和数字均为虚构,并刻意取整。它们不是研究发现,也不检验原始文献的系数。

某产品的数据导入集成存在反复出现的故障。在某一时期内有十位客户报告了该故障。

  • 受理。每位客户的反价值(anti-value)估计为 10 Æ,因此 AV_received,1 = 100 Æ。
  • 一线。已知的变通办法和状态更新使工作得以恢复;客户确认了 120 Æ 的已实现价值。ACM_1 = 120 / 100 = 1.2,处于原始来源的名义范围之内。
  • 二线。找到了配置方面的根本原因;修正后的默认值和一篇知识库文章送达了报告问题的客户及其他客户。确认的已实现价值:400 Æ。ACM_2 = 400 / 100 = 4,低于名义上的 x10。在该协议中,这是一个需要检验的结果,而不是需要纠正的错误。
  • 三线与产品。发现导入协议很脆弱;重新设计和自动化检查已列入路线图,计划价值为 5,000 Æ。目前尚未交付任何内容,因此对该队列而言 ACM_3 = 0。这 5,000 Æ 已被记录,但不计入。
  • 建议。两位客户要求定时导入。这是 VAM 轨道上的潜在价值,不计入 ACM。

在本次评审中,ACM_chain = (120 + 400 + 0) / 100 = 5.2。如果重新设计日后得以交付并且客户确认了价值,则对三线队列进行追溯更新;如果它导致了回归,则该反价值将记在三线名下。该示例揭示了试点必须观察的内容:最深阶段的计划与实际差距(A4、A6)、实现滞后,以及与名义系数可能出现的偏离。

10 局限性

本文以及原始来源中均没有现场数据。系数 x1 至 x1.5、x10 和 x100 是提出的数量级,在所描述的机制下(一次修复扩展到众多客户,创建新的转换器)是合理的,但尚未经过测量。这些公式是本文对文字定义的解读;也可能存在其他解读。Æ 的估计取决于解释,而根据 A2,解释是价值的一种属性,但跨团队比较仍然需要一个经过校准的共享尺度,本文并未提供。各阶段之间的归因在没有规则的情况下被分配给 VSO。

一项能够支持或削弱该模型的试点需要证明:

  • 不同的人对相同的工单给出一致的 Æ 估计;
  • 无论绝对值如何,若干评审周期内的队列 ACM 都按各线遵循预测的顺序;
  • 已实现价值是由客户或约定的替代指标确认的,而不是由提出主张的各线确认的;
  • 在使用这些系数之后,反价值的总流入量有所下降,且没有出现第 7.4 节所列的博弈行为;
  • 这些系数在诸如服务恢复时间(Forsgren, Humble and Kim, 2018)等常规指标之外还增加了信息。

11 结论

只把支持视为成本中心,是对边界的一种选择。在公司的财务系统中,支持是成本;在客户的系统中,它是对反价值的消除;在产品的系统中,它是关于产品在何处失效的最直接的信息。原始来源的模型描述了一条转换器链,其杠杆作用从一线增长到三线并进入产品负责人(Product Owner)团队,形成回到客户的 PDCA 循环,并提出用 VAM 和 ACM 来衡量它。本文为这些系数给出了最小化的公式,将其分子固定在客户的价值系统中,只计入已实现且在领域内可接受的价值,并提出了一套用于记录、验证、评审和防止博弈的协议。原始来源的数量级是否成立,只有试点才能回答。

参考文献

  • 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.

引用此成果

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/

这对您有多大价值?

尚未评价

阅读时间将计为您的评价。登录以自行选择反应。

添加评论

登录即可发表评论。

价值如何评价

全部研究