B端系統設計是個“體系活”，側重體系化建設。本文結合作者多年B端系統設計經驗，從理流程，建模型，捋狀態，畫交互這12個字談談B端系統設計該怎么做，希望對你有所幫助。

B端系統設計是個“體系活”，相較于C端產品強調價值直給，在單點體驗做到最優就可能做出一款好產品，B端產品則側重體系化建設，健壯的流程和嚴謹的邏輯規則是系統運轉的基石，產品外觀及體驗次之。

但是，一些剛入行的產品經理，或者C轉B的產品經理，處理需求時習慣性的會先畫原型圖，所見即所想，但這么做往往會導致流程短缺、邏輯不閉環等問題，尤其是對于復雜的業務模塊，更加需要成體系化的系統設計思路。

這里，結合個人多年的B端系統設計經驗，我認為再復雜的B端系統設計，都離不開這12個字：理流程，建模型，捋狀態，畫交互。

一、理流程

1、業務流

B端系統的設計起點，是從梳理業務流程開始。坐下來，和業務方一起，在具體的業務場景下將一條條業務流程挑明理順。

具體執行思路上，可以從角色、動作、約束、效果四方面去梳理業務流程：

（1）角色：人的角色或者系統角色。都有哪些人（系統）參與到流程中來，參與了哪些環節，角色是流程中最基本的元素，有了角色才有分工明確，才能有機協作。

（2）動作：流程中需要角色完成的業務動作。如銷售人員完成一次leads錄入、快遞小哥去配送一個包裹，即角色按照業務要求完成具體的業務指令。

（3）約束：在具體的業務場景和狀態下，產生的規則限制。如獲取到銷售線索后需在當天完成系統錄入，如快速小哥需在3小時內完成包裹派送。同一個角色完成同一個動作，在不同的約束下可能產生不同的效果，如快遞員在規定時間內妥投和超時妥投，超時妥投會額外觸發扣款等懲罰措施。

（4）效果：角色完成動作后的效果。代表著下一步的動作，是流轉到下一環節還是流程結束。這里注意一點是，產品經理要順藤摸瓜似的多問業務方幾個“然后呢”，防止業務流程有短缺，一步步追問將流程節點串起來直至達到End狀態。

2、系統流

系統流程是業務流程中需要系統支持的部分，是代碼實現的主要參考物。系統流程屏蔽了業務流程中純線下操作的部分，保留了業務流程中人機交互、系統與系統間交互、系統與IOT設備間交互的部分。

3、主流程

劃分主流程及其他流程的目的，是為了設定事情的主次。最先敲定的一定是業務的核心主流程，往往是業務心中所想的那條完美路徑。

有時業務方會僅考慮了主流程就會來提需求，那么作為產品經理需要協助將業務方尚未考慮清楚的留白區填滿，這里面就包括了異常流程、逆向流程和分支流程。

4、異常流程

當操作者或系統未按原定要求執行時，系統或業務所采取的應對措施。如快遞配送快遞員始終無法聯系上收件人怎么辦，是原路退回還是原地保留，如果原路退回所產生的運費是否應由發件人承擔等等，一系列異常場景和解決方案。

5、逆向流程

正向流程因故無法繼續執行，而產生的反向流程，事件回滾/實物原路退回/資源釋放等等。例如快遞配送場景下收件人拒收包裹，從而快遞公司將包裹逆向退回給發件人，屬于實物流的逆向流程，可能會有一次逆向流程、二次逆向流程甚至更多等等。

6、分支流程

在某些特定條件下觸發的子場景流程。如用戶在電商平臺買手機，且選擇了以舊換新服務，那么該快遞在配送流程中，會觸發第三方手機回收商上門回收手機，產生回收手機的分支流程，該分支流程屬于主流程的一部分且在訂單滿足以舊換新條件下特定觸發。

二、建模型

B端系統的業務建模，好比建造一所房子，在開始動工之前，必須將地基打好，包括確定房屋的主體結構（主數據）和關鍵材料（業務單據）等。上層穩不穩，全看地基牢不牢靠，所以，業務建模是B端系統設計中非常重要的環節。

1、主數據

主數據是能夠滿足跨部門業務協同需要，且能夠反映核心業務實體狀態屬性的基礎信息。在業務流程中，主數據屬于底層的基礎信息要素，是構建上層業務活動的根基。主數據相對于業務活動產生的業務單據而言，屬性更加穩定，準確度要求更高，唯一識別。如CRM中客戶信息、電商中的商品信息、協同辦公中的員工信息、組織信息等。

對主數據的建模，是對組織中“人財物事”的抽象化設計。在對主數據進行系統設計時，應考慮父子對象關聯關系、訪問權限設計、數倉的同步方式等問題。

2、業務單據

業務單據是業務活動中的過程產物和結果產物，存儲和記錄著業務的持久化信息和狀態信息。如用戶在電商平臺購買商品，會產生商品訂單，用戶付款后會產生倉儲用的出庫單，出庫完成后會生成各個環節的運輸單等等。

業務視角中，業務單據是業務流程中的核心產物，是推動和管理業務正確執行的關鍵憑證，深入業務場景，提煉業務單據，驅動業務流程。

技術視角中，業務單據是庫表設計的關鍵參考對象，梳理清晰單據的關鍵屬性和單據間的關聯關系，使系統方案在技術實現落地過程中更加順滑。

三、捋狀態

B端產品好不好用不體現在華麗的產品外表，重要的是業務邏輯的完美實現，而業務邏輯最重要的組成部分則是業務對象的狀態流轉，業務狀態流轉驅動業務行為發生，業務行為發生又推進業務對象狀態流轉。

可以說業務規則最終實現準確與否，與狀態機的設計好壞密切相關。

1、狀態機生命周期

在B端系統設計中，一個業務對象實例是有生命周期的。設計一個業務對象的狀態機，就好比去規劃TA的一生。業務對象在其生命周期內，由人或系統來使其激活（起始態），隨著用戶的行為操作和系統的規則，推動其經歷若干個狀態節點（中間態），業務對象也會一次次被調用、被修改、被更新，直至其履行完一次業務流程的職責后，或主動或被動的下線（終結態）。

2、狀態機構成要素

現態：是指當前所處的狀態。

條件：又稱為“事件”，當一個條件被滿足，將會觸發一個動作，或者執行一次狀態的遷移。

次態：條件滿足后要遷往的新狀態?！按螒B”是相對于“現態”而言的，“次態”一旦被激活，就轉變成新的“現態”了。

起始態：指最開始的狀態，如「待付款」，一般只有一個起始態。

終結態：指狀態機結束的狀態，如「已取消」「已完成」，有可能有多個終結態。

3、狀態機設計原則：MECE

我們以業務對象視角，構建狀態流轉的全生命周期，這么做的初衷是防止狀態遺漏，而導致業務不閉環。所謂MECE，“相互獨立，完全窮盡”，對于狀態機設計來說，在枚舉狀態時，能夠做到不重疊、不遺漏。這么做的目的是程序實現沒有二義性，且能夠覆蓋全部業務場景，使系統準確無誤的運行。

四、畫交互

對于B端系統來說，在業務流程、業務對象建模和狀態流轉都確定好之后，方案就已經成功80%了，剩余的我們把產品的交互功能補充完整，方案就大功告成啦。

執行上，根據業務需求和產品調性，輸出產品需求文檔和原型圖。

交互設計主要包括人機交互和系統間交互，并且B端系統設計實用大于一切。

1、人機交互

B端系統的人機交互，講究信息明確、頁面簡約、操作便捷、即用即走。

（1）便捷化：便捷化的操作體驗可以讓用戶身心愉悅，便捷化的最理想情況是業務人員即用即走，用最短的時間完成規定的業務動作，便捷化的產品設計如各種一鍵操作（合并多個操作步驟）、智能記憶、表單自動填充等。

（2）簡單化：簡單化分為交互的簡化和流程的簡化。交互的簡化是指替用戶排除不必要的信息干擾，使信息要素以直白無爭議的方式呈現給用戶，可以參考John Maeda的《簡約至上》，書中有介紹一些實用的設計方法和工具；流程的簡化指的是去掉重復的流程，合并相似的流程，避免在業務流程和產品操作層面產生浪費，如審批流下放等，需結合實際業務場景進行流程梳理，請注意先窮舉再刪減，避免遺漏。

（3）傻瓜化：想用戶之所想，通過數據采集、分類、標注等，提前預測用戶下一步行為，并提供參考信息輔助決策，代替用戶去做信息收集、整理、判斷的事情，如智能調度、智能客服等；

2、系統間交互

系統間交互包括系統間的接口調用、執行順序等，這部分設計方案往往以時序圖表達更為清楚，強調接口的調用關系和依賴關系，研發也更易理解。

需要注意的是除主流程外，在前期將一些異常情況和極限值處理邏輯梳理清楚，將大大降低接口聯調的時間，否則可能會出現「寫代碼」→「聯調」→「發現不對」→「改代碼」→「再聯調」→「再改代碼」的窘境，嚴重影響工期。

寫在最后

我們做任何事情，都應該挖掘本質，抽離規律，以不變應萬變。

在面對業務的變化、職場的變化、人生的變化，仍能從容應對。

一技傍身，不懼人生風雨！