到底如何划分数据产品与数据中台的边界？

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

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

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

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

第一个是成本的问题。

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

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

第二个是质量的问题。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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