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、狀态機構成要素
現态：是指目前所處的狀态。
條件：又稱為“事件”，當一個條件被滿足，将會觸發一個動作，或者執行一次狀态的遷移。
次态：條件滿足後要遷往的新狀态。“次态”是相對于“現态”而言的，“次态”一旦被激活，就轉變成新的“現态”了。
起始态：指最開始的狀态，如「待付款」，一般隻有一個起始态。
終結态：指狀态機結束的狀态，如「已取消」「已完成」，有可能有多個終結态。
3、狀态機設計原則：MECE
我們以業務對象視角，建構狀态流轉的全生命周期，這麼做的初衷是防止狀态遺漏，而導緻業務不閉環。所謂MECE，“互相獨立，完全窮盡”，對于狀态機設計來說，在枚舉狀态時，能夠做到不重疊、不遺漏。這麼做的目的是程式實作沒有二義性，且能夠覆寫全部業務場景，使系統準确無誤的運作。
四、畫互動
對于B端系統來說，在業務流程、業務對象模組化和狀态流轉都确定好之後，方案就已經成功80%了，剩餘的我們把産品的互動功能補充完整，方案就大功告成啦。
執行上，根據業務需求和産品調性，輸出産品需求文檔和原型圖。
互動設計主要包括人機互動和系統間互動，并且B端系統設計實用大于一切。
1、人機互動
B端系統的人機互動，講究資訊明确、頁面簡約、操作便捷、即用即走。
（1）便捷化：便捷化的操作體驗可以讓使用者身心愉悅，便捷化的最理想情況是業務人員即用即走，用最短的時間完成規定的業務動作，便捷化的産品設計如各種一鍵操作（合并多個操作步驟）、智能記憶、表單自動填充等。
（2）簡單化：簡單化分為互動的簡化和流程的簡化。互動的簡化是指替使用者排除不必要的資訊幹擾，使資訊要素以直白無争議的方式呈現給使用者，可以參考John Maeda的《簡約至上》，書中有介紹一些實用的設計方法和工具；流程的簡化指的是去掉重複的流程，合并相似的流程，避免在業務流程和産品操作層面産生浪費，如審批流下放等，需結合實際業務場景進行流程梳理，請注意先窮舉再删減，避免遺漏。
（3）傻瓜化：想使用者之所想，通過資料采集、分類、标注等，提前預測使用者下一步行為，并提供參考資訊輔助決策，代替使用者去做資訊收集、整理、判斷的事情，如智能排程、智能客服等；
2、系統間互動
系統間互動包括系統間的接口調用、執行順序等，這部分設計方案往往以時序圖表達更為清楚，強調接口的調用關系和依賴關系，研發也更易了解。
需要注意的是除主流程外，在前期将一些異常情況和極限值處理邏輯梳理清楚，将大大降低接口聯調的時間，否則可能會出現「寫代碼」→「聯調」→「發現不對」→「改代碼」→「再聯調」→「再改代碼」的窘境，嚴重影響工期。
寫在最後
我們做任何事情，都應該挖掘本質，抽離規律，以不變應萬變。
在面對業務的變化、職場的變化、人生的變化，仍能從容應對。
一技傍身，不懼人生風雨！
本文由 @打傘遛狗 原創釋出于人人都是産品經理。未經許可，禁止轉載。
題圖來自Unsplash，基于 CC0 協定
該文觀點僅代表作者本人，人人都是産品經理平台僅提供資訊存儲空間服務。