CN107580035B

CN107580035B - 物品的管理方法、客户端、服务端及系统

Info

Publication number: CN107580035B
Application number: CN201710740051.1A
Authority: CN
Inventors: 姚薇; 陈冕
Original assignee: Beijing Mobike Technology Co Ltd
Current assignee: Hanhai Information Technology Shanghai Co Ltd
Priority date: 2017-08-23
Filing date: 2017-08-23
Publication date: 2020-10-09
Anticipated expiration: 2037-08-23
Also published as: CN107580035A

Abstract

本发明公开了一种物品的管理方法、服务端、客户端及系统。该方法实施于用于提供物品共享服务的至少一个物品，包括：根据从客户端获取的所述物品的运营状态变化信息，更新对应物品的运营状态记录；根据多个物品的运营状态记录，获取系统运营数据，以供选择对应的管理策略实施物品管理。根据本发明，可以及时、准确跟踪物品完整的运营过程，有效地定位物品运营中出现的问题，并触发实施对应的物品管理，提升运营效率。

Description

物品的管理方法、客户端、服务端及系统

技术领域

本发明涉及共享物品技术领域，更具体地，涉及一种物品的管理方法、客户端、服务端及系统。

背景技术

随着互联网技术和设备制造技术的飞速发展，通过互联网技术使得具有物品使用权暂时转移至用户的共享物品服务应运而生，可以将闲散物品整合以分时或者分段的模式提供给用户使用，让用户不必付出较高成本就能使用物品，有效利用物品资源，避免物品浪费，提供绿色环保的物品使用服务，例如，近年来兴起的共享自行车、共享汽车、共享充电宝、共享雨伞都属于这类共享物品服务。

随着共享物品服务的普及，带来用户数量的迅速增长，投入运营以提供共享服务的物品的数量也随之大量增长，对物品的管理也带来较大的挑战：目前的物品共享服务，大多依赖大量的线下的运营人员对物品的运营状态进行管理，例如往往需要运营人员对物品的出库、入库、维修等状态在线下进行跟踪，但随着投入物品运营的数量急速增长，现有的物品管理模式受限于人力，并不能及时有效地跟踪物品完整的运营过程，无法有效地定位物品运营中出现的问题。

因此，发明人认为，有必要对上述现有技术中存在的问题进行改进。

发明内容

本发明的一个目的是提供一种用于管理物品的新技术方案。

根据本发明的第一方面，提供了一种物品的管理方法，实施于用于提供物品共享服务的至少一个物品，所述方法包括：

根据从客户端获取的所述物品的运营状态变化信息，更新对应物品的运营状态记录；

其中，所述运营状态包括待运营、运营正常以及运营异常，所述运营状态变化信息至少包括对应物品的唯一物品标识、当前的运营状态；

根据多个所述物品的运营状态记录，获取系统运营数据，以供选择对应的管理策略实施物品管理。

可选地，

所述系统运营数据至少包括不同的运营状态下的物品数目以及对应的物品占比，所述物品占比是对应的运营状态下的物品数目与物品总数目的比例；

与所述系统运营数据对应的管理策略，至少包括当所述运营状态是运营异常的物品占比大于对应的预设占比阈值时，触发对处于对应的运营状态的物品实施管理，以降低处于对应的运营状态的物品占比。

可选地，

所述运营状态变化信息还包括对应物品的运营状态发生变化的时间点；

所述系统运营数据至少包括物品在不同运营状态之间变化的平均流转时间；

与所述系统运营数据对应的管理策略，至少包括平均流转时间大于对应的预设时间阈值时，触发对处于对应的运营状态的物品实施管理，以降低对应的运营状态之间的平均流转时间。

可选地，

所述运营状态变化信息还包括对应物品的运营状态发生变化的时间点以及变化原因；

所述系统运营数据还包括每个物品在不同运营状态下的状态耗时；

与所述系统运营数据对应的管理策略，至少包括对运营状态是运营异常且状态耗时大于对应的预设耗时阈值、具有同一变化原因的多个物品，触发实施针对对应的变化原因的批量物品管理，以降低对应的运营状态的状态耗时。

可选地，

所述运营状态变化信息中，还包括对应物品的运营状态发生变化的时间点、通过客户端实施操作以生成对应的运营状态变化信息的运营人员的操作信息，

所述操作信息至少包括实施操作的运营人员的唯一标识和对应的运营区域；

所述系统运营数据还包括不同的运营区域运营人员在不同的运营状态下的平均操作物品数目；

与所述系统运营数据对应的管理策略，至少包括在所述平均操作物品数目低于对应的预设操作阈值时，触发对处于对应的运营区域的运营人员实施管理，以提高对应的运营区域的所述平均操作物品数目。

可选地，

所述运营状态是待运营时，所述运营状态至少包括待出厂、待签收两个运营子状态；

和/或

所述运营状态是运营异常时，所述运营状态至少包括待干预、失窃、已干预待入库、已入库维修中、返厂中、报废、次品返厂七个运营子状态。

可选地，

所述根据从客户端获取所述物品的运营状态变化信息，更新对应物品的运营状态记录的步骤包括：

接收客户端响应于运营人员的操作生成的所述运营状态变化信息，所述运营变化信息中还包括对应的运营人员的操作权限信息；

根据所述操作权限信息，验证对应的运营人员的操作权限允许实施对应的操作时，根据所述运营状态变化信息，更新对应物品的运营状态记录，否则，不更新对应物品的运营状态记录。

进一步可选地，

对不同的运营人员设置不同的操作权限，使得运营人员根据对应的操作权限，通过客户端实施操作以生成对应的运营状态变化信息，

其中，所述操作权限包括允许实施操作的运营状态、时间中至少之一。

或者，进一步可选地，

创建包含多个运营人员的运营群组；

对同一运营群组的运营人员，设置相同的所述操作权限。

根据本发明的第二方面，提供一种物品的管理方法，实施于用于提供物品共享服务的至少一个物品，所述方法包括：

提供物品管理界面，以供运营人员根据物品的运营状态变化实施对应的操作；

响应于实施于所述物品管理界面的操作，生成对应的运营状态变化信息发送给服务端；

其中，所述运营状态包括待运营、运营正常以及运营异常，所述运营状态变化信息至少包括对应物品的唯一物品标识、当前的运营状态。

可选地，

根据运营人员的操作权限，提供对应的物品管理界面，以使得运营人员基于对应的操作权限，根据物品的运营状态变化实施对应的操作；

和/或

所述运营状态变化信息中还包括对应的运营人员的操作权限信息。

根据本发明的第三方面，提供一种服务端，包括：

存储器，用于存储可执行指令；

处理器，用于根据所述可执行指令的控制，运行所述服务端以执行如第一方面提供的任意一项所述的物品的管理方法。

根据本发明的第四方面，提供一种客户端，包括：

显示装置，用于显示人机交互界面；

存储器，用于存储可执行指令；

处理器，用于根据所述可执行指令的控制，运行所述客户端以执行如第二方面提供的物品的管理方法。

根据本发明的第五方面，提供一种物品的管理系统，包括：

至少一个用于提供物品共享服务的物品；

至少一个如本发明第三方面的服务端；

至少一个如本发明第四方面的客户端。

本发明的发明人发现，在现有技术中，对于提供共享服务的物品的管理过程中，受限于人力，不能及时、准确跟踪物品的运营状态变化，有效定位物品管理中存在的问题，物品的管理效率较低。因此，本发明所要实现的技术任务或者所要解决的技术问题是本领域技术人员从未想到的或者没有预期到的，故本发明是一种新的技术方案。

通过以下参照附图对本发明的示例性实施例的详细描述，本发明的其它特征及其优点将会变得清楚。

附图说明

被结合在说明书中并构成说明书的一部分的附图示出了本发明的实施例，并且连同其说明一起用于解释本发明的原理。

图1是显示可用于实现本发明的实施例的物品管理系统的硬件配置的例子的框图。

图2示出了本发明的第一实施例的物品的管理方法的流程图。

图3示出了本发明的第一实施例中更新物品的运营状态记录的流程图。

图4示出了本发明的第一实施例中物品的运营状态流转的示意图。

图5示出了本发明的第一实施例中的服务端的框图

图6示出了本发明的第二实施例的物品的管理方法的流程图。

图7示出了本发明的第二实施例的客户端的框图。

图8示出了本发明的第三实施例的物品的管理系统的框图。

具体实施方式

现在将参照附图来详细描述本发明的各种示例性实施例。应注意到：除非另外具体说明，否则在这些实施例中阐述的部件和步骤的相对布置、数字表达式和数值不限制本发明的范围。

以下对至少一个示例性实施例的描述实际上仅仅是说明性的，决不作为对本发明及其应用或使用的任何限制。

对于相关领域普通技术人员已知的技术、方法和设备可能不作详细讨论，但在适当情况下，所述技术、方法和设备应当被视为说明书的一部分。

在这里示出和讨论的所有例子中，任何具体值应被解释为仅仅是示例性的，而不是作为限制。因此，示例性实施例的其它例子可以具有不同的值。

应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步讨论。

<硬件配置>

图1是示出可以实现本发明的实施例的物品管理系统100的硬件配置的框图。

如图1所示，物品管理系统100包括服务端1000、客户端2000、网络3000。

服务端1000提供处理、数据库、通讯设施的业务点。服务端1000可以是整体式服务器或是跨多计算机或计算机数据中心的分散式服务器。服务器可以是各种类型的，例如但不限于，网络服务器，新闻服务器，邮件服务器，消息服务器，广告服务器，文件服务器，应用服务器，交互服务器，数据库服务器，或代理服务器。在一些实施例中，每个服务器可以包括硬件，软件，或用于执行服务器所支持或实现的合适功能的内嵌逻辑组件或两个或多个此类组件的组合。例如，服务器例如刀片服务器、云端服务器等，或者可以是由多台服务器组成的服务器群组(1000-1)，可以包括上述类型的服务器中的一种或多种等等。

在一个例子中，服务端1000可以如图1所示，包括处理器1100、存储器1200、接口装置1300、通信装置1400、显示装置1500、输入装置1600。尽管服务器也可以包括扬声器、麦克风等等，但是，这些部件与本发明的是合理无关，故在此省略。

其中，处理器1100例如可以是中央处理器CPU、微处理器MCU等。存储器1200例如包括ROM(只读存储器)、RAM(随机存取存储器)、诸如硬盘的非易失性存储器等。接口装置1300例如包括USB接口、串行接口、红外接口等。通信装置1400例如能够进行有线或无线通信。显示装置1150例如是液晶显示屏、LED显示屏触摸显示屏等。输入装置1160例如可以包括触摸屏、键盘等。

在本实施例中，客户端2000是具有通信功能、业务处理功能的电子设备。客户端2000可以是移动终端，例如手机、便携式电脑、平板电脑、掌上电脑等等。在一个例子中，客户端2000是对物品3000实施管理操作的设备，例如，安装有支持运营、管理物品的应用程序(APP)的手机。

如图1所示，客户端2000可以包括处理器2100、存储器2200、接口装置2300、通信装置2400、显示装置2500、输入装置2600、扬声器2700、麦克风2800，等等。其中，处理器2100可以是中央处理器CPU、微处理器MCU等。存储器2200例如包括ROM(只读存储器)、RAM(随机存取存储器)、诸如硬盘的非易失性存储器等。接口装置2300例如包括USB接口、耳机接口等。通信装置2400例如能够进行有线或无线通信，。显示装置2500例如是液晶显示屏、触摸显示屏等。输入装置2600例如可以包括触摸屏、键盘等。用户可以通过扬声器2700和麦克风2800输入/输出语音信息。

物品3000是任何可以分时或分地出让使用权供不同用户共享使用的物品，例如，用于共享的车辆(自行车、助力车、汽车)、充电宝、雨伞等等。在一个例子中，物品3000可以是自行车(3000-1)。

如图1所示，物品3000可以包括处理器3100、存储器3200、接口装置3300、通信装置3400、显示装置3500、输入装置3600、扬声器3700、麦克风3800，等等。其中，处理器3100可以是中央处理器CPU、微处理器MCU等。存储器3200例如包括ROM(只读存储器)、RAM(随机存取存储器)、诸如硬盘的非易失性存储器等。接口装置3300例如包括USB接口、耳机接口等。通信装置3400例如能够进行有线或无线通信。输出装置2500例如可以是输出信号的装置，可以显示装置，例如液晶显示屏、触摸显示屏等，也可以是扬声器等输出语音信息等。输入装置2600例如可以包括触摸屏、键盘等，也可以是麦克风输入语音信息。

网络4000可以是无线通信网络也可以是有线通信网络，可以是局域网也可以是广域网。在图1所示的物品管理系统中，物品3000与服务端1000、客户端2000与服务端1000，可以通过网络4000进行通信。此外，物品3000与服务端1000、客户端2000与服务端1000通信所基于的网络4000可以是同一个，也可以是不同的。

应当理解的是，尽管图1仅示出一个服务端1000、客户端2000、物品3000，但不意味着限制对应的数目，物品管理系统100中可以包含多个服务端1000、客户端2000、物品3000。

以物品3000为共享车辆为例，物品管理系统100为车辆共享系统。其中，共享车辆可以是自行车，也可以是三轮车、电动助力车、摩托车以及四轮乘用车等各种形态。服务器1000用于提供支持车辆使用所必需的全部功能。客户端2000可以是手机，其上安装有车辆运营管理应用，车辆运营管理应用可以帮助车辆运营管理人员甚至车辆用户实现管理运营车辆3000的功能等等。

图1所示的物品管理系统100仅是解释性的，并且决不是为了要限制本发明、其应用或用途。

应用于本发明的实施例中，尽管图1只示出一个服务端1000、一个客户端2000、一个物品3000，但是，应当理解的是，具体应用中，可以根据实际需求使得所述物品管理系统100包括多个服务端1000、多个客户端2000、多个物品3000。

应用于本发明的实施例中，服务端1000的所述存储器1200用于存储指令，所述指令用于控制所述处理器1100进行操作以执行本发明实施例提供的任意一项物品的管理方法：根据从客户端获取的所述物品的运营状态变化信息，更新对应物品的运营状态记录；其中，所述运营状态包括待运营、运营正常以及运营异常，所述运营状态变化信息至少包括对应物品的唯一物品标识、当前的运营状态；根据多个所述物品的运营状态记录，获取系统运营数据，以供选择对应的管理策略实施物品管理。

尽管在图1中对服务端1000示出了多个装置，但是，本发明可以仅涉及其中的部分装置，例如，服务端1000只涉及存储器1200和处理器1100。

应用于本发明的实施例中，客户端2000的所述存储器2200用于存储指令，所述指令用于控制所述处理器2100通过显示装置2500以执行本发明实施例提供的任意一项物品的管理方法：提供物品管理界面，以供运营人员根据物品的运营状态变化实施对应的操作；响应于实施于所述物品管理界面的操作，生成对应的运营状态变化信息发送给服务端；其中，所述运营状态包括待运营、运营正常以及运营异常，所述运营状态变化信息至少包括对应物品的唯一物品标识、当前的运营状态。

尽管在图1中对客户端2000示出了多个装置，但是，本发明可以仅涉及其中的部分装置，例如，客户端2000只涉及存储器2200和处理器2100、通信装置2400和显示装置2500。

在上述描述中，技术人员可以根据本发明所公开方案设计指令。指令如何控制处理器进行操作，这是本领域公知，故在此不再详细描述。

<第一实施例>

<方法>

在本实施例中，提供一种物品的管理方法，实施于用于提供物品共享服务的至少一个物品，该物品是任何可以分时或分地出让使用权供不同用户共享使用的物品，例如，用于共享的车辆(自行车、助力车、汽车)、充电宝、雨伞等等。

该物品的管理方法，如图2所示，包括：

步骤S2100，根据从客户端获取的物品的运营状态变化信息，更新对应物品的运营状态记录。

在本实施例中，客户端是具有通信功能、业务处理功能的电子设备，例如手机、便携式电脑、平板电脑、掌上电脑等移动终端。具体地，客户端是可以对本实施例中的物品实施相关管理操作的设备，例如，物品是车辆时，客户端是可以安装支持运营、管理车辆的应用程序的手机，可以供运营人员对运营状态发生变化的车辆，输入车辆的唯一车辆标识(例如扫描车辆二维码)后进行相关操作，以生成运营状态变化信息供获取。

在本实施例中，可以根据预设的获取周期，触发客户端提醒运营人员通过客户端实施操作生成物品的运营状态变化信息后获取，或者，也可以在物品的运营状态发生变化时，例如由物品通过告警、提醒等方式触发运营人员通过客户端实施操作生成物品的运营状态变化信息后获取，或者由使用物品的用户通过拨打客服热线、通过面向用户的物品应用程序上报的等方式触发通过客户端实施操作生成物品的运营状态变化信息后获取，或者又运营人员在线下核查物品的运营状态后，通过客户端实施操作生成物品的运营状态变化信息后获取等等。

通过客户端获取物品的运营状态变化信息，对应更新物品的运营状态记录，可以及时、有效地跟踪物品的运营状态变化。

该运营状态变化信息，是通过客户端响应运营人员的操作生成的。在实际应用中，不同的运营人员素质参差不齐，存在大量的错误操作的情况，会导致所获取运营状态变化信息不能有效地反映物品的实际运营状态变化。

因此，在一个例子中，步骤2100可以如图3所示，包括：

步骤S2101，接收客户端响应于运营人员的操作生成的运营状态变化信息，所述运营变化信息中还包括对应的运营人员的操作权限信息；

步骤S2102,根据操作权限信息，验证对应的运营人员的操作权限允许实施对应的操作时，根据运营状态变化信息，更新对应物品的运营状态记录，否则，不更新对应物品的运营状态记录。

运营人员的操作权限信息，是与预先为运营人员设置的操作权限相关的信息，例如，可以仅是运营人员的唯一标识，获取该运营人员的唯一标识后，可以根据该标识查询为运营人员设置的操作权限，如果对应的操作权限允许运营人员实施对应的操作时，就可以根据所述运营状态变化信息，更新对应物品的运营状态记录，否则，不更新对应物品的运营状态记录；

或者，运营人员的操作权限信息还可以是运营人员的操作类型、操作权限标识，获取该操作类型、操作权限标识后，根据预先设置操作权限表，查询该操作类型是否在该操作权限标识对应的权限范围内，如果在对应的权限范围内，意味着对应的操作权限允许运营人员实施对应的操作，就可以根据所述运营状态变化信息，更新对应物品的运营状态记录，否则，不更新对应物品的运营状态记录；

用户的操作权限信息还可以是其他能支持完成验证对应的运营人员的操作权限是否允许实施对应的操作的信息，在此不再一一列举。

通过验证运营人员的操作权限，可以只支持根据运营人员在操作权限内生成的物品的运营状态变化信息，更新物品的运营状态记录，极大降低不具有操作权限的运营人员错误操作带来的运营状态变化信息的错误率。

在本实施例中，还可以根据具体的运营策略，对不同的运营人员设置不同的操作权限，例如，对于兼职的运营人员，可以设置兼职的运营人员只允许通过客户端实施操作确认物品处于运营异常的运营状态，并且，还可以根据兼职的运营人员的工作时长，设置兼职的运营人员允许通过客户端确认物品处于运营异常的时间段，比如，设置兼职的运营人员只能在24小时内具有操作权限，24小时过后，兼职的运营人员将不具有任何操作权限等等；又例如，可以设置在物品生产制造地的运营人员，只能允许通过客户端实施操作确认物品处于待运营状态，等等，此不一一列举。

对应地，在本例中，物品的管理方法还包括：

提供对不同运营人员设置不同的操作权限，可以根据不同的运营策略(例如安全性考虑、运营效率考虑等)来设置运营人员的操作权限，使得运营人员只能在操作权限允许的范围内，通过客户端实施操作以生成对应的运营状态变化信息，能确保运营策略实施的有效性，提升运营效率。

在实际应用中，运营人员的数目会随着投放提供共享物品服务的物品数量增长，在本实施例中，还可以通过批量设置操作权限，提高操作权限的设置效率。

具体地，所述对运营人员设置不同的操作权限的步骤还包括：

创建包含多个运营人员的运营群组；

对同一运营群组的运营人员，设置相同的所述操作权限。

具体地，可以提供群组创建界面，用于创建包含运营人员的运营群组。根据运营人员的工作内容和操作权限的不同，可创建多个运营群组。

在创建运营群组后，对统一运营群组的运营人员，设置相同的操作权限，操作权限可以包括允许实施操作的运营状态、时间中至少之一。

例如，对于兼职人员，就可以设置兼职人员的运营群组，通过设置运营群组的操作权限，实现批量设置兼职人员的操作权限。

还可以提供对应的接口，批量上传运营人员的身份信息，该运营人员的身份信息可以唯一标识运营人员身份的信息，例如，运营人员的手机号码、人员标识或者唯一人员名称等等，还可以为群组的运营人员设置统一的密码口令，以实现群组管理，提高管理效率。

例如，对于兼职人员的运营群组，设置的操作权限是24小时内允许实施操作，可以收集当日上班的兼职人员的手机号作为人员信息进行批量上传。在批量上传后，可选择这批人员的对应群组，并统一设置密码口令，实现兼职人员的基础信息录入。使得可以通过读取兼职人员的手机号和操作权限，使得可以兼职人员在操作权限凭借手机号、以及相关的密码口令，登录客户端完成操作权限的操作，在次日后清空对应的群组，使得对应的兼职人员失去操作权限。实现对大量兼职人员权限的实时有效管控，满足运营需求的同时节省了当前技术资源。

在实际应用中，不同的物品的运营状态还可能包括多种运营子状态，例如，物品的运营状态是待运营时，物品可能是处于已经生产制造完成的工厂模式，即待出厂的状态，也可能是处于已经出厂但是未被签收进入运营的待签收的状态；或者，物品运营状态是运营异常时，可能是处于出厂后在签收时发现为次品进行返厂的次品返厂状态、可能是处于被偷盗而无法提供物品共享服务的失窃状态、可能是处于出现故障(使用物品的用户上报故障、物品自身检测上报故障)等待运营人员干预的待干预状态，可能是处于运营人员已干预等待入库维修状态的已干预待入库状态、还可能是已经入库在被维修的已入库维修中的状态、还可能是入库无法修复只能返厂的返厂中的状态，也可能返厂后依然无法修复的报废状态。

因此，在本实施例中，所述运营状态是待运营时，所述运营状态至少包括待出厂、待签收两个运营子状态；和/或

例如，可以如图4所示，通过物品的运营子状态，进一步细化物品的运营情况，使得从客户端获取的运营状态变化信息更准确地反映物品的运营状态变化，对应更新物品的运营状态记录。可以通过车辆的标识，获取车辆的运营状态记录，跟踪车辆整个运营过程。实现更及时、有效地跟踪物品的运营状态变化，实现物品的精细化运营管理。

步骤S2200，根据多个所述物品的运营状态记录，获取系统运营数据，以供选择对应的管理策略实施物品管理。

物品的运营状态记录，记录的是物品运营状态变化。通过物品的运营状态记录，可以跟踪物品在整个运营过程中运营状态。

系统运营数据，是用于表征投入运营提供物品共享服务的多个物品的运营状态的数据。通常选取来获取系统运营数据的多个物品，可以是投入运营提供物品共享服务的全部物品，也可以是其中抽样的多个物品，可以是划分了运营区域后的某个运营区域内的全部物品，还可以根据实际的物品管理场景选取，在此不一一列举。

在一个例子中，系统运营数据至少包括不同的运营状态下的物品数目以及对应的物品占比，所述物品占比是对应的运营状态下的物品数目与物品总数目的比例；

其中，预设占比阈值可以根据具体的物品运营场景设置，或者根据工程经验或者历史实验值设置。

例如，物品是提供共享服务的车辆时，车辆的运营状态可以如图4所示，根据车辆的运营状态变化信息，可以统计得到不同的运营状态(包括不同的运营子状态)下的车辆数目以及对应的车辆占比，具体的，可以统计每个运营状态(包括运营子状态)的车辆数目，分别除以车辆的总数据，得到对应的车辆占比。

在理想情况下，运营状态为运营正常的车辆占比应该在90％以上，运营状态为运营异常、待运营的车辆占比应该尽可能小，以保证有足够车辆提供给用户来骑行。而当运营状态为运营异常的车辆占比超10％时，则可认为整体车辆的运营情况存在问题需要实施管理。

因此，可以将预设占比阈值设置为10％，当运营状态是运营异常的物品占比大于10％时，则可以通过生成告警信号提醒查看、告警信息推送、自动拨打电话提醒或者发送告警邮件(邮件还可以包括对应的系统运营数据)等方式，触发对应的运营人员对对应的车辆实施管理，例如由对应的运营人员，根据在运营状态为运营异常的车辆里在失窃、待干预、维修中等七个运营子状态分别的车辆占比，确定车辆占比对大的运营子状态即为车辆积压最多的，调动人力资源集中解决这部分车辆问题，尽快让车辆进入运营正常的运营状态，从而降低在运营异常的车辆占比。

在另一个例子中，获取的运营状态变化信息还包括对应物品的运营状态发生变化的时间点；

对应的，系统运营数据至少包括物品在不同运营状态之间变化的平均流转时间；

与所述系统运营数据对应的管理策略，至少包括当所述平均流转时间大于对应的预设时间阈值时，触发对处于对应的运营状态的物品实施管理，以降低对应的运营状态之间的平均流转时间。

其中，预设时间阈值可以根据具体的物品运营场景设置，或者根据工程经验或者历史实验值设置。

在运营变化状态信息中还包括运营状态发生变化的时间点，对应的，更新的物品运营状态记录中也会记录运营状态变化发生的时间点，从物品的运营状态记录中，可以跟踪物品运营状态变化以及变化发生的时间点。

根据物品的运营状态记录，可以计算每个物品在每个运营状态之间流转的时间，即从一个运营状态变为另一个运营状态的所耗费的时间，例如，运营状态从运营异常到运营正常所耗费的时间。然后将统计得到多个物品的运营状态之间的流转时间求平均，就可以得到对应的物品在不同运营状态之间变化的平均流转时间。

例如，物品是提供共享服务的车辆时，车辆的运营状态可以如图4所示，根据车辆的运营状态变化信息，可以统计得到车辆在各个运营状态(云因状态)之间的平均流转时间。比如，可以统计车辆从“已入库维修中”变成“运营正常”所耗费的平均时间，也就是车辆维修的平均时间；可以统计车辆从“待干预”到“已干预待入库”的所耗费的平均时间，得到车辆被报障后运营人员成功干预故障车所需的平均时间等等。从统计的平均流转时间，不仅可以获取一辆车辆被报障后到恢复正常运营，平均需要耗费的总时间，还可以定位平均流转时间耗费较大的运营状态变化环节，触发实施车辆管理。例如，预期的从“已入库维修中”变成“运营正常”所耗费的平均时间为24小时，保证车辆周转效率，使得有足够车辆提供给用户来骑行。

因此，可以将“已入库维修中”变成“运营正常”的平均流转时间对应的预设时间阈值设为24小时，当系统运营数据中“已入库维修中”变成“运营正常”大于24小时，确定车辆维修的时间耗费太长影响了车辆的周转效率，可以通过生成告警信号提醒查看、告警信息推送、自动拨打电话提醒或者发送告警邮件(邮件还可以包括对应的系统运营数据)等方式，触发对应的运营人员对在这两个运营状态变换环节内(具体是“已入库维修中”)的车辆实施管理，例如由对应的运营人员，调动人力资源集中解决这部分车辆问题，尽快让车辆进入“运营正常”，从而降低“已入库维修中”变成“运营正常”的平均流转时间，提高车辆的周转效率。

在又一个例子中，所述运营状态变化信息还包括对应物品的运营状态发生变化的时间点以及变化原因；所述系统运营数据还包括每个物品在不同运营状态下的状态耗时；与所述系统运营数据对应的管理策略，至少包括对运营状态是运营异常且状态耗时大于对应的预设耗时阈值、具有同一变化原因的多个物品，触发实施针对对应的变化原因的批量物品管理，以降低对应的运营状态的状态耗时。

其中，预设时耗时阈值可以根据具体的物品运营场景设置，或者根据工程经验或者历史实验值设置。

在运营变化状态信息中还包括运营状态发生变化的时间点以及变化原因，对应的，更新的物品运营状态记录中也会记录运营状态变化发生的时间点以及原因，从物品的运营状态记录中，可以跟踪物品运营状态变化、变化的时间顺序、造成变化的原因。

根据物品的运营状态记录，可以计算每个物品在每个运营状态中状态耗时，即从进入这个运营状态到离开这个运营状态的所耗费的时间，例如，从进入“运营异常”到离开“运营异常”所耗费的时间。

当物品在运营状态为运营异常(包括对应的运营子状态)的状态耗时过长时，则意味着会影响正常运营提供服务的物品数量，导致物品运营效率下降。因此，可以通过设置对应的预设耗时阈值，定位这些状态耗时过长的物品，对根据导致这些物品进入运营异常的原因进行归类，对于同一变化原因的多个物品，触发实施针对对应的变化原因的批量物品管理，以降低对应的运营状态的状态耗时。

例如，物品是提供共享服务的车辆时，车辆的运营状态可以如图4所示，根据车辆的运营状态变化信息，可以统计车辆在各个运营状态下的状态耗时。

例如，通过统计一辆车辆从“已入库维修中”变成“正常运营”所花费的状态耗时，得到的是该车辆维修的时间，同时，对应的变换原因会记录车辆故障类型、还可以记录的车型、维修所需配件等信息。对应的预设耗时阈值可以是预期保证车辆运营效率的时间，例如24小时。

可以统计得到车辆对应的状态耗时大于24小时那些车辆，确定都是基于同一变化原因(车型/故障类型/维修配件等数据上具有相同性)，例如，都是因为需要XX配件才能维修，但这个配件当前维修仓库缺货，导致了这一批车辆的维修时间较长；或者因为都是车辆的车锁的软件故障，而车锁故障维修周期很长，导致了这一类车辆维修时间较长。对于同一变化原因的在“运营异常”的状态耗时超过24小时这一批车辆，可以通过生成告警信号提醒查看、告警信息推送、自动拨打电话提醒或者发送告警邮件(邮件还可以包括对应的系统运营数据)等方式，触发对应的运营人员实施对应的管理，例如尽快调配仓库所需零配件去支持维修，或者针对锁的故障设计和开发一种高效的维修工具提升效率等等，降低这批车辆对应的运营状态的状态耗时，提高运营效率。

在又一个例子中，所述运营状态变化信息中，还包括对应物品的运营状态发生变化的时间点、通过客户端实施操作以生成对应的运营状态变化信息的运营人员的操作信息，所述操作信息至少包括实施操作的运营人员的唯一标识和对应的运营区域；

其中，预设操作阈值可以根据具体的物品运营场景设置，或者根据工程经验或者历史实验值设置。

在所述运营状态变化信息中，还包括对应物品的运营状态发生变化的时间点、通过客户端实施操作以生成对应的运营状态变化信息的运营人员的操作信息，操作人员的唯一标识、运营区域等。

对应的，物品的运营状态记录中还可以记录操作物品进入对应的运营状态的人员、操作时间(物品发生运营状态变化的时间)以及对应的区域。通过物品的运营记录，可以统计预设时间段(每天、每小时或者每周、每月等)内不同的运营区域运营人员在不同的运营状态下的平均操作物品数目，例如，可以统计运营区域为全国范围内运营人员在一天内将物品从“待干预”变为“已干预待入库”的数量和运营人员的数量，得到全国在“待干预”的平均干预物品数量，还可以统计运营区域为某个城市的人均干预数量等等。

对应不同的运营状态下，可以通过达到预期的平均操作物品数目的平均操作物品数目，来保证运营效率。对于低于预期的平均操作物品数目的运营区域的运营人员，可以触发实施管理，来提供对应的平均操作物品数目，以提升运营效率。

因此，可以将预设操作阈值设置为预期的平均操作物品数目。以物品是提供共享服务的车辆为例，车辆的运营状态可以如图4所示，根据车辆的运营状态变化信息，可以统计不同运营区域的运营人员在车辆的运营状态下的平均操作车辆数目。对于“待干预”状态，运营人员可以实施干预操作，将车辆变为“已干预待入库”，对应的预设操作阈值可以设置为全部运营区域的运营人员平均干预车辆的数量。比如，统计的全国人均日干预数量为60辆，然后如果统计得到部分城市的人均干预数量仅为30辆，其中还有部分人员的干预数量仅为20辆。低于对应的预设操作阈值，可以通过生成告警信号提醒查看、告警信息推送、自动拨打电话提醒或者发送告警邮件(邮件还可以包括对应的系统运营数据)等方式，通知对应的运营人员，对该运营区域的全体运营人员，特别是对干预数量更少的人员进行管理，例如，做该运营区域的全体运营人员原因调研和惩罚警告、扣减绩效等，以提高对应的运营区域的平均车辆干预数目，提升运营效率。

进一步地，还可以触发对平均干预车辆数目高于预设操作阈值较多的运营区域/运营人员，实施奖励等。从另一个方向提升运营效率。

<服务端>

在本实施例中，还提供一种服务端200，如图5所示，包括：

存储器210，用于存储可执行指令；

处理器220，用于根据所述可执行指令的控制，运行所述服务端以执行如本实施例中提供的任意一项所述的物品的管理方法：

在本实施例中，服务端200是支持实施物品管理的任意电子设备。可以是整体式服务器或是跨多计算机或计算机数据中心的分散式服务器。例如，服务器例如刀片服务器、云端服务器等，或者可以是由多台服务器组成的服务器群组，可以包括上述类型的服务器中的一种或多种等等。在一个例子中，服务端200可以如图1所示的服务端1000。

本领域技术人员应当明白，可以通过各种方式来实现服务端200。例如，可以通过指令配置处理器来实现服务端200。例如，可以将指令存储在ROM中，并且当启动设备时，将指令从ROM读取到可编程器件中来实现服务端200。例如，可以将服务端200固化到专用器件(例如ASIC)中。可以将服务端200分成相互独立的单元，或者可以将它们合并在一起实现。服务端200可以通过上述各种实现方式中的一种来实现，或者可以通过上述各种实现方式中的两种或更多种方式的组合来实现。

以上已经结合附图和例子说明了本实施例。本实施例中提供一种物品的管理方法以及服务端，实施于用于提供物品共享服务的至少一个物品，通过从客户端获取的物品的运营状态变化信息更新对应物品的运营状态记录，再根据多个物品的运营状态记录获取系统运营数据，选择对应的管理策略实施物品管理。实现可以及时、准确跟踪物品完整的运营过程，有效地定位物品运营中出现的问题，并触发实施对应的物品管理，提升运营效率。

<第二实施例>

在本实施例中，提供一种物品的管理方法，实施于用于提供物品共享服务的至少一个物品。

该物品是任何可以分时或分地出让使用权供不同用户共享使用的物品，例如，用于共享的车辆(自行车、助力车、汽车)、充电宝、雨伞等等。

该物品的管理方法，如图6所示，包括：

步骤S3100,提供物品管理界面，以供运营人员根据物品的运营状态变化实施对应的操作；

步骤S3200，响应于实施于所述物品管理界面的操作，生成对应的运营状态变化信息发送给服务端。

物品管理界面是可以响应于接受的操作提供对应的功能的人机交互界面。

具体地，物品是车辆时，物品管理界面可以是车辆管理界面，提供扫描窗口获取车辆二维码这样的车辆唯一标识，并且提供登录框供运营人员登录输入自身的信息，获取运营人员的人员信息(人员标识、运营区域等)，提供按钮、输入框等供运营人员操作输入车辆当前运营状态并自动生成运营人员操作的时间等。

运营人员可以在发现物品的运营状态发生变化(例如线下核查时发现)时、或者被服务端、物品通过消息推送、发送短信、拨打电话、邮件通知等各种方式提醒物品的运营状态发生变化时，通过物品管理界面实施对应的操作，触发生成对应的运营状态变化信息发送给服务端，实现及时、准确跟踪物品的运营状态变化，使得服务端可以获取系统运营数据，并根据系统运营数据选择对应的管理策略实施物品管理，提升运营效率。

在本实施例中，服务端是支持实施物品管理的任意电子设备，例如第一实施例中的服务端200。可以是整体式服务器或是跨多计算机或计算机数据中心的分散式服务器。例如，服务器例如刀片服务器、云端服务器等，或者可以是由多台服务器组成的服务器群组，可以包括上述类型的服务器中的一种或多种等等。在一个例子中，服务端可以如图1所示的服务端1000。

在实际应用中，不同的运营人员素质参差不齐，存在大量的错误操作的情况，会导致所获取运营状态变化信息不能有效地反映物品的实际运营状态变化。

在本实施例中，可以通过对运营人员预先设置不同的操作权限，根据运营人员的操作权限，对运营人员呈现对应的物品管理界面，使得运营人员只能在其操作权限内实施对应的操作，减低错误操作的概率。

例如，对于兼职人员，可以预先设置操作权限为对“待干预”更改为“已干预待入库”，并且操作时限为兼职时间，兼职人员看到的物品管理界面只能对目前处于“带干预”状态的车辆进行操作，也只能操作为“已干预待入库”，并且在兼职时间之外，兼职人员就不能登录看到物品管理界面。

或者，在生成的运营状态变化信息中还包括对应的运营人员的操作权限信息，发送给服务端可以供服务端验证运营人员的操作权限，服务端可以通过只支持根据运营人员在操作权限内生成的物品的运营变化信息，更新物品的运营状态记录，也能减低错误操作的概率。

具体的，运营人员的操作权限、操作权限信息在第一实施例中已经描述，在此不再赘述。

因此，在本实施例中提供的物品管理方法，还可以包括：

和/或

<客户端>

在本实施例中，还提供一种客户端300，如图7所示，包括：

显示装置310，用于显示人机交互界面；

存储器320，用于存储可执行指令；

处理器330，用于根据所述可执行指令的控制，运行所述服务端以执行本实施例中提供任意一项的物品的管理方法：

在本实施例中，客户端300可以是例如手机、便携式电脑、平板电脑、掌上电脑等移动终端。具体地，客户端是可以对本实施例中的物品实施相关管理操作的设备，例如，物品是车辆时，客户端是可以安装支持运营、管理车辆的应用程序的手机。

在一个例子中，客户端300可以如图1所示的客户端2000。

本领域技术人员应当明白，可以通过各种方式来实现客户端300。例如，可以通过指令配置处理器来实现客户端300。例如，可以将指令存储在ROM中，并且当启动设备时，将指令从ROM读取到可编程器件中来实现客户端300。例如，可以将客户端300固化到专用器件(例如ASIC)中。可以将客户端300分成相互独立的单元，或者可以将它们合并在一起实现。客户端300可以通过上述各种实现方式中的一种来实现，或者可以通过上述各种实现方式中的两种或更多种方式的组合来实现。

以上已经结合附图、例子说明本实施例，在本实施例中，提供一种物品的管理方法及客户端，通过提供物品管理界面，并响应实施于物品管理界面的操作，触发生成对应的运营状态变化信息发送给服务端，使得服务端可以实现及时、准确跟踪物品的运营状态变化，并定位物品运营中出现的问题触发实施对应的物品管理，节省人力资源，提升运营效率。

<第三实施例>

在本实施例中，提供一种物品管理系统，如图8所示，包括至少一个物品400、至少一个如第一实施例中提供的服务端200、以及至少一个如第二实施例中提供的客户端300。

该物品是任何可以分时或分地出让使用权供不同用户共享使用的物品，例如，用于共享的车辆(自行车、助力车、汽车)、充电宝、雨伞等等。在一个例子，物品400可以如图1所示的物品3000。

在物品是提供车辆共享服务的车辆时，物品管理系统是车辆管理系统，可以包括多个车辆、多个服务端200以及多个客户端300。

服务端200是提供车辆运营、管理功能的云端服务器。客户端300具体可以是安装有车辆管理APP(应用程序)的手机。

在某一个车辆的运营状态发生变化时，运营人员可以通过登录手机的车辆管理APP，进入其提供的车辆管理界面实施操作，扫描该车辆的车身二维码或者手动输入该车辆的编号，并且操作记录当前变化后的运营状态，车辆管理APP可以根据运营人员的操作，生成包括运营人员的账号、所属运营区域、车辆的标识、当前的运营状态、位置、当前时间点的运营状态变化信息发送给云端服务器。云端服务器可以对应更新车辆的运营状态记录。实现可以通过车辆的标识，获取车辆的运营状态记录，及时、准确地跟踪车辆整个运营过程。

云端服务器可以根据车辆的运营状态记录，统计当前的系统运营数据后，定位当前车辆管理中存在的问题，触发实施对车辆的管理。对应的例子在第一实施例中已经描述，在此不再赘述。

通过跟踪车辆的运营状态变化、定位车辆管理中存在的问题，触发实施对应的车辆管理，可以提高运营效率。

以上已经结合例子说明本实施例，在本实施例中，提供一种物品的管理系统，包括物品、客户端及服务端，通过客户端提供物品管理界面，并响应实施于物品管理界面的操作，触发生成对应的运营状态变化信息发送给服务端，使得服务端可以实现及时、准确跟踪物品的运营状态变化，并定位物品运营中出现的问题触发实施对应的物品管理，提升运营效率。

本领域技术人员公知的是，随着诸如大规模集成电路技术的电子信息技术的发展和软件硬件化的趋势，要明确划分计算机系统软、硬件界限已经显得比较困难了。因为，任何操作可以软件来实现，也可以由硬件来实现。任何指令的执行可以由硬件完成，同样也可以由软件来完成。对于某一机器功能采用硬件实现方案还是软件实现方案，取决于价格、速度、可靠性、存储容量、变更周期等非技术性因素。因此，对于电子信息技术领域的普通技术人员来说，更为直接和清楚地描述一个技术方案的方式是描述该方案中的各个操作。在知道所要执行的操作的情况下，本领域技术人员可以基于对所述非技术性因素的考虑直接设计出期望的产品。

本发明可以是系统、方法和/或计算机程序产品。计算机程序产品可以包括计算机可读存储介质，其上载有用于使处理器实现本发明的各个方面的计算机可读程序指令。

计算机可读存储介质可以是可以保持和存储由指令执行设备使用的指令的有形设备。计算机可读存储介质例如可以是――但不限于――电存储设备、磁存储设备、光存储设备、电磁存储设备、半导体存储设备或者上述的任意合适的组合。计算机可读存储介质的更具体的例子(非穷举的列表)包括：便携式计算机盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、静态随机存取存储器(SRAM)、便携式压缩盘只读存储器(CD-ROM)、数字多功能盘(DVD)、记忆棒、软盘、机械编码设备、例如其上存储有指令的打孔卡或凹槽内凸起结构、以及上述的任意合适的组合。这里所使用的计算机可读存储介质不被解释为瞬时信号本身，诸如无线电波或者其他自由传播的电磁波、通过波导或其他传输媒介传播的电磁波(例如，通过光纤电缆的光脉冲)、或者通过电线传输的电信号。

这里所描述的计算机可读程序指令可以从计算机可读存储介质下载到各个计算/处理设备，或者通过网络、例如因特网、局域网、广域网和/或无线网下载到外部计算机或外部存储设备。网络可以包括铜传输电缆、光纤传输、无线传输、路由器、防火墙、交换机、网关计算机和/或边缘服务器。每个计算/处理设备中的网络适配卡或者网络接口从网络接收计算机可读程序指令，并转发该计算机可读程序指令，以供存储在各个计算/处理设备中的计算机可读存储介质中。

用于执行本发明操作的计算机程序指令可以是汇编指令、指令集架构(ISA)指令、机器指令、机器相关指令、微代码、固件指令、状态设置数据、或者以一种或多种编程语言的任意组合编写的源代码或目标代码，所述编程语言包括面向对象的编程语言—诸如Smalltalk、C++等，以及常规的过程式编程语言—诸如“C”语言或类似的编程语言。计算机可读程序指令可以完全地在用户计算机上执行、部分地在用户计算机上执行、作为一个独立的软件包执行、部分在用户计算机上部分在远程计算机上执行、或者完全在远程计算机或服务器上执行。在涉及远程计算机的情形中，远程计算机可以通过任意种类的网络—包括局域网(LAN)或广域网(WAN)—连接到用户计算机，或者，可以连接到外部计算机(例如利用因特网服务提供商来通过因特网连接)。在一些实施例中，通过利用计算机可读程序指令的状态信息来个性化定制电子电路，例如可编程逻辑电路、现场可编程门阵列(FPGA)或可编程逻辑阵列(PLA)，该电子电路可以执行计算机可读程序指令，从而实现本发明的各个方面。

这里参照根据本发明实施例的方法、装置(系统)和计算机程序产品的流程图和/或框图描述了本发明的各个方面。应当理解，流程图和/或框图的每个方框以及流程图和/或框图中各方框的组合，都可以由计算机可读程序指令实现。

这些计算机可读程序指令可以提供给通用计算机、专用计算机或其它可编程数据处理装置的处理器，从而生产出一种机器，使得这些指令在通过计算机或其它可编程数据处理装置的处理器执行时，产生了实现流程图和/或框图中的一个或多个方框中规定的功能/动作的装置。也可以把这些计算机可读程序指令存储在计算机可读存储介质中，这些指令使得计算机、可编程数据处理装置和/或其他设备以特定方式工作，从而，存储有指令的计算机可读介质则包括一个制造品，其包括实现流程图和/或框图中的一个或多个方框中规定的功能/动作的各个方面的指令。

也可以把计算机可读程序指令加载到计算机、其它可编程数据处理装置、或其它设备上，使得在计算机、其它可编程数据处理装置或其它设备上执行一系列操作步骤，以产生计算机实现的过程，从而使得在计算机、其它可编程数据处理装置、或其它设备上执行的指令实现流程图和/或框图中的一个或多个方框中规定的功能/动作。

附图中的流程图和框图显示了根据本发明的多个实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或指令的一部分，所述模块、程序段或指令的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或动作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。对于本领域技术人员来说公知的是，通过硬件方式实现、通过软件方式实现以及通过软件和硬件结合的方式实现都是等价的。

以上已经描述了本发明的各实施例，上述说明是示例性的，并非穷尽性的，并且也不限于所披露的各实施例。在不偏离所说明的各实施例的范围和精神的情况下，对于本技术领域的普通技术人员来说许多修改和变更都是显而易见的。本文中所用术语的选择，旨在最好地解释各实施例的原理、实际应用或对市场中的技术改进，或者使本技术领域的其它普通技术人员能理解本文披露的各实施例。本发明的范围由所附权利要求来限定。

Claims

1.一种物品的管理方法，实施于用于提供物品共享服务的至少一个物品，所述方法包括：

根据多个所述物品的运营状态记录，获取系统运营数据，以供选择对应的管理策略实施物品管理，

其中，所述运营状态是待运营时，所述运营状态至少包括待出厂、待签收两个运营子状态；

和/或

2.根据权利要求1所述的方法，其特征在于，

3.根据权利要求1所述的方法，其特征在于，

4.根据权利要求1所述的方法，其特征在于，

5.根据权利要求1所述的方法，其特征在于，

6.根据权利要求1所述的方法，其特征在于，

接收客户端响应于运营人员的操作生成的所述运营状态变化信息，所述运营状态变化信息中还包括对应的运营人员的操作权限信息；

7.根据权利要求6所述的方法，其特征在于，还包括：

8.根据权利要求7所述的方法，其特征在于，所述对不同的运营人员设置不同的操作权限的步骤还包括：

创建包含多个运营人员的运营群组；

对同一运营群组的运营人员，设置相同的所述操作权限。

9.一种物品的管理方法，实施于用于提供物品共享服务的至少一个物品，所述方法包括：

其中，所述运营状态包括待运营、运营正常以及运营异常，所述运营状态变化信息至少包括对应物品的唯一物品标识、当前的运营状态，

和/或

10.根据权利要求9所述的方法，其特征在于，还包括：

和/或

11.一种服务端，包括：

存储器，用于存储可执行指令；

处理器，用于根据所述可执行指令的控制，运行所述服务端以执行如权利要求1-8任意一项所述的物品的管理方法。

12.一种客户端，包括：

显示装置，用于显示人机交互界面；

存储器，用于存储可执行指令；

处理器，用于根据所述可执行指令的控制，运行所述客户端以执行如权利要求9或10所述的物品的管理方法。

13.一种物品管理系统，包括：

至少一个用于提供物品共享服务的物品；

至少一个如权利要求11所述的服务端；

至少一个如权利要求12所述的客户端。