WEBVTT

00:00:08.000 --> 00:00:13.887
大家好，欢迎回到 Operational
ITAM Podcast。我是 Bill Van

00:00:13.887 --> 00:00:18.465
Nort，今天我们跟随一笔节省款项，它在进入账户
之前先出现在演示中。

00:00:19.135 --> 00:00:29.273
许可证已清理完毕，变更工单已关闭，项目报告称工作
已完成。随后财务部门询问为何供应商仍在收取旧金额

00:00:29.273 --> 00:00:29.480
。

00:00:30.075 --> 00:00:36.360
没人再认为那是他们项目的一部分了。幸运的是，发票
让大家重新聚在了一起。

00:00:37.075 --> 00:00:40.460
今天，《决策表》：节省的钱去哪了？

00:00:41.095 --> 00:00:51.226
早上好、下午好或晚上好，无论您身在何处。这是我们
将企业技术的枯燥机械变得合情合理的节目。请准备好

00:00:51.226 --> 00:00:52.260
您的咖啡。

00:00:52.935 --> 00:01:01.359
在第 15 集中，我们确定了谁可以做出续期决定。
我们向此人提供了证据、选项以及他们实际能够批准的

00:01:01.359 --> 00:01:01.875
条件。

00:01:02.655 --> 00:01:08.780
今天我们在获得批准之后开始。我们将遵循 1
change，直到我们可以解释结果。

00:01:09.495 --> 00:01:18.340
FinOps 基金会的报告与分析指南要求将实际支
出与决策背后的估算进行比较。这是一个有用的起点。

00:01:18.340 --> 00:01:25.560
实际的挑战在于，在不因出现问题而每次更改原始估算
的情况下，解释两者之间的距离。

00:01:26.155 --> 00:01:36.273
我的观点，明确标注：原始业务案例应保留在文件中。
更新预测，绝对要这样做。保留早期版本，以便组织了

00:01:36.273 --> 00:01:43.500
解发生了哪些变化。否则，每个项目最终都会达到最后
输入其中的那个数字。

00:01:43.835 --> 00:01:52.749
让我们使用一家虚构公司和一份虚构的软件协议。这些
是说明性的美元金额，并非供应商价格或客户成果。我

00:01:52.749 --> 00:01:55.660
们将遵循从一月到十二月的日历年。

00:01:56.190 --> 00:02:04.360
该公司为 1000 个订阅席位付费，每个席位每月
20 美元。每月 20000 美元。全年

00:02:04.360 --> 00:02:06.175
240000 美元。

00:02:06.850 --> 00:02:13.033
一项分配审查发现，800
个席位可以满足持续的业务需求。拟议的减少量为

00:02:13.033 --> 00:02:20.805
200 个席位，从一月开始。在同一单位价格下，这
将每月减少 4000 美元，或全年减少

00:02:20.805 --> 00:02:22.395
48000 美元。

00:02:22.775 --> 00:02:32.823
那是我们最初的总预测。总（Gross）意味着在实
施变更的成本之前。它也是有条件的：数量必须可商业

00:02:32.823 --> 00:02:38.360
缩减，变更必须在 1
月生效，且剩余服务仍需满足要求。

00:02:39.135 --> 00:02:45.824
在追踪资金流向之前，先明确我们要比较的内容。在本
案例中，财务部门同意，以 1000 seats

00:02:45.824 --> 00:02:52.653
的现有服务规模和相同的 20 美元费率维持现状是
本年度的一种可行替代方案。我们拥有当前的发票以及

00:02:52.653 --> 00:02:55.440
一份可用的未变更续订合同来支持这一方案。

00:02:55.800 --> 00:03:06.660
业务需求保持不变。此次削减仅移除不必要的分配，而
非关闭某个部门。比较中不存在任何价格上涨、税收变

00:03:06.660 --> 00:03:09.320
更、货币波动或服务降级。

00:03:10.020 --> 00:03:14.885
这些假设使本示例易于阅读。在您自己的记录中，每一
项都需要核查。

00:03:15.480 --> 00:03:25.174
这个商定的比较基准就是基线。它说明我们用什么来衡
量结果。去年的付款、今年的预算、供应商的初始报价

00:03:25.174 --> 00:03:34.275
和未来需求预测是不同的基线。同一张发票相对于某个
基线可能显得有利，相对于另一个却可能不利。

00:03:34.870 --> 00:03:44.513
如果需求真的发生变化，请单独解释。也许公司服务了
更多客户或收购了另一个部门。保持批准的对比，然后

00:03:44.513 --> 00:03:51.795
展示调整后的视图及其新范围和相关证据。不要悄悄重
写起点并将差异称为业绩。

00:03:52.500 --> 00:04:01.116
您还需要句号。每月减少量乘以 12 描述的是以该
速率计算的完整一年，但这并不能确立发生了 12

00:04:01.116 --> 00:04:05.245
个月的收益。我们很快就会看到这一区别的重要性。

00:04:05.900 --> 00:04:14.169
一个容易失去这种纪律性的地方是团队之间的交接。发
现未使用分配的人可能会估算出一个机会。采购部门可

00:04:14.169 --> 00:04:19.400
能会记录一个协商后的位置。交付部门可能会标记一项
行动已完成。

00:04:19.960 --> 00:04:27.528
财务部门可能会报告已确认的结果。这些是有用的里程
碑，但它们需要各自的日期和证据。如果全部 4 项

00:04:27.528 --> 00:04:32.625
都被标记为已节省，那么报告就停止告诉你工作实际上
处于什么阶段了。

00:04:33.240 --> 00:04:43.362
保留原始估算、最新预测以及截至目前的验证结果。如
果原始估算有误，请简要说明原因；如果估算合理但情

00:04:43.362 --> 00:04:52.865
况发生变化，请记录该变化。您的目标是改进下一项决
策，而不是排列列式以便无人需要讨论此问题。

00:04:53.380 --> 00:05:02.625
团队清理工作比计划晚完成。一月仍保持 1000
个已付费席位。签署的变更于二月一日生效。

00:05:02.990 --> 00:05:12.745
还有另一个区别。供应商同意将承诺仅减少至 850
个席位。这是本虚构修正案中的最低限度。这并非关于

00:05:12.745 --> 00:05:14.935
特定出版商规则的陈述。

00:05:15.570 --> 00:05:24.181
授权所有者接受该选项，团队记录 800
个已分配席位对 850 个已购买席位。仍有 50

00:05:24.181 --> 00:05:30.835
个未分配席位正在付费。这些是可用的容量，而非已经
实现的另一项节省。

00:05:31.330 --> 00:05:39.064
现在我们可以解释修订后的预测。我们失去了原定的
4000 美元一月削减额。对于剩余的 11

00:05:39.064 --> 00:05:44.563
个月，那额外的 50
个付费席位每月成本比原始目标高出 1000

00:05:44.563 --> 00:05:49.375
美元。原始预测中的另外 11000
美元今年将不会实现。

00:05:50.060 --> 00:05:58.773
48000，减去 4000 用于时间调整，再减去
11000 用于保留的承诺。这留下了 33000

00:05:58.773 --> 00:06:01.085
美元的预期年度订阅减少额。

00:06:01.780 --> 00:06:09.502
这里有一个更简单的检查方法。二月份的账单应从
20000 降至 17000。每月减少 3000

00:06:09.502 --> 00:06:13.445
美元，持续 11 个月，共计 33000 美元。

00:06:13.830 --> 00:06:22.346
运营清理工作可以完成，但商业成果可能小于最初提议
的数额。这两句话都应包含在报告中。将这项工作称为

00:06:22.346 --> 00:06:28.255
失败会忽略其带来的缩减效果。保留 48000
在预测中会忽略该协议。

00:06:28.845 --> 00:06:37.025
这就是你连接证据的地方。将批准的提案、签署的修正
案、生效日期和分配记录放在一起。

00:06:37.565 --> 00:06:46.553
每个答案回答一个不同的问题。我们原本打算做什么？
供应商同意了什么？该义务何时发生变更？团队实际实

00:06:46.553 --> 00:06:47.470
施了什么？

00:06:48.080 --> 00:06:57.582
给予变更一个可在收益记录和账单调查中使用的稳定参
考依据。它不需要新平台。如果人们能找到支持性文件

00:06:57.582 --> 00:07:00.685
，现有续订记录中的参考就足够了。

00:07:01.400 --> 00:07:11.137
微软关于购买或移除企业订阅许可证的指导在此处做出
了有用的区分。将许可证从不分配给用户和移除已购买

00:07:11.137 --> 00:07:20.874
的许可证是两个独立的步骤。移除时间取决于计费安排
和适用的窗口。在预测收费何时产生之前，请检查实际

00:07:20.874 --> 00:07:22.265
的订阅和协议。

00:07:22.720 --> 00:07:30.850
这是一个真实的产品机制，与我们虚构的 850 个
席位最低要求是分开的。一张显示较少分配任务的截图

00:07:30.850 --> 00:07:36.325
证明了关于分配任务的一些内容，但它本身并不能证明
可支付数量更低。

00:07:36.980 --> 00:07:46.711
在移除访问权限之前，需与相关负责人核实持续服务、
数据和保留要求。如果变更导致授权人员无法执行必要

00:07:46.711 --> 00:07:50.285
工作，那么账单更便宜并非成功的结果。

00:07:50.920 --> 00:08:00.801
我们虚构的公司还向外部专家支付 6000 美元以
完成清理工作。在此示例中，这是唯一的增量实施成本

00:08:00.801 --> 00:08:06.245
，该成本在当年发生并支付，财务部门将其纳入效益比
较。

00:08:06.960 --> 00:08:15.215
33000 美元的订阅减少额，减去 6000
美元的实施成本，预计年度净收益为 27000

00:08:15.215 --> 00:08:15.765
美元。

00:08:16.400 --> 00:08:24.965
内部员工也花费时间处理此项变更。记录该投入。在本
例中，其工作量在现有容量范围内，未识别出额外薪酬

00:08:24.965 --> 00:08:29.860
或受影响的已资助工作，因此我们并未产生额外的现金
支付。

00:08:30.380 --> 00:08:37.925
如果它取代了重要工作，请说明被取代的内容并对其进
行评估。已支付的发票并非决策的唯一可能成本。

00:08:38.500 --> 00:08:48.606
完成检查不仅需要工单状态。需要服务所有者确认已移
除正确的分配、保留了必要人员的访问权限，且采购数

00:08:48.606 --> 00:08:58.711
量与修正案匹配。保留由系统实际控制分配的带日期记
录。如果自动化规则可以在明天恢复这些分配，在关闭

00:08:58.711 --> 00:09:01.805
工作前，先识别该规则的负责人。

00:09:02.460 --> 00:09:13.051
保持检查与服务成比例。您无需因移除休眠账户而重新
测试整个应用程序，但您需要知道该移除已发生，且将

00:09:13.051 --> 00:09:21.265
其称为不必要的原因是合理的。如果证据仅是一项变更
请求，则实施仍未得到验证。

00:09:21.980 --> 00:09:30.702
反方论点很有道理：这听起来像是为了适度的减少而进
行了大量的核查。投入应与成果相称。一个小型、简单

00:09:30.702 --> 00:09:39.423
的变更可能需要几条关联记录和一次简短的审查。但仍
有某人需要确定生效日期、实际数量和到达该状态的成

00:09:39.423 --> 00:09:42.805
本。当事实简单时，算术运算会变得更短。

00:09:43.420 --> 00:09:52.262
此时我们有了修订后的预测。我们尚未验证一整年的结
果。现在我们需要发票，而这正是我们的案例变得更有

00:09:52.262 --> 00:09:53.345
意思的地方。

00:09:58.000 --> 00:10:05.090
让我们稍作休息。如果您需要此工作的实用流程，Op
erational ITAM Store 有 1

00:10:05.090 --> 00:10:09.720
个名为“验证收益并报告业务成果”的流程。其流程编
号为 F02。

00:10:10.440 --> 00:10:20.663
它包括一个可编辑的 HTML 程序、一个 SVG
流程图以及本地采用和证据清单。起始输入包括商定的

00:10:20.663 --> 00:10:27.965
基线、批准的行动、发票或报价单、实施成本、货币、
期间和业务成果证据。

00:10:28.560 --> 00:10:32.080
这为您提供了一个与财务部门开始对话的结构化起点。

00:10:32.960 --> 00:10:36.380
根据贵组织的职责和测量决策进行调整。

00:10:37.120 --> 00:10:43.045
该流程不会决定您的财务团队将确认什么，也不会替代
数字背后的记录。

00:10:43.650 --> 00:10:51.227
您可以在 operationalitam.com
/store 查看相关内容。这是我的付费资源，购

00:10:51.227 --> 00:10:56.175
买它有助于支持节目。今天的作业使用的是您已有的信
息，无需购买。

00:10:56.745 --> 00:11:01.717
您也可以在
operationalitam.com 找到播客

00:11:01.717 --> 00:11:07.850
和实用资源。如果有人不断追问节省的钱去了哪里，这
一集或许值得与他们分享。

00:11:11.945 --> 00:11:13.550
好的。回到发票。

00:11:14.445 --> 00:11:20.744
一月份的账单正确开具为 20000
美元。但二月份和三月份也被开具了 20000

00:11:20.744 --> 00:11:27.673
美元的账单，尽管签署的修正案规定从二月起应为
17000 美元。四月和五月则达到了正确的

00:11:27.673 --> 00:11:29.090
17000 美元。

00:11:29.565 --> 00:11:33.645
在五月底，这 5 张发票总计为 94000
美元。

00:11:34.285 --> 00:11:40.944
我们过去 5 个月的未变基线为
100000。目前的发票显示减少了 6000

00:11:40.944 --> 00:11:41.470
美元。

00:11:42.105 --> 00:11:49.570
该协议支持不同的数字。一月为 20000，随后
4 个月为 17000，总计

00:11:49.570 --> 00:11:55.070
88000。与基准相比，到五月应减少 12000
美元。

00:11:55.645 --> 00:12:05.253
6000 美元的差距是二月和三月额外收取的
3000 美元。这是一笔由修正案支持的账单争议，

00:12:05.253 --> 00:12:07.760
并非合同价格的再次降低。

00:12:08.495 --> 00:12:18.011
在五月报告截止日，显示有 6000
由当前记录的发票支持，另有 6000 处于争议中

00:12:18.011 --> 00:12:28.660
。财务部门根据组织政策决定争议金额是否需要进行任
何会计调整。预期的信用并非信用已到账的证据。

00:12:29.345 --> 00:12:40.315
调查应具体明确。请识别订阅项、法律实体、两张发票
编号、相关服务期间、约定数量以及修订生效日期。要

00:12:40.315 --> 00:12:50.390
求供应商更正已发现的 2 处差异。这比收到一条说
节省报告看起来不对的消息要容易解决得多。

00:12:51.085 --> 00:13:00.429
Microsoft 的发票指南区分了发票日期与收
费所涵盖的服务期间。这种区分不仅限于本例。本月收

00:13:00.429 --> 00:13:09.010
到的文件可能涉及更早的期间。请同时记录这两个日期
，以免将迟到的更正误认为是新的运营改进。

00:13:09.645 --> 00:13:14.494
在我们的虚构案例中，供应商接受了争议，并于六月发
放了 6000

00:13:14.494 --> 00:13:21.615
美元的信贷。该信贷用于抵扣六月的正常 17000
美元费用，使得该发票的应付金额为 11000

00:13:21.615 --> 00:13:22.070
美元。

00:13:22.845 --> 00:13:30.277
六月并未成为一项价值 11000
美元的服务。重复性收费仍为 17000。6000

00:13:30.277 --> 00:13:32.090
用于纠正二月和三月。

00:13:32.765 --> 00:13:42.003
将信用额关联到原始发票，并显示其应用时间。如果财
务部门已在早期期间确认了该更正，则其后续到账即结

00:13:42.003 --> 00:13:46.150
算该项目。它不得在节省报告中产生第二次收益。

00:13:46.725 --> 00:13:56.278
如果要说现金已经节省下来，就要检查结算情况。发票
、费用分录、贷项余额和付款是相关记录，但不能互相

00:13:56.278 --> 00:14:05.830
替代。在这个已经结束的虚构年度中，所有相关费用和
贷项都已结清。在此之前，应采用证据所支持的表述。

00:14:06.525 --> 00:14:16.235
让我们结束这一年。从七月到十二月，订阅费用保持在
每月 17000 美元。不再发生任何新的计费错误

00:14:16.235 --> 00:14:22.180
、新增席位或额外项目成本。企业主确认持续服务符合
约定要求。

00:14:22.700 --> 00:14:29.191
扣除信用额后的最终订阅总额为 207000
美元。您可以这样核对：1 月份为

00:14:29.191 --> 00:14:35.510
20000，加上随后 11 个月每月
17000。相对于我们 240000

00:14:35.510 --> 00:14:38.585
美元的基准线，减少额为 33000。

00:14:38.880 --> 00:14:46.925
减去 6000 美元的实施成本。在我们声明的假设
下，日历年净收益为 27000 美元。

00:14:47.530 --> 00:14:57.028
该信用额已包含在该结果中。再次添加会导致高估收益
。不将其包含在内则会低估收益。该信用额修正了账单

00:14:57.028 --> 00:14:59.935
记录，使其与修订后的义务相符。

00:15:00.515 --> 00:15:05.168
我们现在可以解释原始 48000
发生了什么。4000

00:15:05.168 --> 00:15:13.095
是因为变更在一个月后才开始而损失的。11000
是因为承诺只能降至 850 个席位而损失的。

00:15:13.695 --> 00:15:20.020
6000 用于实施该变更。剩余的 27000
由已完成的案例提供支持。

00:15:20.695 --> 00:15:31.736
这是他人可以复现的解释。它还提供了下一个项目的有
用信息。生效日期需要更多关注。最低承诺应在原始预

00:15:31.736 --> 00:15:37.820
测发布前进行测试。账单需要在技术工作完成后进行跟
进。

00:15:38.515 --> 00:15:47.186
现在假设有人询问年度化缩减额。每月 3000 美
元，在相同范围、费率及承诺持续的前提下，重复订阅

00:15:47.186 --> 00:15:54.796
缩减额将在 12 个月内达到 36000
美元。这是一个前瞻性运行率。它并不替代今年的

00:15:54.796 --> 00:15:59.220
33000 美元毛节省或 27000
美元净收益。

00:15:59.775 --> 00:16:09.469
如果管理层将释放的预算用于另一项服务，请单独报告
该分配。即使技术总预算保持不变，原始服务的成本也

00:16:09.469 --> 00:16:15.800
可能更低。同样，较低的总预算并不能证明您的特定行
动导致了削减。

00:16:16.435 --> 00:16:22.198
Amazon Web Services
提供了另一个关于标签为何重要的有用示例。其

00:16:22.198 --> 00:16:27.540
Savings Plans
利用率文档定义了针对相同使用量的总净节省额与预估

00:16:27.540 --> 00:16:31.195
On-Demand
成本的对比。这是一个明确的比较。

00:16:31.855 --> 00:16:36.200
这并不意味着该组织的账单较上个月减少了相应金额。

00:16:36.915 --> 00:16:42.523
Amazon Web
Services，或通常所说的 AWS，也会报告

00:16:42.523 --> 00:16:50.374
承诺额的使用情况。如果工作负载减少，请检查该承诺
额会发生什么变化，以及是否有其他符合条件的用量可

00:16:50.374 --> 00:16:51.175
以吸收它。

00:16:51.775 --> 00:16:55.735
技术缩减和财务缩减可能发生在不同时间。

00:16:56.415 --> 00:17:00.140
答案在于使用、承诺和账单证据的综合。

00:17:00.855 --> 00:17:10.027
在我们的席位示例中，50 个未分配的付费席位日后
可能容纳新入职人员。如果他们这样做，请记录实际的

00:17:10.027 --> 00:17:19.199
重新使用。如果有人想要主张避免购买，请记录否则本
需要的额外购买并与财务部门达成一致比较。不要将保

00:17:19.199 --> 00:17:24.440
留容量及其后来的重新使用都算作今年削减的单独现金
节省。

00:17:25.115 --> 00:17:34.495
如果信用从未到账，或者记录不完整，请保留该项目并
列出金额、证据缺口、负责人和后续行动。

00:17:34.995 --> 00:17:42.856
分别报告有证据支持的结果和尚未解决的金额。在所有
问题都解决之前，结果也可以具有参考价值，前提是报

00:17:42.856 --> 00:17:44.300
告清楚说明其局限。

00:17:44.790 --> 00:17:53.307
如果服务变差了怎么办？将其与财务结果并列。跟踪约
定的指标：所需访问权限、工作完成情况、支持需求，

00:17:53.307 --> 00:18:00.607
或业务所有者确定的其他内容。订阅减少并不能抹去返
工或运营中的其他问题。FinOps

00:18:00.607 --> 00:18:06.864
Foundation 的 Quantify
Business Value

00:18:06.864 --> 00:18:11.035
指南明确包含服务和组织绩效，而不仅仅是货币成本。

00:18:11.670 --> 00:18:21.963
我的建议是，只有在另一个人能够跟进其比较和证据时
，才关闭福利索赔。记录范围和期间，保留源文件，解

00:18:21.963 --> 00:18:31.415
释调整内容，并由约定的审核员确认结果。认可做出贡
献的人员，不要将金额乘以涉及的部门数量。

00:18:32.090 --> 00:18:41.860
今天的原则是可追溯性。有人应该能够从报告的结果开
始，回溯到已批准的操作、已实施的变更以及支持这些

00:18:41.860 --> 00:18:43.455
内容的财务记录。

00:18:43.890 --> 00:18:52.675
下课。这是你们的作业。预留大约一小时，选择一项已
完成的技术变更，并使用你们有权访问的记录。

00:18:53.280 --> 00:19:02.720
请记录原始预期效益、其基准值及涵盖期间。在执行协
议或获批变更中找到生效日期。

00:19:03.280 --> 00:19:10.785
比较已实施的内容与已采购的内容。然后检查涵盖受影
响期间的发票以及任何相关贷项。

00:19:11.500 --> 00:19:21.516
记录变更的成本。解释原始估算与可支持结果之间的每
一项重大差异。如果缺少文件，请列出其名称并分配下

00:19:21.516 --> 00:19:30.305
一步行动。最后用一句话说明已验证的内容和尚未解决
的事项。将此页带给您的财务合作伙伴。

00:19:30.800 --> 00:19:35.213
如果您希望获得一种流程以帮助使该工作可重复，请在
运营 ITAM 商店中查找

00:19:35.213 --> 00:19:39.975
F02、Validate Benefits
and Report Business

00:19:39.975 --> 00:19:42.065
Outcomes。链接在节目附注中。

00:19:42.880 --> 00:19:49.215
在决策表（The Decision Table）
中，有一个自然的下一个问题：一旦你验证了一个结果

00:19:49.215 --> 00:19:55.549
，什么会导致你重新审视它？将该问题保留在你完成的
记录旁边。我们将回到决策如何随着业务变化而保持有

00:19:55.549 --> 00:19:56.325
效性的问题。

00:19:56.835 --> 00:20:05.201
案例文件已打开。1 个情境，1 页内容。约束条件
、你做了什么以及发生了什么。在通过网站发送前，请

00:20:05.201 --> 00:20:11.860
移除公司名称和敏感细节。发给我 1
个值得工作的素材，我将围绕它制作一期节目。

00:20:12.315 --> 00:20:18.806
我是 Bill Van Nort，这是
Operational ITAM 播客。保持对比

00:20:18.806 --> 00:20:24.560
可见。跟随账单的变化进行追踪。报告你可以支持的结
果。我下周再与你交谈。保重。
