财务分析师通常不负责设定 KR--那是 BP 团队或各部门负责人的工作。本文的起点是：运营团队给出评分之后，如何将其转化为模型输入，并向下传导至 P&L 底线。
Google re:Work OKRs 指南中的两类目标：对应两套财务处理逻辑
rework.withgoogle.com 将承诺型与挑战型 OKR 的区分追溯至 Andy Grove 在英特尔建立的目标管理体系，Grove 于 1983 年在 High Output Management（Harper Business）中系统记录了这套方法。John Doerr 1999 年将其引入 Google，并在 2018 年的 Measure What Matters（Portfolio/Penguin）中进一步阐述。
re:Work 指南核心表述："如果挑战型 KR 持续得到 0.7 分，说明目标难度设定适宜；如果持续拿到 1.0 分，则应重新审视--很可能还不够有野心。"
对财务建模的含义：
| 承诺型（Roofshot） | 挑战型（Moonshot） | |
|---|---|---|
| 评分目标 | 1.0 | 0.6-0.7 |
| 未达成的含义 | 出现实质性问题 | 正常，重新校准 |
| 财务处理 | 支撑基准预算假设 | 驱动上行情景 |
| 评分公式 | MIN(1, 实际值/目标值) | 实际值/目标值（可超过 1.0） |
| 典型示例 | ARR 续约率 ≥95%、Q2 新签 180 万元 | NRR ≥115%、3 个企业级集成上线 |
映射层：OKR 评分 → 加权假设值
核心公式只有一行：
// Assumptions!B3 - NRR 假设值，OKR 评分加权混合
=KR_Tracker!E4 * KR_Tracker!G4 + (1 - KR_Tracker!E4) * KR_Tracker!F4
// 评分 0.73：(0.73 × 115%) + (0.27 × 108%) = 113.1%
E4 为当前 OKR 评分，F4 为基准值（108%），G4 为挑战值（115%）。评分每月更新后，假设值自动调整，无需手动覆盖，也不存在评分已更新但模型未同步的"僵尸单元格"。
KR_Tracker 标签页结构（每行一个关键结果）：
| 部门 | 关键结果 | 基准值 (F) | 挑战值 (G) | Q2 2026 评分 (E) | 加权假设值 |
|---|---|---|---|---|---|
| 客户成功 | NRR ≥115%（Q4 2026） | 108% | 115% | 0.73 | 113.1% |
| 销售 | Q2 新签订单 ≥180 万元 | 140 万元 | 180 万元 | 0.85 | 174 万元 |
| 产品 | Q3 前 3 个企业级集成上线 | 1 个 | 3 个 | 0.60 | 2.2 个 |
新签订单（承诺型 KR）同理：(0.85 × 180 万元) + (0.15 × 140 万元) = 174 万元，直接流入新增 ARR 行，无需情景切换。
从续约 ARR 到 EBITDA：完整传导链
续约 ARR 会动是前提，EBITDA margin 变了多少才是汇报层面的真实问题。
以期初 ARR 1,250 万元为基础，基准情景（NRR 108%）与挑战情景（NRR 115%）的续约瀑布：
| 季度 | 基准（NRR 108%） | 挑战（NRR 115%） | 差值 |
|---|---|---|---|
| Q1 2026 | 1,275 万元 | 1,297 万元 | +22 万元 |
| Q2 2026 | 1,300 万元 | 1,344 万元 | +44 万元 |
| Q3 2026 | 1,325 万元 | 1,391 万元 | +66 万元 |
| Q4 2026 | 1,350 万元 | 1,438 万元 | +88 万元 |
| 全年营收差值 | +219 万元 |
将差值向下传导至 P&L（以 75% 毛利率为例，服务存量客户边际成本低、客户成功团队人力固定假设）：
| 传导层级 | 公式引用 | 差值 |
|---|---|---|
| 全年营收增量 | ARR_Bridge!H12 | +219 万元 |
| 毛利润（× 75%） | × Assumptions!$B$6 | +164 万元 |
| 增量客户成功成本 | 固定假设，0 增量 | 0 |
| EBITDA 增量 | P&L_Summary!B15 | +164 万元 |
// P&L_Summary!B15 - EBITDA 增量，源于 NRR OKR 加权假设
=ARR_Bridge!H12 * Assumptions!$B$6
// 219 万元 × 75% = 164 万元
// ARR_Bridge!H12 = 四季度续约 ARR 差值汇总行
ARR_Bridge!C8（Q1 续约 ARR，按评分加权 NRR 计算）：
// ARR_Bridge!C8 - 季度续约 ARR
=ARR_Bridge!B8 * (1 + (Assumptions!$B$3 - 1) / 4)
// B8 = 期初 ARR（1,250 万元），B3 = 113.1% 混合 NRR
// 结果：1,250 万元 × 1.03275 = 1,291 万元
将公式横向拖拽至 Q2-Q4。完整传导链为：
KR_Tracker!E4（OKR评分）
→ Assumptions!B3（NRR 加权假设）
→ ARR_Bridge!C8:F8（续约 ARR 逐季）
→ ARR_Bridge!H12（全年差值汇总）
→ P&L_Summary!B15（EBITDA 增量）
当客户成功团队将评分从 0.73 更新为 0.81 时，Assumptions!B3 自动重算为 (0.81 × 115%) + (0.19 × 108%) = 113.7%，164 万元的 EBITDA 增量随之实时更新--这是可以直接写进董事会备忘录的数字，而不是三周前锁定在某个标签页里的静态判断值。
两类 KR 的评分公式
承诺型 KR，上限封顶为 1.0：
// KR_Tracker!E4 - 承诺型 KR（新签订单目标）
=MIN(1, Actuals!D4 / KR_Tracker!D4)
// Actuals!D4 = Q2 实际订单金额；D4 = 目标值 180 万元
挑战型 KR，允许超过 1.0，超额完成清晰可见：
// KR_Tracker!E7 - 挑战型 KR（NRR）
=Actuals!D7 / KR_Tracker!D7
// 实际 NRR 118% vs. 目标 115%：评分 = 1.02
部门加权平均分（H 列为 KR_Weight，I 列为状态，J 列为周期标签，各目标下 KR 权重之和为 1.0）：
// Summary - 客户成功部门当前周期加权平均分
=SUMPRODUCT(
(KR_Tracker!$B$2:$B$50="客户成功") *
(KR_Tracker!$I$2:$I$50<>"Cancelled") *
(KR_Tracker!$J$2:$J$50=Assumptions!$B$1) *
KR_Tracker!$E$2:$E$50 *
KR_Tracker!$H$2:$H$50
) / SUMPRODUCT(
(KR_Tracker!$B$2:$B$50="客户成功") *
(KR_Tracker!$I$2:$I$50<>"Cancelled") *
(KR_Tracker!$J$2:$J$50=Assumptions!$B$1) *
KR_Tracker!$H$2:$H$50
)
// B1 = 当前周期标签，例如 "Q2 2026"
用 SUMPRODUCT 替代 AVERAGEIFS 的原因："上线3个企业级集成"与"ARR 续约率 95%"在财务量级上不能等权平均--re:Work 指南未提供权重机制，需在 KR_Weight 列手动配置，方可生成对汇报有意义的部门评分。
re:Work 指南对财务团队的两个盲点
盲点一：周期中途修改 KR 目标值
若"NRR ≥115%"在八月因大客户流失被修订为"NRR ≥110%"，问题随之而来：财务模型以 115% 为基础构建，董事会 Q2 汇报中也引用了 115%，而 KR 目标值已悄然变更。解决方案：在周期启动时通过 KR_Lock 时间戳列锁定目标值，变更时另起一行并标记"已修订"，保留原行用于差异审计。财务模型引用锁定行进行差异分析，引用修订行进行前瞻预测，并在董事会摘要备注中注明差距来源。
盲点二：KR 权重缺失
指南未提供任何加权机制。在 KR_Weight 列（H 列）配置权重，要求每个目标下各 KR 权重之和为 1.0，再将 AVERAGEIFS 替换为上方的 SUMPRODUCT 公式，即可生成财务量级加权的部门评分，用于投资人路演和董事会汇报。
将实际数据实时拉入追踪器
映射层能否发挥作用，取决于 Actuals 列是否保持实时更新。ModelMonkey 可直接从 Stripe、HubSpot 或数据仓库将实际数据拉取至 KR_Tracker，使 Actuals!D4（Q2 实际新签订单）无需手动导出 CSV 即可自动更新。截至 2026 年年中，OKR 关联模型最常见的失效模式不是公式设计问题，而是实际数据依赖人工操作、滞后六周，导致 P&L 底线数字在两次复盘会议之间失去参考价值。
如需从零构建追踪器，OKR Google Sheets 模板涵盖完整的五标签页搭建方法，包含上述 KR_Tracker 结构；若需在周期中期保持 OKR 状态实时更新，请参阅在 Sheets 中刷新 OKR 状态。
常见问题
OKR 评分多久更新一次，才能保证财务模型的时效性？
re:Work 指南建议每月评分一次，季度末正式评定。对财务模型而言，月度更新已足够--KR_Tracker!E4 每月刷新，Assumptions!B3 自动重算，续约计划与 EBITDA 假设在同一刷新周期内更新。若等到季度末才更新，则在长达三个月的时间窗口内，模型依赖的假设值与实际运营状态持续脱节。
承诺型 KR 未能达成，财务模型如何响应？
承诺型 KR 的加权公式上限为 1.0，未达成（如评分 0.8）时，Assumptions 层对应的假设值会自动低于基准值：(0.8 × 目标值) + (0.2 × 基准值)。这不是正常的"重新校准"，而是需要触发预算差异分析和立即上报的信号，处理逻辑与挑战型 KR 低于 0.7 截然不同--公式的上限封顶设计本身就是这一区分在模型层面的体现。
如何处理多个 KR 同时影响同一个财务假设的情况？
增加 KR_Assumption_Map 列，将每个 KR 映射到对应的 Assumptions 单元格地址。当多个 KR 共同驱动同一假设（例如两个 KR 均影响 NRR）时，在 Assumptions 层用 SUMPRODUCT 按权重汇总各 KR 的贡献值，确保每个假设只有一个公式入口，避免多人协作时的覆盖冲突。
运营团队和财务团队如何协同维护 KR_Tracker？
最有效的分工：运营团队（BP 或各部门负责人）只负责更新 E 列的 OKR 评分与实际数据，不触碰 F、G 列的基准值和挑战值（这两列在周期启动时由财务团队锁定）。评分列与假设列的权限分离，是防止"评分和基准值被同一人同时调整"这一常见错误的最简单机制，也是在董事会材料中保持数据可溯源性的基础。