关于共享单车管理系统这几点需要明白.docx

关于共享单车管理系统这几点需要明白.docx

《关于共享单车管理系统这几点需要明白.docx》由会员分享，可在线阅读，更多相关《关于共享单车管理系统这几点需要明白.docx（6页珍藏版）》请在冰豆网上搜索。

关于共享单车管理系统这几点需要明白

关于共享单车管理系统，这几点需要明白

编辑导读：

经过前几年的共享单车“混战”，现在市面上只留下美团摩拜、青桔、哈啰“三足鼎立”。

共享单车作为出行最常用的交通工具，具有很大的市场价值。

本文作者以自己参与过的一个共享单车项目为例，谈谈对共享单车管理系统的看法，与你分享。

众所周知，随着这些年共享单车的发展，从一线城市到四线城市基本上都能看到共享单车的身影，而各大车厂通过这些年的竞争和火并，也算教育用户的一个过程。

就作者所处的环境来看，破坏共享单车的现象明显少很多了，车座上疤痕的新旧程度似乎也能说明人们对待共享单车的态度，新疤痕多，说明它们所处的环境仍然很恶劣，旧疤痕多，说明它们曾经所处的环境很恶劣，这里只是提供一个思路来判断大家对待共享单车的态度随笔和大家分享一下。

言归正传，共享单车深入到我们的生活当中，给我们带来了很多的便利性，这其中离不开共享单车企业的高效运营。

而企业的高效运营，离不开企业信息化系统的支持。

笔者有幸在一家企业做支持企业业务的B端产品经理时接触过共享单车方面的业务，时间虽短，但接触下来，共享单车的业务还是挺有意思的，很耐研究的。

而通过研究企业的业务，也对自己之前积累的经验和知识做了一个复盘总结，进而沉淀。

得益于笔者在这段工作经历之前的电商信息化经验，通过三年的OMS+WMS产品的售前、实施、售后、产品全方位的历练，打下了还算凑合的基础，上手共享单车B端业务系统的时候前期痛苦了两周，后面就顺利多了，从业务拓扑到功能架构再到模块功能再到岗位需求逐渐的将整个企业的业务梳理的较为完整了。

下面我会从公司整体的业务出发，结合自己的理解，和大家分享一下这段从业的经历。

一、集团业务

提到业务，不得不提到业务部门，借助业务部门来分析集团的业务，也就能够帮助我们更清晰的了解业务，我尽量按照系统信息流的顺序给大家罗列一下（忽略笔者所在的软件研发部门，尽管他很重要哈哈）：

产品部（硬件）：

负责单车工业设计，硬件需求调研与实现；

采购部：

负责单车采购；

财务部：

负责财务结算、营收预算等；

运维部：

负责单车投放于维护；

客服部：

处理用户日常骑行问题；

营销部：

负责用户运营（C端产品经理）、线下推广等；

数据部：

数据分析、业务指导。

具体的部门名称不是按照实际情况来的，比如营销部有的互联网公司叫“企划部”有的叫“市场部”，但是不影响大家了解业务，看到这里大家心中应该已经有了一个模糊的业务流程，那就是从单车设计（产品部）——到单车采购（采购部）——到财务付款（财务部）——到运维投放（运维部）——到用户骑行过程中遇到问题的沟通（客服部）——再到市场营销（营销部）的一个简单业务流程，业务主线搞清楚之后，接下来如何入手就清楚了。

二、功能拓扑

这里给大家大概画了个功能拓扑，是根据业务部门来画的，并没有完全根据当时实际业务中所需要的功能模块去画，勉强称它为“功能拓扑”吧。

考虑着为了让大家能够更容易理解，这里对功能模块做了调整，只保留了功能模块的主体，后面我们具体谈功能的时候再延伸探讨一下。

大家作为B端产品经理，着手工作的时候，一定要了解企业业务，或者说是行业业务。

因为笔者是作为支撑企业业务的ToB产品经理，所以先从企业业务入手了。

和各个部门接触下来，公司的业务就梳理清楚了，然后再针对各个部门的业务去梳理一下需要的功能。

做这一步的时候，其实就是在做拓扑的前身工作了。

有了可视化的功能梳理结果之后，大家再去思考哪些功能模块的复用率高，哪些功能模块是部门内独有功能，这样下来，支撑企业业务的整体思路便出来了。

三、聊点业务

聊完框架类的东西，我们来聊点具体的业务，其实框架类的东西如果思路清晰的去做，不同人梳理出来的结果可能差不太多，但是具体到业务上，因为互联网企业的业务相较传统企业的业务变化比较多，很多传统软件在支撑了基础功能之后，很难再深入支撑企业的业务。

这时候对于ToB的产品经理来讲，就很“吃”经验了，甚至要具备从窥一个功能，而预想到业务全貌的能力。

写这一段的时候，笔者想了很久从哪里入手，想来想去，虽然前面给大家按照部门梳理了功能架构，但是具体谈业务的时候，还是不要从具体的业务部门入手，我们从基础数据入。

，因为很多时候，限制产品扩展或者是业务发展的地方，往往是产品的根基，基础配置（数据）。

就像我们软件行业，应用层很强大，但是操作系统甚至基础应用软件我们还有很长的路要走。

说到基础业务，对于集团业务来说，就是“车辆资产”的数据最基础了。

“车辆资产”数据的重要性，就像角色权限之于一个系统的重要性一样。

而用户权限的控制有很成熟的“RBAC模型”来辅助我们工作，“车辆资产”模块设计的时候却要结合集团各个部门的业务展开。

下面，我们从“车辆资产”展开，和大家聊一下笔者在从业过程中遇到的问题的解题思路。

3.1车辆资产

既然是单车业务，那么最基础的业务一定是离不开单车的，从单车设计——单车采购——单车资产管理——单车投放——单车运营——单车运维，始终离不开单车。

围绕单车，上面一段又给大家梳理了一下涉及到单车数据的业务大概有哪些，所以，从设计单车在系统中的基础数据模块时，就要考虑到涉及到单车的业务有哪些，而那些业务中，要使用到单车资产的什么数据，使用到的数据中，要设计在哪个模块上，而模块和模块之间，又要通过什么数据去链接。

接下来，我们从车辆本身到业务需求的角度出发，梳理一下各个业务环节上需要的关键信息。

3.1.1车辆基础

共享单车因为它的联网属性，需要锁是联网的，为什么是锁联网，而不是其他部件联网呢？

简单来说，传统的自行车生产企业是不具备生产物联网设备的能力的，而现在普遍的智慧汽车中的车机，也大多数是外部采购的，仅仅是车载系统是自研的。

自行车就更不必多说了，专业的事情还是要交给专业的人去做。

而对于车辆资产管理，也就顺势分成了两大类，车架主体（除车锁外的整车）和车锁，我们这里把车架上的零部件也归纳到“车辆资产”中，因为属于低值易耗品，所以对于每个配件的唯一性几乎没有要求，只有对数量的上的要求，做到资产数量的有效管理即可，这一段先将车辆资产两大类中的关键信息列出来。

3.1.1.1车架：

车架号、车辆型号

车架号：

车辆唯一码，用于车辆管理

车辆型号：

用于区分不同型号的车辆

3.1.1.2车锁（联网）：

车锁编号、车锁型号

车锁编号：

车锁唯一码，用于区别和管理车锁

车锁型号：

用于区分不同型号的车锁，批量升级固件等

注：

我们可以把车架当做主资产，车锁虽然也讲究唯一性，但我们这里把它理解成为消耗品，这里不做过多解释，大家继续看就会理解。

3.1.2车辆采购/入库

有了两大类的资产信息，那么采购的工作就好开展了，接到采购任务后，就可以下采购单了，采购什么型号的车辆多少辆，什么型号的车锁多少把。

这里有个知识点，关于两类资产的采购是分开进行，还是整车采购（车架+车锁）。

要明确清楚，一般情况下，有两种情况。

一是分别采购，车架和车锁到货后自己组装，这样的方式有个好处，可以在组装过程中绑定车架和车锁，从而实现整车的入库流程，而车锁作为消耗品，也应该备足充足的库存。

另外一种就是委托车厂采购指定的车锁并组装后交付，个人觉着这样会存在很多问题，例如锁资产的管理维护以及价格控制等。

因为笔者所在的企业车架和车锁是分开采购的，到货后自行组装车架和车锁，所以从“车辆资产”的介绍开始，便对这两者进行了区分，车架和车锁到货后分别入库，等待集团运营和运维的统一调配。

入库功能需要注意的就是单据不仅要对应车辆/车锁型号、数量，还要有对应编号的明细记录，以及入库的地点，其中入库的地点/仓库是比较重要的一环，这里的地点可以和具体需要投放的区域设计在一起，概念和仓库类似。

因为车架和车锁是分别入库，所以这里还会牵扯到一个状态，就是车锁和车辆的绑定状态。

这个状态和资产的移动密切相关，车架和车锁的入库默认状态是未绑定的状态，车锁因为是在线资产，需要检查在线状态来判断锁是否故障，所以还会有很多信息，等一下到在线资产管理的时候我们再细说。

关键信息：

车架：

存放地点、绑定状态

车锁：

存放地点、绑定状态

3.1.3资产管理

车架和车锁入库后，下一步就是等待集团使用了，一般情况下运营部门会根据数据做出调配决策，然后运维部门根据决策做具体调配。

但是文章写到现在，车架和车锁还是散装状态在集团仓库，系统内记录的是在哪个地点，什么型号的车架/车锁、多少件，以及对应的明细，这些资产以对应的状态在系统内呈现，无论是组装与否都能够有效的对资产进行管理，说到资产为什么要以这种方式管理，就和具体业务息息相关了。

例如新开辟了一个投放城市，或者一个城市需要新增投放车辆，那么就需要给这个城市发送整车，如果是某个城市的车辆上的车锁遭到破坏或者其他配件遭到破坏，就需要单独给城市运维发送配件状态的资产了。

车辆到达指定城市后，需要地方运维操作收货，收货完成后，改变资产的存放地点，完成资产在内部的流动，这一段比较简短，给大家穿插地描述了一下资产以什么样的形势，以及简单的资产流动过程。

关键信息：

车架：

存放地点、绑定状态

车锁：

存放地点、绑定状态、在线状态

整车：

存放地点

3.1.4单车投放/单车运维

对于已经到达地方运维手中的单车，剩下最重要的工作就是单车投放和运维工作了，投放工作比较简单，选取需要投放的单车，挂靠投放单，再一次检查车辆状态无误后即可投放，投放后改变车辆资产的投放状态，使其能够在C端应用中给用户骑行，并根据车辆型号检查对应的资费信息即可完成投放。

完成投放后，车辆资产（整车）就进入用户使用阶段了，而这个阶段，才是一线运维伙伴们面临最大工作量的阶段，要做巡检车辆、调度车辆、维修车辆等等工作，而每种工作，都需要信息系统提供功能上的支撑，这时候就对在线资产管理的需求就出来了。

例如：

巡检车辆需要有车辆的定位、电量、在线状态，还有一些特殊状态根据不同的需求来设置，例如超区风险的预警、车辆掉线的提醒等等。

这一段主要讲一下维修吧，维修是一个需要注意的资产管理场景，车辆维修涉及到的资产有：

车辆配件（刹车部件、车轮、车座、车筐、车把套等等）、车锁，一般情况下很少需要对车架进行大修的（虽然很少，但是也提供一个思路。

一般车架需要大修的，可以调拨回总部，通过集中大批量维修后当做新车投放，亦可以走报废处置），对车架上的小配件进行维修时，走一个正常的维修单登记好维修记录和消耗配件的明细即可了。

但涉及到更换车锁的时候，这里要注意了，这里牵扯到一个车架和车锁解除绑定和重新绑定的关系，要不然这辆车的身份就会混乱掉。

关键信息：

车架：

存放地点、绑定状态

车锁：

存放地点、绑定状态、在线状态

整车：

存放地点、投放状态

3.1.5小结

写到这里，资产管理的部分基本上写完了，比较笼统，甚至有些流水账的意思，有些业务也是不太适合从“资产管理”这个模块中展开细聊。

虽然如此，但整体思路是顺着个人的产品设计经历过来的，有很多地方大家可能会认为设计过于复杂了。

是的，这个要看具体的业务了。

但是从笔者写这篇文章的角度，是需要把实际业务和个人的理解相结合一下的，这样才能更加完善的表达一个车辆资产从系统中的生命周期是怎样的。

这，就是它的生命，而这，就是我们需要认真对待它的方式。

相信ToB的朋友们看过“资产管理”这一段之后会对整体业务有一个基本上的想象，如果文章能达成这个目的，也算笔者没有白花心思码字了。

四、收笔

关于这段工作的分享先告一段落了，总感觉意犹未尽，在写资产管理的时候牵扯到了很多有意思的业务，像采购、运维等业务，想多写一些分享出来和大家讨论，但展开来写的话业务又有些复杂，本身工作也挺忙的，一时没有思绪从何处起笔，等有时间了给大家好好梳理一下一个业务一个业务的分享。

对于支撑企业业务的B端产品经理来说，对业务理解的深入程度，直接影响产品设计的质量和用户使用的效率，区别于平台型的B端产品经理，服务于企业的时候，考虑更多的是业务的流畅性，和功能的复用性，而做平台型产品经理的时候，考虑更多的是行业的通用性。

例如我们经常提到的SaaS、模块化等概念，都是为了能让平台型的产品能在企业业务中落地的目的，而不管是服务于企业的B端产品经理，还是在做平台型产品的B端产品经理，都需要有丰富的业务经验，而业务也是我们成长路上可靠的伙伴，尽管他曾经无数次刁难过我们。

再给正在从事或者是想要从事B端产品经理的小伙伴们打打气吧，因为笔者自身是从软件专业毕业的，所以希望大家多和程序员小伙伴们沟通，多一些理解和包容，少一些戾气和盛气凌人，专心放到业务和服务上，你会发现，一名优秀的程序员同事，会是你成长道路上不可多得的良师益友。

显然，笔者就曾经经历过这样美好的时光。

最后，ToB，加油！