打个比方，你是羽毛球玩家，拿个林丹同款的羽毛球拍，根本不能提升你打羽毛球的水平；你的打球水平主要取决于你的身体先天素质，体能、反应灵敏度等的后天训练。同时，如果你的身体资质够好，即便不用林丹同款球拍，也能痛绝大多数菜鸟级球手。

数据的源头是业务，数据从业务操作中产生，支持跨部门的业务协作，反映了端到端业务的结果。数据有质量问题来动手“治理”数据，就像娃已经长歪了，你拼命给他化妆。

业务过程中发生的问题，就应该去纠正业务；等到歪果已经长出来，不去追根溯源，反而后期搞各种所谓数据“治理”，给不了解业务细节的企业高管造成一切尽在掌握的假象…… 有果必有因，现在企业IT服务市场产生这类热潮现象的根因是什么呢？说严重点，就是哄企业老板高兴。

很多做ERP实施或者做企业业务系统出身的顾问都对现在“数据治理”这个话题很困惑，甚至嗤之以鼻，数据质量问题在他们来看，都是业务系统实施本身的问题。过去实施ERP有个口号，叫做“数据不落地”，就是报表要从业务系统里直接出，不能用手改；现在这些各种“数据治理”的套路，对数据进行手工粉饰，真是越搞信息化越倒退到几十年前的操作水平了。

所以尚明怀（曾用名尚明淮）老师认为我们首先要思考：当我们在谈数据治理，我们到底在谈什么？

当我们在谈数据治理，本质是谈变革

没错，数据治理，是N个治理之一，而治理的本质是变革。交流中，H公司首先分享了他们对“治理本身”而不是“数据治理”的理解，总结下来就是：治理是一个设立变革目标、执行变革措施、度量变革效果，对变革效果进行考核和不断改进的过程。

听着是不是很熟悉，PDCA嘛，但是，精髓在于变革的对象：是流程，而不是数据。因此，数据治理的目标，是帮助流程的变革与改进。按照H公司的思维，没有流程变革和可度量改进的工作，大概率是无效的。那么，在这个思维下，数据治理的本质，就应该是以流程变革为目标，在数据领域就数据权利与责任、标准与规范进行定义，并对数据质量、数据安全、数据共享等工作进行持续度量和改进的工作。

这也从一个侧面提醒了我们，为什么在一些企业，数据治理的深入推进往往伴随着企业级信息架构建模和流程改进。因为，企业级建模过程就是企业的一次变革过程，其所必须的业务建模、流程建模、产品建模，为数据治理提供了丰富与可控的对象。这也是某种意义上，为什么缺乏企业级建模的数据治理，难以同时在广度、深度、成本这个三角形上获得优势的根本原因。

当我们在谈数据需求管理，本质是谈架构

需求整合是一个大难题，数据需求的整合和管理更是一个大难题。在交流前，我们提到一个问题，如何做好“数据需求扎口”？当没有“变革思维”的时候，需求扎口是一个很熟悉的企业用语，面对已经固化的需求开发流程，似乎就是全面介入，否则不能称之为扎口；而一旦深入下去，就开始担心这种扎口工作所带来的成本蔓延和资源不足。可是，换个思路，在“流程变革”的框架下去重新审视这个老话题，我们发现了新的解题思路：哪里需要扎口？为什么要扎口？很重要，这个思维方式的转变，很重要。回到关于治理的本质，是流程变革和改进，因此，我们意识到数据需求扎口管理的目的，是关注那些对流程变革和改进有重大影响的领域。那么如何识别这些领域，在这些领域变革的流程中进行数据需求的扎口管理，是一个精准治理的点。

这个点在哪里，在架构。H公司提出的模型，80%的需求是架构驱动的主动的需求变更，而剩余的20%的变更，是运营中产生的被动式变更，即所谓维护类变更。既然80%的需求变更是架构驱动，那么架构的调整和管理就是治理的“七寸”，把数据需求扎口管理的重点放在架构的规划、设计、调整环节，这是“管理抓手”。在H公司，这个组织在“需求和变革管理委员会”。启发在于，企业的实际需求，一方面是项目制方式新建需求，大多要经历业务方案和技术方案的准备，甚至立项评审，在这个过程中数据需求的扎口管理，需要数据架构师以人工为主充分互动和主动作为。而在另一方面，日常的海量的维护性的需求，出于“维护效率考核”的要求，需要快速实施，应该通过工具和标准进行尽可能的自动化管控。这是一个数据需求扎口管理的可行之路和正解。

当我们在谈数据质量管理，本质是在谈设计

质量是设计出来的，然后才是执行。因此，对于数据质量的管理，如何度量“设计质量”，如何监控“执行质量”，才是问题的核心。

那么什么是设计质量，新建一个业务流程，产生大量的数据（use data），这些数据是否能够符合企业的管理需要，有利于企业在对这些数据的“re-use data”过程中进行客户、产品、机构、员工维度的对应和分拆，有利于价值分析和效益考核，有利于营销推荐和风险控制？这些问题的度量，就是设计质量。另一方面，在IT系统的实施和企业实际业务活动中的数据采集环节，是否达到了数据的检验条件，这个是执行质量。事实上，执行质量的检测监控，有质量规则，有检核系统，有问题单流程，基本应付；而企业的真正的痛点在于产品体系的规划设计、枚举参考数据的设计、卡片主档和流水记录的设计，这些过程所产生的设计问题，都是影响深远且一旦种下就只能不断补丁的质量问题。为什么在数据治理领域一直提到一个话题就是数据质量的源头改进？本质上，就是对设计质量的管控要求。在源头采集环节，做多，做够，是对整个后续的数据应用质量的基础和根本。因此，后评估模式的质量检测规则很重要，而前置的设计质量评估规则，虽然格式化和标准化可能还需要改进，但是却是一个更加值得投入研究的领域。

作文不怕短，做饭不怕晚。思考是为了再出发。

从根本上解决企业数据问题要从源头抓起，不能在要用数据时才来抓，需要从企业跨部门的流程管理入手，避免按部门、按产品条块分割建系统，要从“企业架构”角度去规划业务流程的端到端的整合。

总之，尚明怀老师认为目前市场上的“数据治理热”的根子还是企业核心业务系统建设混乱或实施不到位的问题。

免责声明：市场有风险，选择需谨慎！此文仅供参考，不作买卖依据。

责任编辑：kj005