企業發展到一定階段，業務系統對企業的高效管理和運轉具備不可替代的核心作用。例如，當一家公司只有幾個銷售人員時，客戶資料用Excel即可管理；當銷售人員發展到上千人時，則必須通過一套OCRM系統進行管理。業務系統可提升管控能力、控制經營風險、降低運營成本、提升銷售業績，其建設的好壞決定了企業的核心競爭力，例如外賣公司之間競爭的是配送員的效率，而配送員效率取決於TMS（運輸管理系統）。
而且，互聯網公司的邏輯是，商業模式創新帶來業務模式創新，業務模式創新推動運營、管理機制創新，這就註定他們無法由標準軟件來支持業務。滴滴公司在成立時，是無法在市面上找到一款成熟的司機管理運營軟件的，需要結合業務，從無到有地設計一套司機（甚至是針對司機運營的機構）管理系統。美團需要管理大量的地推人員和客戶，傳統的OCRM軟件根本無法滿足美團對地理位置管理的訴求，即便採購成熟的OCRM做定製化開發，難度也比較大，最好的辦法是自主研發一套全新的基於獨特業務模式的OCRM軟件來支持業務。
由此可以看出，互聯網企業創新的本質，決定了必須有一批優秀的業務系統設計人員，結合公司特殊業務訴求，快速、合理地設計配套系統，並落地支持業務。業務系統的產品經理即B端產品經理，要具備企業經營管理、軟件系統設計的多方面經驗和知識，才能設計出合理的業務系統。
業務系統設計流程
從無到有地設計業務系統，是有一套標準範式可以遵循的。一般來講，從0到1地構建一套業務系統，需要經歷如下環節， PM需要從整體上把控業務系統的建設，協調各個相關方，對整個項目負責。
- 業務調研：全面研究並理解業務的現狀和規劃，挖掘並總結業務問題。
- 產品整體方案設計：明確產品定位（界定業務和系統的邊界）、抽象功能模塊、設計演進藍圖、設計整體應用架構，明確新系統如何與公司已有系統連接、交互。
- 產品細節方案設計：數據建模、角色梳理、界面設計、權限設計等。其中數據建模是最難的部分，數據建模的好壞決定了系統未來的靈活性、可擴展性。數據建模要求對業務有全面理解，並且有極強的抽象和歸納能力。
- 實施驗收：PM對項目的最終落地負責，系統上線後要展開持續的迭代優化，深度參與產品運營、數據分析等。
- 如果是從無到有地設計一套業務系統，以上環節必須全面貫徹，尤其是應用架構設計和數據模型，是重中之重。
電商渠道銷售系統案例
某電商企業M公司，成立5年，主營生鮮商品，以C端客戶為主，業務穩定，系統建設成熟。M公司在三個月前嘗試開展分銷業務，成立銷售團隊，開發分銷商合作伙伴（通過分銷商批量推廣和銷售商品）。業務試點在北京、上海開展，三個月以來發展迅速，同時，在高速發展中，若干流程、管理、風險問題突顯。
- 評估：經公司管理層評估，目前分銷業務月流水50萬元，以月增長20%的速度快速發展。公司決定投入研發資源建設軟件系統，支撐業務發展。
- 任務：公司要求在2~3個月的時間內搭建出一套分銷業務平臺，支撐分銷業務在未來2年的高速發展，提升效率，控制經營風險。項目期間CTO全力提供人力資源支持。
- 工作計劃：作為項目負責人，產品經理在接到任務後，先要理清工作思路，拆解任務，制訂時間計劃。只有嚴格遵循時間計劃執行工作，才能保證整體工作有序展開，如期落地。根據經驗和初步判斷，我們制訂粗略的工作計劃表如下。
時間緊，任務重，產品經理需要立即開展行動。當然，計劃表中的研發週期只是一個粗拍的時間，具體實施週期要結合一期項目範圍及人力投入，在立項時細化。
業務調研與業務方案
設計系統前必須透徹理解業務現狀與業務目標，考慮如何結合現有系統改造優化業務流程和模式。此階段可以由一個高級產品經理帶領幾個初級產品經理來做。最好邀請技術負責人一起參與，這樣有利於技術人員提前理解業務，為技術選型和方案設計做好準備，也便於讓技術負責人協助產品經理共同完成整體方案設計和細節方案設計，因為有時產品方案設計會受技術方案影響。
業務調研的方法
業務調研有多種方法，例如輪崗實習、問卷調研、深度訪談等。其中輪崗實習是深入理解業務的好方法，但是需要的時間較長。深度訪談是一種更加便捷快速的方法。訪談之前最好對業務有大體認知，安排好訪談的對象，提前準備好問題，讓訪談更高效。以下是針對分銷業務的訪談計劃和調研表。
主持人員：產品經理、研發經理
調研對象：業務負責人、一線主管、一線業務人員、合作伙伴（分銷業務客戶）
調研方式：深度訪談（訪談大綱如下圖），並進行數據分析
調研目標：業務模式和業務特點、業務目標和業務規劃、當前業務運轉方式、挖掘當前問題與痛點
業務調研總結
業務調研主要需要梳理清楚以下方面的情況，我們結合案例依此來看。
組織架構：通過調研，我們首先理清了當下的基本業務組織架構，通過組織架構圖能夠方便地理解管理體系和職能單元的設計。根據公司的要求，需要提升分銷業務的效率，控制經營風險，所以我們計劃做出兩方面調整：各分公司成立自己的運營部，招聘自己的運營人員，以便對市場做出迅速響應，提升效率；在分銷業務部下新增業務支持與風控部，以便控制風險。
業務目標：梳理了關鍵業務指標和目標，如下表所示。
業務流程：通過調研，我們還梳理了目前的業務運作流程，這樣才能對實際業務運作有清晰的瞭解，如下圖所示。可以看出，目前業務開展以手工作業為主。下單配送環節依託於公司已有的系統實現。
問題梳理：基於目前手工作業流程，我們整理出如下業務問題——①生鮮實時變價，每次下單要根據折扣表手工計算價格，效率低，易出錯；②因為缺少完善的客戶賬號管理體系，所以無法實現客戶總部集採、大區集採、城市集採、門店自採等靈活的混合採購模式；③因為無法標識特殊客戶的特殊訂單，所以無法支持特殊分揀、配送要求，例如對某些訂單加急配送；④無法對賬期客戶及時控制回款進度和賬期風險；⑤對賬和開票工作複雜，需要處理大量數據表，容易出錯。
當前流程下，一個運營人員只能跟進並維護5個左右的客戶，每日只能處理10筆左右的訂單，人效極低。
基於業務調研的核心訴求分析
- 基於整體調研結果，我們概要性地列出如下解決思路，括號中註明了優先級。
- 實現客戶自主下單（高優）。
- 實現系統自動定價（高優）。
- 支持客戶多門店分別定價與下單（高優）。
- 實現對賬報表（高優）。
- 運營人員聚焦參數設置、審核和異常問題跟進（高優）。
- 將運營工作下放到各城市分部（中優）。
- 支持賬期和預付款模式（低優）。
- 系統實現賬期風控（低優）。
我們將業流程優化確定為高優訴求，將擴展功能或針對部分客戶的小眾功能及風控功能列為低優。經過探討，和業務人員達成一致，一期項目聚焦高優訴求的實現。
業務主流程設計
經過和業務人員充分溝通，我們設計出系統支持下的核心業務流程圖，如下圖所示。其中客戶開發、合同審核等前置流程，依然通過線下處理完成；而客戶簽約後的賬號管理、價格管理、自主下單等環節，則通過分銷系統來支持，以提升效率。
系統整體方案設計
完成業務調研後，進入系統整體方案設計環節。該環節需要由經驗豐富的產品經理以及公司的架構師一起探討完成，因為方案涉及和公司現有應用架構如何融合的問題，因而還需要經過產品委員會或架構組的評審和確認。
系統定位
我們對業務進行分析。
- 分銷客戶希望能有一個便捷快速下單的工具，所以需要有一個手機版商城C端。考慮到投入產出比，我們決定通過H5來實現，具有獨立域名，外網可訪問。
- 需為分銷客戶提供一套方便操作的管理後臺，因為涉及大量的商品編輯處理，賬號、門店管理等功能，所以考慮PC版本實現，暫不支持手機版。
- 考慮到公司運營人員和分銷客戶管理員的管理訴求不同，操作功能和頁面差異較大，所以決定將管理後臺拆解為兩個獨立的系統：給分銷客戶管理員使用的客戶管理後臺，具備獨立域名，外網可訪問；給公司運營人員使用的運營管理後臺，具備獨立域名，僅限內網訪問。
於是，我們打算將分銷系統拆分為三個獨立的子系統，來支持分銷業務：分銷商城前臺（移動端，用H5實現）為分銷客戶提供下單功能；客戶管理後臺（PC端）為分銷客戶提供子賬號管理、門店管理及業務輔助功能；運營管理後臺（PC端）為分銷業務部門提供對客戶及商品定價管理的業務支持。
設計業務系統常見的問題是，為了省事，把所有業務單元的功能糅合到一個系統中實現，這會造成管理的混亂，尤其是系統維護的混亂。一般來講，系統的抽象要結合業務完成，獨立的業務職能單元要配合獨立的系統來使用。如果業務部門之間邊界模糊，權責界定不清，會導致系統之間存在模糊性。清晰的系統定位和邊界，可以讓各個子系統具備足夠的獨立性，是整個系統具備靈活性和可擴展性的基本前提。
整體架構設計
現在，需要考慮分銷平臺的三個子系統如何與公司的整體應用架構融合。公司經過多年發展，系統架構體系已經非常完備，大量公共組件和模塊可以複用，這樣就減輕了新平臺的實現成本和難度。分銷平臺只需要聚焦自己業務特殊獨立的地方，其他公共組件和模塊複用已有系統的即可。
- 電商業務是公司的主營業務，有成熟的訂單體系和倉配系統。分銷業務的獨特性在於前置客戶（是企業客戶）的管理維護，下單後的分揀配送業務流程和之前的業務是一樣的，所以分銷商城的訂單中心直接複用已有訂單中心，訂單寫入後續的處理流程完全不變，只需要訂單中心稍作改造即可支持，這樣也可以保證整個訂單臺賬、財務、倉儲、配送基本都不需要重寫或改造。另外分銷平臺的商品中心複用已有商品中心SKU數據，只是價格管理模塊部分需要新做一套獨立的，以支持特殊報價業務。
- 分銷業務的賬戶體系、權限管理體系、在線支付功能，都可以利用已有系統。其中賬戶體系需要做改造，以支持子母賬號管理；在線支付功能完全複用即可。
- 客戶資料的存儲利用已有的客戶主數據系統實現，因為企業客戶資料和個人客戶資料的差異較大，所以需要對MDM做較大改造，要新做一套企業客戶數據模型。但是在架構上，必須將客戶（包括個人客戶和企業客戶）資料作為主數據來建設，統一管理維護。
最後一個問題，既然公司已經有C端商城，為什麼要單獨再做一套針對分銷客戶的C端商城？經過分析評估，個人客戶和企業客戶需要的功能差異，如果對原有商城進行改造來支持分銷業務，一方面需要投入的工時可能比新做一套還要多，另一方面會影響主營業務系統的健壯性，因此最終決定為分銷業務做一套新的C端商城。
基於上述分析，我們將三個子系統繪入簡化版的公司整體應用架構圖中。
功能抽象
基於對業務的分析，以及三套系統的定位，可以抽象並繪製完整的系統功能藍圖。
功能模塊圖，是對業務訴求系統化設計的進一步高度抽象。模塊的設計，要體現出同一個業務職能單元中不同業務場景和操作的集合，模塊也代表了系統中的一二級導航菜單的設計。常見的問題，是設計人員對模塊設計的隨意和混亂，以及後來新增功能的隨意擺放，會造成用戶使用系統時產生困惑，同時還會導致開發人員編碼設計的混亂。
功能模塊圖，代表了設計師對業務和系統本質的理解和提煉，包含了對業務、系統未來發展的展望。我們常說，系統建設要有規劃和節奏，實際上功能模塊圖就是一幅遠景規劃藍圖，是系統的骨架，決定了系統的整體結構，結合業務需求，每一個具體功能的實現，都是在對骨架不斷地填充血肉，讓他更真實，更立體，更豐富。
隨著業務的開展，變化，功能模塊圖可能會有新的規劃和調整，但如果業務單元的本質和模式沒有變化，功能模塊圖不應出現結構性的調整和改動。
演進藍圖
我們已經繪製了系統的功能模塊圖，體現了業務和系統規劃的脈絡，現在，讓我們開始研究這套“體系”，大概需要幾期實現，每期實現的側重點是什麼，也就是常說的演進藍圖，Roadmap。
- 白色部分，是一期的項目範圍，聚焦解決最基本的業務流程線上化問題，以及最痛的痛點，例如對賬功能。一期功能有一個原則，凡是可以手工處理和解決的問題，都不做系統支持。所以，類似於“報表”，可以定期跑sql實現；類似於“價格係數設置”，考慮到維護頻率低，可由RD在後臺改數據庫完成；類似於“搜索、推薦”，並不影響客戶下單，因為根據調研目前每個客戶維護的最多sku數量只有二十個，無搜索功能並不會嚴重影響客戶下單效率。
- 綠色部分，是二期的項目範圍，二期將解決部分特殊業務剛需的訴求，如要支持“預付款”模式，“賬期”模式，“發票管理”，如果時間允許，可以一併實現若干報表查詢功能。
- 藍色部分，是三期的項目範圍，三期將聚焦風險控制，並強化運營功能。一般來講，很多互聯網公司初期會先跑業務，走流水，驗證可行性，成本和風險控制並不是特別在意，當業務具備一定規模時，則必須引入系統風控機制，做到事前、事中、事後的風險控制。此外，基於本案例B2B業務的特點，設計中並沒有考慮太多的C端功能。實際上C端只需要保證客戶能夠方便下單，並做一些很粗的運營、通知即可。
本文是對《決勝B端——產品經理升級之路》一書中“業務調研”與“產品整體方案設計”兩章的濃縮。人口紅利和補貼驅動的時代已結束，創業和投資的關注點也逐漸從C端產品轉向B端產品，運營模式創新與運營效能提升成為關鍵詞，擁有紮實、體系化的B端知識儲備的人才，越來越搶手。偶得一線專家在“槍林彈雨”中收穫的痛徹感悟和寶貴經驗。