资金风险是计费系统中永恒的挑战，一旦发生资损，不仅会对企业造成直接的经济损失，还可能引发信任危机。本文从资金风险治理的角度出发，提出了量化指标设计的五大原则，供大家参考。

资金风险是计费永恒的主题之一，也是计费产品日常面临的主要挑战之一。

计费如果有资金风险，就像人中了慢性病毒一样，直至毒发的一天，才“悔之晚矣”，谁都不想中毒，就像每个产品都不希望自己的产品方案“带病上阵”一样，但产品经理对项目的精力投入，在项目上线时达到顶峰后会迅速进入低谷，资损发生时往往伴随着弱精力投入，所以资金风险的发生具有时间上的滞后性，这就是为什么资损运营如此关键的核心原因之一。相对应地，产技预期的目标就是要主动识别资金风险并及时治理，“扼杀”在萌芽之时，避免事态扩大。

既然资损运营如此重要，那么要怎么做才能最大程度避免资损的发生？

第一，要能主动识别资金风险。主动识别光靠人的肉眼肯定不够，而且非常不经济，那么就必须要有系统、有工具能替代人、帮助人识别，就像每次发烧意味着你的免疫力下降、每次体验时隐形健康指标超标你就知道身体状态不佳一样，你得需要系统有个“东西”告知产品系统“病”了，这就是可度量（专业术语叫量化），比如有XX笔订单没有正常结算，此处不讲实例，只讲认知。度量指标的设计遵循几个原则：

1）真实性。不用赘述，非常基础，也是非常底层的原则。指标是给人看的，本质是要帮助人解决问题的，弄虚作假没必要，而且最终坑的只有自己。

2）完整性。指标设计，要覆盖所有横向的相关产品域、产品子域，纵向要cover所有执行流程的子节点，否则100%的精力投入在80%的大多数，那剩余的20%就很可能成为压倒你的“最后一根稻草”，而且指标的不完整，也无法100%让团队信服，何以自证自己的“权威性”和“专业性”？我觉得，“行百里者半九十”，“事要竞全功”，可以有策略，但必须要完整推进。

如何定义B端产品及B端产品经理方法论

相较于C端产品，B端产品最大的特点是：面向特定领域用户，且数量少得多，但更注重对用户专业领域操作流程的深度挖掘——也就是专业性更强，与业务的结合更紧密。

查看详情 >

3）及时性。指标的生产时效要快，快到什么程度？快到给自己团队争取解决时效、快到将舆情风险、实际影响压缩到最低。当然指标的生产快还不够，使用指标的人要快速响应才能发挥最大效能，这里考验的是产技的基本功、敏锐嗅觉和组织协同能力，如果说需求推进上线需要的是产技的基础专业能力，那么运营资损、处置资损考验的则是产技的应急决策、组织协同等更高阶的能力、更综合的素养。

4）层次性。或称为可拆解性。

在资金规模足够庞大、支撑足够多的差异化行业时，必然需要产品设计多层次的结构化指标（说的专业点，类似杜邦分析法的底层逻辑），每层结构的指标侧重实现的目标不同，比如第一层反应整体的指标，往下个层次拆，要反映更细粒度、更具体产品域的问题。

当然，层次性，还有个区分维度，一种层次是非常明显的资损case识别，比如某个单子的计费流程没有完整地流转，在某个节点卡住了，识别起来相对容易；另一种层次是比较难发现的资损case，像人类的慢性病一样，表明感受不到明显不适但身体已在恶化，这种需要部署相应的稽核模型才能发现，比如某个订单，需要在两个异构系统中实现两个不同的费用计费，其中有个正常计费，另外个没计费或者计费金额错误，需要相关性稽核才能发现，这种需要长期的治理经验积累和总结才能做到。

5）拆解到人。最后的最后，无论指标设计的多么复杂、庞杂，都必须要能拆解到人，执行任务拆解到人，需要人去执行，这是产品化的基准。如果不能自动拆解到某个业|产|技|测执行下去，缺少“临门一脚”，问题并没有得到根治和解决。某种程度上，拆解到人是主动识别资损风险的本质诉求。

根据系统的成熟度，拆解到人有不同的策略支撑，逐步推进。第一阶段，个人建议，可以先实现到计费相关指标的直接负责人，由他负责推进；接着可以考虑，根据异常原因实现产品域之间的穿透，自动链接到更上层、更接进问题发生第一现场的人。

第二，要能主动运营已经发现的资金风险。要能基于已经量化的资损风险和拆解到人，用一套标准的流程机制，替代人去推进治理，重点是运营SOP的设计，关键则在于SOP的执行考核。

1）将相关的产品域负责人纳入到流程分支节点。更高阶的是，能根据系统的异常，提前预置或者配置到系统中，做到前置的提醒或者阻断，但对一号位的综合素质要求以及对上游产技的约束和资源配备要求都非常的高，循序渐进即可。

2）对SOP的执行考核。SOP设计后，更关键的是执行是否到位，如果流程执行非常拖沓，那流程的设计就形同虚设，没有起到推进治理的核心作用。我觉得提供两点作为思考上的抛转引玉，一是往上升级、寻求更大能级的人介入；二是通过财务的专业性和重要性来推进。

最后，避免资金风险的再次发生。只要业务在持续发展，资金风险敞口就会一直存在，也在时刻变化着，完全避免风险就像产品把需求都做完一样，更像是非常完美的场景，没法出现在现实中。个人觉得，有风险敞口不可怕，更可怕的是没有产品化的手段在支撑。只要能及时发现并治理风险、相同风险不再二次发生，“今天比昨天好，这就是希望”，这就是进步。