导语：在上一篇数据中台的实战文章《数据中台实战：以圆猿买手为案例谈如何从0到1搭建实时标签引擎》中，作者为我们讲了如何打造一个实时的标签平台，这篇文章，作者分享了做中台项目时的失败案例以及怎么避免中台项目失败。

当阿里巴巴在2009年完成了分布式架构的改造后，淘宝平台整体能力得到了质的提升。此时却面临了新的挑战和问题，随着淘宝商家交易量的爆发式增长以及越来越多大型的零售快消行业入驻淘宝和天猫，原有平台所提供的商品管理、库存管理等功能显得捉襟见肘，大大影响了商家的运营效率。

这些几百万的商家从某种程度对于淘宝和天猫来说是衣食父母，没有这些商家在淘宝和天猫上开店，也就没有了电商平台存在的价值，所以面对这些商家的诉求，淘宝团队第一时间就调集了当时在ERP、CRM业界最为专业的团队，开发了一套针对淘宝和天猫上商家提供统一CRM服务的平台，以提升商家对于商品、库存、促销、物流各方面的运营能力。

经过近百人、几个月的浴血奋战，淘宝统一CRM平台很快推出上线，商家使用CRM的服务所需的服务费用也非常低廉，甚至对于一些商家是提供免费服务。当大家都以为这样将大大提升商家的开店体验，商家对淘宝平台的满意度会显著提升时，结果却让人大跌眼镜，大部分商家对于淘宝建设的统一CRM平台怨声载道，淘宝团队在一段时间内对CRM平台进行了全力优化和改进，但还是没有改变CRM平台最终下线的结局。

究其原因，我认为本质上是统一CRM平台建设前，对于所服务客户的需求并没有清晰的认识，在当时淘宝近200万商家中，有来自家电、服务、数码、生鲜、玩具等上百个不同行业；有像双11那天一天交易金额超10亿的大型商家，也有一年交易额可能几千块的商家；这些客户存在的差异导致对于CRM平台的需求差别是巨大的，所以寄希望用一套统一的平台解决需求差异这么大的用户群体，最终的结果一定是所有人都不满意。

在项目失败后，淘宝团队对项目进行了复盘，总结和定位出失败的原因，痛定思痛之后，开始了淘宝开放平台的建设。淘宝开放平台是将淘宝和天猫上商家后台数据开放给商家授权的技术团队，基于商家后台系统开放的权限能实现商家针对商品、库存、订单、物流和客服等个性化的业务流程。

商家自身的开发团队或者第三方的开发商基于淘宝所开放的商家数据，经过定制和扩展后，实现了商家各自不用的需求，从而根本上提升了一直困扰商家很长时间的运营效率问题。

几年前做数据中台项目时也犯过同样的错误，当时运营团队要定期给某个排行榜前十的用户发优惠券，以刺激他们复购。由于排行榜规则比较复杂，业务线产品研发团队很难搞定，需要数据中台团队提供排行榜数据。因为是周期性的发券任务，此时业务团队提出要做一个排行榜用户展示及数据导出的功能。

当时属于数据中台项目初期，数据中台就连一个可视化的组件都没有，这个排行榜做起来还是有一定的工作量，我们团队就十分纠结排行榜展示及导出的功能该由谁来做。当时业务产品研发团队是不想做这个事的，因为他们觉得既然那么复杂的排行榜的数据是由你计算的，那开发一个展示及导出的功能，岂不是非常简单？就想推给我们来做这个事。

当时我们的团队也是这么想，既然这么复杂的排行榜算法我们就搞定了，如果把数据拱手让人，交给其他团队，那我们数据中台的价值怎么体现呢？最后在这种想法的驱动下，数据中台还是硬着头皮把这件事给做了。

不过现在想想这件事是犯了一个中台团队极其典型的错误：

把自己当后台，什么都想做。中台是什么？中台就是中心化的能力复用平台，无论业务中台还是数据中台提供的都是底层的通用的能力。

上面排行榜案例中其实犯了很大的错误，作为数据中台，你要非常清晰哪些应该你来做，哪些应该业务团队来做。那个排行榜的功能，数据中台要做的只应该是提供排行榜的数据接口给业务团队，然后由业务团队承担展示及导出的功能。

现在由数据中台团队来做，就导致运营团队每当做这个活动，一边要登录数据中台来取数，一边要登录业务系统来配置优惠券活动，业务团队做活动时还是更习惯用业务系统，这样不是浪费他们的时间吗？另外数据中台做的这个针对这个业务线的排行榜功能，真的能够复用给其他的业务团队使用吗？其实很难。

当时经过反思，为了不犯同样的错误，给团队定下了几个规则：

• 数据要开发的功能能不能节省业务团队2个小时以上的时间？（保证数据中台研发的功能能提高业务团队的效率）
• 数据中台要开发的相关指标能不能直接反馈公司的问题或者帮助公司增长？（确保数据中台开发的数据指标对公司有价值）
• 数据中台开发的功能未来能否开放给商家使用？（做为一个电商平台，针对业务人员开发的功能要能够复用给商家，保证数据中台的复用性）

阿里做CRM的项目也是犯了同样的错误，不把自己当中台，把自己当后台，想通过一个几百人的团队搞定200万商家的所有需求，简直是痴心妄想。

阿里引入的新的角色第三方开发商，简直是神来一笔，由原来自己的几百人的团队，变成与几千甚至几万人的第三方开发商合作共同服务200万的商家，这样就能保证大部分的商家需求能得到满足。

我这里提到一个了一个关键词“合作”，对于中台团队，合作能力及其重要，合作能力决定一个人的上限，也决定一个团队的上限。

中台是站在公司全局的角度去搭建系统的，就必定触碰到公司下面某些部门的利益。我做业务中台项目经常被问，这个功能凭什么要交给你来开发，我自己做不是更快吗？做数据中台项目遇到的最大问题也是，我的数据为什么要给你？

怎么解决这一系列的问题？

其实都是合作的问题，做中台，你不仅要向业务线团队推你的中台系统，还要向业务线团队推公司为什么要搭中台，中台怎么帮你们业务部门等等这些问题，给他们洗脑。

不但要洗脑还要真正的通过中台帮助业务部门解决问题，这样才能慢慢的与他们合作起来，他们才会越来越依赖中台，否则你一根筋，自己什么都想干，到最后什么都干不好，还得罪一群人。

当时公司电商平台发展到一定阶段要引入推荐系统，推荐系统最核心的其实还是算法，应该由数据中台团队主导，但数据团队的强项是做算法，业务线产品、运营团队对业务流和数据流更加了解。

当时我们遇到一个情况是，业务线产品技术团队已经开发了一个轻量的推荐系统，已经在试行。这个问题就比较难搞了，我们是推翻业务线产品、技术团队搭的推荐系统重新来做呢？（因为他们搭的推荐系统是针对自己的业务来设计，通用性不强）还是在他们的基础上去做呢？如果推翻他们好不容易搭的推荐系统重新去做，业务线的产品、运营团队肯定是不乐意的，这种感觉就好像他们正在打牌，突然来了个数据中台掀翻了他们的桌子，搁谁谁都生气。

当时我们梳理了他们现有的系统，发现他们做的推荐系统，一部分功能是可以复用的，比如说用户行为（访问、浏览、加购、下单）权重的设置，这些功能我们采用同步数据的方式来读取运营人员设置的权重，这样一方面保证了业务产品技术团队开发的功能不被浪费，另外一方面可以让运营人员参与进来，由他们设置初期的用户行为权重，这样做，他们是有参与感的。

但是他们做的算法模块是真的不行，太个性化，没办法通用。推荐系统是需要按照召回、排序、过滤的标准流程分大块，来设计系统的，这样才能保证推荐系统后面能复用给其他业务团队，所以算法这块，我们决定推倒重来，由数据中台算法团队主导，当时还给业务线产品运营 团队做了培训，讲清楚为什么要这么做。

另外只有干巴巴的算法是不行的，还需要业务线产品、运营团队的配合。业务线的产品技术团队帮助梳理了核心的业务流和数据流以及补充了新版推荐需要的数据埋点。业务线的运营团队更加了解业务，比如做为一家快时尚电商平台，针对新款的权重应该更高、什么时候是用户的访问高峰期（决定计算时间）、高退款率的商家该怎么处理等等，把这些因素都考虑进去加入了算法。

最最要的是数据中台团队和业务线产品、运营团队，当时定了一个目标：选择了几个平行的坑位中的一个当推荐坑位，这个推荐坑位的转化率（访问/支付）至少要和由人工组货的平行坑位持平。最终我们一起合作做了3个大的版本，半年的时间做到推荐坑位的转化率是人工组货平行坑位的2-3倍。

这算是一个中台团队和其他部门合作做的一个非常典型，从结果来看效果还算不错的案例。为什么最后的效果还不错，就是因为各个团队合作的很好，各自发挥自己的优势，大家参与感都很强，都觉得自己是有价值的，发挥出了1+1大于2的效果。

做中台，千万不要把自己当成了后台，总想着蛇吞象，什么都做，这样很容易消化不良，还容易得罪人。

做中台，与其他部门的合作能力极其重要，合作能力也决定中台团队的上限，有时候该当孙子就当孙子，该当爷的时候也尽量要憋着，毕竟完成目标才最重要嘛。

Wilton董超华，微信公众号：改变世界的产品经理，人人都是产品经理专栏作家。畅销书《数据中台实战》作者，曾任职科大讯飞，现任富力环球商品贸易港数据中台产品负责人。主要分享商业、产品、运营、数据中台相关原创文章。

本文原创发布于人人都是产品经理，未经许可，禁止转载。

题图来自 Unsplash，基于 CC0 协议