彭友们好，我是老彭啊。最近有个彭友问我：能不能给推荐一个好用省心的数据中台？这个问题其实很难回答。原因很简单，市场鱼龙混杂，万一选错了，后面得填无数坑，甚至要推倒重来。现在是个数据产品都能给自己冠名“数据中台”，这也是没谁了。我见过最奇葩的是一个用低代码组装的数据产品，功能倒是挺全活儿的，采集、抽取、转换、存储、报表、大屏展示啥都有。这玩意就是一个ETL+报表+大屏，使使劲叫数据平台也就凑合了，但是叫“数据中台”就有些过分了吧？哪个销售能卖出去这个数据中台，那得是修了八辈子的福。谁选到这个玩意也是倒了八辈子血霉了。
艰难的选型
作为一个数据人，对于“数据中台”这个中国本土产生的概念，我个人是举双手投票支持的。但这个符合数字化转型期望的概念一路都磕磕绊绊，总是不太顺利。
在老彭看来，这其实归结于“数据中台”这个概念太好了，太深入人心了，而市场又缺乏衡量标准，导致充斥着牛鬼蛇神，甚至还有“假中台”的说法。
学过一点经济学的彭友都知道，在这种“劣币驱逐良币”的格局下，对供求两端都不友好。买方的决策时间和风险剧增，项目成功率降低；卖方的竞争成本压力巨大，不得不用增加POC的方式获得订单。
业务部门需要数据中台（或者其他产品）增强竞争力，但是负责建设的IT/数据部门则要防止选中“假中台”带来的巨大风险。于是不得不一次又一次地反复PUA乙方：“你们的产品和其他竞对有什么区别？这个功能对业务来说到底有什么用？能给我们带来什么价值？”其实这也不怪他们矫情。餐厅里负责点菜、收银的服务员并不关注后厨用的是什么工具，他们只关注是否能提供令客人满意的菜品。而后厨采购厨刀、案板的时候关注的永远只有一条：是否趁手好用。So，数据中台对于甲方不同角色的感受是不一样的。业务部门并不在乎使用什么产品，建设什么项目，他们看中的是能否能帮助业务部门建立起足够强的能力。IT/数据部门则关注的是产品是否好用，能不能让他们在后期的建设、实施过程中更加省心省力。一般来说，在进行产品选型的时候，都会关注企业实力、产品功能、实施能力、报价等因素。
上面这个表格看上去很专业，但只要做过选型的人都知道，这些常规的选型维度并不能让数据部门选出一个让人省心好用的好产品。因为鞋合适不合适，只有脚知道。
选型，是一件非常难的事情，因为下了决定，就要为这个选择承担责任。一旦选择错误，后果非常严重。轻则项目失利，重则扫地出门。
合脚的数据中台
究竟怎样的数据中台才是最合适的？买鞋可以挨个上脚试，数据中台怎么挨个试？ 所以一般的方式就是广撒网，挨个邀约厂商上门，首拜、演示、试用、Demo、POC，一轮又一轮，旷日又持久。厂商为了订单，会无所不用其极，各种阴谋阳谋全上，商务、关系多管齐下。讲真，在这种情况下，最终的决策很可能超出原有的期望，变成一个“多角色、综合决策”。就像小时候买鞋，虽然是我穿，但都没征得我的同意，甚至都不合脚，因为我妈说买大一点能多穿两年。
所以，选型的时候，一定要明白我们IT/数据部门要的是什么。是供应商的名气？是同类行业经验？是一条龙的服务？还是有限的预算下不得不妥协的结果？以上内容都是综合决策时需要考虑的内容，并没有对错之分，甚至能明哲保身。比如：供应商名气大是有好处的，就算项目最后失败了，也可以跟老板说：这是全国最好的，这家做不了，实在是时机/数据/市场等条件不行导致的。供应商同行业项目经验好处一样，至少可以看到别人是怎么做的，然后照猫画虎，多方参考。
如果我们没有足够的开发人员，选择一个有较强实施能力的团队是非常有必要的，否则就像只买菜，没有厨子照样做不好一桌菜一样。站在一个数据部门负责人的视角，我认为选数据中台和买鞋一样，最重要的选型维度是：舒服。于是我们选择数据中台的核心问题只剩下一个：如何让自己舒服？如何让团队舒服？
高效协同：数据团队最舒服的姿势
作为一个职业摸鱼人，老彭的摸鱼绝招是打造一个高效的数据问题自动解决机制：打入敌人内部的数据小分队+规范的数据工作流+灵活高效的工具。
也就是组织、流程和工具。这其中落地的关键就在于数据中台这个工具。数据中台作为承接所有数据处理工作的载体，必须要非常好用，否则效率提不上来，问题解决不了，一切都白搭。因此，数据中台最关键的能力是“协同能力”。一个好的数据中台必须要做到三协同：1、数据与数据的协同2、产品与产品的协同3、数据与业务的协同其中，数据与数据的协同是基本能力，OneID、离线+实时数据处理、数据统一建模等都是数据协同的范畴。
这些能力是最基础的，绝大多数数据中台产品都能拥有这些能力。如果这些能力都达不到，妥妥的挂羊头卖狗肉。产品与产品的协同指的是数据中台与BI、大屏、数据门户等产品之间的协同。如果这一步协同不到位，会带来极大的系统集成工作量，甚至导致部分效果无法实现。
很多供应商就停在这一步了，仅仅通过提供接口与其他产品进行对接。这一倒是能协同，但是不够高效。比如对于数据中台提供的各种API接口，就难以做到“API可视化”，实时掌握上层BI、大屏对数据服务的调用情况。数据与业务的协同指的是业务的变化能及时在数据上反馈，同样，数据的优化能及时赋能业务。在数据团队，最令人头疼的一件事情就是如何管理不断暴增的业务指标，以及如何同步开发指标计算逻辑。
绝大多数产品把指标管理和计算割裂开来，结果就是在BI层调整指标口径后，数据中台里的指标计算逻辑并没有跟着变化。你说你的，我做我的。要不就是BI里开发一遍，中台再开发一遍，造成非常严重的重复建设。这也是很多数据中台没能用好的根本原因。中台开发团队累成狗，数据分析团队还是累成狗。根本没有体现出中台的优越性。这一点网易数帆就做的很好，直接打通了旗下的BI（网易有数BI）和数据中台（数据开发治理平台EasyData），进行业务指标的统一建模和调用。同样的工作，中台做完，BI直接调用即可。这同样也促进了数据团队内部的协同。题外话：有意思的是，神奇的康威定律在这里又一次灵验了。网易数帆的BI和中台打通的根本原因在于这俩产品是一个团队开发的。康威定律戳这里：神奇的康威定律-组织决定产品形态。更进一步，是能加强数据团队与业务团队的协同。能做到这一点的数据中台已经是凤毛麟角了。数据部门与业务部门交涉最讨厌的局面就是业务以“业务需要”为由，要求数据部门无条件配合。如何才能为数据团队提供一个抓手，帮助数据团队在与业务部门沟通的时候获得主动权？
比如这个绝佳的小工具：把每一张报表的成本以及使用情况自动计算出来。在这张图里可以很直观地看到：如果这张报表经常使用，那么对业务是有价值的，付出成本也是应该的。如果长期不用，对业务的价值就不是那么明显，投入产出比不高，可以优化。
拿着这个结果，不仅可以理直气壮地告诉业务部门报表对业务的价值，更进一步地量化了报表的成本，为数据部门从成本中心转向利润中心提供数据参考。如同前面提过的“API可视化”，这里我称之为“数据中台价值可视化”。这个功能的设计，不是亲自操盘过数据的人根本提不出来这个需求。
好用省心的选型维度
综上所述，我认为可以再加上两个维度：省心能力和协同能力。具体的内容可以根据团队实际情况自行添加。
比如在上表中我还增加了一个自动生成数据血缘的内容，看上去很小的一个功能点，实际上会造成后期非常大的运维工作量。有个彭友就跟我吐槽过一个项目中数据中台和BI用了两个产品，导致数据血缘无法打通、需要手动生成的问题，导致报表数据出错了，向上溯源非常困难。这样，我们就梳理出一个完整的数据中台选型维度，包括：1、企业综合实力
2、产品能力
3、实施运维能力
4、产品报价
5、省心能力
6、协同能力
其中1-4用来进行综合决策参考，5和6才是数据部门最终选型的核心指标。只有符合这两个指标的数据中台产品，才能真正让我们的数据工作省心、省力。
结语
想让大家支持你的工作，最好的方式是让大家知道这件事情的价值。数据有价值这件事情已经成为共识，但是到底对业务有什么价值却很少有人能说清楚。
尤其是数据治理这种“下水道工程”，更是难以说清楚其业务价值。我个人很喜欢网易数帆设计的“报表成本”这个小功能，非常直观地从成本的角度说清楚了它的价值：
为了产出这张报表，需要采集和存储多少原始数据，加工多少张中间表，数据清洗及预计算时用了多少CPU，最终耗费了多少存储和计算成本，才把你想要的报表呈现到你的面前。
不过这个功能在不同领域的作用有所差异：像是在互联网、物联网这种需要大量资源存储、计算的场景中就非常令人吃惊：这张报表花了我4位数的成本？
在传统企业中，数字化转型之下物联网产生的数据量和计算量越来越大，计算成本也不断增强，配合使用也能体现ROI，同时还能迫使用数部门提高描述需求的质量，从而形成数据开发全生命周期的正向循环。
