起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識SaaS從0到1，案例實操系列（三）
編輯導語：在掌握基本資料、對客戶需求等方面有了較為深刻的認知后，此時，SaaS產品設計人員就應當輸出相應的設計方案，推動后續的工作進展。那么要如何進行整體架構設計？本文作者便結合相關案例做了總結，一起來看一下。
在上一篇《SaaS從0到1，案例實操系列（二）》中我們講到，SaaS產品經理小張經過一周的調研，已經對客戶的相關業務和系統有了較為全面、深入的認識。接下來，小張需要制定產品方案，并形成原型設計，以便UI和開發同學能夠正式開展工作。
小張決定首先制作“整體方案”，他主要基于以下兩方面的考慮：
- 對于產品經理來說，整體方案是詳細方案的基礎；
- 對于客戶和其他同事來說，整體方案能幫助盡早發現整體架構層面的問題。
小張認為，整體方案應該包含以下幾個部分：
1）方案概要
說明由于產品的目標客戶明確，且有合同約束，因此方案概要說明主要是對客戶痛點進行簡單闡述，并說明產品方案如何解決客戶最關注的問題。
2）整體方案流程圖
通過整體方案流程圖，客戶可以“鳥瞰”整個產品方案，從而確認流程不存在錯漏。
3）應用架構設計
應用架構設計可以明確產品包含的模塊，以及模塊之間的關系。有利于產品經理和研發同學分工，也有利于和客戶對產品功能范圍初步達成一致。
4）多組織架構設計
由于客戶是年銷售額高達百億的集團型企業，對于數據權限管理，以及分公司之間、部門之間和經銷商之間的數據安全性有著很高的要求，因此有必要對多組織架構進行單獨設計和確認。
一、方案概要說明
由于產品已經有明確的客戶，小張在“方案概要說明”重點闡述了客戶的主要訴求，并且說明了我們將如何滿足客戶訴求。以下為重點內容節選：
1. 客戶主要訴求
XX企業為快消品行業知名品牌商，主要采取了以下分銷模式：
1）傳統批發模式：【具體說明略】。
2）KA直銷模式：【具體說明略】。
3）深度分銷模式：【具體說明略】。
在本次項目中，客戶期望對以上三種模式的分銷業務進行管理，并重點解決銷售人員外勤作業效率問題，以及銷售過程管理問題，主要包括：
1）銷售人員拜訪計劃自動生成
給銷售人員分配相應的拜訪路線、拜訪日期，并結合拜訪頻率等信息，自動生成合理的每日拜訪計劃。
【其他具體說明略】。
2. 重點方案說明
本次項目將提供商品管理、價格和促銷管理、門店管理、經銷商管理、銷售人員管理、拜訪管理、采購訂單管理、銷售訂單管理、物流管理等模塊，全面滿足客戶的各項訴求。
其中，拜訪管理將支持拜訪路線管理，并支持將路線分配給具體的銷售人員?？蛻粜畔⒅С职菰L頻率管理，可以根據所在商圈、客戶等級等信息，給不同客戶自動分配合理的拜訪頻率。最終，結合銷售人員的考勤安排等，系統將自動生成銷售人員每日拜訪計劃，并支持管理人員調整。
【其他具體說明略】。
二、整體方案流程圖
對于小張來說，整體方案流程圖除了確認整體方案的邏輯與范圍無誤，也是和其他同事溝通和分工的重要基礎。畢竟，產品經理最重要的工作之一，就是幫助團隊其他成員準確無誤的理解整個方案。
整體方案（1）：深度分銷
由于項目涉及業務較為復雜，整體方案流程圖分為了多個流程圖，以上是“深度分銷”模式下的整體流程圖。整體流程圖說明：
通過整體流程圖，我們能夠看到整個方案涵蓋了從采購、庫存到拜訪和銷售的整個核心業務，而且，使用系統的用戶，除了廠商-分公司銷售部的員工，還有經銷商的員工。
另外，根據流程圖：小張團隊的產品需要與客戶Oracle系統打通。這樣，負責采購模塊的產品經理以及開發團隊，就可以提前討論對接方案。
三、應用架構設計
整體方案流程圖更多是從業務視角來表述整體方案，但是小張還需要從研發視角來表述整體方案，這樣，大家才知道到底要改造哪些模塊，要新研發哪些模塊。
應用架構設計（示例）
由于公司已經有一套針對快消品行業的分銷SaaS系統，小張需要考慮哪些模塊應該復用，哪些模塊需要全新開發。
本著“能復用就復用，不能復用就新開發”的思路，小張分析了模塊復用的優劣勢。
1. 復用的優勢
- 可以充分利用原有資產，后續迭代也減少重復開發；
- 由于共用一套表結構，未來“面對經銷商的SaaS系統”與“面對廠商的SaaS系統”如果打通，那么打通的難度將大大降低。
2. 復用的劣勢
1）由于一個功能需要滿足更多不同類型客戶的需求，產品設計難度大大增加
2）不同類型客戶對功能有不同期望，多方兼顧的產品設計，可能影響用戶體驗
基于以上考慮，小張決定對“基礎模塊”盡量復用。
首先這些模塊都是低頻操作，用戶體驗問題相對不嚴重，產品設計難度也相對沒那么大。其次，考慮到未來如果兩個SaaS系統打通，共用基礎數據模塊肯定能大大降低打通的難度。
不過，由于原有SaaS系統的客戶主要是經銷商，并不需要單獨的“促銷管理”和“商圈管理”模塊，因此新的SaaS系統將新增這兩個模塊。
而“業務模塊”和“報表模塊”都是高頻操作，客戶對用戶體驗要求很高，如果復用以前模塊，很可能影響客戶工作，導致客戶投訴。而且由于“原有SaaS系統的目標客戶群體”的業務和“新SaaS系統的目標客戶群體”的業務差異很大，即便不考慮用戶體驗，整個產品設計的難度也將大大增加。
因此，小張計劃開發新的“業務模塊”和“報表模塊”。
而原有SaaS系統暫時不需要“集成模塊”，因此本次也將全新開發。
四、多組織架構設計
由于業務規模大、組織架構和數據權限較為復雜，客戶很擔心小張設計的系統能否滿足數據安全性方面的要求。
小張也明白，對于針對大型企業的SaaS產品，多組織架構是幾乎所有功能的基礎，一旦設計出現疏漏，后期改造的代價就會很大。
慎重思考后，小張決定把組織分為三類。
1. 總部組織
比如總部銷售管理部、IT部。這一類組織并不涉及實際的業務管理，但是他們需要全局權限。
2. 內部業務組織
比如上海分公司。這一類組織負責具體的業務，并且他們擁有自身組織的數據權限。比如銷售部同事需要查看到所有歸屬于上海分公司的銷售訂單數據，物流部同事需要查看到所有歸屬于上海分公司的待發貨和已發貨數據。
3. 外部業務組織
比如上海分公司負責某商圈配送的經銷商。這一類組織負責具體的業務，他們也擁有自身組織的數據權限。比如A經銷商負責A商圈，那么A商圈的門店信息、訂單信息和物流信息等，A經銷商都需要查看。
外部業務組織比較特別的地方在于，歸屬于外部業務組織的賬號，將被判定為外部賬號，只能申請或分配特定功能，比如“經銷商-采購申請”功能等。同時，外部業務組織必須掛靠在內部業務組織下面，并且該內部業務組織將共享他的所有數據權限。
小張決定，抽象出“利潤中心”的概念，所有的門店、價目表、經銷商和銷售訂單等數據，都必須歸屬于一個“利潤中心”。
這樣，如果某個員工被分配了某個“利潤中心”，他就擁有了歸屬于該“利潤中心”的所有門店、價目表、經銷商和銷售訂單等數據的權限。
再結合功能權限，比如物流部員工只分配物流相關功能，這樣，他們雖然有完整的數據權限，但是仍然看不到價目表等非物流信息。
當然，考慮到一個人可能會被分配多個“角色”。比如上海分公司的物流部員工張三，暫代了成都分公司的物流部經理?？梢园选袄麧欀行摹毕确峙浣o“角色”，再把多個“角色”分配給員工，如此，就能實現最復雜的數據權限需求。邏輯示意圖如下：
黃色方塊實際上起到了橋梁的作用，最終目的是將右邊的“業務數據權限”，正確分配給左邊的“員工”賬號。
關于多組織架構，大家也可以閱讀我的原創《B端大PM必備：多組織架構設計》。
五、后記
完成整體方案后，小張首先組織團隊的產品經理和核心研發人員進行了討論，大家達成一致后，小張約了客戶的項目負責人，將整體方案和客戶進行了溝通確認。
小張明白，應該抓住一切機會多和客戶溝通。一方面，產品經理需要通過溝通去發現問題；另一方面，客戶也需要通過產品經理的引導，對產品方案能否支撐業務，以及是否滿足項目期望進行確認。
本篇完。下一篇，我們接著講SaaS產品的詳細方案如何編制。
#專欄作家#
王戴明，微信公眾號：To B老人家，人人都是產品經理專欄作家，多年互聯網產品與信息化管理經驗。
本文原創發布于人人都是產品經理，未經許可，禁止轉載
題圖來自 Unsplash，基于 CC0 協議
催更下一篇
催更下一篇
????