起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識6000字長文：SaaS從0到1，案例實操系列（二）
編輯導讀：隨著互聯網的發展，關于SaaS產品的討論越來越多，作為一個優秀的SaaS產品經理，應該具備哪些能力呢？本文作者通過剖析SaaS從0到1的案例實操，向我們分享了一些經驗，一起來看看吧。
在上一篇《SaaS從0到1，案例實操系列（一）》中，我們講到SaaS產品經理小張接到客戶的需求，經過分析，他意識到這是公司實現“第二次增長”的好機會。于是他趕緊讓銷售負責人和客戶約定了拜訪時間。
SaaS從0到1系列，全景圖
01 需求梳理-策略層
小張知道，第一次拜訪客戶，最要緊的并不是搞清楚所有需求細節。而是明確客戶需求的范圍，以及客戶的業務策略，從而確認產品研發的范圍，以及 “標準化交付”的難度。
在需求篩選階段，小張已經明確了快消品行業的主要分銷模式（業務策略），并判斷公司有能力通過標準化產品進行滿足。因此，小張的策略是將客戶的分銷模式與行業分銷模式進行匹配，從而將調研重心放在客戶的個性化需求上。
客戶的一位渠道經理接待了小張。他認為自己的需求很簡單：業務人員在手機端錄入銷售訂單，再傳送到ERP系統安排發貨即可。因此，小張公司只需要提供一個手機錄入端口，再打通客戶已有的ERP系統。如下圖：
客戶的需求
一直以來，小張的需求調研原則都是：永遠要相信客戶“存在一個需求”，但是永遠不要相信客戶“搞清楚了自己的需求”。
于是，他在黑板上畫出了分銷管理概要流程，然后按照流程環節逐個與客戶進行梳理，如下圖：
概要流程
梳理的主線，是銷售訂單流程：從拜訪客戶到訂單交付。
通過主線流程，再牽引出支線流程。
比如：要管理“業務員拜訪門店”，就必須進行門店（客戶）管理和業務員管理；要支持“錄入訂單”，就必須管理“商品”和“價格”。
小張之所以先畫“概要流程”，是因為調研的第一要務，是首先確保不遺漏重要流程和板塊。
小張很快發現，該廠家對于區域連鎖賣場等大客戶，采取的是廠家業務員拜訪、工廠直接發貨的KA直銷模式：
KA直銷模式
對于非連鎖便利店等小客戶，采取的是廠家業務員拜訪、經銷商發貨的深度分銷模式：
深度分銷模式
因此，客戶實際上有兩種不同的銷售流程，如下圖：
而且，客戶是希望把兩種銷售流程都管理起來。因此，要滿足客戶需求，遠非“支持錄入訂單并傳送ERP”就可以的，而是必須對商品、門店、經銷商、價目表等基礎數據，以及庫存現有量、發貨、收貨、收款與對賬等業務流程和數據進行全面管理。
另外，在“深度分銷”場景下，由于發貨和收款都由經銷商負責，并不需要對接廠商ERP，而且收款與對賬流程也和“KA直銷”場景不同。因此，兩個場景需要分別設計產品功能。
明確了業務范圍、業務策略和主要流程，小張更有信心了。經過第一次會面，客戶也對小張的專業能力很認可，并當場表達了盡快合作的意愿。
02 需求梳理-業務層
上一次與客戶見面為商務談判打下了很好的基礎。不久，小張就收到了區域銷售負責人的好消息：已經和客戶簽訂了合同，可以進場調研了。
在傳統軟件時代，研發團隊都是駐扎在客戶現場，用戶還可能脫產專職投入項目，這就使得需求調研的難度大大降低。
但小張公司并非項目制公司，研發團隊都在總部辦公，因此小張需要在客戶現場把問題都搞清楚，然后再回來轉達給研發團隊。這就對小張提出了更高的要求。
為了提高調研效率，小張首先梳理了調研提綱：
調研提綱
接下來，就是按照提綱完成調研工作。
1. 明確業務重難點和用戶期望
小張明白，SaaS產品也符合2/8原則：20%的功能，將決定客戶80%的口碑。
從產品設計角度來說，基本需求的實現只能防止客戶“不滿意”。但如果要讓客戶“滿意”甚至“超出預期的滿意”，就必須解決業務重難點問題。
隨著數字化時代的到來，一線用戶的意見，對企業軟件采購決策的影響越來越大。因此，小張也需要收集一線用戶的期望。
經過和客戶溝通，小張了解到，客戶之前已經耗費上百萬實施了某國際知名品牌的CRM系統，但是移動端的用戶體驗非常糟糕。除了使用上不夠高可用，需要反復培訓才能上手；低下的操作效率和緩慢的響應速度，更是使得系統的推廣困難重重。
其實，該客戶為什么選擇小張所在的公司，就是在體驗了他們的移動端產品后，認為產品的用戶體驗非常好，可以解決當前系統推廣的最大難題。
這也正好印證了小張之前的判斷：公司的核心資源和能力，較好的匹配了新領域的需求。這次新產品的開拓，很可能會成就公司的第二增長曲線。（具體內容請參考本系列第一篇文章）
2. 了解組織架構
如果把企業比喻成一個人，組織架構就是人的骨骼，業務流程就是人的血肉。骨骼不復，血肉焉存？
組織架構從根本上決定了業務流程，也決定了業務數據的安全性策略。
比如，如果公司按照產品線劃分銷售事業部，那么銷售事業部往往會具有較為自主的權力。與此同時，事業部和事業部之間的業務數據也是相互屏蔽的，避免不必要的信息泄露以及過度內部競爭。
因此，在調研業務流程之前，小張必須首先搞清楚客戶的組織架構，并繪制出組織架構圖。
組織架構示意圖
在查看相關資料并確認后，小張繪制出以上組織架構圖。為了方便理解，小張去掉了和本次項目范圍關系不大的職能部門，比如總部HR部門等。并對需要重點關注的部門，標注了星號。
1）總部-銷售管理部
總部銷售管理部門是本次項目的主導部門，也是各分公司銷售管理的規則制定部門。
銷售管理部的職責，主要是探索分銷管理最佳實踐，并通過管理制度、SOP和管理軟件等手段，將最佳實踐推廣到各分公司。
為了保證執行到位，銷售管理部還被賦予了考核分公司總經理的權力。
2）總部-IT部
總部IT部門是本次項目的協助部門，也是客戶ERP系統的管理部門。
IT部的職責，主要是負責運維和升級ERP系統，小張公司研發的SaaS系統要打通客戶ERP系統，就必須得到IT部的支持。
3）分公司-銷售部
分公司銷售部是本次項目的執行部門，也是負責客戶具體銷售業務和銷售人員管理的部門。
銷售部的職責，主要是負責銷售人員的招募和管理，并通過拜訪門店和管理經銷商，最終達成公司的業績目標。
銷售部也是本次項目成敗的關鍵——他們對系統的使用情況，決定了項目能否成功落地。
4）分公司-物流部
分公司物流部是本次項目的執行部門，也是負責倉庫管理、物流配送的部門。
物流部的職責，主要是根據銷售人員傳回的訂單，按時按量進行貨物的配送。
3. 梳理業務流程
由于小張已經和客戶確認了整體業務流程（詳見本系列第一篇），因此只需要補充詳細業務流程。要了解詳細業務流程，小張必須進行更為細致的調研。
具體又分為辦公室調研和一線調研。
1）辦公室調研
辦公室調研主要目的是梳理業務邏輯，需要明確以下幾項內容：
* 重點業務說明
主要是流程圖無法清晰表述的業務規則等內容。
小張調研了價格管理規則，他了解到，客戶的價格管理主要是由基本價目表和促銷活動兩個部分組成。
由于不同地區的競爭程度不同，價目表需要按地區進行配置，即不同地區（對經銷商和零售店）的售價可能是不同的。
而促銷則是在價目表的基礎上，鼓勵經銷商和零售店進貨的策略性手段。比如，“買3送1（杯子）”的促銷活動，就是鼓勵一次性采購3箱或以上——每3箱將免費送1個杯子。這對于利潤微薄的經銷商和零售店來說，具有很強的吸引力。同時也不會造成低價商品，從而擾亂平常價格秩序。
* 流程圖
流程圖是調研文檔的核心組成部分。通過“什么崗位”和“負責什么操作”這兩個維度，流程圖可以直觀反映業務處理過程，避免梳理出現錯漏。
雖然只是調研階段的流程圖，但是小張仍然很重視，他針對所有細分流程繪制了流程圖，并對每個步驟做了說明，示例如下：
* 重難點
雖然業務層調研的第一步已經明確了業務重難點和用戶期望。但是在梳理具體流程時，用戶可能會提出更多細節問題。
這些問題應該仔細記錄下來，并在方案設計時妥善處理。否則，在系統上線后，小問題可能會演變成大問題，最終需要耗費更多資源去解決。
在調研時，客戶提出，雖然大部分業務員都能夠遵守規則，但是有極少數業務員會存在弄虛作假的行為。
比如，整理貨架以后，企業希望業務員能對整理后的貨架進行拍照，并上傳到公司服務器。這樣，公司督導人員就可以通過查看照片，判斷業務員的工作質量，并對操作不規范的業務員進行督導和培訓。
但在實際工作中，極少數業務員并沒有對貨架進行規范整理，而是通過調取手機圖片、甚至對著圖片拍照的方式，企圖蒙混過關。
企業為了杜絕這種作弊行為，不得不組織人手對圖片進行檢查，不但工作量很大，而且也存在錯漏的風險。
小張一邊詳細記錄下這些重難點，一邊思考解決方案。
2）一線調研
在傳統軟件時代，大部分系統操作都在PC端，企業對用戶體驗也不夠關注，因此，需求調研主要都在辦公室進行。
在SaaS時代，移動端操作的比重越來越高，企業對用戶體驗也越來越關注，因此，除了辦公室調研，往往還需要在一線現場調研。
考慮到一線調研的時間成本相對較高，因此小張按角色安排了調研計劃，如下：
- 業務員：門店拜訪場景
- 經銷商：采購、發貨與收款場景
- 門店：收貨與付款場景
考慮到業務員是SaaS產品的主要用戶——人員數量多、操作頻次高、體驗要求高，小張特意安排了一天時間，跟隨一位業務員完成一天作業。具體安排示例如下：
在調研過程中，為了不影響業務員的工作，小張盡量作為觀察者，觀察和記錄業務員的行為，以及他所面臨的問題。
在午休時，小張主動請業務員吃了個便飯，一來拉近了關系，二來也順便詢問了很多現場作業的細節。
當然，只進行一次調研未必足夠。因為這種“靜默式調研”主要是了解“現狀”，但并不能明確客戶的“期望”。
比如，客戶希望業務員在拜訪門店時，對門店庫存進行盤點。但是在實際工作中，業務員未必會按規范操作。
因此，有必要拉上業務員的主管人員或者優秀業務員，到現場進行“講解式調研”。即由主管人員告訴我們，規范的操作應該是怎樣的。理論上，我們應該按照可落地的、規范的操作進行產品設計。
當我們按計劃完成了所有辦公室調研和一線調研，并形成調研文檔，還需要和客戶進行確認。切記，任何問題在調研階段被發現，糾正的成本都是最低的。因此，我們應該盡可能多調研、多和客戶溝通。
另外，值得一提的是，在業務調研時，我們也要注意核對調研的范圍是否完整。
比如，由于客戶采用了KA直銷和深度分銷兩種模式，因此小張在制定調研計劃時，就針對兩種模式分別制定了調研計劃。
3. 管理報表
管理報表是企業管理軟件的核心組成部分，同時，考慮到大部分關鍵業務數據最終都會以報表的形式呈現，因此，盡早進行管理報表調研，也可以反向驗證我們是否遺漏了重要流程和業務邏輯。
在業務流程調研的同時，小張找客戶要了相關報表的樣表，并逐一進行了分析和溝通。
其中有一張銷售業績報表引起了小張的注意。
示例（字段和數據均屬虛構）
報表本身很普通，但客戶提出，存在以下情況：
1）銷售人員會在部門間調動。
比如張三去年在B組，今年調動到A組。
2）A、B組所負責的銷售區域，每年都可能調整。
比如2020年A組負責abc三個區域，2021年可能負責abef四個區域。區域覆蓋的商圈范圍可能也會調整。
因此，當需要比較A組2020年與2021年的業績時，由于A組的組織架構、負責區域和銷售人員都在變動，2020年的“A組”和2021年“A組”，就失去了可比性。
但是，為了考核“A組”的績效，與去年業績進行同期對比是必要的。權衡之下，客戶認為，相對于區域，人員在部門間的調動影響較小。因此，決定按“A組所包含的人員”進行往年同期對比。
比如，A組有張三、李四、王五三位銷售人員，就將這三位銷售人員2020年的銷售業績之和，作為A組2020年的銷售業績，并與A組2021年的銷售業績進行對比。
這樣的對比毫無疑問存在偏差。
比如張三去年實際是在B組，他去年的銷售業績，根本不應該歸屬于A組。但是客戶認為這種誤差是相對可控的，因此5年來，一直采用這個邏輯。
小張知道，這個邏輯涉及到部門業績的核算，雖然誤差“可能”不大，但由此可能導致的一線部門抱怨甚至糾紛，將給企業管理帶來很大隱患。
同時，萬一客戶后期又發現更好的方案，就意味著報表的底層邏輯要大改，那么無疑將會造成巨大的研發浪費。
考慮到這些，雖然客戶一再強調“按照原有邏輯處理就好”，小張仍然決定從底層重新思考報表的邏輯。
小張認為，深度分銷的基本邏輯，是將客戶劃片（比如按商圈劃片），再將商圈組成區域，分配給銷售小組進行覆蓋。而這個邏輯的基礎，則是客戶（夫妻老婆店）是相對穩定的。雖然也會存在客戶從a商圈搬遷到b商圈，但是這種情況發生的概率極其低。
因此，小張認為，相對于部門和銷售人員，客戶才是最穩定的。如果將客戶所屬的商圈，作為對比的依據，就可以更多準確的判斷“A部門”在今年的銷售業績，究竟比去年更好還是更差。
比如，A部門今年負責了10個商圈，我們只需要找到這10個商圈在去年的銷售數據，就可以判斷A部門今年的表現情況了。
這種邏輯，在A部門組織架構、負責區域和銷售人員都存在較大變動的情況下，應該是最合適，也最符合深度分銷邏輯的。
心里有底了，小張決定和總部銷售管理部的負責人，也是本次項目的負責人，好好談一談。小張知道，要說服客戶并不容易，因為他們是快消品行業最頂尖的企業，一直都是他們指導供應商，從來沒有供應商“指導”過他們的。
4. 系統集成
大企業往往存在多套“現有系統”，而它們也可能影響到新的SaaS系統的設計和部署。比如：
1）現有系統將被新SaaS系統替代
2）現有系統將與新SaaS系統集成
小張詳細詢問了用戶對現有分銷管理系統的評價，他發現，用戶對現有系統的反應遲緩、操作復雜怨氣很大。毫無疑問，用戶體驗將是這次設計的重點，因為用戶一定會將新SaaS系統與現有系統進行對比。
小張也詳細了解了需要與新SaaS系統集成的系統，其中最重要的是Oracle ERP系統。小張明白，了解集成系統的業務流程和表結構非常重要，否則在集成的時候，流程或者數據接口就會出現問題。
在小張公司原有的SaaS系統中，允許一個訂單行的商品存在多個單位（比如3箱8瓶）。系統按照“錄入單位”進行數據存儲：比如銷售3箱8瓶A商品，雖然6瓶等于1箱，但是仍然按照3箱和8瓶存儲在一個訂單行，而不會進行換算，也不會拆分為兩行。
這樣處理主要是便于經銷商核對實物，即：8瓶和1箱2瓶在實物上是不同的。自動換算或者拆行，都可能影響用戶體驗。
但是，在客戶的Oracle ERP系統中，一個訂單行就只有1個單位。而且，不管訂單行錄入什么單位，最終都要換算成“基本單位”進行存儲（也會保留錄入的單位）。比如錄入了60瓶，系統也會換算為10箱（6瓶等于1箱），并根據10箱進行后續的供應鏈和核算處理。
小張意識到，新的SaaS系統也有必要引入“基本單位”的概念，并對訂單行進行單位換算和存儲，否則和Oracle ERP的集成將會遇到麻煩。
5. 后記
經過一周的調研，小張認為已經對客戶的相關業務和系統有了較為全面、深入的認識。于是，他提前約了客戶的項目負責人，將梳理的調研文檔與客戶進行了逐一溝通，并對其中的一些細節問題進行了補充和糾正。
和傳統軟件項目不同，小張并沒有要求客戶對文檔進行簽字確認。小張知道，在SaaS項目中，產品經理需要承擔起更多的責任——因為這個項目最重要的意義，并不在于服務好某一個特定的客戶。而是在于打造一個真正優秀的SaaS產品，從而服務千千萬萬的客戶。
本篇完。下一篇，我們接著講SaaS產品的整體方案如何編制。
#專欄作家#
王戴明，微信公眾號：To B老人家，人人都是產品經理專欄作家，多年互聯網產品與信息化管理經驗。
本文原創發布于人人都是產品經理，未經許可，禁止轉載
題圖來自 Unsplash，基于 CC0 協議
非常棒！