【在路上3】大数据离线分析快递的派件时效

【在路上1】快递物流大数据的由来

【在路上2】快递的运单轨迹

几乎人人都用过快递,如果说用户最在意什么?那必然是谁家送得快!这也是整个快递物流行业被诟病最多的地方。

都知道顺丰送得快,但价格摆在那里,且它的市场份额不到十分之一。也有许多热心用户质疑,广州到上海开车就18个小时不到,快递怎么样都不可能要四五天(2016年以前),收货1天,运输1天,分拣派件1天,标准时长应该是3天才对,今发后至!这个分析很中肯,同时也是我们自己的疑问,只是无从查起!

很多人都干过一件事,网购以后,每天刷新多次物流轨迹,看看宝贝到哪了。如果上午就到了上海,而下午没有拿到手,大多数人都会发火!

2016年,有了初步的大数据(此时没有任何积累),在高层领导决策下,我们选择了末端派件这么一个环节来进行时效分析。

针对过去一个月进入上海的全部包裹进行数据分析,看看每个网点派件时长,横向对比其它网点,纵向对比该网点不同日期。

咱们用专业术语再来一次:

1,准备20160301至20160407全量签收数据,签收表独立,入库时间作为索引,考虑上传延迟多跑几天。

2,过滤签收网点位于上海,且签收时间位于3月份的数据。签收后可能过1~48小时才会上传入库,所以签收时间不等于入库时间。

3,按照中心发出日期加网点的维度,统计每个网点每天应派件量(中心发出),实际派件量(网点签收),平均时效(签收时间减去中心发出时间)

4,根据坐标计算网点到中心的驾驶时长,留出2小时作为回去后的分拣操作时间,就得到网点实际应该达到的派件时效

所有进入上海的件,在上海中心交给派件网点之前,都会做一次发件扫描,最终派件网点会做签收扫描。

按照这个逻辑,借助Oracle一体机的存储过程跑了一份数据。此时上海全天派件量10万票左右,整个3月份两三百万,跑起来难度不大。

很显然,这份数据根本就没法看!这是纯技术思维考虑的方案,尽管考虑到多跑一段,但是快递业务根本就不是这样的!!!

整个3月份的总量是差不多的,平均时效也偏差不大,问题就在于统计日期,完全错了!

要知道,每天14:30以后到达上海的件,会留到第二天早上6点,作为一派件由网点车拉回去,6:00到12:30作为二派,12:30到14:30作为三派,网点一共会来拉三次件。这里问题最大的就在于一派前半截,下午才到,网点即使拉回去也派不掉,傍晚还得去收件分拣打包。

因此,重新调整了统计日期计算规则,才得到了一份初步数据,以派件任务的视角来查看。这说明,光有技术不行,还得深入到业务之中去。

然而事情并不会那么顺利。拿这份数据去跟网点沟通的时候,才发现自己是多么的幼稚!前面说到,网点会派三次车去中心拉件,这是理想情况。实际上部分网点不会这么操作,比如,几个网点共用一辆车,又比如,二派的车在12:30故意不走,等到13:30,顺带拉走大部分三派的件,等等等!这都是为了节省成本啊,每个人都可以找出成千上万个理由,为派件不及时而辩解,实际上有没有派件不力,就掩盖在其中!

项目就此进入僵局!欲听如何破局,请听下回分解!

这一节进入实战,遇到了许多实实在在的意想不到的问题:

1,采集数据延迟上传,导致业余时间远小于入库时间。而为了能够单向分析以及数据准确性,就得用入库时间作为索引,在目标数据区间前后多跑一段数据。

2,结合快递业务,绝大部分包裹的生命周期在7天以内,因为多跑7天数据。

3,快递有一二三派,不同城市要求不同

---以上所述并非完全真实准确,为了便于书写,把不同时间点发生的事情略微调整。

作者认为,最有价值的应该是大数据落地这么一个过程,如果借助技术去攻城拔寨!

今天除夕,躲在山沟沟里用手机码字实属不易,如果喜欢,帮忙转发一下!

提前祝大家新年快乐!

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
服务中心需求规格说明书 1. 引言 1.1 目的 此需求规格说明书旨在为服务中心的开发提供一个明确的需求框架,以确保系统的开发符合用户需求。 1.2 范围 本文档适用于服务中心的四个模块,即自助服务、新手教学、人工服务和文件下载区。 1.3 参考资料 本文档参考了电商平台相关文档和用户需求调研结果。 2. 服务中心概述 2.1 服务中心功能 服务中心包括自助服务、新手教学、人工服务和文件下载区四个模块。其中,自助服务提供供应商服务热线(电商化采购)、供应商服务热线(电商化执行)、供应商配送时效、供应商售后政策、投诉建议查询等服务;新手教学提供快速登录、搜索商品、采购流程、确认收货等指导;人工服务提供邮件服务、投诉建议、服务工单查询、操作手册等支持;文件下载区提供相关文档下载。 2.2 服务中心用户 服务中心的用户主要是电商平台的供应商和采购商。其中,供应商需要在服务中心中查看订单信息、售后政策、配送时效等信息;采购商则需要在服务中心中学习如何使用电商平台进行采购、查找订单状态等信息。 3. 自助服务模块 3.1 供应商服务热线(电商化采购) 供应商服务热线(电商化采购)提供在线服务,帮助供应商解决采购过程中的问题。用户可以在此模块中查找采购流程、订单状态、商品信息等内容。 3.2 供应商服务热线(电商化执行) 供应商服务热线(电商化执行)提供在线服务,帮助供应商解决订单执行过程中的问题。用户可以在此模块中查找订单状态、配送时效、售后政策等内容。 3.3 供应商配送时效 供应商配送时效提供在线查询服务,帮助供应商查找订单的配送状态和预计到达时间等信息。 3.4 供应商售后政策 供应商售后政策提供在线查询服务,帮助供应商了解售后政策,包括退货、换货、维修等内容。 3.5 投诉建议查询 投诉建议查询提供在线服务,帮助用户查询已提交的投诉和建议的处理进度。 4. 新手教学模块 4.1 快速登录 快速登录提供简单易懂的登录指导,帮助用户快速登录到电商平台。 4.2 搜索商品 搜索商品提供详细的搜索指导,帮助用户快速找到所需商品。 4.3 采购流程 采购流程提供详细的采购指导,帮助用户了解采购流程和订单状态等信息。 4.4 确认收货 确认收货提供详细的收货指导,帮助用户了解如何确认订单收货。 5. 人工服务模块 5.1 邮件服务 邮件服务提供在线服务,帮助用户通过邮件咨询并解决问题。 5.2 投诉建议 投诉建议提供在线服务,帮助用户提交投诉和建议,并跟踪处理进度。 5.3 服务工单查询 服务工单查询提供在线服务,帮助用户查询已提交的服务工单的处理进度。 5.4 操作手册 操作手册提供详细的操作指南,帮助用户了解如何使用电商平台。 6. 文件下载区模块 文件下载区模块提供相关文档下载,包括电商平台使用手册、售后政策等文件。 7. 总体需求 服务中心需要具备以下总体需求: 7.1 用户友好性 服务中心需要具备良好的用户友好性,包括清晰的页面布局、简单易懂的操作指南、符合用户需求的功能等。 7.2 稳定性和安全性 服务中心需要具备稳定性和安全性,包括系统稳定运行、数据安全保障等。 7.3 可扩展性 服务中心需要具备可扩展性,以便在以后增加新的功能和模块。 7.4 可维护性 服务中心需要具备可维护性,以便在系统出现问题时及时修复。 8. 总结 本文档详细描述了服务中心的需求规格,包括自助服务、新手教学、人工服务和文件下载区四个模块的具体功能和用户需求。服务中心需要具备用户友好性、稳定性和安全性、可扩展性和可维护性等总体需求,以满足用户的需求。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值