企业中台建设成熟度和关键指标分析

今天准备整理和分享下企业中台建设成熟度和关键指标，对于企业中台建设的成熟度，当前实际上很难给出一个标准完善的成熟度模型和框架，但是至少从业务，技术，组织管理，支持过程等几个关键维度进行评估本身是没有问题的。

今天谈中台建设成熟度，主要还是结合《中台战略》这本书里面提到的成熟度分析思路，来分析一个中台建设如何评估是否成功的以下关键KPI指标应该如何。整体准备分三个部分来讲：

1. 中台建设成熟度概述

2. 中台建设的知识体系结构

3. 中台建设成败的关键KPI指标分析

中台建设成熟度概述

 

在中台战略这本书里面，提到了中台成熟度模型，这篇不做为读书笔记，更多是自己对企业数字中台建设成熟度一些思考，在这里我们还是给出书里面提到的中台成熟度的3大维度和9大指标。

系统建设维度（a. 服务丰富度 b. 服务共享性 c. 系统灵活性 d. 辅助工具）

中台驱动力(a. 开发组织 b. 数字化运营 c. 生态系统)

过程管理(a. 中台战略 b. 方法论）

对于书里面提到的这个成熟度模型，还是有参考价值，但是我不准备太细化地围绕这个维度和指标展开来说，而是谈下自己对中台建设成熟度模型的一些理解。

成熟度模型本身是对全域内容的覆盖

首先我们就要看到一个成熟度模型实际上对全域内容的覆盖，什么叫全域覆盖，对于中台建设来说你可以看到业务要变更，组织架构要调整，原有的遗留系统要重构，新的技术平台要搭建，应用构建的方式要变化等等，这些都属于一个中台建设的内容。

因此应该从这个入手来分析，一个中台建设究竟有哪些内容域，然后再来思考这些内容域具体哪些内容，内容域间如何协同，单个内容域如何评估成熟度等级。

就中台建设来说，我们初步可以分为业务，技术，管理和过程支撑几个关键的过程域。对于以上几个关键域本身又分为如下内容。

业务域：业务目标，业务架构，业务组织，业务流程

技术域：微服务，DevOps，容器云，API服务和能力开放

管理域：项目管理，研发管理，运营管理，运维管理

过程支持：敏捷方法论，咨询规划方法论，企业架构，SOA，云原生

我们拿上面的内容做下举例说明。

比如对于业务目标，刚开始你可能只是支撑某个业务域的业务目标实现，其次是支撑整个企业的端到端流程业务目标实现，最后则可能是支撑跨域企业边界的产业链整合目标实现。

而对于过程支持和方法论同样，要完成整个中台规划和技术平台建设，里面涉及到敏捷方法论，企业架构规划，SOA和云计算思想，IT管控治理，流程管理等诸多的方法论的一个融合，而不是说一个单一的方法论或知识体系就能够完成。

从目标驱动思路来看中台建设成熟度

当然，我们也可以从目标驱动的思路从顶向下逐层展开来思考这个问题。

即一个中台的成熟，简单来说就是中台建设的很好。那么中台建设的很好一定体现在对前端业务的快速敏捷响应和支撑能力。中台建设的好不好，不是你用了什么先进的类似微服务等技术架构，而是你最终构建的中台能够敏捷地支撑业务需求和目标。

对于这快速敏捷响应本身我们又分为对功能性需求的敏捷响应和对非功能性需求的敏捷响应，功能性需求敏捷响应自然体现在你的API服务库的服务是否做得好，是否可复用，我前端需求要实现的时候都能够快速的找到对应的API接口能力，

其次这种新增或变更需求同时考验你的持续集成和快速交付能力究竟如何。对于非功能性需求，简单来说就是中台是否稳定可靠，在我们搞类似双11，秒杀等活动的时候中台是否具备快速的弹性水平扩展能力。这些也是你需要考虑的问题。

任何一个敏捷能力的实现，你都会看到不仅仅是单个的工具，技术或平台。而是你需要做一系列的事情，从业务层面可能涉及到业务组织架构的变更，流程的重构，从技术层面涉及到技术支撑平台工具的引入，技术组织的调整，敏捷文化的形成，技术标准规范体系的建立等等。这些都是你需要考虑的问题。

从业务支撑范围角度来思考中台成熟度

最后我们来从业务支撑范围角度思考中台，即中台的成熟一定是从企业的组织内或单业务线，走到整个组织和全域业务，然后再从企业内走到企业外，最终形成产业上下游全连接，外围合作伙伴全连接的开放协同能力平台。

具体先企业内还是先面向外部运营构建中台，这个顺序完全可以根据企业自身的业务驱动来考虑。比如对于企业内部信息化建设已经很重的情况下，当需要做自建电商运营平台转型的时候，完全可以围绕这个来构建中台，先支撑对外运营和营销这条线。当然对于制造加工企业，可能业务目标重点在于智能制造，那么你构建中台完全可以围绕智能制造来考虑先构建数据中台能力。

业务驱动和对业务支撑能力始终都是我们在评估中台时候关键点。在前面我们更多谈的是平台，而现在谈中台，要清楚地认识到，平台更多的是技术层面的事情，而中台则是在技术平台基础上增加了关键的可重用业务服务能力沉淀，这些下沉能力则是中台带给企业的核心资产。。

从业务组织和架构来思考中台成熟度

我在前面文章里面已经多次强调过，中台本质是一个业务概念，是共性业务能力的下沉。因此企业中台构建往往是业务先行，在业务上本身就已经形成业务中台，类似各类的共享服务中心，服务整个集团和所有子公司等。其次才是考虑业务中台如何通过技术来实现。

在谈微服务架构的时候就谈到，不是简单地进行微服务模块的技术拆分，而是整个团队也需要按微服务模式进行拆分，形成独立自治的微服务需求，设计和开发运维团队。

在中台建设里面同样道理，中台建设中团队需要遵循康威定律，进行解耦和拆分。每个团队里面都应该有业务和技术人员，同时业务和技术人员之间应该高度协同，最终完成业务目标。

业务人员：核心职责是业务规划，流程梳理，业务建模

技术人员：重点是技术架构搭建，功能开发实现，功能运维

对于中台服务中心纯粹是提供API服务接口能力的，一般不会直接面对C端客户，而对于前台应用团队，那么还必须包括类似产品经理，运营人员等关键岗位角色。

中台建设知识体系架构

如何针对一个细分的业务领域或技术领域，搭建一个完整的知识结构？

实际上我们在前面关于思维和个人知识管理的文章分享里面都有谈到。从我最开始知识结构的搭建采用思维导图方式，到后期我更多地采用二维矩阵表格的方式进行呈现。

为何做了如此的转变？

还是回到我对此强调过的事物认知，即对一个事物的认知一定是分为动态生命周期观察和静态分解两个关键方面，两个方面结合才能够把事物认识清楚。拿中台来说，中台的建设一定涉及到需求分析，架构，开发实现，运营和运维的动态生命周期；也会涉及到业务，技术，管理，过程支撑的静态维度划分。两者相互结合才能够呈现完整的知识体系。

我在前面做过一个IT咨询规划的知识体系图，如下：

该图参考参考业界IT规划的参考模型和框架，结合IT规划方法论和实施，重新整理了IT规划知识体系。对于横轴主要考虑IT规划的方法论和步骤，具体包括了参考模型，调研阶段，差异分析和匹配，目标架构，实施策略和管控治理六个方面的内容；对于纵轴包括了IT基础设施，业务基础设施，业务流程，数据，技术体系，应用系统，集成架构七个方面的内容。

横向包括了IT规划和咨询项目的完整阶段和流程。纵向包括了完整的IT规划和企业架构应该包括了内容。对于原有zachman框架的匹配分析为，去掉了时间和动机，增加了业务流程，技术和集成三个维度。对于zachman横向原来分为目标/范围、业务模型、系统模型、技术模型、详细表达、运行功能。其中将技术模型转化为横向，并增加了实施策略和管控机制。

因此，基于以上思考，我们对中台建设的整体知识体系重新进行梳理。即从动态生命周期和静态维度拆分两个方面来构建一个完整的知识体系架构图，如下：

对于该图，很多地方还不是很完善，后续我对中台架构和建设的知识体系将基于该图进一步做细化和调整。比如横向分层，可以进一步拆分为资源层，中台+服务层，应用层。对于业务层面也需要进一步拆分为组织，管理，业务流程几个方面。

但是从上面我们也基本可以看到完成一个中台建设所涉及到的业务规划，架构设计，开发实施，过程支撑方面的关键内容。这个关键内容仍然是围绕我前面提到的，即：

企业中台构建 =》业务规划设计（业务层面）+云原生架构（技术层面）

对于业务规划设计方面，核心的知识体系仍然是结合SOA和云计算，微服务架构思想的企业架构规划和领域模型设计。在云原生架构层面，重点仍然是微服务架构，DevOps和容器云。

对于中台架构设计，始终是中台建设中承上启下的关键点。

即必须是既懂业务，又懂技术的架构师往往才能够很好地完成。中台架构设计里面需要完成相关关键的两个事情，即微服务模块或叫服务中心的拆分设计，每个微服务应该哪些API接口的设计。

在我自己参与的中台或微服务架构转型的项目中，经常会遇到有些客户项目往往前期没有统一进行接口规划和设计，而是开发中少了什么接口，再临时开发实现。这样做出来的中台接口服务能力层很难真正达到服务重用的目标。

如何中台服务不能重用，那中台建设本身无意义。

中台建设关键KPI指标

在前面我已经谈到，对于中台建设是否成功，一定是从业务驱动和目标实现来谈的，在业务目标的实现过程中你会发现技术指标是为业务目标服务的。

比如我们说的业务敏捷响应能力指标，你会看到对于持续集成，微服务化，DevOps，API接口的复用度，低代码开发平台等全部为业务敏捷服务。

所以，我们谈总体建设的关键KPI指标，仍然要从最终的业务目标分解思路来谈。比如业务目标我们可以分解为业务敏捷响应能力提升，IT建设成本降低，质量提升等几个关键方面，即我们常说得多快好省。基于这个目标再分解为具体的KPI指标。

下面我们列出几个关键的KPI指标来进行说明。

业务需求响应周期

这个实际上是衡量中台构建是否成功的一个关键KPI指标，对于业务需求响应实际上包括了两个方面的内容。其一是当基于新的业务商用模式下，需要全新构建一个新的前台应用的时候；其二是对已有的应用重新业务流程优化调整的时候进行需求变更的时候。

比如原来做一个新的应用你可能需要至少2个月的时间完成需求，设计和开发上线工作。那么在中台能力构建完成后，能否在1个月时间内快速上线新应用。再比如原来应用中出现需求变更需要处理，原来可能需要2到3周的时间完成，在新的架构和模式下能否在1周或者更短的时间内完成。

业务需求响应周期的提升，实际上涉及到敏捷方法论，持续集成和交付，低代码开发平台，开发过程的自动化水平，业务技术沟通协同效率，中台API接口服务的可复用度等多个方面的因素影响。但是正是这些业务，技术和管理的最佳实践完成了敏捷响应业务的最终目标。

业务需求响应周期 = 需求功能点数*新增或变更系数*复杂度系数*基准天数

中台提升的API接口的可复用度

对于中台构建完成后需要提供可复用的API接口服务能力给前台应用使用。实际上在这里包括了两个小指标。其一是中台能力对前台需求本身的覆盖度，其二是API接口本身的可复用度。

当前台应用构建的时候，如果需要中台能力，我们首先会看在当前中台能力库和API服务目录里面能不能找到直接复用，如果可以复用那么前台构建应用效率提升，否则还需要中台重新进行API接口的新增和开发。

其次，为何还要和可复用度一起来评估。简单来说，前台业务需求是否需要下沉到中台能力层去开发，还需要评估业务能力是否存在共性和可复用，如果不可复用，那么就应该在前台应用里面自己实现业务规则和逻辑，而不是在中台实现。因此中台能力接口还必须评估复用度。

复用度 = 前台不同应用同类场景下接口使用数/同类场景数

所以不用一味去追求复用度，也不要一味去追求覆盖度，而是两个指标共同评估。

IT建设和运行成本降低率

一开始构建中台的时候，可能没有企业会关注这个指标。确实，企业进行数字化转型，规划和建设中台的时候，不是成本降低，反而是前期大的成本投入。

但是当中台构建到一定程度，进入到滚动运行期和运维期的时候，必须要考虑建设和运行成本的降低，即前期多投入的成本能够在后续运行和运维过程中逐步降低和回收。

而对于成本的降低主要包括了以下两个方面：

通过开发效率，测试效率，集成交付效率，运维效率提升来降低人员投入。

通过IT基础设施和资源利用率提升来降低硬件资源类成本投入。

而这两个方面刚好是和我们的DevOps持续集成和自动化，容器云，云原生解决方案相关的一个内容。通过云原生方案来实现智能化，自动化。

提升软件产品的质量

如果说到软件产品质量，最直接的就是软件产品上线运行后的缺陷泄露情况或上线后发生缺陷的缺陷密度。但是软件产品的质量属性实际上包括了功能性质量和非功能性需求方面的质量。包括常说的软件上线后的可靠性，可扩展性，高性能，高安全等都应该属于产品质量的范畴。

先说功能性的产品质量提升，这个问题实际上涉及到技术中台能力，测试能力，自动化测试水平，持续集成和交付能力，研发管理水平，研发人员技能水平等多个方面的因素影响，这些方面都需要提升往往才能够提升最终的产品质量。

而对于高可用性，可扩展等非功能性需求质量，往往就涉及到云原生解决方案，即云原生方案会考虑到软件产品本身的高可用性和可扩展能力。

软件产品交付更加敏捷和快速是好事，但是必须满足基本的软件质量属性要求。

来源：人月聊IT