TCO/ROI 与招投标

1 TCO/ROI 与招投标要回答什么

零售订单 API 已经有了需求、候选架构与架构决策记录（ADR），现在来到采购会议。业务希望促销期间能够下单，财务希望预算可控，采购需要能够比较的报价，运维关心接手后需要多少人。此时只问“哪家报价低”，会把架构中的责任分工藏起来：数据库由谁维护，故障由谁处理，旧订单怎样迁走，合同结束后怎样取回数据，都可能在签约后成为支出。本课把技术方案与商务测算连接起来，使决策依据能够进入招标文件、报价表和验收条款。

案例沿用零售订单 API：接口接收订单、查询订单状态，并向后续履约环节发送事件；订单成功必须有可核对的持久记录，重复请求不能生成重复订单。平日负载与促销峰值差异明显，生产环境需要跨故障域部署，并通过演练验证恢复能力。为便于本课计算，统一采用 3 年评价期、人民币万元、不含税的比较口径。示例中可用性目标为 99.95%，恢复时间目标 RTO 为 30 分钟，恢复点目标 RPO 为 5 分钟；它们是待验证的采购要求，不能从产品名称直接推定。

总拥有成本（TCO）回答：在指定时间和服务边界内，为获得并维持这项能力，组织需要付出哪些成本。购置或订阅只是入口，实施、运维、迁移、演练和退出也是获得能力的必要条件。投资回报率（ROI）回答：相对于明确的基线，新增投入带来的可归因收益是否值得。招投标则把需求、证据、价格和承诺组织为可比较且可追责的选择过程。3 个问题相互关联，但低 TCO 不自动意味着高收益，评分领先也不意味着所有风险已经消失。

本课比较 2 个方案。方案 A 由企业团队维护应用、数据库及其备份恢复；方案 B 使用更多托管能力，由服务方承担约定范围内的平台维护，企业仍负责应用、数据与业务恢复确认。两者必须实现同一组订单需求，采用相同的容量假设和高可用验收标准。若 A 的报价含灾备演练，而 B 的报价仅含单环境订阅，直接比较金额没有意义。先统一“买到什么”，再比较“为此付多少”。

采购时可以把问题收敛为 4 句话：哪些要求必须满足，满足要求的成本是什么，收益如何验证，偏差由谁承担。架构师提供容量、部署和恢复假设；业务负责人确认收益口径；财务确认成本归集方式；采购与法务把承诺写入适用的程序和合同。任何单个角色都不应独自替其他角色确认事实。可审查的方案应让每个数字都能回到假设、来源和责任人。

2 成本模型与敏感性

先画成本边界，再填金额。订单 API 的成本可按发生时点分为初始投入、持续支出和结束支出。初始投入包括环境搭建、数据迁移、接口适配、培训和上线演练；持续支出包括资源、软件或服务、运维人力、支持和演练；结束支出包括数据导出、验证、交接及资源清理。这里采用不折现的现金等价比较模型，用于入门筛选；正式决策若涉及融资、折旧、税费或资金时间价值，应由财务补充相应口径，不能把本课的简单总和直接当作财务报表。

为了避免重复计费，先说明“资源与服务费”已经包含哪些项目，再单列人力。方案 B 的支持费若已包含在服务费中，就不能再按服务费比例加收 1 次；企业人员需要进行应用值班和业务核对，这部分也不能因为采用托管能力而消失。共享团队按投入比例分摊，例如 2 名工程师各投入 25%，合计为 0.5 个全职当量（FTE）。本课采用每 FTE 每年 30 万元的综合成本，包含薪酬及组织认可的相关费用，不能只取到手工资。

示例基准如下。每年的资源与服务费已包含约定容量、跨故障域部署、备份存储及正常范围的数据传输；演练与培训费用单列。初始实施含上线前迁移、适配和验证。金额是教学假设，不代表市场报价，真实投标需要附用量清单和价格有效期。

基准 TCO 计算为“初始实施＋3×每年支出＋退出”。A 为 18＋3×（24＋30＋6）＋8＝206 万元；B 为 28＋3×（38＋15＋4）＋12＝211 万元。B 的服务费更高，人力支出更低，最终差额只有 5 万元。这个差额相对于 3 年模型很小，因此真正需要讨论的是人力投入能否兑现、容量预测是否可靠、合同边界是否完整，而不是用总价的小数位制造确定感。

敏感性分析就是只改变某个关键假设，观察结论是否改变。固定 B 的其他条件，若 B 每年需要的人力为 x FTE，其 TCO＝166＋90x。x＝0.5 时为 211，x＝0.3 时为 193，x＝0.7 时为 229；与 A 的 206 相等时，x 约为 0.444。因此“B 能否把投入压到约 0.44 FTE 以下”是值得验证的问题。它要求排班、支持边界和实际工时证据，不能靠“自动化程度高”来回答。

ROI 还需要收益模型。假设相对于现有系统，B 在 3 年内带来经业务确认的新增贡献毛利 240 万元，而批准的增量投入为 211 万元，则简单 ROI＝（240－211）÷211，约为 13.7%。这里特意把现有系统后续成本假设为 0，以便演示；实际必须计算“新方案成本减去继续现状成本”，不能把新方案总成本机械当作增量投入。已经进入 TCO 的人力节省也不能再记为收益。收益尚未确认时，应先呈现 TCO 与收益门槛，而不是填写一个看似漂亮的 ROI。

3 评分、合规与澄清

评分之前需要确定准入条件。对订单 API，准入可以要求满足数据处理边界、接口安全要求、订单一致性验收、可用性和恢复指标，并提交对应证明。准入条件应描述需要达到的结果及证据，避免把特定实现方式误写成唯一选择。是否采用特定采购程序、哪些资质必须具备，应按项目适用的制度和规则确认，本课的评分例子不替代这些要求。未满足强制条件的方案，应按事先公布的处理规则执行，不能用低价抵消关键缺口。

通过准入后，再比较达标方案的差异。一个入门示例是技术与交付 40 分、商务成本 40 分、风险与服务 20 分。技术项关注订单场景的实测表现、迁移计划和验收可执行性；成本项使用统一的 3 年评价价格；风险项关注退出安排、支持响应和变更控制。所有项目需要规定取证方式，例如把“恢复能力优秀”改为“提供演练记录，并按验收脚本完成恢复且核对订单”。没有评分锚点的主观词语，很难在复核时解释。

若规则采用“最低有效评价价格÷本方案评价价格×40”计算成本分，A 的成本分为 40，B 为 206÷211×40，约 39.05。这里的最低价来自通过有效性审查的方案，并非所有报价中的最小数字。其余 60 分需要独立证据，不能为了偏好的结果倒推权重。权重、公式、舍入方式和缺项处理应在适当阶段预先明确；实际项目须使用适用规则，不能把教学公式当作通用法定办法。

澄清的作用是消除歧义并留下可追踪记录。例如报价写“含备份”，应进一步确认保留周期、恢复操作责任、演练次数、存储上限以及超限价格。澄清记录至少包括问题、答复、对价格和范围的影响、文件版本、确认主体与时间。涉及对实质条件的修改时，应遵守适用程序；不能把重大范围补充隐藏为普通解释，也不能在比较完成后偷偷改变某个投标人的价格口径。

合规证据也要区分“声称具备”“文件覆盖”和“本项目适用”。某项认证可能只覆盖服务方的部分组织或设施，未必覆盖订单 API 的部署地点及交付范围。评审人员应把证据映射到具体要求，注明有效期、适用范围和待补事项。最终形成的是需求到证据、证据到评分、评分到合同的链条。合同中的服务范围和验收标准如果与评分依据脱节，评审阶段的优势就无法在交付阶段兑现。

4 动手：做一张三年 TCO 对照

现在用普通电子表格完成计算，不需要采购专用工具。建立“假设”“成本”“证据”3 个工作表。假设表记录评价期 3 年、币种、税费口径、容量基准、增长情景、FTE 单价以及可用性目标。容量不要只写“支持促销”，应记录订单请求峰值、峰值持续时间、平均请求大小、订单保留周期和测试数据来源。本课不指定跨章节通用的流量数值，实际练习直接沿用前面需求文档已确认的订单负载。

成本表以项目为行，以 A、B 为列，同时加入计量单位、数量、单价、发生年份、是否包含及证据编号。把每年 24 万元展开为具体资源清单，能防止某方只报应用节点而漏报数据库副本。迁移如果已包含在实施费中，在迁移行注明“已含于实施”，保留说明但不重复求和。对于未报价的必需项，标记为待澄清，不能填 0；只有已经确认无需额外支付的项目才可以填写 0 并注明依据。

接着录入第 2 节的基准金额。A 在起点发生 18，每年发生 60，期末发生 8；B 在起点发生 28，每年发生 57，期末发生 12。按时间展开后，A 在第 1 年末累计 78，第 2 年末累计 138，第 3 年加退出后为 206；B 对应为 85、142、211。这样能够看出 B 虽然年度运行费用较低，但在评价期内尚未抵消初始和退出成本的差额。第 3 年的退出支出应放在同一时点规则中，不要对其中某个方案提前或延后计算。

然后增加情景列。第 1 个情景把 B 人力从 0.5 调到 0.7 FTE，第 2 个情景把双方每年资源与服务费分别提高 20%，其余条件保持不变。后者使 A 增加 14.4、总计 220.4，B 增加 22.8、总计 233.8。这里的 20% 只是金额冲击测试，不意味着业务增长 20% 就必然导致费用增长 20%；资源扩容可能有档位，合同也可能有阶梯价，正式模型需要采用实际计价规则。

最后在证据表中，把资源费连接到清单和有效报价，把人力连接到值班职责与工时估算，把实施连接到迁移任务，把退出连接到合同条款。为每个待确认假设指定责任人和截止时间。输出时展示基准总额、主要敏感因素、尚未报价项目及选择条件。不要只导出汇总页，因为决策者需要知道 206 与 211 的差别建立在什么条件上，也需要知道何时应重新计算。

完成后尝试口头解释：为什么 B 的资源与服务费更高，年度总支出却更低？为什么 B 仍然没有在 3 年内取得更低 TCO？如果无法回答，先检查是否把初始、持续和退出支出放在了正确位置。动手的目标是形成可以交接的比较依据；计算器正确，只能证明算术正确，不能证明范围、责任和数据来源正确。

5 低价与总拥有成本取舍

低价有时来自效率，也可能来自范围更窄、服务期限更短或风险转移。面对低价，不应先入为主地认为它不可行，而应逐项检查价格背后的工作分配。对订单 API，最容易产生差异的是跨故障域资源、促销容量准备、备份恢复操作、夜间支持、历史订单迁移和终止后的导出。若某项由企业承担，就把企业成本补进模型；若由服务方承担，就在清单和合同中找到相应承诺。

总拥有成本取舍必须建立在达标基础上。若低价方案只能部署在单个故障域，它与本课的高可用需求不匹配，不能简单写成“节约 20% 但可用性略低”。应先要求补足部署与演练范围，再按统一条件重新评价。如果业务确实愿意调整服务目标，需要正式修改需求并评估对下单、客服和履约的影响，让所有候选方案基于同一版本重新比较。预算压力不应让需求变化悄悄发生。

成本较高的方案也不自动更稳妥。B 的托管范围如果只覆盖平台恢复，而不覆盖订单事件补发，企业仍需完成业务核对。减少的基础维护工时能否转化为实际节省，也取决于人员安排：团队可能把时间用于改进业务，而不是减少工资支出。这时可把它描述为释放能力，并给出后续工作及价值证据，不能同时声称“工资现金减少”和“原班团队增加产出”，把同一份时间计算 2 次。

对于风险，可以先列情景和后果，再决定是否量化。例如容量不足可能导致下单失败，恢复未验证可能延长停机，导出受限可能抬高退出成本。若采用“发生概率×影响金额”估算预期损失，要注明数据来源与不确定范围，并与确定性支出分开展示。少见但影响很大的故障，不能仅因预期值较低就忽略硬性要求；高可用验收依然是准入条件。入门阶段宁可公开未知，也不要把主观概率包装成精确事实。

合理的推荐可以是条件式结论：“当前基准下 A 低 5 万元；若 B 经试运行证明年度投入不超过约 0.44 FTE，且退出条款可执行，则 B 的 TCO 可能更低。”这比只说“推荐更先进的方案”更可审查。ADR 应记录选择的方案、替代项、关键假设、接受的代价和重评触发条件。例如价格调整、人力超过阈值或恢复演练失败，都可能触发复评；评审不是签约后永久冻结判断。

6 常见坑：忽视人力与迁移成本

第 1 类遗漏是把日常维护当作已有团队的免费劳动。订单 API 的数据库升级、证书更新、权限复核、容量检查、备份恢复和故障值班都占用时间。即使预算中没有新增岗位，这些任务也会挤占其他工作。估算时可从职责清单出发，分别记录频率、单次工时和参与人数，再汇总为年度投入；避免把所有工作都笼统写为“运维 1 人”。共享值班时间的分摊应保持前后一致，不要求精确到分钟，但必须可解释。

第 2 类遗漏是只计算数据传输，不计算迁移验证。订单迁移至少涉及字段映射、历史状态转换、增量同步、重复订单检查、切换窗口和回退条件。迁移结束不是文件复制完成，而是关键订单数量、金额及状态能够核对，后续事件不会重复触发。旧系统在切换期间可能仍需付费，新旧环境并行运行也可能占用额外资源。把这些都排除在“正式运行期”之外，会让 TCO 在账面上偏低。

第 3 类遗漏是把高可用配置等同于已经具备恢复能力。双副本产生资源费用，演练消耗人力，业务恢复核对还需要订单与履约负责人参与。方案如果只写“支持自动切换”，却没有说明故障判定、应用重连和恢复后的数据检查，费用边界就仍然不清楚。采购文件应以演练脚本和验收结果确认承诺，内部技术实现只保留理解报价范围所必需的层次，更复杂的复制与一致性机制留给后续课程。

第 4 类遗漏是退出成本。合同到期或方案调整时，需要导出数据、获得格式说明、校验完整性、完成交接，并按约定删除残留数据。若导出速度、接口额度、协助工时与费用没有提前说明，企业就很难判断能否按时离开。退出费用不是认定合作必定失败，而是评价期完整性的组成部分。A 同样需要退出预算，不能因为资源在企业控制范围内就默认没有交接和清理工作。

还要警惕把“未确定”写为“免费”。报价表中的空格、演示中的口头承诺以及“按需另议”都应进入待澄清清单。对每个缺项，标明是否属于必需能力、谁确认范围、何时补齐价格，以及未补齐时如何按既定规则处理。这样既能防止漏项，也能避免评审人员事后随意加价。公平比较依赖统一处理方法，而不是对不同候选方案采用不同的宽容程度。

7 案例：中标后变更单吞掉节省

假设团队曾经用不完整的范围比较方案：一个候选方案给出的 3 年报价为 180 万元，另一个范围完整的方案为 206 万元，前者表面节省 26 万元。180 万元只覆盖标准环境和基础实施，报价中的“含迁移”“支持高可用”没有附任务与验收范围。团队没有逐项澄清，直接把它当作与 206 万元等价的服务包，并据此完成采购选择。这里的问题不是签约之后价格突然变化，而是签约之前比较对象已经不同。

上线准备时，服务方提出 3 项额外工作：历史订单字段转换与核对 12 万元、跨故障域演练及恢复验收 10 万元、夜间切换支持 8 万元。这些任务都与已确认的订单需求有关，却未进入原报价边界。如果经核对确认确属原范围外，并按合同流程批准，新增费用合计 30 万元，原方案支出升至 210 万元。企业还因切换延期多支出旧环境费用 6 万元，实际总额达到 216 万元，超过比较基准 10 万元。

分析时必须区分 3 种情况：需求原本存在但漏写；合同已经包含而交付方未履约；业务后来确实新增需求。第 1 种暴露范围管理缺口，第 2 种应按原合同追踪履约，第 3 种才进入新增范围的价值与成本评估。不能把所有事项都自动批准成变更，也不能仅凭“最初说过”就认定已经包含。首先对照需求版本、澄清答复、工作清单和合同附件，建立事实后再确定处理路径。

纠正这个案例，应把迁移拆成可验收的任务，把高可用写成可执行的演练要求，并明确切换时段与支持安排。变更单至少记录原因、范围差异、费用、工期、对订单服务的影响和批准人。在批准前，把新增金额和延期支出回填 TCO，并更新剩余预算；若改变了原决策依据，还应更新 ADR。已经发生的支出不能抹去，但后续决策仍要比较继续执行与替代路径的剩余成本，不应只为了证明最初选择正确而继续投入。

这个案例还说明，偏差复盘应围绕信息流。是谁掌握迁移复杂度，为什么没有进入报价附件，谁有权确认“包含”，验收人员是否参与了澄清，都比简单归咎于“采购压价”更有帮助。修复措施应落实到模板字段、评审职责和证据要求，并在下个采购项目中使用。只有把缺口转化为可重复执行的检查，复盘才会改善后续方案。

8 把商务测算写进投标方案

投标方案应让技术承诺、成本明细和交付结果互相对应。建议按需求编号建立映射：每项关键要求对应实现方式、报价项目、责任边界、证明材料和验收方法。例如“订单 API 达到 RTO 30 分钟”，需要对应恢复方案、演练服务费用、参与角色、演练记录和计时起止点。只给出总价无法说明买到了哪些能力，只给出架构图也无法说明这些能力是否进入交付范围。

商务测算需要同时呈现现金流和假设。报价有效期、计费单位、资源数量、超限价格、续约条件和退出协助都影响后续预算。对促销弹性容量，写清基础额度、临时增加的计费方式和缩容后的费用规则；对数据保留，写清包含容量及超额处理。若采用优惠或折扣，必须说明适用期和到期后的计价依据，不能默认整个 3 年都维持首期价格。不同税费口径应由财务统一转换后再比较。

收益说明要靠业务链条支撑。例如“订单失败减少”需要先定义失败率与统计窗口，再说明哪些失败能由本方案改善，以及改善后如何转化为可归因的贡献毛利。交易额不能直接当作利润，流量增长也不能全部归功于技术替换。尚无实测数据时，给出保守、基准和较高收益情景，并写明验证计划。收益假设属于谁确认、什么时候复查，与成本明细同样重要。

交付管理则要设置可观察的检查点。签约时冻结需求和报价版本；迁移前完成核对脚本与回退准备；上线前验证容量和恢复；上线后按月比较用量、账单与实际工时；重要变更时重新计算剩余评价期成本。服务质量指标与成本指标应同时观察，避免为了压低账单削减必需副本或演练。发现偏差后先定位是用量、单价、范围还是执行效率变化，再决定扩容、优化或按约定发起变更。

最终推荐意见要允许复核。明确基准下谁的 TCO 更低，哪些收益已经确认，哪些优势需要试运行，哪些风险已通过条款分配，以及哪些事项仍待确认。对无法满足的要求应直接列出偏离及影响，不要用模糊措辞掩盖。好的投标方案不是承诺所有事情都能免费完成，而是让范围、价格、责任和验证方法足够清楚，使采购方能够据此做出合理选择。

9 从TCO/ROI 与招投标走向芯片设计流程（H37）

本课把订单 API 从技术选型推进到可购买、可交付、可验收的方案：需求限定比较边界，ADR 记录取舍，TCO 揭示持续责任，ROI 检查业务价值，招投标把证据和承诺落实到文件。这条链条也适用于下一步的芯片设计流程。对象虽然从服务系统变成硬件产品，仍然需要先明确目标、约束、候选方案与验证方法，再投入更大的实施成本。

两类项目的成本形态并不相同。订单 API 常有持续订阅、按量资源和运维支出；芯片项目还会面对前期设计、验证、制造准备和样品测试等投入。这里仅建立认识：前期投入与后续单位成本必须放在同一时间与数量假设下比较，项目阶段越靠后，某些修改的代价可能越大。不要把软件服务的按需扩容经验直接套到硬件制造，也不要只因前期投入高就认定方案没有价值。

进入 H37 时，可以继续携带本课的 4 个问题：目标是否可验证，成本是否覆盖全流程，外部交付边界是否明确，变更是否会触发重新评估。我们会从流程与角色理解芯片如何从需求走向可验证的交付物，暂不展开设计工具内部算法或制造细节。对订单 API 的学习成果则保留为方案附件：统一口径的成本表、敏感性结论、澄清记录、变更规则和高可用验收要求，它们共同支撑后续采购与运行。

放进方案里

在零售订单 API 方案中，增加“商务测算与采购依据”附件，并绑定需求及 ADR 的版本。附件采用 3 年评价期、人民币万元、不含税口径，覆盖初始实施、年度资源与服务、运维人力、演练培训及期末退出。所有金额注明来源、有效期与责任人；未确认项目列为待澄清，不能视作免费。架构、容量和高可用要求应与报价清单保持一致。

基准测算中，A 的 TCO 为 206 万元，B 为 211 万元。B 每年人力投入为 0.5 FTE 时尚未形成总成本优势；其他条件不变时，约 0.44 FTE 是与 A 持平的边界。推荐意见应写明该结论依赖的职责分工与工时估算，并通过试运行验证。双方年度资源与服务金额均上升 20% 的情景下，TCO 分别为 220.4 与 233.8 万元，需将相应预算压力提交评审。

采购先按统一规则审查订单一致性、数据边界与高可用要求，再对达标方案评分。可用性目标为 99.95%，RTO 为 30 分钟，RPO 为 5 分钟，证据必须对应本项目配置和演练。评分表保留需求、证明材料、评价结果和合同条款的映射。ROI 仅使用业务确认的增量收益与增量投入，避免重复计算人力节省，未验证的收益单独展示情景及验证时间。

合同附件写清迁移核对、促销容量、切换支持、恢复演练、数据导出和超限收费。迁移验收须核对订单数量、金额与状态，差异闭环后由业务负责人签认；退出验收须提供可读取的数据样本、完整性校验结果及导出耗时记录，明确协助工时上限和超额单价。上述证据应绑定交付批次，作为对应付款节点的核验依据。变更先核对是否属于原范围，再评估价格、工期及服务影响，经授权批准后回填 TCO 和预算。上线后按月观察账单、工时与服务质量；出现价格调整、人力超出假设或演练不达标时，启动复评并更新 ADR，使采购结论持续接受运行证据检验。

10 小结：下一步芯片设计流程（H37）

TCO 让初始、持续与退出责任进入同一张表，ROI 让投入回到可归因的业务价值，招投标让比较依据成为可追踪的承诺。订单 API 的方案必须先满足共同需求，再比较价格、风险与收益。

带着 3 个问题进入 H37：前期投入如何影响后续选择？验证活动为什么必须进入预算？修改需求时如何重新评价成本与交付？芯片设计流程将用新的工程对象继续回答这些问题。