共享单车车辆淤积：什么情况下系统帮不上忙

早上八点十分，一个地铁口外的停车区堆了九十多辆车，人行道只剩一条能过人的缝。二十分钟后巡查员到场，拍照、上报、等运营商派车，十点出头才清完。

这类场面被讲得太多，容易让人以为装一套共享单车监管平台就一了百了。冷静看，系统能压缩的只是中间那一段，前端的需求和后端的运力，它都管不了。

上线之后，淤积处置的四个环节变了什么

以前处置淤积靠两条线：巡查员在路面上看到，打电话给运营商；运营商自己发现，派人去清。两条线互不通气，同一堆车可能被报两次，也可能一整天没人报。

共享单车监管平台把这件事拆成了四段，每段都留了痕迹。

四段里，系统真正替人干的是第一段和第三段的记录，第二段的判断仍然在人手上：这堆车是该清走，还是该等晚高峰自己消化，算法给不出答案。

第二段之所以难，是因为同样一堆车，工作日早上和周末下午的处理方式相反。工作日的车要往地铁口补，周末的车要从商圈撤。这个方向感来自经验，不来自数据。

四种情况，它确实帮不上忙

把边界说清楚，比把功能说满更有用。下面四种情况，装什么系统都一样。

第一种，车根本进不去的点位。停车区画在断头路尽头、绿化带内侧、地下车库入口，清运车开不进去，只能靠人推。这种点位的问题在线位选择，不在调度。

第二种，运营商运力本身不足。一个片区只有两台清运车，工单派得再快，车也要排队。共享单车监管平台能算出缺口，能考核，但变不出车。

第三种，需求短时暴涨。一场演出散场，两万人同时取车，任何预案都追不上。能做的只有提前封控和临时扩容，属于活动保障，不属于日常调度。

第四种，数据链断了。车锁不广播、嗅探器掉电、网络中断，平台看到的是一个静止的世界。这时候预警不响，不代表没淤积。

工单派给谁，比派得多快更重要

淤积工单最常见的失败不是派得慢，是派错了人。

运营商的运维队按片区划分，一个片区里往往同时有几家企业在投车。监管方在平台里看到的是「这个点位淤积六十八辆」，背后是几家的车混在一起。工单只派给其中一家，别家的车照样堆着，第二天同一时间预警还会响。

比较稳妥的做法是按车辆归属拆单：一次淤积生成一张父单，下挂若干子单，每家只看到自己那部分。这个动作在工单管理里是配置项，配好了扯皮少一半；没配，就是几家企业互相指着对方的车。

升级路径同样要写死。超时未接单升到片区负责人，再超时升到企业区域经理，这条链放在系统里跑，不靠监管方打电话催。催出来的处置，事后翻不到记录。

硬条件四条，缺一条就跑不动

判断一个地方适不适合上这套东西，看四条就够。

四条里，最容易被低估的是第二条。坐标差十几米看起来是小事，实际会让巡查员按图找不到车，几次之后就没人信预警了。第一条则常被高估：以为有备案库就够了，其实库里的车早换过两轮，标识没更新，比对一样对不上。

条件不满足，还有三条路可以走

不是每个地方都能一次到位。条件不足时，按顺序补比一次性铺开更实际。

一是先补台账再上设备。 备案库不全的时候装嗅探器，比对结果全是未备案，采集量再大也没法用。先把运营商报备的车辆标识录全，设备才有比对对象。

二是先做热点再做全城。 挑十条投诉最多的路段布点，跑三个月看处置时长有没有降。降不下来，说明问题不在发现环节，加设备是浪费。

三是先用人工补位，再逐步替换。 巡查员用小程序上报，后台照样生成工单、照样统计办结率。这套流程跑顺了，再决定哪些点位交给设备。

三条路有共同前提：处置流程先跑通，再谈自动化。流程没跑通就上设备，等于把原来的混乱拍成了照片，看着清楚了，事还是那件事。

边界之内，系统值不值

回到那个地铁口。系统能做的是把「发现到派单」从四十分钟压到几分钟，把「谁没接单」变成一条可查的记录。这两件事加起来，通常能省掉一半的扯皮。

验收时有两个数值得一起看：预警到派单的时长，派单到清运完成的时长。前者衡量系统，后者衡量运力。只看前一个，容易得出系统很好的结论；两个一起看，才知道下一步该补设备还是该补车。

它做不到的是让淤积不发生。车往哪骑、人往哪走、运力够不够，这些在系统之外。把系统当成解决淤积的全部手段，装完一定会失望；把它当成把处置过程变透明的工具，用起来就顺。

判断标准很朴素：装之前，淤积清完要多久说不清；装之后，每一堆车从发现到清走有据可查。做到这一点，这套共享单车监管平台就算用对了。