笔者从工作实践中的疑问出发，结合专业知识，分享了自己关于B端产品收益的所思所想，供大家一同参考和学习。

记得上个月开需求管理会议，在讨论如何提升IT研发效能时，有个问题引起了各位老师热烈讨论，即如何衡量B端产品的收益？这个问题让我感到十分困惑，会上听了各位前辈的讨论收获颇多，后续查阅了相关资料，写下了自己的一点思考。

01 首先要对B端产品做分类

B端产品主要可分为下面三种：

1. 业务项目

指具备明确业务价值和收益的项目，很多时候，这类项目具备某方面明确的业务价值，但却难以衡量或度量效果。

2. 基建项目

指业务价值不明显，但是又非常必要的项目。一方面可能是因为功能完善的需要，另一方面可能是因为软件架构抽象的需要（比如最近大热的中台系统就属于此类）。

3. 运维类

指产品已经正常投入使用，但是仍需要进一步迭代优化。

此外业务项目和基建项目多见于企业快速扩张期，需要IT快速配套支持，此时的组织架构是每条业务线都有对应的IT团队。而运维类多见于企业稳定期，此时多条业务线共用IT团队，目的是为了节省研发成本，精细化管理。

02 如何衡量业务项目的收益 1. 企业内部建立IT分包机制，模拟内部盈利分层体系

B端产品之所以很难衡量收益的原因在于：企业内部产品不接触市场，和to c 产品的用户数、营收指标相比，显得十分模糊，很难确定的定量考评。那么我们为什么不可以内部模拟市场化体系呢？

具体来说：在企业内部建立IT分包机制，业务方为甲方，IT团队被定义为乙方。甲方向乙方支付佣金。于是，对于这类TO B产品团队的考核指标就变成了这样的内部分成结算，在内部模拟一套市场化的盈利分成体系。

那么问题来了，业务方根据什么评估B端产品的收益呢？

B端产品的核心价值是帮助企业解决某类经营管理问题。而作为服务于某条业务线或某个业务单元的B端产品，常常在以下方面对业务产生价值：提高收入（规模）、降低成本（成本）、保证品质（品质）、控制风险。其中规模、成本、品质是业务部门运营管理的核心优化方向，而风控属于相对独特的一类业务监管需求。

以上四点可以作为B端项目的大方向的收益类型。任何业务项目的项目目标，都会落在其中某点上。如果某个项目看起来可能有多个收益，那可以分别评估，汇总计算。

例如针对保险公司高客搭建服务预约管理系统，通过此系统高客管家可以线上为高客预约服务，大大节省了时间。同时服务的进度和情况高客管家可以实时在系统中看到并及时告知客户，提升了客户满意度（比如NPS从5到6）。

那么这个项目对于业务的收益就是节省人力成本和品质（提升客户满意度）。假设系统可以节约人力成本100万元，业务部门愿意NPS（净推荐值）从5到6的提升付出100万元。那么此项目的收益就是200万元。

另外需要注意的是，在衡量B端系统的收益时：

要站在一个长期的视角，如果过于短视，那么衡量B端产品的收益往往是低估的；

在评估B端产品收益时，需要对IT有个大体的了解才能较为准确的评估收益。

2. 找到最关键的数据指标

B端产品难以衡量收益的原因还有一个是影响业务指标的因素复杂，除了软件产品本身的影响以外，往往还取决于业务政策、业务人员的能力和态度等外部因素。

例如:某外卖平台骑手端系统一直是抢单模式，现在上线了系统派单，观察发现上线后平台日均收入有显著提升，但实际上影响收入的因素太多了，比如菜品提价、平台抽成变化、骑手数量、平台流量，都是影响因素，这些因素互相掺杂在一起，导致很难衡量收入指标的变化，究竟有多少是因为产品功能而改善的。

此处提供两种解决思路：

（1）拆分一级指标

我们知道：外卖平台日均收入=每日流水*平台抽成，我们试着将收入指标进行层层拆解。

每日流水=每日单量*每单平均流水

每日单量=骑手数量*骑手每日平均跑单量

因此，该功能是影响骑手每日平均跑单量从而影响平台收入，可以考核骑手每日平均跑单量，观察项目上线前后指标的变化，来评估项目收益。

（2）做AB测试

还是刚才那个例子，选取两批特征完全相同的骑手，一组作为实验组，提供系统派单功能，一组作为对照组，还是原来的人工抢单。观察两者在骑手每日平均跑单量的对比，来评估项目收益。

然而，B端项目很多时候难以执行AB测试，例如，如果业务流程是涉及到外部部门协作的完整流程机制，那么如果涉及到新业务流程上线，就不可能新老流程并存，让协作部门某些时候走新流程，某些时候走旧流程。

这可能正是B端产品收益难以衡量的一个致命问题，B端产品的AB测试以及小流量实验，实施成本巨高，很多时候甚至无法实施，这就导致很难准确的比对、测量项目收益。

03 如何衡量基础类项目的收益 1. 考核交付质量和完成时间

在B端产品项目中，基建项目必然会占到一定的比例，这是由于B端产品的性质决定的。B端产品，作为复杂系统，一整套体系的运转，必须是多种类型的软件功能组合而成，例如，要有权限管理、数据管理等功能。这类对业务没有明显价值和收益，但对于软件系统又非常需要的功能，属于基础建设功能。

对于此类项目：考核交付质量和时间就行。交付质量就看发生生产事故的上线次数/全部需求总数。

交付时间可以以行业内相似公司类似系统的建设时间作为参考。

2. 对于中台建设项目，考核系统接入量以及人力节约

中台的目的是抽象建设可以复用的软件系统或模块，例如将各个业务系统都需要使用的短信中心抽象成基础服务，供多个系统使用。

因此中台产品很重要的一个目标，是所谓避免重复造轮子问题，那么则可以通过其接入的客户端数量，来估算研发人力成本的节省。

04 如何衡量运维类项目的收益 1. 考核交付质量和时间

同基础类项目。

2. 考核业务满意度

可以借鉴NPS的方法，只不过此处的用户是业务方。

05 最后的思考

B端产品的收益确实难以评估，但是依然要尽最大努力评估、分析项目，否则就没有继续优化迭代决策的依据，并且思考项目收益如何衡量的过程，本身也是对需求和项目更深层次的分析论证的过程。如果你不能度量一件事情，那么你一定要谨慎思考到底该不该去做。

积分+9999999999999999999999999999999999999999999999999999999999999999

999

999

999

999

999

999

99

9999