当业务相对稳定，进入发展期之后，可以抽时间做基建，如果基建做的太晚不完善只能在老系统不断打补丁，越到后面越不好用。但这个时候业务需求会越来越多，需要平衡做基建和支持业务需求的时间。
大公司的基建项目，通常是我们常说的中台建设。中台产品通过将可复用的模块抽象成中台服务，给到更多的系统使用，目标在于避免重复造轮子，造成资源的浪费。
中台产品服务于各个不同的业务终端，因此可以通过接入的系统数量，来验证中台产品落地的效果。本人没深入接触过大厂的中台，针对中台就不赘述了。
1. 面向管理，业务流和数据的在线、实时、精准面向业务管理的价值，通常会将业务操作和业务数据，做到在线、实时、精准这3个要求。
对管理角度价值的理解，一个是流程管理上的价值，比如一个原本线下的业务作业，通过线上流程进行在线化、规范化，这样能够方便公司管理角色的人员进行业务的管控，并解决一些透明、合规、风控角度的诉求。
另一点是数据管理的价值，比如公司的库存、资产数据在线，便于追溯、核算成本，并作为发挥数据价值的基础。
在线、实时、精准，是衡量后台产品是否达到管理要求的3个标准，依次递进。在线，指的是某个业务流和数据需要在线上体现，不能只在线下运作；实时，是实现了业务在线之后，线上操作需要跟随业务实时进行，不能滞后去补录；精准，指的是数据在线后，计算、关联追溯逻辑需要准确，而且是系统的准确，并非人工填写的准确。
举个例子，某个电商公司的采购业务，需要向外部供应商进行采购。原先业务的模式是线下完成采购之后，在公司自己的系统中手动录一个数据。现在从管理和合规的角度，整个采购系统需要做到线下采购业务的在线实时和精准。
在线，通过供应商端将供应商的业务作业在线进行，解决原先供应商完全在线下的情况；实时，采购业务报价、采购、送货、结算的整个流程，由采购员和供应商实时线上操作，不能全部做完之后再补录，造成采购数据滞后影响后续履约数据一并跟着滞后；准确，商品采购价格和后续每个环节的加价规则准确，因为采购价格是商品成本的来源，采购价格不准直接影响成本核算。
管理角度的后台产品项目，衡量标准通常会有点偏定性，因为还没有对业务本身做到提升，所以会用类似于某某业务是否在线，数据是否精准，作为定性的验证方式。
【 用户|交易履约类后台产品的产品价值和验证方式】一种相对比较完善的做法，比如衡量一个业务流中的环节是否在线，可以先将业务流的每个环节通过流程图的方式抽象出来，然后一一数有多少个环节，几个环节不在线，产品上线后做到了几个环节的在线。比如上面这个采购案例，业务流中有报价、采购、送货、结算这4个环节需要供应商在线参与，那么验证方式就是这4个环节，有几个做到了供应商在线。
针对数据，比如衡量是否准确，也是同样的道理，比如上个案例中有商品报价、采购价格、商品批次成本等，验证方式就是看这几项数据，有哪几项做到了准确。
数据的在线实时精准，除了管理目的之外，还起到了通过积累数据，发挥数据价值的作用，这一点在后面会写到。另外有人会把这一点视为基建的一部分，这个看每个人的理解了。
虽然说流程数据的在线这个事情，实现形式就是基建，但这块需求是能说得出项目价值的，跟虚无缥缈的系统重构还是有一些差别的。
2. 面向用户，用户操作的提效，人效的释放面向用户的价值，通过提升用户使用产品的效率和体验的方式，提升公司的人效。
对用户的价值比较理解，后台产品的用户体验，需要让用户能高效的处理业务，并且能满足多方数据协同、特殊化场景、大批量操作等情况。
提升用户效率是实际可以给业务带来可见的帮助的一个点，除了用户使用的爽之外，给用户提效就是帮公司提升了人效，节省了人力，尤其是针对一线的业务人员。
能被称作提效的产品需求范围很大，小到排序、批量操作、导出excel这类细节功能，大到流程重构、业务操作流转的自动化等大项目，只要是提升了人效，都可以称之为提效。
通常业务方很喜欢给产品提方便他们自己提效的小需求，哪里加个字段，哪里调下排序之类的，但产品经理不能陷入到他们提的这些小细节当中，而且也要关注更多的人，坐办公室的运营人员经常会提需求，一线业务人员不一定会给产品提需求，但他们的提效需求可能更重要。

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

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

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