数据管理的格局

数据工匠俱乐部

做数据管理工作好多年了，其实刚从技术转成管理的时候，自己感觉还是蛮适应的，但随着人员的增加和业务范围的拓展，越来越感觉力不从心，有时会觉得做技术还是比较简单的，因为它面对的还是相对确定的东西。

专业技能的成功也是最具可复制性的，它需要的只是你在一个领域坚持不懈地专注下去，只需要选择一个不算太不靠谱的方向，然后专心致志的专下去，最后必然能成为高手或者绝顶高手。世上有很多成功带有偶然因素和运气成分或出身环境，但至少这一样，被无数人复制了无数遍，否则就不会存在学校和教育了。

但做管理就完全不一样了，以下是大鱼做数据管理多年的一些体会，供你参考！

1、尽人事，仍需听天命

尽人事的重要性不必多说，但成功的偶然性是非常大的。

以大鱼写文章为例，为什么我会写文章？因为想做一些有意义的事情，为什么写的都是与大数据相关？因为自己从事的是大数据相关工作，有些实践的体会，为什么会从事大数据工作？因为公司当年要开展大数据业务，而当时大鱼正好在做取数报表相关工作，为什么大鱼会做取数报表相关工作？因为进公司的时候正好报表组缺人......大鱼不是什么成功人士，但你看，就是写文章这个事，也有大量的偶然因素，这些偶然因素就是天命。

大数据刚起来的时候，不少企业管理者认为大数据就是炒作概念，他们对于大数据唯一认可的东西就是报表，当时不少同仁就跟我抱怨公司的领导对于大数据一毛不拔，报表的投资可以过，精确营销，决策沙盘，客户洞察，元数据管理一个都不让过，认为都是绣花枕头一包草，在这种背景下，大数据不可能得到发展。

后来互联网公司的大数据给整个社会洗了一遍脑，很多公司的管理者才开始逐步认识到其价值，比较可笑的是，早期互联网公司做数据仓库的人很多却是从传统行业跑过来的，这波人得到了巨大的发展，而当时留在传统行业的人现在可能还在做报表。

阿里提出了数据中台的概念，对于整个数据行业是有很大正面作用的，因为企业内的沟通成本变低了，老板起码不会觉得数据中台没用，如果你依托数据中台获得了晋升，除了感谢这个时代给予的机会，也许还要感谢下阿里，否则老板根本不知道你做这个事情的价值。

吴军以下这段话说得很好：

“为什么要听天命呢？因为世界上稍微难点的事情都非常复杂，超出我们的有限认知，更超出我们的控制能力。我们付出努力，无非解决了一些难度上的问题，但是还是有很多维度的因素不是我们能控制的。当然，如果不尽人事，能把握的那些维度也会把握不住，自然一事无成。”

我经常跟团队的同事讲，我们有机会做大数据，能够让数据的价值有些出口，真的是太幸运了，但如果大家一进来就做这个事就很难有这个体会，他们一开始就站在了一个比较高的起点上，殊不知这其实是命运的安排。我们经常说人要往上看，但偶偶也要往下看，这样可以让自己活在当下。

2、没有CDO，就没有未来

公司能设置CDO，对于做数据的团队是幸运的，可惜的是，起码到现在，大多数公司不会设置CDO。但只要公司管理层没有一个数据代言人，那数据团队能获得的上层支持还是有限的，不是说公司不设置CDO就无法做数据了，而是说在操作层面往往无法执行到位，每个专业的发展需要的不仅仅是方向，还需要过程的精细控制，这样才能确保落地。

比如公司即使定了数据战略，但如果没有CDO一贯的支持，这种数据战略就是一纸公文，话说每个企业的老板都支持打破部门数据壁垒吧，都是政治正确吧，但能执行到位的凤毛麟角，有些行业还有顶层的设计，比如相关的数据规范，但那又怎么样？真的行起事来也是举步维艰。

数据管理工作不是一棍子买卖，只要得不到公司管理层持续的、一贯的支持，企业的数据管理基本就没什么未来，有的公司即使设置了数据管理组织，但只要这个数据管理组织的头在公司的管理团队没有发言权，其实也没啥用。

举个例子：

A公司数据管理做不好，B公司却做得很好，也许并不是两个公司能力有什么差距，仅仅在于B公司管理层中有个对于数据较真的领导，他亲自披挂上阵推动数据管理组织的建立，要求各个业务部门必须开放自己部门的数据，必须基于大数据平台提供的数据进行决策，每次决策会都会问业务部门的数据从哪里来。

数据团队在这种背景下获得到了巨大的发展机会，不仅数据采集畅通无阻，而且业务部门还会全力提供业务指导，否则数据取不准自己也吃不了兜着走，各个部门的数据专员也就自然而然形成了。

数据管理部门不需要为业务目标绞尽脑汁，因为老板已经帮你想好了，顺着势头走就行了，在实践的过程中你的团队的数据管理技能日益精进，跟其他公司拉开了巨大的差距。你说B公司数据管理部门开始的时候真的是自己牛逼，还是因为运气好，摊上了一个骨子里有真正数据思维且身体力行的领导？

CFO，COO会将财务和运营视作自己工作的主线，会为自己分管的领域争取最大的利益，但谁来为数据争取利益呢，CIO偶偶会站出来会说说话，其实也没啥卵用，CIO关注的是IT，但IT的范围实在太大了，你要它还兼着数据管理有点勉为其难，让其他出身的CXO负责数据管理从0到1更是挑战巨大，守城还行，打天下那真是刺刀见红的白刃战，不清楚里面的道道，很容易被PPT带偏。

让人纠结的是元数据管理、数据治理、数据质量管理、参考数据这种概念，还普及得特别差，至少在管理层面，远没有云技术、微服务、容器那么容易让人理解，信息不对称的情况下，更需要CDO穿针引线，去年《DAMA数据管理知识体系指南（原书第二版）》出版了，我读了下，感觉是为专业人士特供的，但其他的非专业相关人士谁来照顾？

3、要思考，就需要慢下来

以前一直把做事速度当成核心竞争力，所谓执行力高，但后来做数据团队的管理后发现在面对复杂问题时，做事速度快意味着容易犯错，特别容易把资源浪费在一些无用的地方，一年忙忙碌碌看似做了很多事情，其实一事无成，这里包括三种情况：

一是干了太多不该干的事情，大鱼觉得数据团队的目标特别难以设定，因为夹在业务和平台之间，没有出口，仰人鼻息。

大多数数据团队，并没有一个高层管理者知道或认可的显性的目标，也许你希望设置一个企业数据汇通率的指标，但根本得不到公司的支持，很多数据团队甚至没有意识到这一点，这就意味着数据团队的业绩是出不了部门的，只能在报表取数这类工作上来回倒腾，当然提升速度也很重要，但比起速度，老板更需要你有企业级的视野。

退而求其次，你也许会自我加压设置OKR，认为在做对公司有价值的事情，但很多OKR是自己脑补出来的，一线其实根本不带这么玩的。

比如上周大鱼信心满满的去跟业务部门的领导聊大数据后续的支撑方向，但业务部门的领导听完只是笑笑，委婉的说了下：“其实我们觉得做XX才是比较重要的，你提的那个好是好，但比较理想化......”虽然大家都知道没有调查就没有发言权，但还是喜欢呆在办公室里脑补一些目标出来。

更要命的是，现实工作中，大多数人是不设置目标的，特别容易被事务化，要么去做很多老好人的事情，要么在一些鸡毛蒜皮的事情上跟别人扯皮，更喜欢挑现成的容易的事情先做。

可以马上问问自己，本季度你的主要目标是什么，能否用一句话来简述，如果支支吾吾答不上来，就要问问自己是否需要改进，或者再去问问领导的期望。

大鱼通过二年的OKR实践，才让团队脑子里长了“目标”两个字。

二是喜欢同时做很多事情，大脑会欺骗我们，让我们以为自己可以做得更多，在了解自己的真实能力之前，人的潜意识总认为自己能行，但这只是一厢情愿。

每次跟团队过OKR，发现大家习惯设置很多的OKR，有的团队竟然在同一时间要做4个模型，我说是不是太多了，大家都说没问题，最后能完成的其实寥寥无几。

大鱼后来反思为什么会这样，也许大家开始的时候的确是有信心的，但其见识限制了评估能力，不知道自己不知道挺无解，另外多设几个目标似乎还保险一点。

三是迷信所谓的速成，可以肯定的是，速成这件事是不存在的，即使有低垂的果实，也要相信早被人摘完了，你做的这件事情，要做出与众不同的效果来，肯定是极具挑战的，也许建模的某个阶段可以速成，比如掌握Python语法，但要端到端做好数据建模这个事情根本不可能速成，为什么没法速成，可以看看这篇文章《为什么数据挖掘很难成功？》。

很多人问吴军学什么专业未来收入高，工作还不会太辛苦，吴军就说抱着这种取巧心理的人，不是在和同龄人竞争，而是在挑战经济学的基本原理，挑战市场的有效性，或者说是在和上帝竞争。其实如果真有不需要努力的捷径，所有人都能学会，这个捷径带来的优势一定不具有稀缺性。

凡事要慢三拍，如果周围的人让你做个重要决定，只要有条件，你就要习惯这么说：“我现在脑子不工作，让我想想再答复你吧。”

4、要主动，抓住一切机会

数据团队的很多工作是需要去“抢”的，这是由其生态位决定的。

从平台的角度看，以前大数据平台相对于OLTP是独立建设的，随着云计算的兴起，OLAP和OLTP无论在系统上、还是组织上都有融合的趋势，现在大数据平台放在数据团队还是云计算团队是有争议的，比如阿里云也许就会吃掉原来属于数据团队的底座部分，因为这样更能集约化，更进一步来说，数据开发管理平台、数据可视化平台、元数据管理平台未来是否会成为云基础设施的一部分也未尝可知。

从数据的角度看，企业是否真的需要统一的数据模型也存在争议，统一数据模型带来的集约化和模型各自建设带来的灵活性孰优孰劣存在很大的争议，也许公司刚性的统一数据要求仅限于一些KPI而已，数据也许只是业务的一部分。

每个部门完全可以拥有自己的数据团队做自己的领域模型，去做各种数据产品和数据应用，他们可以基于云的开放性去申请所需的资源、工具和数据，云计算越来越便宜浪费点在线存储又怎么样？企业真的有那么多跨域的数据整合应用场景吗？

现在的数据湖实际是在颠覆数据仓库循规蹈矩的供数模式，数据湖不是数据团队的数据湖，而是企业的数据湖，云的数据湖。这么看来，数据团队被压缩为一个纯后端的运维团队或者退化成一个纯管理的治理组织也不是不可能。

从业务的角度看，数据中台在业务中台之下，其价值出口被业务中台牢牢卡死，业务中台总在那里，而数据中台则可以被业务中台合并。比如淘宝页面没了推荐照样生存，但做推荐的没了淘宝页面“毛将焉附”？

当初数据仓库从OLTP剥离出来的时候，一方面是因为OLTP技术不适合OLAP的分析场景，另一方面是OLTP并没有意识到数据对于业务的巨大驱动作用，现在情况完全变了，大家都有足够的驱动力去用好数据。

这些背景决定了数据团队的生存空间不是那么理想，你的地盘看来并不是那么稳固，数据团队的格局如果仅限于做做后端的数据治理，那的确没问题，但我们想要的总是更多吧，数据驱动业务是数据中台的使命，那抢地盘的唯一方式就是主动出击。

最近大鱼在负责企业某部门的数字化转型工作，就面临一个问题，这个部门的后续数据分析支持工作到底是这个部门自己增加编制、增加投资解决呢，还是由数据团队统一支撑掉？

在大的变革期，有些数据团队容易往后缩，自然没有发展的希望，而要往前一步就要先主动付出，用行动来证明自己。

5、要专业，细节决定成败

数据管理是一门特别讲究细节的学问，近几年政治正确的事情谈得很多，但能真正落地的还是很少，这里讲三个事情。

首先是数据开放。

数据要打破部门壁垒现在说得很多了，部门墙当然是一个问题，但如果实事求是的核实原因，往往不是部门墙的问题，而是落地细节出现了问题，造成了新的部门墙，这里举个例子：

部门A是数据管理部门，A需要从部门B采集数据，部门B说需要走流程，A按照流程走了，但还是发现B的供数周期太长，然后领导组织开协调会，A的人员罗列了一大堆B存在的问题，B的一个经理直接跳出来说:"企业级数据统一归集我们认可，但你们作为一个统一数据管理部门也有责任开放数据给企业的各个部门，我们向你们申请数据的时候，你知道要花多长时间吗？2月前申请的到现在还没开放，你们没有建立快捷的申请流程，没有提供通用的Daas服务，我都不想说......"

后来核实发现，对方需要的数据要么被安全卡住了，要么是DaaS接口问题迟迟未排期解决，数据管理部门不仅有归集的职责，更要明白归集最终的目的是反哺业务发展。

现在数据归集变成了一个政治正确的事情，但更有价值的开放却被忽视了，很多数据管理部门看似在做很多正确的事情，但浪在PPT上的时间太多。

比如拥有了开放的功能和实际是否开放是两码事，数据开放至少要设置端到端的开放时长和数据准确性两类评估指标。

如果以安全的名义推脱开放的责任，则是没有担当的体现，现在各个企业对于数据开放的安全性要求很高，这种情况下数据部门更要在细节上想办法，而不是把责任推给安全部门，否则企业要你干什么，守着一堆数据看风景？

其次是数据采集。

很多数据部门一提数据归集就头疼，说对方部门不配合提供全量数据，但要知道并不是所有的企业数据都是资产，数据管理部门不能对数据采集一刀切，至少需要安排人去进行的详细的调研，整理出数据资产目录，理解这些数据资产代表的业务含义，给出数据资产的基本价值评估，然后再进行有选择的采集，不理解数据资产的含义，即使采集进来了也是废铁一堆，无法去做真正的开放和运营。

从价值的角度来说，数据团队利用好数据也是一个渐进的过程，即使你采集了全量数据进来又如何，企业里有几个人能真正的消化这些新数据，要把某个领域的数据研究透要花费巨大的代价，即使研究透了还要为其找到合适的应用场景，这都需要花费时间，魔鬼全在细节中。

好数据不求多，大鱼评估了近几年采集进来的数据，发现只有几类数据真正有用，但团队在这些新数据的研究上投入了巨大的精力，要不停的打磨数据模型，不停的协调源端去提升数据质量。

最后是制度流程。

老大说过，建立流程要特别谨慎，因为每多一个流程就意味着更多的人力要消耗在管理成本上，如果规模不够大，绝对是亏死了。

大鱼以前制定了一大堆数据管理机制和流程，看起来很好看，但能真正执行好的也就那么几个，因为每个数据管理的机制和流程都必须要花大功夫去制定操作细节，否则就形同虚设，建议没有操作细则的数据管理规范直接扔掉。

将数据管理规范嵌入在生产流程和工具中是确保其执行到位的不二法门，这个大家都懂的，但这更是细节的工作，比制定个规范的难度上了几个档次。