为什么数据管理工作很难成功

大数据时代的到来，大家开始将数据当成资产，数据管理的意义也越来越大，但很多企业的数据管理工作，都难言成功，为什么？首先来看下数据管理的定义：

数据管理，即对数据资源的管理。按照DAMA的定义：“数据资源管理，致力于发展处理企业数据生命周期的适当的建构、策略、实践和程序”。这是一个高层而包含广泛的定义，而并不一定直接涉及数据管理的具体操作（摘自维基百科）。

与百度百科的定义比较，百度百科的定义针对的是数据应用过程中数据的管理，即传统的数据管理。
而维基百科的定义更高一层，针对的是企业数据全生命周期所涉及应用过程数据的管理，即对数据变化的管理，或者说是针对描述数据的数据（元数据）的管理，在此我们称之为面向应用的数据管理。

定义强调了数据管理的手段，但数据管理的最终目的是什么呢？虽然当前如DAMA等的数据管理书不少，但考虑到数据管理体系太过庞大，看这类书往往如盲人摸象，抓不到头绪。

笔者刚接触数据管理的时候，也是云里雾里，本文纯粹是个人的一点实践和主观看法，没有高大上的东西，视野也比较狭隘，算是抛砖引玉，实际上，每个企业都应该建立适合自己的数据管理体系。

首先，为什么要做数据管理？

个人认为，数据管理的目的就是让数据变现高效低成本的运作，正如企业管理一样，因此，没想清楚之前，不要盲目开展一个数据管理项目，更不要盲目采购数据管理产品，首先得问问，做这个事情，能带来什么价值？

那么，何谓高效低成本运作？

首先，要认识到每个数据的实际价值，即哪些核心业务与这些数据，这是定方向，其次，安排好数据优先级，确保正常出数，最后，淘汰过时和无用的数据，即以最小的代价带给业务最大的价值。

这个认识很重要，记得笔者刚开始做元数据管理的时候，是很盲目的，主要致力于工具的考虑，而未深究做事的本质，导致做了大量性价比很低的事情，比如总想着如何进一步提升SQL解析能力，将其作为系统成功的第一要务，但这个真的是最重要的吗？

数据管理，不是为了管理而管理，没有明确的目的，就不要开展数据管理工作。很多人谈到数据管理这类基础工作很难开展，比如领导不理解，做事没成效，原因往往是自己都说不清楚缘由，这为数据管理工作的失败埋下了祸根。

但有了目的和方向还不够。

搞数据的，做事量化是根本，无数据，不管理，数据管理工作，也需要用数据来决策。

以下举例：

数据模型的应用价值KPI-比如模型提供了哪些间接收入，规则可以自己定，但指标要能反映模型对于应用的支撑能力

数据模型的提供能力KPI-比如模型及时正常出数的情况，要能反映模型的及时率及正确率，是衡量运营能力的一组标准

数据模型的优胜劣汰KPI-比如关注投资效益比，要关注数据的生命周期管理，投资当然需要，但也要懂得节省，该转移或删除的数据，就要坚决的执行，一张每天10万数据的临时小表，一年就是3千多万，如果有100张，那也是不小的投资，家里有余粮，也不能滥用。

明确了目标和衡量指标，接下来就要制定一系列的规范和制度，所谓无规矩不成方圆。

数据管理规章制定很难，在起步的时候，不要东订一个，西订一个，最好的建制方式是围绕目标边制定边实践，没有最好的制度，只有适合自己的。

下面先做一个衡量数据管理能力的评估题目，注意回答不要泛泛而谈，一要量化，二要靠机器回答，三要半小时内回答。

能否直接给出每张表对于数据变现的价值？或假如这张表不出，会带来多少潜在损失？（虚拟指标都可以）。

能否直接给出每张表的运行质量报告？能否根据优先级给出运行优化的具体建议？

哪些表能直接下线？

你会发现，要能回答这些问题，不仅仅是建个数据管理系统那么简单，需要制定对应的数据管理的规范和标准。

如果需要知道每张表对于数据变现的价值，必须有应用跟表的关系，因此，开发上线的时候必须制定规范，起码要提交映射关系，同时为了防止两张皮现象，必须依赖自动化的系统。

如果需要知道每张表的数据质量报告，必须制定相关的质量指标，并能够及时预警和处理，这个需要一套数据质量监控制度。

如果需要确定哪些表能直接下线，必须制定一套数据表生命周期管理制度，需要有表的比如血缘和影响分析，否则怎么知道有多大影响？

如果要让运维人员知道这些表谁是谁，则必须有好的数据字典，明确表命名规范和口径定义，以降低管理成本。

如果….

你看，所有的数据管理规章制度其实都是为了确保目的达成，由此会延伸出一个庞大的数据管理体系，但还是要懂得能抓住本质。因为

开始，不可能想到这么多，能做这么多，需从本源开始思考从何入手。

以下是XX公司制定的相关数据管理规范。

说完制度，接下来就提到数据管理工具了。

它是数据管理规范贯彻落地的强大保障，当前工具越来越重要，笔者的一个经验是，数据管理领域，很难靠人肉保障，大多不靠谱且不可持续，如果面对大数据，更加难以管理成功。

谈一个亲身的经历，曾经上线了一个ETL产品，然后项目经理告诉一切运行OK，然后我说每个接口的运行报告给一个看看，项目经理说报表拿不出来，因为产品没有这个统计功能，人肉看了几个大致没问题，然后全量核查发现，30%的接口有一致性问题，就是因为当时现场少了一个系统统计功能。

另数据管理的可视化其实也很重要，ETL任务多达上千个，因此，快速判断任务是否运行成功很重要，以前，管理者拿到的是运维者的报告，但里面可能是有水分的，某天我们做了运维可视化，发现运行情况远没有报告所称的那么理想，任务大量失败而挂起，运维疲于奔命去处理问题，而后提交一个完美的报告，而管理者还以为一切OK，冰山下隐藏的问题，远远超过管理者看到的冰山一角。

当前数据管理的产品不少，但很多其实难以达到要求，原因很简单，数据管理工具太靠近上游，越靠近用户的产品其实越难做抽象，也越难成功。比如一些元数据管理工具，很难解决产品中的元数据跟生产系统元数据两张皮的现象。

因此，笔者更倾向于采用半定制化的产品的，甚至认为，数据管理产品是偏垂直行业的，阿里以前发布了“数加”大数据系列产品，但其数据管理产品很难作为单独实体获得成功，只能平台捆绑。

怎么才算是好的数据管理工具呢？

个人认为是能够将数据管理能力渗透到数据生产流程中去。

比如以前生产建表，是开发人员写代码建表，虽然建表有规范，但开发人员是否执行是另外一回事，而且建表注释写得乱七八糟，往往需要靠事后稽核，但大家都知道这很不靠谱，现在，我提供一个可视化开发界面，将建表规范作为规则纳入系统，强制要求开发人员在该界面上建表，只要不符合规范就予以拒绝，比如注释缺乏，未有分区键，字段定义长度不符，字段命名不符等等。

如果有可能，将所有的数据管理规范提炼成规则，都纳入到系统中强制执行，数据管理就能实现与生产系统的无缝衔接，数据管理成为生产的一部分。

前面提到的很多元数据管理等工具之所以难以成功，往往因为它是一个外挂系统，所有的信息需要事后喂给它，而不是强制的，导致与生产系统变得越来越不一致从而失去信任直至死亡。

有人会质疑这对于数据管理平台要求太高，对于开发约束太多，存量改造太困难，的确，这些都是问题，数据管理本来就是个难度极高的工作，不做当然也可以，反正也能活，最多运维质量低一点，人肉多一点。

但如果希望更进一步，就需要付出代价，近和远，长痛还是短痛，还是需要依据企业的实际情况自己作出选择。

数据管理工具是种辅助手段，是否采用，采用哪种，都依赖于企业基于性价比去做选择。

接下来，提一个关键的一点，即管理者的态度。

数据管理是个系统工程，你去看DAMA，DIMM等内容，都将其上升到企业战略这个层面去谈，但企业即使有了数据战略又如何，再好的规划也赶不上变化。

管理者始终关注的是效益，数据管理也不例外，因此，说服管理者，也应该坚持“效益导向，能力建设”的原则，坚持向数据要收益，比如一个企业，垃圾数据和冗余数据占据了很多空间，做好这类管理可以省一大笔钱，核查问题也一样，原来看文档抓人，现在查系统，哪个更有效？现在IT企业人来人往，没个知识库，系统重翻或新人培养，代价有多大大家都清楚的很。

数据管理也涉及企业很多流程的再造和新机制的建立，比如规范开发流程，影响也是全方面的，必须获得管理者的支持，否则举步维艰。

最后，还是要提一下人。

这个是最最重要的是，数据管理是个专业化的工作，需要专门的人沉下心去做这个事，不要搞什么兼职（估计是常态吧），那也是扯淡的事情，一个数据管理项目的失败，往往是自己投入不足，坚持不足所致。

人才始终是数据管理的第一要务。