酷播亮新聞
從事基因檢測產品經理崗位一年多，工作重心逐漸從前端產品設計轉移到後端的業務系統產品設計。 由於行業的特殊性，很難在市面上找到符合公司實際業務需求的第三方業務管理系統，所以公司決定自己內部團隊開發符合自己實際業務需求的業務系統。 通過复盤這次的業務系統搭建過程，希望能沉澱出自己的一些方法論和思考。
一、為什麼要由專業的PM設計業務系統
很多公司特別是創業公司都低估了系統架構設計的重要性，特別是前期業務系統的架構地基沒打好，業務模塊設計隨意和混亂，新增的功能隨意擺放，不僅導致業務人員使用系統時 產生困惑，同時還會導致開發人員編程設計混亂。 以至於隨著公司的業務發展，後期重構系統時所花費的精力和成本都是難以想像。
企業創新的業務模式，決定了必須要有一批業務系統設計人員，參與理解公司特殊的業務訴求，利用互聯網產品的開發方式和方法，快速、合理的設計系統支持業務。
業務系統的產品經理，要深刻理解公司的經營管理、業務模式，參與製定業務決策，才能設計合理、靠譜的業務系統。 本次分享通過复盤搭建渠道分銷平台，談一談PM如何參與設計業務系統的方法。
業務管理系統設計流程
1、業務方案設計：明確業務角色和工作流
業務調研
設計業務系統，必須要透徹理解業務現狀，而理解業務最好的方法：
- 第一，有機會參與輪崗到業務環節，親身體會業務人員的工作狀態；
- 第二，調研訪談。 在調研之前，需要提前製定訪談計劃，安排好訪談的對象即參與的業務人員，明確調研目的，提前準備好問題，讓訪談更加高效。
組織架構
通過業務調研，對業務體系大體上有一定的了解之後，梳理出組織結構圖：
組織結構將影響業務系統設計的以下幾個方面：
- 組織結構的層級決定業務系統的工作流，間接決定業務流程；
- 組織結構是否清晰決定權限劃分是否正確；
業務流程
通過調研，梳理出對於渠道銷售的業務流程，例如下圖：
需要特殊說明的是：
- 如果業務部門已經有成熟的業務流程，落地可行且執行了一段時間後，效果不錯。 PM在前期規劃上先把這個方案搬到線上，基於目前的工作流設計功能。
- 如果業務部門還沒有落地可行的業務方案，PM就需要和業務負責人一起梳理、制定業務流程，梳理業務中有哪些業務角色參與工作？ 各個角色參與了哪些工作階段？ 業務角色是否跨部門協作？ 業務環節是否可以通過部門進行拆分？
- 如果涉及多個部門協同及分工，那麼在確定業務流程時及時與多部門業務負責人溝通確認
業務訴求分析
基於目前的業務流程，需要和業務負責人確定業務系統現階段需要解決的問題，實現對應的功能，如下：
- 支持將渠道信息從線下紙質合同錄入到線上系統中，優先級：高；
- 支持二級分銷模式，優先級：高；
- 支持對賬報表，優先級：高；
- 支持賬期提醒和預付款模式，優先級：低；
- 處於業務流程中必不可少的環節定為較高優先級，擴展功能和針對部分客戶的小眾功能，定為較低的優先級。
經驗總結
- 必須要有標準化的業務流程，明確係統邊界，這一點一定要和業務負責人確定清楚。 標準化=高效率。
- 了解業務中參與的角色、包含哪些關鍵工作節點，工作流程是怎樣的？
- 如果有必要，在最終與業務負責人敲定業務方案時，最好拉上技術負責人，一方面，有利於技術人員提前理解業務，另一方面，技術負責人可以站在技術角度為技術選型 做好準備。
- 業務人員作為系統的用戶，相對來說，更能明確自己的需求，但是在溝通交流中，業務負責人可能會提出較為複雜，認為“完美”的系統，這個時候PM要過濾出重要的需求通過 MVP等方法排出需求優先級，縮短研發週期。
- 不要依賴業務方提需求，要幫業務方想方案，由於角色的不同、思維方式的不同，業務方同學只能提出自己最終想要的功能，提出模糊的功能需求，並不一定能提出自己真正 的需求，產品經理需要主動思考業務中的問題，並形成業務需求。
- 擴展性和效率之間需要做權衡，有的時候想得太多容易給自己和團隊挖坑，所以平衡擴展性和效率是門藝術
2、 系統架構設計：業務模塊拆分和權限劃分
業務模塊
通過調研對業務有了整體的認識，與相關的業務人員確定了業務方案，接下來就是結合業務訴求與目標，梳理出整體的業務系統的架構圖，如下：
經過分析，這次業務系統迭代主要的目的是為了支持渠道銷售的業務訴求，系統已經有底層的業務模塊可以直接復用，減輕了新平台的實現難度和開發工作量，渠道銷售模塊只需要聚焦 業務特殊獨立的地方，渠道銷售業務的獨特性在於前置的渠道管理維護和後置的賬單管理。
電商業務是系統主要的業務流程，也是最底層的業務邏輯，有完善的訂單管理和出庫管理。 渠道下單後，產品的出庫配送直接復用已有的出庫管理，後續為客戶提供的服務。
如：樣本檢測和出具報告，業務流程完全一樣。 只需要對訂單管理的數據結構稍加拓展即可支持（訂單管理中的客戶信息與渠道管理的渠道信息關聯性），這樣就可以保證訂單、倉儲、樣本、報告等模塊業務邏輯不需要重寫 或改造。
需要特殊說明的是，渠道銷售的商品可以直接復用已有的商品SKU，但每個渠道對應的商品價格都不同，因此需要將商品價格維護在渠道管理模塊中，以支持財務和賬單管理。
業務模塊要做到“高內聚、低耦合”。
內聚描述的是模塊內部各個元素彼此結合的緊密程度，越緊密，內聚性越高，單一責任原則越強，單一責任指一個模塊負責一項任務。
耦合描述的是模塊外部各個模塊彼此結合的緊密程度，越緊密，耦合性越強，模塊的獨立性越差。
權限劃分： RBAC權限設計模型
權限管理三要素： 賬號、角色、權限
賬號：業務系統的用戶就是業務人員，每個業務人員分配一個賬號，通過給業務人員分配賬號驗證身份登錄業務管理系統進行操作。 新增賬號時需要設定：用戶名、密碼和角色，如下：
角色：角色用來控制賬號的查看和操作範圍，在系統中由於權限較多，不可能每個每個賬號都分別設置權限，且由於賬號對應的業務人員從屬同一崗位和部門，工作內容多有 重合。 在創建賬號時，就可以直接賦予賬號不同的角色，從而將權限通過角色給到這個賬號。 一個賬號可以綁定多個角色，一個角色又擁有多個權限。
權限內容包括： 操作權限、查看權限、數據權限
數據權限：即角色能看到的數據范圍。 比如銷售總監能看到銷售部門下所有銷售員的銷售數據，而銷售員則只能看到自己的銷售數據。
頁面權限：即角色在業務系統中看到的頁面內容和元素。 比如對於訂單管理，客服人員可以看到訂單的基礎信息和詳情等所有信息，而倉儲人員只能看到訂單的基礎信息。
操作權限：即角色可以進行的操作，如增刪改查。 同樣拿訂單管理舉例，客服人員可以對訂單進行刪改，而倉儲人員卻無法對訂單進行刪改，可以查詢。
對於母子賬號管理，在創建角色時，就已經限定了數據權限。 在給角色選擇權限分配時，需要選擇該角色的對應的頁面權限（如，列表信息：渠道商）和操作權限（如，查看詳情）。
Tips：
- 一個賬號對應多個角色時，當該用戶登錄系統時，他在系統中的權限是所有角色權限的並集。
- 創建角色之前，需要明確各個部門之間的業務範圍和工作職責，根據這些業務人員劃分權限。 隨著公司的業務和後台系統功能的改變，各個角色的權限是需要不斷完善和調整的。
- 如果公司管理比較扁平化時，同一部門的業務人員會共同使用同一角色，數據權限相同。 但如果部門的職級關係需要映射到業務系統中，那麼在創建角色時需要增加一個拓展的功能點-母子賬號管理，以此來劃分數據權限。
3、產品原型設計及PRD
PM在繪製原型時需要跟開發部門確定開發系統時使用什麼樣式的前端框架，這樣就不需要UI設計師參與到業務系統的工作中，交互也可以直接引用開源的前端框架，提高效率。
原型盡量使用高保真製作，一方面排版舒適，良好的體驗是團隊的潤滑劑，另一方面，將數據項、列表項等細節信息已經繪製在原型中，不需要在文檔中特殊說明。
基本信息
基本信息即本次迭代產品說明書的總覽，包含：
修訂歷史：包括修訂時間、版本號，修訂歷史的作用是為了產品人員方便後期查閱，一旦產品人員變動或工作交接給新員工，讓新的產品負責人查看產品迭代歷史
版本說明：即本次產品改動修改了什麼（功能），新增了什麼（功能），優化了哪些（功能），
業務背景&需求分析：在產品評審的時候，一定要和技術的同事交代清楚這次開發背後的目的是什麼？ 誰提出來的需求？ 需求分析的結果什麼？ 要不然技術同事會聽著很懵，評審時如果技術同事很少和你互動，那麼技術的同事就只能低頭敲自己的代碼，完全不知道自己設計的這個功能是乾什麼的。
業務流程圖
PRD的靈魂，重中之重，不多說，PRD可以什麼都不寫，但是流程圖必須要有。
權限說明
如果這次產品迭代是新增業務模塊和業務邏輯，那麼可能在系統中新增了一個角色，需要在文檔中說明新增的角色名稱和該角色下分配的具體有哪些權限，同時還需要說明 業務人員的賬號增刪改了哪些角色。
如果是優化了業務模塊或業務邏輯，調整業務流程，那麼可能需要在文檔說明系統角色中調整的權限。
數據說明
數據類型是什麼？ 是否必填？ 長度是否有限制？ 是否校驗唯一性？ （如用戶名，是否唯一？）有無特殊說明？ （如密碼以星號展示）是否有默認值？ 刷新數據是否還在？ 空數據展示什麼？
交互說明
模態框，彈出框、提示框等的樣式，按鈕、篩選項的狀態和位置區域，頁面切換樣式，提示樣式？ （成功提示、失敗提示、異常提示），操作反饋（點擊、滑動、縮放等等）。
頁面規則：是否需要使用麵包屑，列表頁的數據條數，排序規則等，空數據、頁面報錯等頁面。
操作說明
操作是否可以撤回？ （如回滾功能，回收站功能）？ 關鍵操作之前是否需要給予提示/警告（如刪除操作）？ 是否需要為某些操作添加特殊說明（如後台產品，有些操作並不是所有用戶都了解的，有必要給出特殊文字說明）？ 操作如果異常/失敗/強制中斷，如何處理？ 是否有備份？ 操作中是否允許中斷？
權限說明
如果這次產品迭代是新增業務模塊和業務邏輯，那麼可能在系統中新增了一個角色，需要在文檔中說明新增的角色名稱和該角色下分配的具體有哪些權限，同時還需要說明 業務人員的賬號增刪改了哪些角色。
如果是優化了業務模塊或業務邏輯，調整業務流程，那麼可能需要在文檔說明系統角色中調整的權限。
業務系統 產品設計的特點
更關注業務流程與業務邏輯
前台產品注重用戶體驗，站在用戶角度設計產品，考慮用戶使用場景，打磨產品細節，讓用戶用著爽。 相比較而言，後台產品更注重實際的業務邏輯，用戶在前台產品的每一個觸發操作行為，產品如何應答，需要處理那些數據，如何處理數據，如何傳輸數據，傳輸哪些數據給前台產品與用戶 交互互動。
後台產品設計更注重功能實現，後台產品設計時更貼合產品MVP設計的理念，對於後台業務系統來說，很多功能模塊可以採用開發成本更低的臨時方案，即使體驗不好，業務人員操作效率 不高，只要能保障功能可以實現，業務邏輯處理正常，業務可以正常運轉即可。
需求更為明確
用戶端的產品需要通過不斷的調研分析、需求挖掘，測試驗證，提升產品價值。 而業務系統的用戶是內部的業務人員，業務方往往都是主動推進需求。
但是，對於業務人員的需求仍然需要判斷其真實性及目的。 由於業務系統的業務邏輯的複雜性，業務主流程之外的異常流程也較多，如果沒有正確理解需求的真實意圖，就會導致業務系統的功能疊加，系統愈發混亂。
高效率、靈活性、可拓展
而內部業務人員在使用後台系統時，一般都屬於工作範疇，所以要講究高效率，如此才能快速高效的完成相應任務，說的更宏觀一些，能否提高業務人員的工作效率是衡量業務系統好 壞的標尺。
高效率： 比如，在設計報告打印管理時，業務人員需要接收從打印廠中打印完成的報告然後交付給下一個部門，報告就在多個部門中流轉產生多個狀態變更。 相應的業務人員需要標記每個報告的狀態變更。 為了嚴謹防止實際操作中業務人員出現操作失誤，業務人員需要一個個確認報告的狀態變更。 如下圖：
但在實際使用場景中，業務人員經常從打印廠接收一批報告，報告數量較大。 業務人員可能要重複性的操作標記每一個報告的狀態變更，這個時候，“批量操作”、“全選”功能就解決了業務人員重複性的操作，效率較低的情況。
再比如在下載excel表格時，狀態自動變更，而不需要業務人員手動調整狀態。
靈活性： 靈活性處理的是同一業務場景下，某個環節一但出現異常，系統可以進行補救，從而使該業務場景下異常狀態回歸正常業務邏輯，跑通業務流程。 正常業務場景是，用戶購買基因檢測產品後，我們將採樣盒郵寄給用戶，用戶自助將採樣盒綁定到自己的賬號下，並完成樣本採集，後期才能查看報告。
有個異常的業務場景是，用戶忘記綁定樣本並郵寄回來，用戶沒有任何補綁的機會怎麼辦？ 也就是說在前台的用戶端產品，對於這個樣本沒有任何補救的機會，最後考慮只能從業務系統進行優化，調整系統的靈活性。 即使用戶沒有綁定自己的樣本，客服人員可以在後台幫助用戶填寫信息完成綁定，用戶可以在後期通過手機號索取到自己的樣本。 如下圖：
拓展性： 拓展性是指業務系統可以處理不同的業務場景，讓不同的業務場景可以兼併符合同一業務邏輯。
上一點提到的業務系統的靈活性主要符合的場景是單一用戶完成樣本綁定，屬於2C業務。 如果是2B業務怎麼辦呢？ 通過調研之後，我們了解到2B的業務場景完全不同於2C的業務場景，2B大企業是通過召集大批量的客戶集中在一個會場中完成樣本採集。
對於2B的客戶來說，不需要用戶自己單獨進行綁定採樣盒，因為2B的大企業已經有了客戶的個人信息。 對於這種業務場景，設計一個“批量導入樣本”的功能，2B銷售員只需要通過Excel表格將客戶信息錄入到系統中就可以完成採樣盒綁定。 如下圖：
以上，本次的 《產品复盤：從0到1設計業務系統 分享結束》，希望對你有所幫助！
本文由 @獨貓X 原創發佈於人人都是產品經理。 未經許可，禁止轉載。
題圖來自PEXELS，基於CC0協議