編輯導讀：經過前幾年的共享單車“混戰”，現在市面上只留下美團摩拜、青桔、哈囉“三足鼎立”。共享單車作為出行最常用的交通工具，具有很大的市場價值。本文作者以自己參與過的一個共享單車專案為例，談談對共享單車管理系統的看法，與你分享。
眾所周知，隨著這些年共享單車的發展，從一線城市到四線城市基本上都能看到共享單車的身影，而各大車廠透過這些年的競爭和火併，也算教育使用者的一個過程。就作者所處的環境來看，破壞共享單車的現象明顯少很多了，車座上疤痕的新舊程度似乎也能說明人們對待共享單車的態度，新疤痕多，說明它們所處的環境仍然很惡劣，舊疤痕多，說明它們曾經所處的環境很惡劣，這裡只是提供一個思路來判斷大家對待共享單車的態度隨筆和大家分享一下。
言歸正傳，共享單車深入到我們的生活當中，給我們帶來了很多的便利性，這其中離不開共享單車企業的高效運營。而企業的高效運營，離不開企業資訊化系統的支援。筆者有幸在一家企業做支援企業業務的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，加油！
本文由 @橙子哥哥 原創釋出於人人都是產品經理，未經許可，禁止轉載
題圖來自Unsplash，基於CC0協議