查看原文
其他

到底如何划分数据产品与数据中台的边界? by 大鱼先生

讨厌的大鱼先生 大鱼的数据人生 2022-05-08

国庆参加聚会,其中朋友A是一家金融公司的CEO,提到了下面几个事业部的IT部门和公司的中台部门的微妙关系,事业部的老大多是业务出身,也不太管IT的工作,随着业务规模的扩大,这些事业部的IT问题也开始变多了。


A希望事业部多找公司的中台部门学习下,但这些事业部的老大没太当回事,直到最近发生了几次重大故障才有所行动,A也要求公司的中台部门也去了解下这些事业部的IT情况,中台部门调研了一圈跑回来说:它们的每个应用都是竖井,有些全网应用还仅仅用了两台服务器,神仙也救不了啊。


这让我想起自己负责的数据中台部门和各条产品线的关系,跟A公司的情况何其相似,我们所有的数据产品线都有自己独立的前端、后端、模型和运营的人员配置,数据中台团队虽然很早设立,但主要的职责是完成公司的报表和取数工作,同时为数据产品线提供基础数据的支持,但不负责数据产品相关的数据模型等工作,全是产品线自己搞定。


这种职能架构前期适应了业务快速发展的需要,所有产品线都能独立开展工作,产品线迅速从0到1,但5年后,也显示出了弊端。


第一个是成本的问题。


每个产品线为了自身的发展,都会持续提出新的数据资源诉求,虽然通过产品需求合理性的审核可以进行控制,但大量探索性的工作是很难客观评估的,只要手头还有资源,可做可不做还是会纳入这些产品线的需求列表,直到耗尽能给予的所有资源,虽然这个时候的全局资源配置一定不是最优的,但资源一旦分配出去,就很难收回来。


自己曾经有过在数据产品线配备成建制的数据团队的想法,后来发现养不起,也培养不动,一般的企业养一只数据中台团队已经够呛,根本无法为产品线的数据团队提供良好的成长环境,单打独斗的太多了。


第二个是质量的问题。


虽然产品线做的是数据产品,但优势体主要现在业务理解上,而不是在数据模型上。


你会发现,产品线很难在数据层面保持长时间的投入,短频快的模型它可以做,但复杂的模型做起来就非常吃力,因为产品利润和运营的压力已经让产品线喘不过气来,根本无暇顾及模型的长期研究和优化。在速度和质量面前,产品经理大多会选择速度,从而降低模型的交付质量,这让很多数据产品逐步丧失竞争力。


比如我们以前有个商业分析产品,产品经理3年内忙于满足商务需求,产品相关数据和模型没有任何改进,只能靠各种定制化来满足客户需求,这个时候即使数据中台侧已经有新的数据和模型可以使用,也很难引入到产品线。


大家都认为中台是解决问题的关键,共享复用诸如此类等等,但实操层面挺难,正如前面朋友A碰到的一样。


我一直想尝试解决,现在也摸索出了一些办法,供你参考。


首先,必须对各产品线的数据资源进行限制


组织架构决定了系统架构,只要产品线有独立的数据人员招聘权限,就很难奢望产品线能主动找数据中台团队来进行合作,资源控制在自己手里是保证确定性的最好手段,产品线可以说培养自己的数据团队,如果真的很急,那就花更多的钱,找更牛的人。


回收数据人员招聘权限是强制产品线使用数据中台能力的不二法门,但在推进过程中也要讲究一点策略。


为了不影响生产,存量的数据盘子尽量不用去动,毕竟很多产品和数据是强捆绑的,给产品线留出专业数据资源池能带来一定的灵活性。


同时新建动态数据资源池,这些资源全局共享,由上层管理者按需动态调配,比如每月需要对各产品线进行动态+专业数据资源池的盘点,基于全局最优的原则来进行资源腾挪,比如哪些产品已经不需要发展了或者已经过了人力资源使用高峰期,那这个时候剩余资源需要重新划回到全局动态资源池。


各产品线都不太愿意释放资源,但只要资源的使用是透明的,实际是比较容易统筹的,成功与否依赖于上层对于资源池的管理能力,比如产品和数据线同一领导负责就比较容易推进,前期较大的挑战是梳理清楚家底并建立动态更新机制。


数据产品线没有了无限的数据资源权利,如果想做更多的事,自然会寻求数据中台的帮助,这不以人的意志为转移,所谓中台团队容易被架空什么的,只是因为缺少了权利而已。


其次,需重定义数据产品和数据中台的职能边界


要做好协同,最好能区分清楚产品线和中台的边界,但大家都知道这里存在模糊地带,一方面企业希望用中台能力去提升复用能力,另一方面也怕中台团队由于业务理解不够、响应太慢影响生产。


我对这个问题也很纠结,但经过分析发现,业务中台的确很难,但数据中台和数据产品的边界则可以划分得相对清楚。


数据产品可以区分为两种类型,业务流程类洞察分析类,针对两种类型可以采取不同的分工策略。


如果数据产品是以业务流程为核心的,其流程和数据的耦合性不会太高,比如营销平台,那么数据能力可以由数据中台团队统一提供,比如标签,模型,API等等,这类产品数量一般不大,但价值很高,如果企业的这类数据产品已经发展到一定规模,可以做分工的尝试。


如果数据产品是以洞察分析为核心的,比如交通规划产品,那么应用模型由产品自己负责,公共模型由数据中台负责。


如果应用模型和公共模型很难区分,这个时候也不必强求,因为公共模型往往复杂,消耗的资源很多,而应用模型相对简单,变化较快,产品团队在资源受控的前提下,会权衡利弊做出选择。


最后,团队必须建立基于中台的信任文化


无论是对于资源的权利进行限制,还是重新定义职能边界,都无法彻底解决协同的问题,这个时候靠的就是文化的力量。


以前我们团队有个数据产品总监,产品、售前、运营、开发都是一肩挑,其通过自身的努力打开了行业的市场,也不太依赖外部团队,但随着客户规模越来越大,产品模型的问题也越来越多,在客户的压力下,只能靠一次次的定制化分析来临时满足要求,但无法从根子上解决问题。


我问为什么不求助数据中台团队,他说数据中台团队不太理解业务,很难做好模型,我说能不能尝试一下,他虽然同意了,但还是有点不清不愿,在模型验证配合上也不是很主动。


我要求数据中台团队更主动一点,数据中台团队也比较委屈,说我们也很努力了,但产品对我们的模型方案似乎不太认可。直到最近两只团队才算有了真正的合作,数据中台团队也比较争气,交付的模型质量达到了预期。


有了第一次合作,大家就形成了基本的信任,有了数据中台团队的支持,产品侧能够腾出更多的精力去干自己擅长的事情。


但团队之间要形成信任并不是那么容易,第一,需要领导自上而下的宣贯和影响;第二,需要组织机制的保障;第三,需要产品方和中台方有一定的觉悟,站位能高一点;最后还需要中台方具备足够的实力,多点工匠精神,因为市场最终还是实力说话。


当然最重要的,还是两只团队都要有想干事,干成事的那股劲。我们的数据中台团队一直在努力寻找价值出口,数据产品团队一直在追求更高业绩,在这一点上他们有共同的目标,这才是双方能够协同的根本。



数据新人职场第一年,需要证明自己的可塑性 by 大鱼先生
我的数据人才观 by 大鱼先生
数据领域,甲方和乙方分工的18个原则 by 大鱼先生
为什么我说OKR与KPI没有本质区别?(万字长文解读) by 大鱼先生
数据驱动业务的18个有效策略
数据管理的格局
繁华落尽,做数据有了“面子”,更别忘了“里子”
皮实,我就喜欢这样的下属!

点击左下角“阅读原文”查看更多精彩文章,后台回复【加群】申请加入万人数据学习社群


🧐分享、点赞、在看,给个3连击呗!👇

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存