编辑导语：交易履约的后台产品，可以理解为通过进行一系列履约业务流程，实现一笔交易从发生到完成的整个过程。本文作者就结合了个人经验，为我们深度分析了履约类后台产品的价值所在和结果验证方式，一起来了解一下吧。

后台产品，我把它分为3个类型，面向客户的SaaS，服务于公司管理事务的后台产品比如OA、财务系统，和服务于公司交易履约业务的后台产品。

交易履约的后台产品，可以理解为通过进行一系列履约业务流程，实现一笔交易从发生到完成的整个过程。

比如一个电商或者O2O的公司，通过运营或者销售完成客户转化，通过用户下单来形成交易，然后采购、物流配送业务来将商品送到用户手上，或派单、实时配送来完成交易，这里面的订单、供应链、CRM等系统，就是我们常见的后台系统。

我做这一块的后台产品这些年，最开始只会是按业务需求做，到后面我发现，大家都需要产品经理来证明你做的产品有什么价值，而后台产品要衡量产品和项目的效果比较困难，不一定能找到真能表现产品价值的数据指标。

比如说我要做一个供应链的采购、物流流程，涉及到一大堆单据流、状态机，但它的价值似乎只能描述为，我不做业务就没法线上运行。

再比如一个CRM系统，做了若干需求希望提升销售的成交转化率，实际上影响转化率的因素太多了，客户线索的质量，销售个人能力，外部环境，甚至销售今天的心情，都会对转化率这一结果有影响，导致即使转化率提升了，也不知道是哪个因素提升的。

但是即使后台产品的收益和效果难以量化，我们还是得知道产品为什么目标而做，并想办法去分析、验证，不然产品说不清价值，那产品经理不就没了价值，或者单纯的沦为给业务方打杂的。

本文主要结合我做过的几个案例，来写履约类后台产品的价值所在，和结果验证方式。SaaS类产品，和OA之类管理领域的产品，不在本文讨论范围内。

当然不同公司业务不一样，具体的产品设计思路也会有区别，本文适合小公司的或者入门级别的后台产品经理看看，也欢迎大公司的产品经理来批评指正。

一、为什么要做交易履约类后台产品

一个做在线交易的公司一定会有交易履约类后台产品，不然业务无法在线运转起来。这个点每个产品经理应该都知道，因为这是后台产品最基础的一个价值，即支持业务在线运转的基建价值。

除此之外，后台产品还有哪几方面的价值，我们可以从产品服务的对象去做分析。

不同于C端产品服务于用户、SaaS产品服务于某领域内的企业客户，交易产品首先面对的是一套运转中的业务，在业务中除了固有的业务流程，还会有一线的执行人员和管理人员的参与。

于此对应的，后台产品可以分出业务价值、用户价值和管理价值这三个层面的价值。以下针对这几个层面，阐述下具体的价值所在和验证方式。

二、基建项目

基建是每个后台产品的基础，没有基建就无法撑起一个后台。

一个公司的后台系统一定会包含很多基建的部分，比如做电商的公司要实现用户在线下单，就需要有管理商品的商品系统，实现订单流程的订单系统，支持使用优惠券的营销系统，再到用户体系、权限系统，这些都是基建的部分。

具体工作中，往往存在大量的基建项目。

一类是大型基建项目，从0到1做一个新业务模块，或者系统重构。

做这类大型基建项目的背景，通常是公司有了一块新业务，或者说老系统已经很难支持业务的不断发展，需要进行一轮重构以便更好的支持后续的需求。做一个大型基建项目的出发点通常不是业务，而是系统本身架构层面的一些问题，所以要衡量项目成果时，没法直接从业务数据上获得结果。

因此针对大型基建项目，不需要非得找某个指标去验证价值，想找也找不到，最多考核一下项目的上线时间即可。

还有一类是优化型的基建项目，比如修改一个业务规则，业务流程中增加一个环节，提供一个业务报表等等。

很多优化型的基建项目不是单独存在的，通常是业务上出现了需求，需要对应的做下基建来满足这个诉求。这类项目如果本身有其他维度的目标，那么可以直接用这个目标进行结果的验证，比如说上线一个业务报表能提升线下业务人员操作的效率，或者业务流程改一个环节能够让某个数据实时生成，等等。

不同业务规模的公司，对基建这个事情的方式、做法也不一样。对于处于业务初创期和发展期的小公司而言，基建是一个比较难把控的事情，因为第一小公司没有那么多的资源来给你做基建，第二早期一定是业务先行，初创期的业务随时有变更的可能，基建做的太重一旦因为变更被推翻，非常浪费开发成本，所以我不建议在业务还没定型的时候就做大规模的基建。

当业务相对稳定，进入发展期之后，可以抽时间做基建，如果基建做的太晚不完善只能在老系统不断打补丁，越到后面越不好用。但这个时候业务需求会越来越多，需要平衡做基建和支持业务需求的时间。

大公司的基建项目，通常是我们常说的中台建设。中台产品通过将可复用的模块抽象成中台服务，给到更多的系统使用，目标在于避免重复造轮子，造成资源的浪费。

中台产品服务于各个不同的业务终端，因此可以通过接入的系统数量，来验证中台产品落地的效果。本人没深入接触过大厂的中台，针对中台就不赘述了。

1. 面向管理，业务流和数据的在线、实时、精准

面向业务管理的价值，通常会将业务操作和业务数据，做到在线、实时、精准这3个要求。

对管理角度价值的理解，一个是流程管理上的价值，比如一个原本线下的业务作业，通过线上流程进行在线化、规范化，这样能够方便公司管理角色的人员进行业务的管控，并解决一些透明、合规、风控角度的诉求。

另一点是数据管理的价值，比如公司的库存、资产数据在线，便于追溯、核算成本，并作为发挥数据价值的基础。

在线、实时、精准，是衡量后台产品是否达到管理要求的3个标准，依次递进。在线，指的是某个业务流和数据需要在线上体现，不能只在线下运作；实时，是实现了业务在线之后，线上操作需要跟随业务实时进行，不能滞后去补录；精准，指的是数据在线后，计算、关联追溯逻辑需要准确，而且是系统的准确，并非人工填写的准确。

举个例子，某个电商公司的采购业务，需要向外部供应商进行采购。原先业务的模式是线下完成采购之后，在公司自己的系统中手动录一个数据。现在从管理和合规的角度，整个采购系统需要做到线下采购业务的在线实时和精准。

在线，通过供应商端将供应商的业务作业在线进行，解决原先供应商完全在线下的情况；实时，采购业务报价、采购、送货、结算的整个流程，由采购员和供应商实时线上操作，不能全部做完之后再补录，造成采购数据滞后影响后续履约数据一并跟着滞后；准确，商品采购价格和后续每个环节的加价规则准确，因为采购价格是商品成本的来源，采购价格不准直接影响成本核算。

管理角度的后台产品项目，衡量标准通常会有点偏定性，因为还没有对业务本身做到提升，所以会用类似于某某业务是否在线，数据是否精准，作为定性的验证方式。

一种相对比较完善的做法，比如衡量一个业务流中的环节是否在线，可以先将业务流的每个环节通过流程图的方式抽象出来，然后一一数有多少个环节，几个环节不在线，产品上线后做到了几个环节的在线。比如上面这个采购案例，业务流中有报价、采购、送货、结算这4个环节需要供应商在线参与，那么验证方式就是这4个环节，有几个做到了供应商在线。

针对数据，比如衡量是否准确，也是同样的道理，比如上个案例中有商品报价、采购价格、商品批次成本等，验证方式就是看这几项数据，有哪几项做到了准确。

数据的在线实时精准，除了管理目的之外，还起到了通过积累数据，发挥数据价值的作用，这一点在后面会写到。另外有人会把这一点视为基建的一部分，这个看每个人的理解了。

虽然说流程数据的在线这个事情，实现形式就是基建，但这块需求是能说得出项目价值的，跟虚无缥缈的系统重构还是有一些差别的。

2. 面向用户，用户操作的提效，人效的释放

面向用户的价值，通过提升用户使用产品的效率和体验的方式，提升公司的人效。

对用户的价值比较理解，后台产品的用户体验，需要让用户能高效的处理业务，并且能满足多方数据协同、特殊化场景、大批量操作等情况。

提升用户效率是实际可以给业务带来可见的帮助的一个点，除了用户使用的爽之外，给用户提效就是帮公司提升了人效，节省了人力，尤其是针对一线的业务人员。

能被称作提效的产品需求范围很大，小到排序、批量操作、导出excel这类细节功能，大到流程重构、业务操作流转的自动化等大项目，只要是提升了人效，都可以称之为提效。

通常业务方很喜欢给产品提方便他们自己提效的小需求，哪里加个字段，哪里调下排序之类的，但产品经理不能陷入到他们提的这些小细节当中，而且也要关注更多的人，坐办公室的运营人员经常会提需求，一线业务人员不一定会给产品提需求，但他们的提效需求可能更重要。

提效的起点是用户线下实际的业务操作，因此提效的衡量标准也需要回归线下业务和人。

常见的方式有两种，第一种统计时间，将用户的使用时间量化，什么业务操作，哪个角色，X个人，目前花费X分钟/天，产品预计能提升X分钟，不同的业务城市、熟练度不同的人员，这个时间是否有不同。这个量化的时间不只是用户操作产品的时间，更确切的是用户处理业务的时间。具体时间根据实际线下的业务情况进行预估。

举个例子，某电商公司的物流配送业务，从供应商送货，到排线，现场装车调度，配送，货物清点，整个流程效率过低时间太长，影响履约时效。接下来需要分析每个环节，有哪些因素影响人效，比如供应商送货慢，因为给到供应商的送货单会慢30分钟；排线每次都要人工排一遍，耗时15分钟；现场对货需要通过人工制作的excel表，多出来额外做表的20分钟，等等。

针对这些问题输出产品方案，送货单自动推送给供应商，预计能提前10-20分钟送货；在线自动排线，并自动导出现场对货的表，预计省去这35分钟。其他环节也是同样的逻辑，最终将每个环节的解决方案，提效的时间，和开发成本，综合考虑。

第二种更加宏观一些，统计人，某个范围的业务需要X个人完成，或者说一个人能处理多少范围的业务。这个数据会涉及到公司的人员数量，是一个反应结果的数据，影响的因素会比较多，不限于产品功能的提升。

举个例子，某公司的管理业务，某站点当前业务管理人员和一线业务人员的比例为1:5，公司需要提升管理的人效，以节省公司管理人员的人力成本。

针对这一点，产品通过将更多一线业务在线管理，提供报表，提供管理建议等手段，让一个管理人员能更有余力的管理更多一线业务人员，提升业务人员的数量同时不需要再增加管理人员，通过后续管理人员和一线业务人员的比例是否低于1:5，可以观察产品的效果。

这些提升用户人效的后台产品都有一个前提，就是用户有没有使用你做的产品功能。如果不好用，或者用户习惯了之前老的方案导致不想用，那么这些个对业务提效的目标都无从谈起了。

有些时候新功能上线时用户确实不习惯，尤其是一些对线上产品感知不大、又比较忙的一线业务人员，推广和适应都需要时间，不过产品上还是得保证首先好用让用户愿意用，当用户习惯之后，再去看实际的效果。

3. 面向业务，业务运转的自动化，高效、准确

面向业务的价值，指的是通过业务的计算、匹配、流转规则，对业务从人工转化为自动化的过程。

对业务的价值是后台产品最直观、有效，也是更终极的价值。诸如业务流程的自动化，对订单、采购数量的预测，订单和履约之间的智能分配，异常状况的预警等，都属于后台产品对业务的价值。这里有些已经超出后台产品，属于策略产品的部分。

业务自动化的前提条件，是数据的在线和准确，也就是前面写到的面向管理要做的部分。因为没有准确的数据，通过数据价值去进行业务的自动匹配计算就无从谈起。所以针对业务的价值，通常是业务较为后期的目标。

一个业务还未成熟的公司，一些决策和预警的业务，一般都是人工执行为主，这个阶段的重点可能更多在于流程在线准确和用户提效的价值，当公司业务逐渐扩大成熟之后，因为自动化业务的准确率、匹配度等都高于人工，再逐步由系统自动化代替人工。

针对业务的衡量方式，直接从对应的具体业务指标入手，看这个指标是否有提升即可。这块相关的指标一般是比例、时间之类的，比如业务数据的准确率，履约完成率，流程的时效，等。

举个例子，某O2O公司的订单履约业务，存在由于超出履约时效，导致用户不满意、履约率降低的问题。其中一个问题，在订单采购环节如果出现库存缺货，会导致订单履约时间被拉长，现在需要提升缺货订单的履约时效。

原先的方案，只是定期提采购需求的时候进行采购，新的策略中，首先优化缺货的处理策略，缺货的商品先找周边的仓库调度，如果没有就直接提采购需求，通过减少从下单到采购中间等待的时间来加快履约时效。

这一点可以通过缺货订单的到货时效来验证。同时，通过对采购需求计算逻辑进行优化，让每个站点在预估采购需求量时候能够更加准确，减少缺货情况的发生。这一点可以从缺货订单的比例进行验证。

整体上，可以看缺货订单的订单履约率是否有提升。

从以上案例能看出来，很多处理方式实际上是业务策略，业务数据的指标表现的就是业务方案的效果。业务指标的影响因素不仅限于产品上的改动，业务上自己的策略、人员、能力等因素也会影响业务指标，而且影响的更大一些，指标本身业务方也会更加关注。

这个方面产品和业务是分不开的，产品方案和业务策略提升的是同一个大的指标，具体到每个项目，需要再进一步对指标进行分拆，尽可能减少指标的影响因素。实在分拆不了的，那只能视为产品和业务共同的影响，至于是产品主导还是业务主导，得看不同公司不同业务线。

这是3个价值方向，并不是具体产品功能，这几点之间是相辅相成的，不是分隔独立的。事实上不同的目标，很有可能都是同一个方案去解决。

比如，将某块在线下进行的业务，通过线上的自动化规则代替人工操作，那么同时起到了针对用户的提效，和针对业务提升准确度的价值。再比如，数据的在线精准，一方面起到了管理价值，一方面也作为业务自动化的数据基础。

尤其是基建，很多后台产品的需求都会涉及到一部分基建，常见的比如让某业务流程线上化替代人工、让某数据在线之类的，将这些基建项目往在线管理和用户提效方向靠，通常就能找到可以衡量的价值。

三、从指标拆解后台产品对公司的价值

以上这些后台产品的价值，可以用我们常用的两个词，提效和降本来概括。产品的最终目的都是为公司的盈利而服务，不管什么方式的提效和降本，都能往盈利这个大目标上去靠。

当我们做一个后台产品，如何找到适合且有用的指标，以及这个指标会如何影响到公司整体的目标，对公司的价值到底产生在哪，这个问题可以通过指标拆解去看。不同的业务部门，会有自己的核心指标作为考核的依据，具体到每个项目，再会拆分二级三级指标，找到一个适合评估项目结果的指标。

比如一个做交易的公司的指标拆解，利润之下是收入和成本。其中收入=订单量*客单价，订单量取决于流量、转化、履约、复购这几个因素。

后台产品在其中能发挥的作用，流量方面，通常是运营和市场带来的，产品的CRM和运营支撑系统可以帮助运营和市场人员提升流量的获取、转化之类的；履约即提升交易的履约率，包括时效、距离、库存、服务等各种影响履约的因素，比如前面提到的案例，提升商品缺货订单的履约率。

成本，大致可以分为原料、营销、售后、仓配、人力这几类。

原料和仓配属于供应链业务，后台产品在其中除了做到数据在线准确之外，也能起到业务上的降本，比如通过供应商评级帮助采购选择原料成本更低的供应商，通过采购数量计算降低库存损耗等等。

人力成本方向，是后台产品发挥比较大的地方，所有提升人效相关的产品，包括降低每人次的业务操作时间、提升每人次的业务范围或管理范围，都是对人力成本的提升。

整体上而言，后台产品无论对公司业务还是对用户，都有比较明确的价值，但有些类型的产品，收益还是相对难评估的。尽管如此，作为后台产品经理，还是要尽可能的去衡量产品对业务的收益，无论是对公司还是对用户，定量还是定性，尽可能找到比较合适的指标。

#专栏作家#

潘帕斯雄鹰，人人都是产品经理专栏作家，进击、踩坑中的产品狗一枚，关注互联网，写过小说，看过哲学。简书：潘帕斯雄鹰。

本文原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自 Unsplash ，基于 CC0 协议。