【转载】菜鸟物流数据化-破局之路的思考

导读

    菜鸟作为了阿里生态"商流,支付流,物流"中的核心一环,从出生那一天起,就担负起"以数据化的方式改变传统物流行业"的责任,最终实现全国24小时达,全球72小时达的使命. 数据化如此的重要,主要责任方是哪个团队呢?(这里指的是运营,产品,还是技术) 具体推进策略是什么呢? 在推进过程中,遇到的问题是什么呢? 本文尝试着回答这些问题,也是希望能够抛砖引玉,愈辩愈明!

前言

本人自2017年从集团到菜鸟CTO团队,服务于菜鸟国际的业务。在此之前是在集团的业务平台事业部的商品团队,平台型团队更多考虑的是系统/产品的高复用,可扩展性以及稳定性的问题,同时还要解决业务接入的效率问题; 在这样的团队技术是有很大的主动权的,能够清晰的知道今年,明年的工作。

而我在菜鸟技术近3年的时间里,是完全不同的场景,我们紧贴着业务,支撑业务的发展。 技术团队的工作以及规划是与业务紧密的联系在一起的。

举两个具体的例子:

第一个例子, 菜鸟国际超过20人天的项目,都会要求强制上BBB(buddy,buddy,buddy),即由业务,产品,技术的一些资深同学作为评委,项目发起的同学(也是三方)以present PPT的方式,大家一起讨论决策是否要启动项目,其中会重点讨论业务价值,产品方案,以及技术成本等,诚然,这样的机制最大程度的规避的一些业务价值并不明确的项目。但也带也一些问题,比如一些前瞻性,或摸着石头过河的项目就会受到很大的挑战。(本文并不是想深入讨论BBB机制的优缺点。)

另一个例子是每次搞年度规划(无论是新财年,还是S2)都比较痛苦。我们基本上是根据业务的规划,再到产品,再到技术,一层层分解下来了。而在每次规划的时候,业务很多只是有一些大方向,而没有具体落地的事情。而技术需要更具体一些的事情规划,所以就会存在反向push产品,业务一起将大方向分解成可落地的一个个项目。 这本身是一个加速的过程,对于尽快理清楚业务的规划是有帮助的。但最终还是有很多的不确定性。另外,在这个时候要求业务down到具体的项目一层,本身是否合理是值得探究的。

结合以上两点,我常常在想,在这样的技术团队除了服务于"运营"(这里对"运营"打个引号,后面会有更清楚的阐述),支撑好业务之外,技术团队是否应该有自己明确的方向呢? 基于这个方向,就可有我们自己的强抓手,确保每年都会朝着这个方向努力,并取得一定进展。 这就引出了这篇文章的主题: 技术的方向就是数据化!

注: 本文并没有更多关注在数据从采集,挖掘到反馈的完整闭环场景上,一方面是这个闭环的道理大家都能明白;
另一方面,在这个闭环中,数据本身是最根本和重要的一环;
没有数据就谈不上智能.而菜鸟目前面临最大的问题是数据化.对于数据的挖掘与使用这方面阿里有着强大的数据驱动的电商与支付的经验,所以在这一点上并不用过于担心.(当然,前提是对物流行业有着深刻的理解才可以.)

附上典型电商场景下的数据的闭环场景. 这里可以看出,电商的大部分数据已经是线上化了, 这是物流区别与电商很重要的区别.

数据化改造物流行业

在菜鸟对内对外大大小小的场合,我们一直在说,菜鸟的未来是通过数据化物流要素,从而改造整个物流行业。这里我直接引用菜鸟CEO万姥爷在菜鸟5周年大会的演讲吧。

其次我想再用一句话更详细地阐述一下我们为什么做数据化、社会化协同的物流平台，我们要做的事情是链接物流要素、输出平台能力、基于智能算法的供应链解决方案。实际上物流是一个非常传统的行业，它已经存在了上千年，而这个行业实际上它的互联网化才刚刚开始，这就是为什么有这么多关