摘要:本文深入探讨物流产品经理在TMS系统(运输管理)商超零售城配场景下的进阶之路,同时聚焦产研合作的基本原则。通过剖析复杂运输场景和核心业务指标,结合实际案例,为物流产品经理提供宝贵经验和实用指南。
本文深入探讨物流产品经理在TMS系统(运输管理)商超零售城配场景下的进阶之路,同时聚焦产研合作的基本原则。通过剖析复杂运输场景和核心业务指标,结合实际案例,为物流产品经理提供宝贵经验和实用指南。
完蛋了!我的两任技术搭档炜哥和瑫哥也跑过来关注了我的公众号,这让我压力很大。后续文章我还是自我审核两遍再发吧,严谨点,这二位都是掘地三尺,刨根问底的高手;同时感谢二位多年对我这种产品风格的容忍。
要不,我们先讨论一个问题:产品经理和技术团队到底如何搭档才有最佳产出呢?对于这个问题,我们统一认识:
最佳产出:这里的产出物到底是什么?最佳的标准是什么
产品经理的输出应该包括什么?产品经理最好不要介入哪儿些事情。
下面是我个人思考与实践,可能与其他产品的日常工作标准不同,我们不相互抬杠,适配自己团队的就是最好的产品经理的产出物及最佳标准
产品经理的工作有很多,从面向研发团队的交付而言,我认为最佳产出物是:讲明白和带回成就感, 什么叫讲明白?怎么带回成就感?
讲明白:是产品经理在对业务的深刻理解前提下,将产品方案讲明白,我发现有些产品为了在技术评审时 保证产品方案能通过,开始玩儿小心思;这样除了增加产品和研发/测试人员的间隙,毛帮助没有,后续的技术评审就变得双方相互头疼和火药味十足,要知道产品经理的背靠背是研发和测试人员,他们的输出质量完全决定了产品在面向客户时有多少底气,所以产品经理坦诚一点:讲明白是将业务场景讲明白,产品经理一定是个讲故事的高手,业务现场的业务现状,业务流程,角色职责及角色之间的冲突以及业务的深度挖掘,包括未来业务的走向,只有通过产品经理生动的演绎,才能为研发和测试提供统一的业务基础,为产品方案的评审和技术方案的构建提供正确的方向,这是技术团队负责人最关心的地方,当一个团队没有技术架构师时,技术团队负责人就负责了产品方案转换为技术方案的人选,所以不要吝啬讲业务故事的时间,一个评审会我基本是拿出一半儿的时间再讲业务故事,从实践来看,炜哥和瑫哥他们也没提出反对意见,看来他们也接受这种方式。讲明白是将产品方案讲明白,这里的产品方案不是你直接掏出流程图,掏出你的原型;而是产品经理是怎么思考的,为什么选择当下的方案,这套方案的优点在哪儿,缺点在哪;当第一阶段[ 讲故事 ] 结束后,其实你的产品方案 研发和测试理解是水到渠成的事情,原因很简单:大家是基于同一个业务场景说事情。至于你的产品方案硬性产出物:流程图,动作时序图,原型图,PRD文档,是为了辅助你把产品方案讲明白。而不是说这些留痕就是产品方案(当然这些也很重要,是为了后续开发过程中回看的需要,这部分硬性产出我做的就非常的不好,感谢炜哥和瑫哥的不杀之恩)。带回成就感:首先我们要严重明确一下:产品经理不是输出PRD/流程图给研发并评审完毕,就是算自己完美交付了, 研发不是按照产品的方案开发完毕并发布上线就完美结束了, 这不是一种团队合作方式,这只能叫团伙儿,我不咋喜欢这种方式。
带回成就感是说当你的方案发布后,产品经理要负责实施效果的跟进,并把业务现场的直观变化以及作业人员的心理感受带回来,交付给你的研发团队,这样研发的代码就有了业务生命力,“原来我的代码片段是对这块儿业务起作用” ,“原来我的代码这么大的使用量,需要多加一些监控保证稳定性,或者多堆一些机器扛一下突增流量高峰”,这些内容就会在技术团队间形成共识。一旦这份责任感和自豪感形成,那他们的代码在场景开发时,对异常和边界的开发就会有的放矢,测试Case也会在覆盖度方面有了自己的考量标准;这个时候产品经理上线前验收不验收就变得不重要(回想起来我好像就咋做过功能验收,感谢炜哥和瑫哥对我这么懒产品的容忍)。
讲明白和带回成就感 就是最佳标准吗?
产品经理通过对业务现场的需求挖掘和分析,解决了业务痛点,实现了业务交付。产品经理和研发测试团队基于统一的业务场景,实现了产品方案和技术方案的交付,产研团队在业务领域专业度上同步精进,合作沟通无团队间内耗我认为这就是最佳标准。产品经理最好不要介入哪儿些事情:
百度文化中有一项:把最好的一棒交给下游;同时信任自己一样信任兄弟部门把事情做到优秀。所以产品经理不要介入技术方案的选型和设计,也不要介入技术开发逻辑,包括数据库设计。产品可以有写Python,Shell和SQL语句的技能,这是为了方便业务数据分析和系统故障的判定,但是在技术评审环节研发在讨论技术方案设计阶段产品给出技术见解是不合适的,技术团队负责人或者技术架构师会有自己的判断。我认为这是有必要的,就像产品要把重点精力放到业务需求的挖掘,需求真实性判定和产品方案有效产出上一样。如果产品把精力放到技术领域势必导致需求挖掘和方案产出思考的不足。毕竟一个人的精力是有限的
这个产品工作有个缺点:产品硬性输出物会不像功能型产品经理写的那么标准。会对后续产品研发人员的接手有一定障碍。
上面这么大篇幅讲产研团队合作和对外一致输出,这需要产品经理很大的功力,涉及到产品经理非常专业的技能:需求的挖掘与分析, 这部分我们放到这本书的最后来讲,这部分内容太多,并且不太好描述,有点可意会不可的味道。
好了,有感而发到此结束,我们继续我们伟大的事业:我昨天晚上对书籍大纲做了调整,把零售数字化转型和我们产品非常相关的『信息化数字化』部分单独出了章节,请大家看看是否合适:
下面是调整后的大纲,大家可以对比前续文章中的大纲做一下对比。
昨天我说会节选 这本书的章节:
业务场景:商超零售城配场景
嗯,下面就是这个章节的内容,由于这个章节内容太多,我们分成两部分:业务场景:商超零售城配场景(一)
我们以一家全国零售企业为例,这家企业有800多家门店分布在全国各地,尤其在重庆,闽赣,京津冀,云贵最为集中。物流园区多以自建为主,仓储设备在自动化智能化方面走在同行前列,在供应链方面,物流运输尤其在生鲜运输方面有自己独特的运输标准和时效要求。在物流规划上,集成了源头仓,产地加工厂,中心仓,边缘仓,销地加工厂,门店/到家仓;其中门店又形成了前店后仓的配送业务,到家仓的配送业务,所以这家企业的运输场景集成了:
源头仓—-中心仓/边缘仓:社会车辆运输模式中心仓 —- 中心仓:干线运输中心仓—-边缘仓:支线运输边缘仓/中心仓 —- 门店/前置仓:城配运输门店/前置仓 —- 顾客:最后一公里运输在运输包裹维度,所需要的运输环境及车辆也有很大区别,特征包括:
食百标品打板包裹:商品是长保质期商品,商品包装为箱/包/个;同一商品条码下商品体积重量恒定。方便打板,一般打板高度在1.8m-2.2m,液体软饮(比如牛奶)等打板在1.6m左右。常温下就可运输。
干杂易碎易压非标打板包裹:针对袋装大米,袋装面粉。袋装粉丝,调料等进行打板,易压轻碰是商品的搬运禁忌要素。
生鲜短保非标打板包裹:比如称重黄瓜,西红柿等散装商品运输,比如易裂商品西瓜和白萝卜,且自然水分蒸发导致商品品相降级,这类商品在运输时需要特殊容器。尤其夏天运输需要使用冷藏货厢
冻货冷冻包裹:比如冷冻带鱼,冻丸子等商品是需要在冷冻温度下运输,常年使用冷冻车厢。
水产非标特殊条件包括:这类最难运输,活体搬运有天然的死亡率,如果在温度,湿度,含氧量,含盐量出现问题死亡率大幅增加
在执行食百标品运输时,由于每天门店/前置仓要货量大,全天生产满足业务口需求,所以食百类大仓一般采用仓驱动运的方式,也就是调度人员定时巡场(查看发货区待发货的包裹数量),达到满载率且成本较低即可发车。
在执行生鲜/冻品等品类时,由于叶菜,根茎类商品自然损耗严重,如果收货后采用上架会导致成品满足率更差,所以采用运驱动仓的作业方式,也就是商品到货后,由调度员安排具体哪儿些门店/前置仓派车到同一车次,将该车次作为仓库的拣货波次进行拣货作业。
在运力资源维度,由于食百大仓全天24小时轮波发车,生鲜以供商送货到库立马分播出库,导致物流园运力长时间处于备运状态或者运营状态。这种情况下就需要运力随叫随到,基于这种特性,公司采用两种方式进行运力的管理
公司自有运力资源:即公司自行购买车辆,车辆的运营损耗/绿牌车的充电保养/油车的油费例行保养均由公司负担
与承运商签约,车辆所有权归及后续的保养等事宜承运商,运营权归零售公司,从而保证了运力资源的随时可用,这也是目前大部分零售商的做法
由于收货门店/前置仓有卖场,有精品店,有便利店,导致能通行的车辆高度,是否必须有尾板成为车型的限制要素,所以一般零售公司运营车辆包括多种车型,比如4.2T,7.6T,9.6T。
至此,我们将该公司的业务背景介绍完毕,作为产品经理第一步是能够对公司业务做第一层的抽象概括,这一步很重要,这标志着你能否鸟瞰公司的整体运输业务并能够剥离出运输业务的边界(这里就涉及到输入输出思维模型),运输链路抽象示意图如下:
我们说过:按时、安全和经济性是物流运输的核心要素,而经济性是当下环境“降本增效”重点考虑的方向,这里我们需要重点介绍一个指标:
满载率:(它的反义词是空载率,都是表达同一个本质问题):在仓库生产作业货物件数相同的情况下,通过将车厢装更多货物,就可以降低车辆运输次数,从而降低成本。所以满载率越高,整体运输成本越低。
我们在介绍实际作业场景之前,需要重点介绍几个和TMS运输管理系统相关的基础概念以及设计逻辑说明:
物流园区:也叫物流园,什么叫物流园?和仓库什么关系?一般来说是几个距离较近仓库,被统一物业或者高墙管理的区域叫物流园,在同一物流园中的仓库,行使的功能有可能进行分化,比如产生独立的合流仓(就是几个仓库货量小,货随着不断生产,录入搬运到合流仓,合流仓将几个仓库的货进行统筹调度发车。这个区域就是物流园区。
仓库:商品暂存和中转的场地,和工厂的车间类似,里面有很多货架和暂存的商品,仓库作业人员将上游订单转为商品并集合成包裹。
装运点:这是一个运输业务的重要概念,装运点是指仓库生产的包裹在该地点进行装车交接。那么装运点和仓库是什么关系呢?是不是一个仓库就有一个装运点?不是!
可以是一个仓库一个装运点:比如一个小型仓库都集中到这个仓库的一个装运点进行集中装车作业,这个时候 仓库 : 装运点 = 1:1
也可以是一个仓库多个装运点:同一个仓库有两种不同的零售业态进行发车作业,比如说便利店发车 和 卖场发车,由于两种业态使用的车型,发运时间都不相同,所以就在装运点做了分化,此时 仓库:装运点 = 1:N
也可以是多个仓库对应一个装运点:如果同一个物流园中,其他仓库作业的包裹都集中在合流仓进行发车,那么仓库:装运点 = N:1
装运条件:这个比较好理解,化工商品要按照特定的条件装车,烘焙商品也对车厢环境有特殊要求,面粉等不得与化工或者易漏液商品进行混合运输;这些都是装运条件的内容。
我们就写到这儿吧,后续的内容,我们明天继续。
明天,我会节选 这本书的章节:
业务场景:商超零售城配场景(二)
来源:人人都是产品经理