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

文章插图
后台产品，我把它分为3个类型，面向客户的SaaS，服务于公司管理事务的后台产品比如OA、财务系统，和服务于公司交易履约业务的后台产品。
交易履约的后台产品，可以理解为通过进行一系列履约业务流程，实现一笔交易从发生到完成的整个过程。
比如一个电商或者O2O的公司，通过运营或者销售完成客户转化，通过用户下单来形成交易，然后采购、物流配送业务来将商品送到用户手上，或派单、实时配送来完成交易，这里面的订单、供应链、CRM等系统，就是我们常见的后台系统。
我做这一块的后台产品这些年，最开始只会是按业务需求做，到后面我发现，大家都需要产品经理来证明你做的产品有什么价值，而后台产品要衡量产品和项目的效果比较困难，不一定能找到真能表现产品价值的数据指标。
比如说我要做一个供应链的采购、物流流程，涉及到一大堆单据流、状态机，但它的价值似乎只能描述为，我不做业务就没法线上运行。
再比如一个CRM系统，做了若干需求希望提升销售的成交转化率，实际上影响转化率的因素太多了，客户线索的质量，销售个人能力，外部环境，甚至销售今天的心情，都会对转化率这一结果有影响，导致即使转化率提升了，也不知道是哪个因素提升的。
但是即使后台产品的收益和效果难以量化，我们还是得知道产品为什么目标而做，并想办法去分析、验证，不然产品说不清价值，那产品经理不就没了价值，或者单纯的沦为给业务方打杂的。
本文主要结合我做过的几个案例，来写履约类后台产品的价值所在，和结果验证方式。SaaS类产品，和OA之类管理领域的产品，不在本文讨论范围内。
当然不同公司业务不一样，具体的产品设计思路也会有区别，本文适合小公司的或者入门级别的后台产品经理看看，也欢迎大公司的产品经理来批评指正。
一、为什么要做交易履约类后台产品一个做在线交易的公司一定会有交易履约类后台产品，不然业务无法在线运转起来。这个点每个产品经理应该都知道，因为这是后台产品最基础的一个价值，即支持业务在线运转的基建价值。
除此之外，后台产品还有哪几方面的价值，我们可以从产品服务的对象去做分析。
不同于C端产品服务于用户、SaaS产品服务于某领域内的企业客户，交易产品首先面对的是一套运转中的业务，在业务中除了固有的业务流程，还会有一线的执行人员和管理人员的参与。
于此对应的，后台产品可以分出业务价值、用户价值和管理价值这三个层面的价值。以下针对这几个层面，阐述下具体的价值所在和验证方式。
二、基建项目基建是每个后台产品的基础，没有基建就无法撑起一个后台。
一个公司的后台系统一定会包含很多基建的部分，比如做电商的公司要实现用户在线下单，就需要有管理商品的商品系统，实现订单流程的订单系统，支持使用优惠券的营销系统，再到用户体系、权限系统，这些都是基建的部分。
具体工作中，往往存在大量的基建项目。
一类是大型基建项目，从0到1做一个新业务模块，或者系统重构。
做这类大型基建项目的背景，通常是公司有了一块新业务，或者说老系统已经很难支持业务的不断发展，需要进行一轮重构以便更好的支持后续的需求。做一个大型基建项目的出发点通常不是业务，而是系统本身架构层面的一些问题，所以要衡量项目成果时，没法直接从业务数据上获得结果。
因此针对大型基建项目，不需要非得找某个指标去验证价值，想找也找不到，最多考核一下项目的上线时间即可。
还有一类是优化型的基建项目，比如修改一个业务规则，业务流程中增加一个环节，提供一个业务报表等等。
很多优化型的基建项目不是单独存在的，通常是业务上出现了需求，需要对应的做下基建来满足这个诉求。这类项目如果本身有其他维度的目标，那么可以直接用这个目标进行结果的验证，比如说上线一个业务报表能提升线下业务人员操作的效率，或者业务流程改一个环节能够让某个数据实时生成，等等。
不同业务规模的公司，对基建这个事情的方式、做法也不一样。对于处于业务初创期和发展期的小公司而言，基建是一个比较难把控的事情，因为第一小公司没有那么多的资源来给你做基建，第二早期一定是业务先行，初创期的业务随时有变更的可能，基建做的太重一旦因为变更被推翻，非常浪费开发成本，所以我不建议在业务还没定型的时候就做大规模的基建。

稿源：(人人都是产品经理)

【傻大方】网址：http://www.shadafang.com/c/110E4623R021.html

标题：用户|交易履约类后台产品的产品价值和验证方式