引言

企业建设过数据中台，还有必要做数据治理吗？

企业做过领导驾驶舱，还需要做数据治理吗？

企业做过生产管控、质量管控等，也有需要做数据治理吗？

企业数据中台项目中包括了数据管理，为什么还要做数据治理呢？

企业建了数据中台，就等于企业具备数据管理及服务能力吗？

……

【当下痛点】“慢、难、不准”

在数据要素背景下，大部分的企业数字化转型选择了基于数据驱动业务增长的路径，建设了数据中台项目。这类项目以面向业务部门的看板指标设计为主，基于平台进行数据采集-数据仓库加工-看板开发的工作落地。把数据中台更多的建设成了一个数据链路的采集处理的技术平台，是大部分企业的建设现状，虽然有数据质量、数据标准、数据安全、数据目录等诸多模块，但是可能并没有实质性的实施内容。往往还面临如下痛点：

01、响应慢：业务部门提出看板需求，数据部门无法快速响应，从采集数据到看板开发完成往往需要1周~1个月，不能及时满足业务端的“看数”需求；

02、运维难：数据管理部门/数据应用开发部门运维压力大，工业企业主价值链看板往往后台有四五千~上万个调度运行的任务，通常在看板上出不来数据的情况下开始排查，问题难定位、影响范围不确定，千丝万缕，不敢动；

03、不准确：业务部门对看板应用存在两种极端，一是不用、没问题，月度访问量个位数，日常业务工作的开展不使用看板；二是用的多、抱怨多，看板信息不准确，但不知道怎么不准确，无从下手。

【根本原因】“与其解析SQL，不如重写一段”

企业数字化转型建设初期选择“以应用为牵引的数据管理”建设路径开展工作，这是聚焦业务价值开展数据管理的正确路径。在这种情况下，建设重点更对放在业务部门相关的管控场景、公司领导相关的驾驶舱场景下的指标体系设计及看板开发，以期激发业务人员对于“用数”的积极性和认同度。

该类项目的建设工作内容中，往往存在以下问题：

01、数据采集欠缺规范及复用性考虑，往往做一个指标从源头采一次数，造成了多次采集、接口的重复开发；

02、数据加工多采用SQL，四五百行的SQL是运维工作的现实阻碍，与其解析SQL，不如重新写一段是大部分的运维现状；复合指标导致的调度编排关系错综复杂，影响范围不可控也未知；

03、数据仓库分层及模型规范执行不到位，规划是“超市的货架”，现实是“菜市场的摊位”。

【如何解决】“从数据仓库到数据超市”

伴随着“应用牵引式”的数据工作建设，企业逐步认识到数据工作不仅仅是建看板应用，数据标准、数据质量、元数据管理等数据治理工作同样重要，所以这些年建了数据中台的企业，还在做数据治理，甚至做数据治理的迫切程度更高。

数据部门如何从疲惫的数据运维工作中解脱出来，需要依赖：

01、数据标准：统一的数据标准，形成对数据的统一认识，是端到端业务流程贯通的前提，是多个业务视角打通分析报告的前提；

02、数据规范：提数据应用需求需要遵循提需求的规范、做数据采集需要遵循采集的规范、建仓库模型需要遵循模型设计的规范、配调度编排需要遵循编排的规范、开发可视化看板需要遵循看板取数的规范，这是可追溯、能复用的前提；

03、数据服务：数据管理/数据应用开发部门如何从提供数据加工结果转向提供数据服务，除了数据仓库规范化的完善与重构，还要注重必要的数据角色以及数据工作分工的模式建设。

那么，作为数据管理部门应该如何统筹分析应用、数据标准、数据目录、元数据以及数据仓库、数据服务这些数据管理职能域的实际工作，以什么为抓手做好从“提供结果到提供服务”的转型呢？下回见喽 ~  ~