? ? ? ? 很多產品經理都因為缺少能夠獨立負責一個項目從0到1的機會炬守，最后不得不淪為產品功能優(yōu)化專員，本文的作者以銷售的業(yè)務系統(tǒng)舉例鹃答，全面細致地復盤分析了業(yè)務系統(tǒng)設計的過程和重點注意事項伯顶。在此分享出來，希望共同學習進步呢蛤。
一、為什么要由專業(yè)的PM設計業(yè)務系統(tǒng)
很多公司特別是創(chuàng)業(yè)公司都低估了系統(tǒng)架構設計的重要性棍郎，特別是前期業(yè)務系統(tǒng)的架構地基沒打好其障，業(yè)務模塊設計隨意和混亂，新增的功能隨意擺放涂佃，不僅導致業(yè)務人員使用系統(tǒng)時產生困惑励翼，同時還會導致開發(fā)人員編程設計混亂。以至于隨著公司的業(yè)務發(fā)展巡李，后期重構系統(tǒng)時所花費的精力和成本都是難以想象抚笔。
企業(yè)創(chuàng)新的業(yè)務模式，決定了必須要有一批業(yè)務系統(tǒng)設計人員侨拦，參與理解公司特殊的業(yè)務訴求，利用互聯(lián)網產品的開發(fā)方式和方法辐宾，快速狱从、合理的設計系統(tǒng)支持業(yè)務。
業(yè)務系統(tǒng)的產品經理叠纹，要深刻理解公司的經營管理季研、業(yè)務模式，參與制定業(yè)務決策誉察，才能設計合理与涡、靠譜的業(yè)務系統(tǒng)。本次分享通過復盤搭建渠道分銷平臺持偏，談一談PM如何參與設計業(yè)務系統(tǒng)的方法驼卖。
業(yè)務管理系統(tǒng)設計流程
1、業(yè)務方案設計：明確業(yè)務角色和工作流
業(yè)務調研
設計業(yè)務系統(tǒng)鸿秆，必須要透徹理解業(yè)務現(xiàn)狀酌畜，而理解業(yè)務最好的方法：
第一，有機會參與輪崗到業(yè)務環(huán)節(jié)卿叽，親身體會業(yè)務人員的工作狀態(tài)桥胞；
第二恳守，調研訪談。在調研之前贩虾，需要提前制定訪談計劃催烘，安排好訪談的對象即參與的業(yè)務人員，明確調研目的缎罢，提前準備好問題伊群，讓訪談更加高效。
組織架構
通過業(yè)務調研屁使，對業(yè)務體系大體上有一定的了解之后在岂，梳理出組織結構圖：
組織結構將影響業(yè)務系統(tǒng)設計的以下幾個方面：
組織結構的層級決定業(yè)務系統(tǒng)的工作流，間接決定業(yè)務流程蛮寂；
組織結構是否清晰決定權限劃分是否正確蔽午；
業(yè)務流程
通過調研，梳理出對于渠道銷售的業(yè)務流程酬蹋，例如下圖：
需要特殊說明的是：
如果業(yè)務部門已經有成熟的業(yè)務流程及老，落地可行且執(zhí)行了一段時間后，效果不錯范抓。PM在前期規(guī)劃上先把這個方案搬到線上骄恶，基于目前的工作流設計功能。
如果業(yè)務部門還沒有落地可行的業(yè)務方案匕垫，PM就需要和業(yè)務負責人一起梳理僧鲁、制定業(yè)務流程，梳理業(yè)務中有哪些業(yè)務角色參與工作象泵？各個角色參與了哪些工作階段寞秃？業(yè)務角色是否跨部門協(xié)作？業(yè)務環(huán)節(jié)是否可以通過部門進行拆分偶惠？
如果涉及多個部門協(xié)同及分工春寿，那么在確定業(yè)務流程時及時與多部門業(yè)務負責人溝通確認
業(yè)務訴求分析
基于目前的業(yè)務流程，需要和業(yè)務負責人確定業(yè)務系統(tǒng)現(xiàn)階段需要解決的問題忽孽，實現(xiàn)對應的功能绑改，如下：
支持將渠道信息從線下紙質合同錄入到線上系統(tǒng)中，優(yōu)先級：高兄一；
支持二級分銷模式厘线，優(yōu)先級：高；
支持對賬報表瘾腰，優(yōu)先級：高皆的；
支持賬期提醒和預付款模式逊移，優(yōu)先級：低勾栗；
處于業(yè)務流程中必不可少的環(huán)節(jié)定為較高優(yōu)先級，擴展功能和針對部分客戶的小眾功能，定為較低的優(yōu)先級钥勋。
經驗總結
必須要有標準化的業(yè)務流程格了，明確系統(tǒng)邊界售淡，這一點一定要和業(yè)務負責人確定清楚理张。標準化=高效率。
了解業(yè)務中參與的角色召廷、包含哪些關鍵工作節(jié)點凳厢，工作流程是怎樣的？
如果有必要竞慢，在最終與業(yè)務負責人敲定業(yè)務方案時先紫，最好拉上技術負責人，一方面筹煮，有利于技術人員提前理解業(yè)務遮精，另一方面，技術負責人可以站在技術角度為技術選型做好準備败潦。
業(yè)務人員作為系統(tǒng)的用戶本冲，相對來說，更能明確自己的需求劫扒，但是在溝通交流中檬洞，業(yè)務負責人可能會提出較為復雜，認為“完美”的系統(tǒng)沟饥，這個時候PM要過濾出重要的需求通過MVP等方法排出需求優(yōu)先級添怔，縮短研發(fā)周期。
不要依賴業(yè)務方提需求贤旷，要幫業(yè)務方想方案澎灸，由于角色的不同、思維方式的不同遮晚，業(yè)務方同學只能提出自己最終想要的功能，提出模糊的功能需求拦止，并不一定能提出自己真正的需求县遣，產品經理需要主動思考業(yè)務中的問題，并形成業(yè)務需求汹族。
擴展性和效率之間需要做權衡萧求，有的時候想得太多容易給自己和團隊挖坑，所以平衡擴展性和效率是門藝術
2顶瞒、系統(tǒng)架構設計：業(yè)務模塊拆分和權限劃分
業(yè)務模塊
通過調研對業(yè)務有了整體的認識夸政，與相關的業(yè)務人員確定了業(yè)務方案，接下來就是結合業(yè)務訴求與目標榴徐，梳理出整體的業(yè)務系統(tǒng)的架構圖守问，如下：
經過分析匀归，這次業(yè)務系統(tǒng)迭代主要的目的是為了支持渠道銷售的業(yè)務訴求，系統(tǒng)已經有底層的業(yè)務模塊可以直接復用耗帕，減輕了新平臺的實現(xiàn)難度和開發(fā)工作量穆端，渠道銷售模塊只需要聚焦業(yè)務特殊獨立的地方，渠道銷售業(yè)務的獨特性在于前置的渠道管理維護和后置的賬單管理仿便。
電商業(yè)務是系統(tǒng)主要的業(yè)務流程体啰，也是最底層的業(yè)務邏輯，有完善的訂單管理和出庫管理嗽仪。渠道下單后荒勇，產品的出庫配送直接復用已有的出庫管理，后續(xù)為客戶提供的服務闻坚。
如：樣本檢測和出具報告沽翔，業(yè)務流程完全一樣。只需要對訂單管理的數(shù)據(jù)結構稍加拓展即可支持（訂單管理中的客戶信息與渠道管理的渠道信息關聯(lián)性）鲤氢，這樣就可以保證訂單搀擂、倉儲、樣本卷玉、報告等模塊業(yè)務邏輯不需要重寫或改造哨颂。
需要特殊說明的是，渠道銷售的商品可以直接復用已有的商品SKU相种，但每個渠道對應的商品價格都不同威恼，因此需要將商品價格維護在渠道管理模塊中，以支持財務和賬單管理寝并。
業(yè)務模塊要做到“高內聚箫措、低耦合”。
內聚描述的是模塊內部各個元素彼此結合的緊密程度衬潦，越緊密斤蔓，內聚性越高，單一責任原則越強镀岛，單一責任指一個模塊負責一項任務弦牡。
耦合描述的是模塊外部各個模塊彼此結合的緊密程度，越緊密漂羊，耦合性越強驾锰，模塊的獨立性越差。
權限劃分：RBAC權限設計模型
權限管理三要素：賬號走越、角色椭豫、權限
賬號：業(yè)務系統(tǒng)的用戶就是業(yè)務人員，每個業(yè)務人員分配一個賬號，通過給業(yè)務人員分配賬號驗證身份登錄業(yè)務管理系統(tǒng)進行操作赏酥。新增賬號時需要設定：用戶名喳整、密碼和角色，如下：
角色：角色用來控制賬號的查看和操作范圍今缚，在系統(tǒng)中由于權限較多算柳，不可能每個每個賬號都分別設置權限，且由于賬號對應的業(yè)務人員從屬同一崗位和部門姓言，工作內容多有重合瞬项。在創(chuàng)建賬號時，就可以直接賦予賬號不同的角色何荚，從而將權限通過角色給到這個賬號囱淋。一個賬號可以綁定多個角色，一個角色又擁有多個權限餐塘。
權限內容包括：操作權限妥衣、查看權限、數(shù)據(jù)權限
數(shù)據(jù)權限：即角色能看到的數(shù)據(jù)范圍戒傻。比如銷售總監(jiān)能看到銷售部門下所有銷售員的銷售數(shù)據(jù)税手，而銷售員則只能看到自己的銷售數(shù)據(jù)。
頁面權限：即角色在業(yè)務系統(tǒng)中看到的頁面內容和元素需纳。比如對于訂單管理芦倒，客服人員可以看到訂單的基礎信息和詳情等所有信息，而倉儲人員只能看到訂單的基礎信息不翩。
操作權限：即角色可以進行的操作兵扬，如增刪改查。同樣拿訂單管理舉例口蝠，客服人員可以對訂單進行刪改器钟，而倉儲人員卻無法對訂單進行刪改，可以查詢妙蔗。
對于母子賬號管理傲霸，在創(chuàng)建角色時，就已經限定了數(shù)據(jù)權限眉反。在給角色選擇權限分配時狞谱，需要選擇該角色的對應的頁面權限（如，列表信息：渠道商）和操作權限（如禁漓，查看詳情）。
Tips：
一個賬號對應多個角色時孵睬，當該用戶登錄系統(tǒng)時播歼，他在系統(tǒng)中的權限是所有角色權限的并集。
創(chuàng)建角色之前，需要明確各個部門之間的業(yè)務范圍和工作職責秘狞，根據(jù)這些業(yè)務人員劃分權限叭莫。隨著公司的業(yè)務和后臺系統(tǒng)功能的改變，各個角色的權限是需要不斷完善和調整的烁试。
如果公司管理比較扁平化時雇初，同一部門的業(yè)務人員會共同使用同一角色，數(shù)據(jù)權限相同减响。但如果部門的職級關系需要映射到業(yè)務系統(tǒng)中靖诗，那么在創(chuàng)建角色時需要增加一個拓展的功能點-母子賬號管理，以此來劃分數(shù)據(jù)權限支示。
3刊橘、產品原型設計及PRD
PM在繪制原型時需要跟開發(fā)部門確定開發(fā)系統(tǒng)時使用什么樣式的前端框架，這樣就不需要UI設計師參與到業(yè)務系統(tǒng)的工作中颂鸿，交互也可以直接引用開源的前端框架促绵，提高效率。
原型盡量使用高保真制作嘴纺，一方面排版舒適败晴，良好的體驗是團隊的潤滑劑，另一方面栽渴，將數(shù)據(jù)項尖坤、列表項等細節(jié)信息已經繪制在原型中，不需要在文檔中特殊說明熔萧。
基本信息
基本信息即本次迭代產品說明書的總覽糖驴，包含：
修訂歷史：包括修訂時間、版本號佛致，修訂歷史的作用是為了產品人員方便后期查閱贮缕，一旦產品人員變動或工作交接給新員工，讓新的產品負責人查看產品迭代歷史
版本說明：即本次產品改動修改了什么（功能）俺榆，新增了什么（功能）感昼，優(yōu)化了哪些（功能），
業(yè)務背景&需求分析：在產品評審的時候罐脊，一定要和技術的同事交代清楚這次開發(fā)背后的目的是什么定嗓？誰提出來的需求？需求分析的結果什么萍桌？要不然技術同事會聽著很懵宵溅，評審時如果技術同事很少和你互動，那么技術的同事就只能低頭敲自己的代碼上炎，完全不知道自己設計的這個功能是干什么的恃逻。
業(yè)務流程圖
PRD的靈魂，重中之重，不多說寇损，PRD可以什么都不寫凸郑，但是流程圖必須要有。
權限說明
如果這次產品迭代是新增業(yè)務模塊和業(yè)務邏輯矛市，那么可能在系統(tǒng)中新增了一個角色芙沥，需要在文檔中說明新增的角色名稱和該角色下分配的具體有哪些權限，同時還需要說明業(yè)務人員的賬號增刪改了哪些角色浊吏。
如果是優(yōu)化了業(yè)務模塊或業(yè)務邏輯而昨，調整業(yè)務流程，那么可能需要在文檔說明系統(tǒng)角色中調整的權限卿捎。
數(shù)據(jù)說明
數(shù)據(jù)類型是什么配紫？是否必填？長度是否有限制午阵？是否校驗唯一性躺孝？（如用戶名，是否唯一底桂？）有無特殊說明植袍？（如密碼以星號展示）是否有默認值？刷新數(shù)據(jù)是否還在籽懦？空數(shù)據(jù)展示什么于个？
交互說明
模態(tài)框，彈出框暮顺、提示框等的樣式厅篓，按鈕、篩選項的狀態(tài)和位置區(qū)域捶码，頁面切換樣式羽氮，提示樣式？（成功提示惫恼、失敗提示档押、異常提示），操作反饋（點擊祈纯、滑動令宿、縮放等等）。
頁面規(guī)則：是否需要使用面包屑腕窥，列表頁的數(shù)據(jù)條數(shù)粒没，排序規(guī)則等，空數(shù)據(jù)簇爆、頁面報錯等頁面革娄。
操作說明
操作是否可以撤回倾贰？（如回滾功能，回收站功能）拦惋？關鍵操作之前是否需要給予提示/警告（如刪除操作）？是否需要為某些操作添加特殊說明（如后臺產品安寺，有些操作并不是所有用戶都了解的厕妖，有必要給出特殊文字說明）？操作如果異常/失敗/強制中斷挑庶，如何處理言秸？是否有備份？操作中是否允許中斷迎捺？
權限說明
如果這次產品迭代是新增業(yè)務模塊和業(yè)務邏輯举畸，那么可能在系統(tǒng)中新增了一個角色，需要在文檔中說明新增的角色名稱和該角色下分配的具體有哪些權限凳枝，同時還需要說明業(yè)務人員的賬號增刪改了哪些角色抄沮。
如果是優(yōu)化了業(yè)務模塊或業(yè)務邏輯，調整業(yè)務流程岖瑰，那么可能需要在文檔說明系統(tǒng)角色中調整的權限叛买。
業(yè)務系統(tǒng)產品設計的特點
更關注業(yè)務流程與業(yè)務邏輯
前臺產品注重用戶體驗，站在用戶角度設計產品蹋订，考慮用戶使用場景率挣，打磨產品細節(jié)，讓用戶用著爽露戒。相比較而言椒功，后臺產品更注重實際的業(yè)務邏輯，用戶在前臺產品的每一個觸發(fā)操作行為智什，產品如何應答动漾，需要處理那些數(shù)據(jù)，如何處理數(shù)據(jù)撩鹿，如何傳輸數(shù)據(jù)谦炬，傳輸哪些數(shù)據(jù)給前臺產品與用戶交互互動。
后臺產品設計更注重功能實現(xiàn)节沦，后臺產品設計時更貼合產品MVP設計的理念键思，對于后臺業(yè)務系統(tǒng)來說，很多功能模塊可以采用開發(fā)成本更低的臨時方案甫贯，即使體驗不好吼鳞，業(yè)務人員操作效率不高，只要能保障功能可以實現(xiàn)叫搁，業(yè)務邏輯處理正常赔桌，業(yè)務可以正常運轉即可供炎。
需求更為明確
用戶端的產品需要通過不斷的調研分析、需求挖掘疾党，測試驗證音诫，提升產品價值。而業(yè)務系統(tǒng)的用戶是內部的業(yè)務人員雪位，業(yè)務方往往都是主動推進需求竭钝。
但是，對于業(yè)務人員的需求仍然需要判斷其真實性及目的雹洗。由于業(yè)務系統(tǒng)的業(yè)務邏輯的復雜性香罐，業(yè)務主流程之外的異常流程也較多，如果沒有正確理解需求的真實意圖时肿，就會導致業(yè)務系統(tǒng)的功能疊加庇茫，系統(tǒng)愈發(fā)混亂。
高效率螃成、靈活性旦签、可拓展
而內部業(yè)務人員在使用后臺系統(tǒng)時，一般都屬于工作范疇锈颗，所以要講究高效率顷霹，如此才能快速高效的完成相應任務，說的更宏觀一些击吱，能否提高業(yè)務人員的工作效率是衡量業(yè)務系統(tǒng)好壞的標尺淋淀。
高效率：比如，在設計報告打印管理時覆醇，業(yè)務人員需要接收從打印廠中打印完成的報告然后交付給下一個部門朵纷，報告就在多個部門中流轉產生多個狀態(tài)變更。相應的業(yè)務人員需要標記每個報告的狀態(tài)變更永脓。為了嚴謹防止實際操作中業(yè)務人員出現(xiàn)操作失誤袍辞，業(yè)務人員需要一個個確認報告的狀態(tài)變更。如下圖：
但在實際使用場景中常摧，業(yè)務人員經常從打印廠接收一批報告搅吁，報告數(shù)量較大。業(yè)務人員可能要重復性的操作標記每一個報告的狀態(tài)變更落午，這個時候谎懦，“批量操作”、“全選”功能就解決了業(yè)務人員重復性的操作溃斋，效率較低的情況界拦。
再比如在下載excel表格時，狀態(tài)自動變更梗劫，而不需要業(yè)務人員手動調整狀態(tài)享甸。
靈活性：靈活性處理的是同一業(yè)務場景下截碴，某個環(huán)節(jié)一但出現(xiàn)異常，系統(tǒng)可以進行補救蛉威，從而使該業(yè)務場景下異常狀態(tài)回歸正常業(yè)務邏輯日丹，跑通業(yè)務流程。正常業(yè)務場景是蚯嫌，用戶購買基因檢測產品后聚凹，我們將采樣盒郵寄給用戶，用戶自助將采樣盒綁定到自己的賬號下齐帚，并完成樣本采集，后期才能查看報告彼哼。
有個異常的業(yè)務場景是对妄，用戶忘記綁定樣本并郵寄回來，用戶沒有任何補綁的機會怎么辦敢朱？也就是說在前臺的用戶端產品剪菱，對于這個樣本沒有任何補救的機會，最后考慮只能從業(yè)務系統(tǒng)進行優(yōu)化拴签，調整系統(tǒng)的靈活性孝常。即使用戶沒有綁定自己的樣本，客服人員可以在后臺幫助用戶填寫信息完成綁定蚓哩，用戶可以在后期通過手機號索取到自己的樣本构灸。如下圖：
拓展性：拓展性是指業(yè)務系統(tǒng)可以處理不同的業(yè)務場景，讓不同的業(yè)務場景可以兼并符合同一業(yè)務邏輯岸梨。
上一點提到的業(yè)務系統(tǒng)的靈活性主要符合的場景是單一用戶完成樣本綁定喜颁，屬于2C業(yè)務。如果是2B業(yè)務怎么辦呢曹阔？通過調研之后半开，我們了解到2B的業(yè)務場景完全不同于2C的業(yè)務場景，2B大企業(yè)是通過召集大批量的客戶集中在一個會場中完成樣本采集赃份。
對于2B的客戶來說寂拆，不需要用戶自己單獨進行綁定采樣盒，因為2B的大企業(yè)已經有了客戶的個人信息抓韩。對于這種業(yè)務場景纠永，設計一個“批量導入樣本”的功能，2B銷售員只需要通過Excel表格將客戶信息錄入到系統(tǒng)中就可以完成采樣盒綁定园蝠。如下圖：
