供应链系统设计-中台系统设计系列（四）- 衡量好中台的指标体系

概述

我们讨论中台的文章已经有了三篇，前三篇主要中台的概念、复用性和稳定性，在写指标衡量体系之前我们之前的三篇中台文章主要内容我做一下简短的总结，这边便于我们后面针对中台指标体系进行讨论。

供应链系统设计-中台系统设计系列（一）- 一看就懂的中台概述

中台的定义与作用：中台是将前台业务元素抽象后，将通用能力沉淀到中台，避免重复造轮子，解决复杂业务的协同问题。中台可以是技术或业务的概念，用于指导系统协同设计，提高前台业务的效率和响应市场的速度。

中台解决的问题：业务中台：提高前台效率，避免前台业务重复开发相同的功能，如商品维护、库存管理和订单维护等。

数据中台：统一归集和标准化数据，解决数据分散、不标准化和信息孤岛问题，提升数据质量，支持数据分析和决策。

中台与后台的区别：前台需要快速响应市场和客户需求，而后台更多关注企业管理效率问题，变化速度较慢。中台作为前台和后台之间的“齿轮”，匹配速度，支持前台的快速创新和变化，同时保持后台的稳定性。中台的存在使得企业能够更灵活地适应市场变化，同时保持运营效率。

供应链系统设计-中台系统设计系列（二）- 好中台的标准之复用原则

前台业务效率提升：好的中台能够显著提高前台业务的效率，通过将前台业务中通用的元素能力沉淀到中台，避免重复造轮子，实现能力的复用。这种复用不仅减少了前台的工作量，也加快了业务响应速度和市场适应能力。

中台边界的合理划分：中台的边界划分应基于业务发展情况和场景需求，以复用性为原则。在业务发展的不同阶段，中台可能需要保持“小中台大前台”的架构，以便实现更多的复用。随着业务的成熟和稳定，中台可以逐渐扩展，沉淀更深层次和更广泛的业务能力。

业务能力和原子能力的复用：中台的设计应当基于复用原则，将业务活动中可复用的部分抽象为业务能力，进一步细分为原子能力。这些能力的复用是中台系统设计的核心，它们可以跨越不同的前台业务场景，提供灵活、可扩展的服务。

供应链系统设计-中台系统设计系列（三）- 好中台的标准之稳定原则-CSDN博客

中台稳定性的重要性：类似于餐厅菜品的味道稳定性，中台系统也需要保证服务和数据的稳定性，这对于保持业务连续性和客户满意度至关重要。

中台领域模型的稳定性：中台的领域模型应该具有清晰的边界和标准，避免因为不同业务需求而频繁变更，这样可以减少系统的复杂度，提高稳定性。通过领域驱动设计（DDD）来定义限界上下文，可以将特定业务逻辑限制在特定的上下文中，避免污染其他领域模型。

中台能力的逻辑稳定性：中台的能力应该是通用的、可复用的，并且具有一致性的实现。为特定业务定制的能力不应该影响中台的通用性。中台的稳定性直接影响到前台业务的复用性和系统的稳定性。如果中台模型和能力频繁变更，会导致前台业务系统也必须频繁变更，从而影响整个系统的稳定性。
中台的腐化会降低开发效率，拖慢业务创新和落地速度，最终可能导致中台战略的失败。

以上就是中台前三篇内容的主要内容，本章是第4篇将中台的概念的最后一篇，主要是和大家讨论一下好中台的衡量指标体系，有前三篇的基础，我们想如何衡量非常简单了。主要是还是围绕的这中台量大原则：复用性与稳定性，进行展开。

好中台的衡量指标体系

复用率

最后我们聊了这么多，那么具体中台会有那些指标体系呢？

首先，我们化了很多时间去复用，将能力复用，给前台业务提效，因此复用率如何类进行衡量。基于我们对于复用的理解，其实我们觉得从中台层面来看，复用率可以定义成为以下的公式：

前台业务复用能力命中数量就是中台的哪些能力被前台使用了，如果中台中很多能力未被前台使用，其实是没有任何意义的。

其次，我们还要看每个能个被前台使用复用的程度，如果一个中台的能力，只能被前台的少数业务复用，说明中台能力的通用性是不够的，我们需要将这些能力找出来，看看是不是其他的前台业务不存在这样的业务场景，还是存在，对于中台能力的实现可能有问题，导致其他的前台的业务无法使用，可能需要对能力进行改造后就可以做到通用了，这个前端的业务都可以进行复用。

我们还是以阿里的业务为例子，针对商品新增、商品发布和商品审核三个中台一级能力以及二级能力，如图所示：

我们可以从图中看出，对于新增商品基本信息和扩展信息，基本上淘宝、天猫和阿里健康都复用了，说明这个两个二级能力通用性非常好，也说明商品新增的一级业务能力也非常通用。

而我们看商品发布能力中发布提交和发布审核中的两个二级能力，只有阿里健康业务使用起来，其他的天猫和淘宝是没有使用的，因此，对于这个两个二级能力设计的通用性很好，可能是淘宝和天猫的业务前台对于这个两个能力无法使用，也有可能淘宝和天猫在前期阶段根本就不要商品发布和商品审核功能。而健康业务由于他的特殊性，所以需要对商品信息进行审核和发布。

基于这种情况，其实我们上一讲是说过的，就是中台的扩展机制，因此，遇到这种情况，中台有默认实现，如果默认实现不能满足，则需要前台业务方自己按照中台的扩展规范机制，进行能力的扩展，最常规的实现方式就是SPI机制，如果对于这块不是非常清楚的同学可以看一下上篇中台复用原则。

在这种情况下，其实对于中台的挑战还是非常大的，因此，对于中台的商品业务需要理解的非常透彻，对于前台业务对于商品的诉求需要有较深的理解，对于领域模型的抽象和设计也有非常高的要求，因此，这也是中台前台设计为什么要叫“小中台”的原因，因为小才会最够的通用，因为前期业务是不成熟的，业务确定性不高，变化快，所以，中台只有把业务逻辑做的薄才会通用而且稳定。

所以，我们可以得出，能力复用的宽度计算公式：

前台业务应用复用能力数量就是业务前台的一个应用，复用了1次计数为1。例如：天猫业务有1000个应用，其中有700个应用复用了新增商品信息，淘宝有500个应用，其中有100个应用复用了新增商品信息，那么，新增商品信息能力复用宽度 = 700 + 100 = 800。因此，新增商品信息能力复用宽度就等于800。复用宽度越宽，说明业务能力被复用率就越高，也越通用。

另外，还有一种能力的场景宽度，就是一个能力被多少个业务场景使用，这个也是一个非常重要的指标，因为不同场景代表是一些行业的特性，因此，复用的场景数越多，说明该能力的行业通用性就越高。

开发效率

我觉得复用率最终表现出来还是开发的效率，如果复用越高，开发的效率也会越高，因此直接复用了，所以不需要开发，或者只是需要开发差异化的那部分就可以了。因此，需求开发如下图所示：

复用能力且开发（XX）人天以内的需求，其中（XX）人天就是我们经常讲的开发人天数，就是你说你的开发效率提高，如何衡量呢，最好的方式开发的人天数。至于是3天、还是5天，这个具体根据自己公司的情况是可以灵活定义的。比如：前台商品发布复用了中台的能力，只用了2天就上线了。如果没有复用中台的能力，可能需要7天。所以，从这里我们可以到通过能力的复用是如何让前台业务需求的开发提高的。因此，最后就和我们的以下两个图就吻合上了。