租赁调度软件:如何规划送货、司机与设备

把一件设备从仓库送到一个客户手中,是一个已经解决的问题:选一名司机,给他一个地址,他就出发了。但要在同一天把十二件或二十件设备送到十二个或二十个不同的客户那里,有些要送货,有些要取货,有些已经锁定在固定的上午时段,有些则比较灵活,这就是一个完全不同的问题。这既是一个排序问题,也是一个排期问题:哪些停靠点彼此相邻,哪名司机本来就要往那个方向走,以及哪些地址实际上够得着,这些都要在路线定下来之前想清楚,而不是等货车装好车出发以后才发现。

这正是租赁调度中最容易被忽视的部分。关于司机出发之后会发生什么,已经有很多可以说的,从他们在路上使用的司机应用,到客户等待时看到的送货体验,再到在交接时留存扎实证据,这方面能说的就更多了。这篇文章要讲的是在这一切之前的那一步:办公室里的规划界面,也就是当天路线真正被搭建出来的地方,发生在任何一名司机离开仓库之前。如果路线搭建得不好,再精致的应用,再完整的交接证据,都弥补不了后面出的问题:一名司机一天之内三次穿过同一个邮编区域,一个停靠点直到司机把车停在它面前才有人意识到它超出了服务区域,或者某个老客户每周一次的上门服务被忘掉,只因为没有人从上周的清单重新搭建当天的路线。

当天路线的起点应该是已经存在的预订,而不是当天早上负责排线的人重新打出来的一份清单。租赁订单本身已经包含送货地址、要送出或要取回的物品、现场联系人以及相关日期,因为这些信息是在下单时就记录下来的,而不是在调度那一刻才临时编造的。把这些信息中的任何一项重新输入到一个独立的规划工具里,恰恰就是错误潜入的地方:邮编里被打乱顺序的数字、从错误行里复制来的联系电话、悄悄偏离实际报价的物品数量。

在 Renttix 中,送货和取货任务直接在调度看板上规划,信息来自订单本身,而不是一份并行的电子表格。这一点比听起来更重要:负责规划当天路线的人,使用的正是客户订单所在的那份记录,因此对订单所做的任何修改,更新后的数量、不同的现场联系人、改期后的日期,都会直接体现为看板上的变化,而不必再单独通知负责路线计划的人。

当天的任务一旦生成,接下来要做的就是把它们安排成司机真正能够按合理顺序完成的样子。这并不是什么特别的事:把彼此相邻的送货和取货归到同一条路线里,而不是让一名司机在城里绕来绕去,同时另一名司机只负责三条街之外的区域,这是路线规划中一个基本且广为人知的原则。这样做的好处很直接:更少的里程、停靠点之间更少浪费的时间,还有一条司机可以记在脑子里的路线,而不是被一个完全不知道接下来会发生什么的导航仪一站一站地牵着走。

在调度看板上,任务按路线分组并直接分配给司机,这样负责规划当天工作的人就能在路线搭建的过程中看到它的整体形态:哪些停靠点应该放在一起,哪名司机当天任务本来就不多、还能再接一单,以及哪些任务还没有分配给任何人。把这幅图景搭建在调度看板上,而不是在一份打印清单和一张单独的地图之间来回折腾,能让整条路线成为一个统一的计划,而不是几份必须在司机出发前彼此对得上的文件。

调度规划中最容易避免的问题之一,就是一个从一开始就不该被接受的地址。一个通过电话记下的预订,或者一个被重新用于新订单的老客户地址,可能落在仓库实际能够覆盖的区域之外,而通常第一个发现这一点的人,是一名在预定时段之后四十分钟停在大门外、打电话回办公室询问该怎么办的司机。

Renttix 在规划阶段就处理这个问题,而不是在路上处理。每个仓库都有一个在地图上以多边形定义的服务区域,送货地址会与之核对。通过已接入商城下的订单,如果地址超出相应仓库的覆盖范围,会在结账前就被拦截,这样这笔预订从一开始就不会被接受。对于通过其他方式进入看板的订单,在规划当天路线时会应用同样的检查:超出仓库服务区域的停靠点,会在路线仍在搭建的阶段就在调度看板上被标记为超出区域,而不是等货车已经离开仓库之后才发现。这就是关键的区别所在:关于一个任务是否可行的判断,发生在规划界面上,有充足的时间把它重新分配给正确的仓库,或者向客户核实,而不是发生在某个人停在路边时用手机通话的当口。

租赁业务中有相当一部分是重复性的:同一个客户每周同一天租用同样的物品,或者一份持续数月、按固定间隔安排送货和取货的合同。哪怕客户的模式从不改变,每天都从一张空白表格开始规划路线,也是白费力气,同时也是一种可靠性上的风险。如果搭建明天的路线要依靠有人记得某个特定客户又该上门服务了,那么迟早会有人忘记。

周期性排程通过自动生成调度任务来解决这个问题。规律只需设置一次,从那以后,相应的送货和取货就会在正确的日期自动出现在看板上,并且已经打上了各自所属路线的标记。规划下一周工作的仓库不必从零开始;重复上门的任务已经排在对应的日期上,真正的规划工作其实是把新增或一次性的任务安排进去,并围绕已经存在的排程做适配。

还有一种相关但不同的情况,就是一份租赁本身就包含持续性的服务内容,而不是一次性送货加最后一次取货。一台需要每周维护的长期租赁移动厕所是最清楚的例子:设备只送出一次,但只要这份租赁还在持续,司机就必须按固定周期回到现场,而每一次这样的上门都是独立的一个任务,都有自己独立的完成记录。

在订单中添加一个服务项,直接处理了这种情况:Renttix 会据此生成这份租赁整个期限内的上门排程,并且每一次上门都会沿着自己的生命周期被跟踪,从已排期,到已完成,再到可开票。最后这一步对规划的意义不亚于对开票的意义:一次处于可开票状态的已完成上门,是一个看得见的信号,说明这项任务确实发生过并且被正确收尾了,而不是要在月底另外去追讨的东西。

把路线规划好只是工作的一半;知道司机出发之后事情实际进展如何,是另一半。一旦一项任务被分配出去,而司机正在执行它,它的状态就会实时呈现给办公室。一项正在进行、暂停或已完成的任务,会出现在它被规划时所在的同一个看板上,而不是要等到司机当天结束回到仓库时才被知道。

对于负责调度的人来说,这就是在还有时间采取行动时对问题做出反应,和事后才知道之间的区别。如果一条路线上后面的某项任务会因为前一个停靠点耗时超出预期而延误,这一点在当天剩余时间还能调整的时候就能被看到。司机在执行任务过程中的自身体验,比如记录签名、照片等等,是一个值得单独成文的话题;从规划这一侧来看,重要的是调度看板和司机应用读取的是同一个底层任务,而不是两套需要人工核对的独立系统。

举例来说,设想一个仓库正在为第二天规划一条混合路线上的送货和取货:那一周新进来的几笔一次性订单、几份长期租赁到期的每周维护上门,以及两笔即将结束的租赁取货。这些都不需要从各自独立的清单里拼凑出来。一次性订单出现在看板上,是因为它们从一开始就是作为订单被预订的;每周维护上门之所以已经在那里,是因为它们由各自的服务项生成;而取货任务出现在看板上,是因为对应租赁的结束日期触发了它们。那天早上规划人员真正要做的,是检查任何被标记为超出区域的地址,把剩下的停靠点按区域分组成合理的路线,再分配给当班的司机,而不是重新发明一条其实大部分内容早就摆在那里、只等着被整理好的路线。

这正是应该把调度规划当作一门独立学科来对待的真正原因,它既不同于司机应用,也不同于送货记录:这是决定一天最终变成一份排序合理、切实可行的计划,还是变成一份到上午过半就散架的美好愿望清单的那个阶段。如果你想看看这样一条混合路线,在你自己的调度看板上,配合你自己的仓库、服务区域和老客户,会是什么样子,预约一次演示,我们一起来看看。