你的数据中台需要做一个成熟度评估了

中台没有严格的规范，所以对于许多组织来说，很难有标准的管理和监控机制，但尽管没有硬性规定，组织还是可以从约定边界开始，划分模块以及通过建立一些指标来管理每个模块。我们认为数据中台的成熟度评估应该从文中的七个维度入手。

自从阿里提出了“大中台，小前台”的概念后，一场组织变革席卷了国内许多公司，这其中不仅仅包括互联网公司，还有传统行业，如金融、电信、零售、物流、制造业等。

从 2018 以来，“数据中台”成为行业头部企业普惠至更多的中小企业，成为数据应用的“基础设施”。未来每个企业都会标配自己的“数据中台”，为企业数据化转型和创新奠定坚实基础。

数据中台，是通过获取各类数据，对数据进行分析和挖掘，产出结果和洞察，提供给业务和决策者使用，进而打造创新产品和服务，优化管理推动组织数字化转型。“让数据用起来”，是数据中台终极目标，也是数据中台要为处于不同数据认知成熟度阶段的企业实现一个个具体的目标。企业在业务的快速发展、信息化越来越高前提下追求自身的价值，业务部门不停的提出新的需求和挑战，给普惠数据服务提出了数据服务的按需提供、业务流程化、数据自我治理、统一数据服务、智能化数据运营等特点。

随着近 2 年来数据中台在很多企业雨后春笋般的落地，很多企业不知道自己的数据中台到底建设得怎么样了？

最近频繁听到一些企业所服务的部门级负责人提出这样的困惑：

数据中台建设一年多了，我们投入了很多资源，做了很多东西，规模也扩张了不少，也有一些产出，但这些结果到底怎样呢？

我如何知道这些结果是好还是不好？接下来我该如何调整？

我如何根据现在数据中台建设的情况来进行下一年的规划呢？

也就是说，现实中，他们需要一个数据中台的成熟度评估，来对中台的建设做一个全面的体检，这既是一次结果的盘点，也是为未来的规划提供输入。

近期和同事一起做数据中台成熟度的研究分析，也对服务过的组织做过调研和评估，我们认为数据中台的成熟度评估应该从以下七个维度入手。

（图 1 数据中台成熟度模型）

01 数据战略

数据中台的建设通常不是无缘无故发生的，也不是追求“时尚”的产物，在中台建设的行动之上和活动之初必然有个数据战略，这个战略可能是在建设过程中逐渐被清晰化的，也可能只是在小部分成员（通常是负责人）之间共享，更有可能只出现在 ppt 或者口头表达里，它可能是公司级别的战略，也可能只是部门级别的战略，但这个战略很重要，它就如同一家组织的愿景和目标，是指导行动的灯塔，没有它，组织的决策可能会具有随机性，导致资源利用不集中、行动效率低、重复建设等现象发生。

有了数据战略，还需要确认组织（或者部门团队）对战略的理解是否一致，如果理解不一致，数据战略可能只存在口号或者争论里，落地的结果不尽人意或者没有结果产出。

如何保证有清晰明确的数据战略，并且这个战略能被统一认识和理解呢？答案是需要一个管理组织，这个组织可能只以虚拟的形式存在，但是管理得当的话，它可以保证战略目标能被有效的分解，并且能在部门和团队之间得到拉通落地。

与管理组织配套的还需要一些制度建设，比如保证战略落地的流程，如何处理冲突、不一致，决策流程是怎样的？战略（和行动）的调整和优化机制是什么？

总结一下，数据中台建设的前提是数据战略的清晰和明确化，评估一个组织有没有数据战略的关注点是：数据战略是什么以及是否一致，管理组织的成立和运作，制度建设的配套和保障等。

02 数据治理

并不是所有的组织都会组建单独做数据治理的团队，但数据治理的工作却必须有。有很多组织的原则是“先建设，后治理”，也就是说先把中台的架构搭建起来，循序渐进完善各个功能模块，在这个过程中，绝大多数组织会选择先建设和用户（业务或者业务 IT）强相关的功能模块，过一段时间再回头计划数据治理的工作。但建设功能和数据治理的时间间隔通常不会太久，通常来讲会在半年到一年以内，否则组织会发现，功能建设的工作难以为继，治理的难度也会随着时间的推移逐步增加。

评估数据治理的时候，也需要关注一些点：

• 比如，元数据相关的，有没有做元数据管理和怎么来做的元数据管理，是否有元数据分类，技术和业务元数据的管理，有没有完善的元数据管理体系，是自动管理还是手动管理，维护机制是怎样的？

• 比如，数据字典相关的，是否有相应的管理和维护机制，字典包括什么内容，数据字典的变更、权限审批流程是怎样的，是否和业务系统保持同步等？

• 比如，数据模型相关的，数据建模的方式、标准方法和流程是怎样的，按照哪种方式来建模，模型的自适应能力怎样，是否有统一的建模工具，维护、优化和变更流程是怎样的？

• 比如，数据质量相关的，是否有做数据质量管理，是否有质量的评分模型、监控流程和评估流程，是否有完善的反馈、变更和处理机制，质量是否和考评指标联系等等？

• 比如，数据标准相关的，是否有数据标准体系，是否有源系统和目标系统的数据标准映射逻辑关系，是否有反馈、变更、处理机制等等？

• 比如，数据安全相关的，是否建立数据安全管理机制和定义安全分级分类标准，是否有适当的数据安全控制及措施，是否有数据隐私保护等相关活动及维护数据安全的工具，是否有完善的数据访问权限和回收策略，是否有脱敏机制和策略等？

• 比如，数据生命周期相关，数据生命周期的体系规划和落地机制是怎样的？是否有获取与存档方案，是否有备份和恢复计划以及数据销毁方案，是否有保留与归档的日常活动以及归档数据的检索与使用策略？

总的来说，当数据量多并且复杂到一定程度，数据治理的工作如果不能成为中台建设的重点，就极有可能成为中台建设的瓶颈。

03 数据资产管理

数据资产管理也是数据中台必须建设的功能模块，正如其名字所诠释的那样，把数据当成资产，建设好了给组织带来价值增值，建设不好则给组织带来资产流失或贬值。

评估数据资产管理的时候，需要关注中台的这样一些点：

• 有没有数据资产审核能力，也就是对数据资产的注册申请进行审批，保证数据资产能被合规注册和发布的能力；

• 有没有数据资产发布能力，指的是将审批通过的数据发布到数据资产地图，供数据消费者查询使用；

• 有没有数据资产标签，比如客户的特征标签、关键业务的指标标签等，以便使用者通过标签组合来消费数据；

• 有没有数据资产地图，指的是通过地图或者目录的形式，提供数据资产的查询功能，实现数据资产的“可视化”；

• 有没有数据资产的开放能力，通过接口的方式，数据资产被开放给内外部的用户，实现数据资产“增值”；

• 有没有数据资产盘点能力，如同组织盘点自己的动产和不动产一样，数据既然已经被当做资产，也需要周期定期不定期甚至实时进行盘点，盘点成果将会被导入到数据资产运营平台进行管理；

• 有没有数据资产定价，围绕数据的不同价值模型，比如业务价值，成本价值，市场价值等，按照不同的权重配比对数据资产的价值进行评估定价；

• 有没有数据效益评估，根据数据资产产出的价值，来数据资产的价值进行评估。

根据现实经验，上面的所有项可以不是同期同步发生的，许多组织的数据资产管理只是覆盖了以上几项，但中台仍然能“负重”运作，也正是如此，数据资产管理的成熟度评估才显得尤为重要，因为只有认识到数据资产管理的全貌，才有利于设置正确的建设路径。

04 数据平台和架构

数据平台和架构是在全域的数据基础之上，设计出易用的、稳定的、可扩展的、支持多应用的平台架构，此外，进行数据分层建模和标准定义，最终呈现出一套完整的、规范的、准确的数据架构和应用的解决方案，可以方便支撑数据应用。所以数据平台和架构主要关注如下：

首先要关注的就是架构标准，有没有架构选择的流程，比如同业调研，选型，POC 以及决策机制，是否有专门的架构组来保证流程和机制的落实，是否有部门内部和部门之间的架构评审流程和机制等等；

其次，架构方法也至关重要，比如架构规划、整体架构、基础架构、数据架构、功能架构和部署架构的设计原则是什么，有没有标准的架构实施规范，有没有评估机制，是否有调整、优化和改进机制等等；

再次，数据是怎样集成的，有无数据整合架构政策和标准，数据集成的流程和标准是什么，包括内外部数据集成、离线和实时数据的集成方案等，是否有自动化的数据集成工具或平台，集成过程中是否有异常处理、回滚等操作；

整体来说，这部分既需要整体规划又需要对细节进行考虑，不仅仅是部门内部的工作，还涉及跨部门的协作机制，是非常具有技术含量的一个模块。

05 数据服务化

数据服务化是指数据中台以什么样的方式向外提供服务，而能直接使用这些服务的人通常不是业务人员，却极有可能是业务应用的 IT 人员，业务通过调用配置好且已开放的服务（比如 API）来为业务快速开发满足某一需求的功能。

数据服务化的背后也通常会有一个服务平台在支撑，所以在做中台服务化评估的时候既要关注服务平台又要关注服务本身。

比如，服务标准的确立，指的是有没有明确的服务目标，以什么样的方式提供服务，提供服务的流程和优先级是怎样的，和业务 IT 的协作机制是怎样的？

另外就是服务监控和维护，在平台之上以什么样的方式监控数据服务，有无量化的标准来评估数据服务，数据服务维护的流程和机制是啥？

还有服务结果分析，有没有对服务结果进行分析的机制，结果的读取和分析是否同步，分析结果是否发布、发布给谁、以怎样的方式发布？

最后还要关注数据服务的评估和优化，中台提供数据服务是否被评估，按照什么维度进行评估，评估的流程和机制是怎样的，评估的结果是否会用来指导数据服务化的优化和改进？

在对数据服务化这一维度进行评估的时候，通常既需要关注功能（技术）实现，又需要关注治理，因为规范成熟的治理机制是中台持续不断对外提供“优质”服务的保障。

06 数据产品化

有的组织会把产品化和服务化放在一起，因为这两部分都是比较靠近前端数据消费者的，因为无论是产品化还是服务化，对整个中台来讲，它们都是数据产品。

略微不同的是，数据产品化的结果，有相当一部分是可以直接被业务使用的，比如报表的分析服务（产品），业务人员可以直接通过托拉拽的方式在平台配置自己所需的报表以及展示方式。

这一维度所要关注的目标就和战略方向特别靠近，比如：

• 业务支撑能力：数据产品化（或者数据产品平台）支撑什么样的业务功能，有无功能选择的标准，所能支撑的业务是否能反映战略的方向或战略的执行情况，功能支撑能力是不是能被周期性评估和优化；

• 业务分析响应能力：响应机制是啥，业务功能使用的响应能否做到实时（T+N），产品平台功能开发的响应机制是啥（如果提出一个功能开发需求，多久可以上线），有无对底层数据整合平台的依赖；

• 数据可视化能力：是否支持业务友好的使用方式，比如指标和数据维度的托拉拽，是否支持数据挖掘和分析结果的呈现，是否有自定义图表的呈现，是否集成第三方分析呈现工具；

• 统一服务的能力：是否能将业务需求沉淀成统一服务的能力从而能够服务于更多业务团队，沉淀的原则是什么，是否实现跨集市引用的沉淀，等等。

数据产品化是比较靠近业务，也比较容易被业务感知到的一个模块，这块的设计和开发应该借鉴产品开发的思路，既需要考虑功能、业务反馈，还需要关注运营指标。

07 中台运营

指的是将整个数据中台作为一个产品来看，是否有运营的指标和控制机制。

• 比如，是否有中台管理平台，类似于整个中台管理的入口，所有通用文档、规范、标准、流程的管理，都能够列出来并且能被方便的查找，对各个平台运营指标的监控和分析进行区别性的展示；

• 比如，存储成本、计算成本和研发成本的管理和分析，有没有这些成本的投入计划，估算原则和成本分析；

• 比如，是否有中台内部各模块之间的整合与协作机制，架构的设计、职责和工作内容是否清晰，互相调用和协作机制是否完善，功能模块间的资源分配是否均衡

• 比如，在价值层面是否具有良好的用户体验和较高的用户满意度；

• 比如，在资产的管理方面，是否能反映数据或服务被调用的频率或次数，等等。

总之，中台运营评估的是中台作为一款“产品”，它是否能为组织提效降本，是否能为业务带来价值增值。

以上便是对数据中台进行成熟度评估所建议采用的维度，但鉴于业界没有一个对数据中台的标准定义，在实际操作过程中，还需要根据组织和部门的特点以及结构组成、业务的场景、落地执行的情况来做调整，还有一个情况是，并不是所有的组织里面都能找到划分清晰的 7 块，这个时候需要做的就是对维度进行合并或者拆分，总的来说，数据中台成熟度的评估既可以反映组织结构（主要指数据部门或者中台部门）是否合理，又不能完全脱离现有的结构进行设计和评估。

有了对数据中台各个维度的定义，接下里要做的就是对于每个维度下每个评估项进行打分，最后的产出会是量化的一些维度评估数字，有了这个评估结果，组织可以设置一些改进目标，同样，改进目标也是可以通过这个模型进行量化展示的，所以最后可以得出类似以下这样一个评估结果和改进结果的展示：

（图 2 数据中台成熟度评估示例）

总结

中台没有严格的规范，所以对于许多组织来说，很难有标准的管理和监控机制，但尽管没有硬性规定，组织还是可以从约定边界开始，划分模块以及通过建立一些指标来管理每个模块。

此外，中台也是跟着组织变化的，组织不一样，最终的架构设计也会不一样，但是中台建设的关键是服务化和标准化，如果能够做到内部服务足够敏捷，加上配套的机制，比如规范、运营指标和考核机制，中台的建设会自己迭代和发展。

本文转载自公众号 ThoughtWorks 洞见（ID：TW-Insights）。

原文链接：

https://mp.weixin.qq.com/s?__biz=MjM5MjY3OTgwMA==&mid=2652468348&idx=1&sn=158607123cb85c88ff45d9fe9516ec54&chksm=bd4f466b8a38cf7d584524658a95834a02bc3ec57721924253f50173940d8b6d8d2a674e4aa9&scene=27##