数据，不能只讲大道理

在谈论数据时候，有些供应商特喜欢提变革性、推到重来解决方案，必带一些时髦名称；2019-2021 人人都提数据中台，张口就说业务数据化、数据业务化，数据驱动业务，甚至数据重塑业务；如今大家都不提数据中台（会被打上骗子标签），开始说 DAAS，阿里提了一个独特口号“not saas ，but DAAS”，当然，只是 DAAS 还不能满足产品高度的具像化，接下来就会听到各种让你云里雾里，但又让你觉得好像很牛逼样子词汇：分析云、营销云、产销云、客服云、开发云。

甲方爸爸好这口

并不是说提这些概念有什么不好，毕竟能够张嘴就滔滔不绝说这些在公司里都是有头有脸的人，不来几个这样词汇确实体现不了他们格局；另外甲方爸爸也喜欢听这些，甲方爸爸也需要一份前瞻性、有格局的 ppt；就像有些甲方项目能不能落地不重要，ppt 覆盖到就行。确实，在数据建设过程中需要全局、全链路规划，需要“大处着眼”的顶层战略规划，但不能人人只是讲大道理（因为领导就喜欢讲大道理，你不讲大道理好像就不能跟老板在同个高度对话），动不动就提推到重来革命式解决方案；

大道理易讲，小事难做

大道理大家都懂，就像数据中台核心内容是提高数据复用性、避免烟囱式开发，这些道理大家到明白，但怎么实现、怎么落地才是最难的；公司在快速发展阶段为了快速响应需求，大家更多关注是需要响应速度；当公司业务发展遇到瓶颈时，这时开始追求降本增效，开始讲人效时候，这时就上面就有人关注数据复用问题，想通过提高数据复用性，达到提高人效。但当开始规划、执行、落地时，发现这是一个长期、系统工程，不能快速产生价值工程，最终结果是 ppt 讲了很多、规范文档也很多但执行落地的很少。

数据建设，是一个个细节叠加

企业数据建设不是一朝建设好的，没有什么一劳永逸方案，需要遵循一定的原则，把一件件小事做好，把一个个小环节理清楚，是一个循序渐进过程，最近读到一段话挺有道理的：

DevOps 的前提是开发规范，大数据人工智能的前提是数据治理，OKR、精益敏捷的前提是透明文化

数据建设，是一个个细节叠加，在我们讨论数据化转型、数据中台、数据云时候，先做好数据规范建模“小事”