編輯導語: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協議