一个公司的后台系统一定会包含很多基建的部分，比如做电商的公司要实现用户在线下单，就需要有管理商品的商品系统

基建项目

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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