车联通信技术与租赁软件：把设备数据变成运营决策

如今在租赁车队中流转的设备,比十年前多得多的比例已经配备了某种联网传感器或GPS装置。发电机、空压机、挖掘机、高空作业平台,乃至越来越多体型更小的电动工具,出厂时就已装好车联模块,会把数据发送到某个地方,这已成为标配,而不是可选项。这种变化发生得相当渐进,以至于很容易忽略它已经走了多远:一家从未刻意去寻找车联功能的租赁企业,也完全可能正在运营一支车队,其中相当一部分设备早已在传输数据,无论办公室里是否有人利用这个事实。

既然如此,真正值得问的问题就不再是"我的设备有没有车联数据"。越来越多的情况是,您的车队中已经有一部分设备具备这项功能了,而这是厂商的决定,不是租赁公司的决定。更有用的问题是,这些数据在生成之后到底去了哪里,是否传到了正在就那件具体资产做决策的人手中。位置、使用情况和故障数据如果只是躺在厂商自家的应用里,偶尔被唯一还记得登录密码的人看一眼,对一家要规划送货、要计算租期报价、要决定何时保养设备的企业来说,起不了多大作用。同样的数据一旦进入真正决定可用性、定价和维护的系统,情况就完全不同了,尽管传感器本身其实并没有任何变化。

本文关注的正是这个差距,而不是硬件本身的问题:不是要不要安装车联设备,因为很多设备本来就已经有了,而是这些数据之后会发生什么,以及当它不再是一股没人看的孤立数据流、而是开始和这件资产已知的所有其他信息放在一起时,会有什么改变。

车联技术并不是单一的东西;它是一大类联网传感器和数据上报方式的统称,某个具体设备到底上报什么,取决于厂商、设备类型,以及安装时模块是如何配置的。尽管如此,在大多数与租赁相关的设备上,有几种数据类型会反复出现,值得在讨论这些数据该去哪之前,先弄清楚它们一般指的是什么。

位置是最为人熟知的一种:按一定时间间隔或在设备移动时上报的GPS坐标,让人不必亲自去找,就能大致知道一件设备在哪里。使用时数或发动机小时数同样常见,而且在运营上往往更有用:这台发电机自离开场地以来实际运转了多久,这和它单纯被租出去多久是两回事。这两个数字并不相同,而有意思的信息往往就藏在这个差距里。除此之外,许多设备还会上报基本的故障或诊断代码:发动机警告、燃油不足,或者某个原本只有当有人碰巧路过机器旁、或客户打电话投诉设备停止工作时才会被发现的故障。

这些都不算稀奇,也不是哪家供应商独有的做法;多年来,车联技术在工程机械、大型设备和发电机这类装备上大致就是这样上报数据的。真正在实践中千差万别的,不是测量了什么,而是这个读数产生之后会发生什么,以及它是否真的会出现在租赁企业里有人真正会看的屏幕上。

大多数租赁企业遇到的实际问题,不是车联数据不够多。而是这些数据待错了地方。一台由厂商安装了GPS装置和使用传感器的设备,通常会把数据回传到那家厂商自己的门户或应用里,这个系统是为那一个机型品牌专门打造的,登录账号也和企业日常使用的其他一切系统完全分开。这套系统从来就不是为了和租赁管理系统对接而设计的,原因很简单——它不是由租赁管理系统的供应商开发的。它是设备厂商开发的,是这台机器本身的一项功能,而不是围绕它运转的租赁业务的功能。

一个示例说明

设想一家中等规模的设备租赁企业,运营着一支发电机车队,其中大多数设备出厂时就已经装好了GPS追踪器——这并不是租赁公司特意要求或额外付费加装的,只是较新型号上的标准配置。这些追踪器产生的位置和运转小时数据,原则上确实很有用:它能显示一台已经在工地上待了三周、但租期只有两周的发电机,到底是在正常运转,还是从第一周起就已经闲置不动。但实际情况是,这些数据存放在厂商自己的应用里,登录账号是十八个月前车间里的某个人设置的,如今很少再打开,与预订记录、保养计划,或办公室在决定这台发电机是否可以接下一份报价时会查看的任何东西都毫无联系。车联硬件本身在尽职地工作。只是这些数据从来没有到达真正做出租赁决策的地方。

这个差距,比传感器本身更值得关注。对于正在算下一份报价、或正在决定某件资产是否该召回检修的人来说,一个日常运营中没人会去看的独立应用,和完全没有车联数据其实没什么本质区别。车联技术所承诺的东西——了解一件设备在租出去期间到底发生了什么——完全取决于这些数据能否到达一个与它本应支撑的决策相连的地方。

这一点值得直接说清楚,而不是含糊带过:Renttix 不生产、不销售、也不安装车联硬件。它不制造GPS追踪器、传感器,也不制造任何要装到设备上的实体装置。Renttix 所做的,是接收并利用已经联网设备产生的车联数据——传感器和联网功能属于厂商,或者某家专门的车联服务商,而 Renttix 的角色是从这些数据已经存在、需要一个有用的落脚点时才开始的。

这个区别很重要,一家正在考虑租赁车联软件的企业应该清楚自己在评估的到底是什么:不是一款要装到车队上的硬件产品,而是一种方式,能把设备已经产生的车联数据,带入与这件资产其他所有已知信息相同的系统里,而不是让它继续困在厂商自己的门户中。

在 Renttix 内部,这体现为资产智能的一部分:实时车联数据和按资产划分的健康与成本报告、带有冻结与调查机制的受管生命周期状态、条码盘点以及RFID并列存在,而不是作为一个单独加装的模块,只服务于恰好会上报位置的那部分设备。这里的重点不是为了拥有车联功能而拥有车联功能。重点在于,一件资产的实时位置和使用数据,是又一项值得了解的信息,与它带来多少收益、花费多少成本、处于什么状态放在一起,而不是被单独放在别处、由某个必须记得去登录的人另行跟踪。

把车联数据接入租赁管理系统、而不是让它留在厂商独立应用里的价值,其实并不在于数据本身是新的。传感器本来就已经在产生这些数据了。价值在于,当这个读数与企业已经了解的关于同一资产的其他一切信息放在一起时,会浮现出什么。

最清楚的例子就是"已预订"和"已使用"之间的差距。预订记录只能说明某件资产在两个日期之间处于租出状态;它不会说明这段时间里这件资产实际发生了什么。当使用小时数据进入与预订同一个资产记录时,这个差距就开始被填补——它能显示一台租期两周的发电机是否真的运转了两周,还是在最初几天之后大部分时间都闲置不动。这与单纯的"是否已预订"是完全不同的信息,而且通常也是租赁企业除了打电话到工地询问现场的人之外,没有别的办法获得的信息。

同样的模式也适用于跨场地的可见性:车联数据中的位置信息,会汇入同一个实时视图,显示资产在各个场地和堆场里实际所在的位置,而不必再为那些恰好会上报GPS的设备,单独去查厂商自己的地图。同样重要的是要诚实说明这一点目前还做不到什么:使用数据与成本、收益信息放在一起,原则上未来或许能够为按使用量计费的决策提供参考,一些租赁企业确实已经在这样考虑。但那是整个行业正在朝向的一个大方向,并不是 Renttix 今天可以宣称拥有的具体计费功能。真正已经实现的,是可见性本身:一幅更完整的图景,让人知道某件具体资产是否真的在被使用,而且就在它的健康与成本报告所在的同一个地方,而不是归档在一个独立应用里,让人在做出那个决定之前根本想不到要去查看。

如果您的车队里已经有厂商预装车联功能的设备——而且越来越可能有一部分确实如此——真正实际要做的功课,并不是决定要不要引入车联技术。而是要弄清楚这些数据现在到底流向了哪里,以及正在做出可用性、定价或维护决策的人是否真的会去看它。

一个合理的起点是:列出您车队中已知具备某种联网追踪能力的设备,不论是GPS、使用小时数,还是基本的故障代码。对每一件设备都问一下:谁在看这些数据、多久看一次,以及这些数据是否哪怕稍微靠近用来计算租赁报价、安排保养、或核算某件资产实际运营成本的系统。如果诚实的答案是"那些数据在某一个人手机上的某个应用里"或者"我们其实几乎从没登录过那个门户",那么问题不在硬件本身。问题在于数据所在的地方和决策发生的地方之间的脱节。

租赁车联数据如果能到达与资产的收益、成本和健康记录相同的地方,就能把厂商的传感器——迄今为止只是一个没人查看的功能——变成真正能改变办公室下一步做法的信息。如果您想看看这在自己的车队上会是什么样子,包括那些出厂时就已配备车联功能的设备,欢迎预约演示,并带上一个真实的例子。