編輯導語：B端產品更多是面向客戶的，是比較有實用性的產品，在產品設計中，需要從各個方面進行產品的調研輸出，找到最佳的業務方式以及完整框架；本文作者分享了關于B端產品設計的整體方案，我們一起來學習一下。

經過充分調研，我們了解了業務現狀和問題。接下來是不是應該畫原型寫PRD了？其實不然，還需要再輸出“整體解決方案”。

整體解決方案是一個產品的實現思路、明確產品的基本框架和范圍。只有確定了整體方案，才能夠細化后續的工作內容，為產品做詳細設計。

方案主要由五部分組成：梳理業務梳理、明確產品定位，功能模塊設計、劃分實施階段、應用架構設計。

方案呈現形式根據團隊的規范要求輸出即可，如果團隊沒有輸出要求，產品經理也應和對應干系人溝通情況并達成共識。達成共識的內容需要公示，讓團隊及相關人知曉。

接下來依次講述整體解決方案的各組成部分。

01 梳理業務流程

在調研時已經梳理過業務流程，明確了在業務運行時各環節各角色的具體任務。

現在我們再次梳理業務流程，是需要進一步將業務和系統（產品）相結合，確定需要系統介入的環節、保留線下操作的環節、對接三方系統的環節。

系統不是純粹的將線下操作改為線上操作，而是根據業務現狀、項目目標、資源限制等因素，設計出符合當下需求又為未來保留了拓展可能性的靈活產品。

舉例：

Z公司TMS項目中，調研得知目前的緊急需求在于2部分：

• 運輸任務初步信息化，提高作業環節效率；
• 車輛執行監控，掌握車輛位置相關信息。

關于運輸任務：任務來源于上游的業務系統，由于時間和資源限制，暫不考慮系統對接；所以訂單創建與管理、運單調度等環節均由本系統操作；在運輸執行的交接環節涉及多業務方，暫時保留線下操作。

關于執行監控：因為對司機行為管控力度不足、軟件對手機設備要求等因素影響，最終采用安裝GPS硬件設備的方式采集車輛執行信息，TMS系統和GPS設備系統對接獲取相應行駛數據，從而達到監控目的。

02 明確產品定位

當我們知道了產品會參與哪些業務部分，這也要求我們為產品做好“定位”。

定位的意義在于明確產品是做什么的，即：針對誰（角色）在什么場景下提供什么支持。這樣也就限定了產品對業務支持的邊界，或者說是功能邊界。

定位是錨，讓我們知道自己在哪里，該做什么，讓產品設計不偏離跑道。

舉例：

Z公司TMS項目中，運輸執行的最后環節是將物料運至倉庫簽收，因此在運輸送貨和倉庫收貨會有交接；業務場景中，車輛送貨到達倉庫后進行掛號排隊，然后等待叫號卸貨。

在此之前我們為“TMS”做好定位：為運輸任務管理和任務執行提供支撐，以此為中心拓展服務內容。

在實際場景中“排號”屬于倉儲業務范圍，同時為了后續系統的拓展性考慮，將排號劃分到WMS系統中，即便WMS的1.0版本只有排號功能；現階段車輛達到倉庫的自動排號由TMS向WMS傳數據并觸發任務，以此支持雙方后續業務的開展。

03 功能模塊設計

從表面上看，系統就是由各個功能模塊通過邏輯組裝在一起的集合體；實際上是基于業務場景，對對應角色在該業務環節中需要做的操作進行抽離，以此提煉出功能模塊。

提煉過程中常出現對資源、業務的管控邊界模糊問題，就需要及時代入實際業務場景驗證，或者和業務負責人溝通，避免設計偏差。

當功能模塊提煉完成后，需要規劃出系統的菜單結構。菜單結構猶如身體骨架，具體功能猶如不斷填充的血肉；菜單萬不能隨意擺放，結構若是不符合整體邏輯，對系統設計和用戶體驗都是極不友好的。

舉例：

Z公司TMS項目中，通過業務邏輯能夠劃分出前期資源準備、運輸任務執行、運營結果數據。

所以在提煉功能模塊時1期功能主要分為以下：

• 資源管理：物料管理、供應商管理、承運商管理、車型管理、車輛管理、司機管理。
• 業務管理：訂單管理、運單管理、車次管理、異常管理（運單）。
• 數據報表：數據概覽（首頁）、車次統計。

上述功能為主要模塊，在實際場景中存在其他功能；如“在途監控”，調度需要觀察執行任務的所有車輛當前狀態，此功能不能歸屬于具體車次；因此在設計菜單時需要充分考慮全局。

1期功能菜單如下，后續功能可進行延伸：

04 劃分實施階段

劃分實施階段又稱為演進藍圖，可以理解成系統規劃不同的發展階段。

俗話說一口吃不成胖子，產品也不是一次就開發成最終版；往往基于重要緊急程度、功能影響面等因素，先明確功能優先級，進而劃分產品不同階段的功能模塊以及實現節奏。

階段劃分的影響因素有很多，比如項目資源（時間、人員、支持…）、業務訴求（當前訴求和未來訴求），要根據權重綜合考量。

舉例：

Z公司TMS項目中，在調研時已明晰了當前重要緊急需求，因此以實現此目標為主。其他功能都要靠邊站，哪怕很有技術含量、提升用戶操作體驗等。

車輛調度時運輸任務執行的核心之一，系統至少可以通過2種方式實現。

• 調度員在系統中手動指派車輛和司機；
• 系統自動指派車輛和司機，系統通過維護物料和車型匹配數據、送貨時間和車輛任務匹配等多種參數自動指派。

方式2比方式1從工作效率和操作體驗上都加分不少，但是在1期的項目目標、項目各項資源、實際場景（前期業務量不是特別多）約束下，選擇了方式1來實現調度功能，方式2則規劃至2期階段實施。

05 應用架構設計

應用架構屬于技術層面的考慮，關注系統的整體結構。需要考慮公司不同系統之間的對接；考慮新系統在公司戰略定位下延伸出的訴求（有時和項目目標有所區別），考慮公司或項目的其他訴求。

系統架構對產品的拓展性影響深遠，需要和技術及相關負責人充分溝通后才能進行應用架構的設計。

舉例：

Z公司TMS項目中，因為業務方當前存在ERP、SAP等多系統同時運行，所以要考慮TMS系統如何和現有系統架構進行結合，不同系統模塊之間如何進行更好銜接。

復雜的暫且不論，簡單的如物料基礎數據是通用數據，多系統維護成本較大，后續要進行多系統復用；所以從技術實現成本、降低數據偏差異常、減少用戶重復工作等多方考慮；基礎數據以SAP系統為準，其他系統進行數據調用。

溫馨提示：

• 產品設計和規劃不是一經確認就固定不變的，而是隨著設計深入、業務發展、環境變化而變化，是不斷進行調整的。
• 設計系統結構時需要考慮滿足現狀，同時兼容未來發展，滿足系統的拓展性。
• 系統小的調整經常有，大的調整只有業務模式發生較大范圍或本質變化，功能模塊才會出現結構性的變動。

以上。

本文由 @耳目不染 原創發布于人人都是產品經理。未經許可，禁止轉載。

題圖來自Unsplash，基于CC0協議