編輯導(dǎo)讀：隨著互聯(lián)網(wǎng)的發(fā)展，關(guān)于SaaS產(chǎn)品的討論越來越多，作為一個優(yōu)秀的SaaS產(chǎn)品經(jīng)理，應(yīng)該具備哪些能力呢？本文作者通過剖析SaaS從0到1的案例實操，向我們分享了一些經(jīng)驗，一起來看看吧。

在上一篇《SaaS從0到1，案例實操系列（一）》中，我們講到SaaS產(chǎn)品經(jīng)理小張接到客戶的需求，經(jīng)過分析，他意識到這是公司實現(xiàn)“第二次增長”的好機會。于是他趕緊讓銷售負(fù)責(zé)人和客戶約定了拜訪時間。

SaaS從0到1系列，全景圖

01 需求梳理-策略層

小張知道，第一次拜訪客戶，最要緊的并不是搞清楚所有需求細(xì)節(jié)。而是明確客戶需求的范圍，以及客戶的業(yè)務(wù)策略，從而確認(rèn)產(chǎn)品研發(fā)的范圍，以及 “標(biāo)準(zhǔn)化交付”的難度。

在需求篩選階段，小張已經(jīng)明確了快消品行業(yè)的主要分銷模式（業(yè)務(wù)策略），并判斷公司有能力通過標(biāo)準(zhǔn)化產(chǎn)品進行滿足。因此，小張的策略是將客戶的分銷模式與行業(yè)分銷模式進行匹配，從而將調(diào)研重心放在客戶的個性化需求上。

客戶的一位渠道經(jīng)理接待了小張。他認(rèn)為自己的需求很簡單：業(yè)務(wù)人員在手機端錄入銷售訂單，再傳送到ERP系統(tǒng)安排發(fā)貨即可。因此，小張公司只需要提供一個手機錄入端口，再打通客戶已有的ERP系統(tǒng)。如下圖：

客戶的需求

一直以來，小張的需求調(diào)研原則都是：永遠(yuǎn)要相信客戶“存在一個需求”，但是永遠(yuǎn)不要相信客戶“搞清楚了自己的需求”。

于是，他在黑板上畫出了分銷管理概要流程，然后按照流程環(huán)節(jié)逐個與客戶進行梳理，如下圖：

概要流程

梳理的主線，是銷售訂單流程：從拜訪客戶到訂單交付。

通過主線流程，再牽引出支線流程。

比如：要管理“業(yè)務(wù)員拜訪門店”，就必須進行門店（客戶）管理和業(yè)務(wù)員管理；要支持“錄入訂單”，就必須管理“商品”和“價格”。

小張之所以先畫“概要流程”，是因為調(diào)研的第一要務(wù)，是首先確保不遺漏重要流程和板塊。

小張很快發(fā)現(xiàn)，該廠家對于區(qū)域連鎖賣場等大客戶，采取的是廠家業(yè)務(wù)員拜訪、工廠直接發(fā)貨的KA直銷模式：

KA直銷模式

對于非連鎖便利店等小客戶，采取的是廠家業(yè)務(wù)員拜訪、經(jīng)銷商發(fā)貨的深度分銷模式：

深度分銷模式

因此，客戶實際上有兩種不同的銷售流程，如下圖：

而且，客戶是希望把兩種銷售流程都管理起來。因此，要滿足客戶需求，遠(yuǎn)非“支持錄入訂單并傳送ERP”就可以的，而是必須對商品、門店、經(jīng)銷商、價目表等基礎(chǔ)數(shù)據(jù)，以及庫存現(xiàn)有量、發(fā)貨、收貨、收款與對賬等業(yè)務(wù)流程和數(shù)據(jù)進行全面管理。

另外，在“深度分銷”場景下，由于發(fā)貨和收款都由經(jīng)銷商負(fù)責(zé)，并不需要對接廠商ERP，而且收款與對賬流程也和“KA直銷”場景不同。因此，兩個場景需要分別設(shè)計產(chǎn)品功能。

明確了業(yè)務(wù)范圍、業(yè)務(wù)策略和主要流程，小張更有信心了。經(jīng)過第一次會面，客戶也對小張的專業(yè)能力很認(rèn)可，并當(dāng)場表達了盡快合作的意愿。

02 需求梳理-業(yè)務(wù)層

上一次與客戶見面為商務(wù)談判打下了很好的基礎(chǔ)。不久，小張就收到了區(qū)域銷售負(fù)責(zé)人的好消息：已經(jīng)和客戶簽訂了合同，可以進場調(diào)研了。

在傳統(tǒng)軟件時代，研發(fā)團隊都是駐扎在客戶現(xiàn)場，用戶還可能脫產(chǎn)專職投入項目，這就使得需求調(diào)研的難度大大降低。

但小張公司并非項目制公司，研發(fā)團隊都在總部辦公，因此小張需要在客戶現(xiàn)場把問題都搞清楚，然后再回來轉(zhuǎn)達給研發(fā)團隊。這就對小張?zhí)岢隽烁叩囊蟆?/p>

為了提高調(diào)研效率，小張首先梳理了調(diào)研提綱：

調(diào)研提綱

接下來，就是按照提綱完成調(diào)研工作。

1. 明確業(yè)務(wù)重難點和用戶期望

小張明白，SaaS產(chǎn)品也符合2/8原則：20%的功能，將決定客戶80%的口碑。

從產(chǎn)品設(shè)計角度來說，基本需求的實現(xiàn)只能防止客戶“不滿意”。但如果要讓客戶“滿意”甚至“超出預(yù)期的滿意”，就必須解決業(yè)務(wù)重難點問題。

隨著數(shù)字化時代的到來，一線用戶的意見，對企業(yè)軟件采購決策的影響越來越大。因此，小張也需要收集一線用戶的期望。

經(jīng)過和客戶溝通，小張了解到，客戶之前已經(jīng)耗費上百萬實施了某國際知名品牌的CRM系統(tǒng)，但是移動端的用戶體驗非常糟糕。除了使用上不夠高可用，需要反復(fù)培訓(xùn)才能上手；低下的操作效率和緩慢的響應(yīng)速度，更是使得系統(tǒng)的推廣困難重重。

其實，該客戶為什么選擇小張所在的公司，就是在體驗了他們的移動端產(chǎn)品后，認(rèn)為產(chǎn)品的用戶體驗非常好，可以解決當(dāng)前系統(tǒng)推廣的最大難題。

這也正好印證了小張之前的判斷：公司的核心資源和能力，較好的匹配了新領(lǐng)域的需求。這次新產(chǎn)品的開拓，很可能會成就公司的第二增長曲線。（具體內(nèi)容請參考本系列第一篇文章）

2. 了解組織架構(gòu)

如果把企業(yè)比喻成一個人，組織架構(gòu)就是人的骨骼，業(yè)務(wù)流程就是人的血肉。骨骼不復(fù)，血肉焉存？

組織架構(gòu)從根本上決定了業(yè)務(wù)流程，也決定了業(yè)務(wù)數(shù)據(jù)的安全性策略。

比如，如果公司按照產(chǎn)品線劃分銷售事業(yè)部，那么銷售事業(yè)部往往會具有較為自主的權(quán)力。與此同時，事業(yè)部和事業(yè)部之間的業(yè)務(wù)數(shù)據(jù)也是相互屏蔽的，避免不必要的信息泄露以及過度內(nèi)部競爭。

因此，在調(diào)研業(yè)務(wù)流程之前，小張必須首先搞清楚客戶的組織架構(gòu)，并繪制出組織架構(gòu)圖。

組織架構(gòu)示意圖

在查看相關(guān)資料并確認(rèn)后，小張繪制出以上組織架構(gòu)圖。為了方便理解，小張去掉了和本次項目范圍關(guān)系不大的職能部門，比如總部HR部門等。并對需要重點關(guān)注的部門，標(biāo)注了星號。

1）總部-銷售管理部

總部銷售管理部門是本次項目的主導(dǎo)部門，也是各分公司銷售管理的規(guī)則制定部門。

銷售管理部的職責(zé)，主要是探索分銷管理最佳實踐，并通過管理制度、SOP和管理軟件等手段，將最佳實踐推廣到各分公司。

為了保證執(zhí)行到位，銷售管理部還被賦予了考核分公司總經(jīng)理的權(quán)力。

2）總部-IT部

總部IT部門是本次項目的協(xié)助部門，也是客戶ERP系統(tǒng)的管理部門。

IT部的職責(zé)，主要是負(fù)責(zé)運維和升級ERP系統(tǒng)，小張公司研發(fā)的SaaS系統(tǒng)要打通客戶ERP系統(tǒng)，就必須得到IT部的支持。

3）分公司-銷售部

分公司銷售部是本次項目的執(zhí)行部門，也是負(fù)責(zé)客戶具體銷售業(yè)務(wù)和銷售人員管理的部門。

銷售部的職責(zé)，主要是負(fù)責(zé)銷售人員的招募和管理，并通過拜訪門店和管理經(jīng)銷商，最終達成公司的業(yè)績目標(biāo)。

銷售部也是本次項目成敗的關(guān)鍵——他們對系統(tǒng)的使用情況，決定了項目能否成功落地。

4）分公司-物流部

分公司物流部是本次項目的執(zhí)行部門，也是負(fù)責(zé)倉庫管理、物流配送的部門。

物流部的職責(zé)，主要是根據(jù)銷售人員傳回的訂單，按時按量進行貨物的配送。

3. 梳理業(yè)務(wù)流程

由于小張已經(jīng)和客戶確認(rèn)了整體業(yè)務(wù)流程（詳見本系列第一篇），因此只需要補充詳細(xì)業(yè)務(wù)流程。要了解詳細(xì)業(yè)務(wù)流程，小張必須進行更為細(xì)致的調(diào)研。

具體又分為辦公室調(diào)研和一線調(diào)研。

1）辦公室調(diào)研

辦公室調(diào)研主要目的是梳理業(yè)務(wù)邏輯，需要明確以下幾項內(nèi)容：

* 重點業(yè)務(wù)說明

主要是流程圖無法清晰表述的業(yè)務(wù)規(guī)則等內(nèi)容。

小張調(diào)研了價格管理規(guī)則，他了解到，客戶的價格管理主要是由基本價目表和促銷活動兩個部分組成。

由于不同地區(qū)的競爭程度不同，價目表需要按地區(qū)進行配置，即不同地區(qū)（對經(jīng)銷商和零售店）的售價可能是不同的。

而促銷則是在價目表的基礎(chǔ)上，鼓勵經(jīng)銷商和零售店進貨的策略性手段。比如，“買3送1（杯子）”的促銷活動，就是鼓勵一次性采購3箱或以上——每3箱將免費送1個杯子。這對于利潤微薄的經(jīng)銷商和零售店來說，具有很強的吸引力。同時也不會造成低價商品，從而擾亂平常價格秩序。

* 流程圖

流程圖是調(diào)研文檔的核心組成部分。通過“什么崗位”和“負(fù)責(zé)什么操作”這兩個維度，流程圖可以直觀反映業(yè)務(wù)處理過程，避免梳理出現(xiàn)錯漏。

雖然只是調(diào)研階段的流程圖，但是小張仍然很重視，他針對所有細(xì)分流程繪制了流程圖，并對每個步驟做了說明，示例如下：

* 重難點

雖然業(yè)務(wù)層調(diào)研的第一步已經(jīng)明確了業(yè)務(wù)重難點和用戶期望。但是在梳理具體流程時，用戶可能會提出更多細(xì)節(jié)問題。

這些問題應(yīng)該仔細(xì)記錄下來，并在方案設(shè)計時妥善處理。否則，在系統(tǒng)上線后，小問題可能會演變成大問題，最終需要耗費更多資源去解決。

在調(diào)研時，客戶提出，雖然大部分業(yè)務(wù)員都能夠遵守規(guī)則，但是有極少數(shù)業(yè)務(wù)員會存在弄虛作假的行為。

比如，整理貨架以后，企業(yè)希望業(yè)務(wù)員能對整理后的貨架進行拍照，并上傳到公司服務(wù)器。這樣，公司督導(dǎo)人員就可以通過查看照片，判斷業(yè)務(wù)員的工作質(zhì)量，并對操作不規(guī)范的業(yè)務(wù)員進行督導(dǎo)和培訓(xùn)。

但在實際工作中，極少數(shù)業(yè)務(wù)員并沒有對貨架進行規(guī)范整理，而是通過調(diào)取手機圖片、甚至對著圖片拍照的方式，企圖蒙混過關(guān)。

企業(yè)為了杜絕這種作弊行為，不得不組織人手對圖片進行檢查，不但工作量很大，而且也存在錯漏的風(fēng)險。

小張一邊詳細(xì)記錄下這些重難點，一邊思考解決方案。

2）一線調(diào)研

在傳統(tǒng)軟件時代，大部分系統(tǒng)操作都在PC端，企業(yè)對用戶體驗也不夠關(guān)注，因此，需求調(diào)研主要都在辦公室進行。

在SaaS時代，移動端操作的比重越來越高，企業(yè)對用戶體驗也越來越關(guān)注，因此，除了辦公室調(diào)研，往往還需要在一線現(xiàn)場調(diào)研。

考慮到一線調(diào)研的時間成本相對較高，因此小張按角色安排了調(diào)研計劃，如下：

• 業(yè)務(wù)員：門店拜訪場景
• 經(jīng)銷商：采購、發(fā)貨與收款場景
• 門店：收貨與付款場景

考慮到業(yè)務(wù)員是SaaS產(chǎn)品的主要用戶——人員數(shù)量多、操作頻次高、體驗要求高，小張?zhí)匾獍才帕艘惶鞎r間，跟隨一位業(yè)務(wù)員完成一天作業(yè)。具體安排示例如下：

在調(diào)研過程中，為了不影響業(yè)務(wù)員的工作，小張盡量作為觀察者，觀察和記錄業(yè)務(wù)員的行為，以及他所面臨的問題。

在午休時，小張主動請業(yè)務(wù)員吃了個便飯，一來拉近了關(guān)系，二來也順便詢問了很多現(xiàn)場作業(yè)的細(xì)節(jié)。

當(dāng)然，只進行一次調(diào)研未必足夠。因為這種“靜默式調(diào)研”主要是了解“現(xiàn)狀”，但并不能明確客戶的“期望”。

比如，客戶希望業(yè)務(wù)員在拜訪門店時，對門店庫存進行盤點。但是在實際工作中，業(yè)務(wù)員未必會按規(guī)范操作。

因此，有必要拉上業(yè)務(wù)員的主管人員或者優(yōu)秀業(yè)務(wù)員，到現(xiàn)場進行“講解式調(diào)研”。即由主管人員告訴我們，規(guī)范的操作應(yīng)該是怎樣的。理論上，我們應(yīng)該按照可落地的、規(guī)范的操作進行產(chǎn)品設(shè)計。

當(dāng)我們按計劃完成了所有辦公室調(diào)研和一線調(diào)研，并形成調(diào)研文檔，還需要和客戶進行確認(rèn)。切記，任何問題在調(diào)研階段被發(fā)現(xiàn)，糾正的成本都是最低的。因此，我們應(yīng)該盡可能多調(diào)研、多和客戶溝通。

另外，值得一提的是，在業(yè)務(wù)調(diào)研時，我們也要注意核對調(diào)研的范圍是否完整。

比如，由于客戶采用了KA直銷和深度分銷兩種模式，因此小張在制定調(diào)研計劃時，就針對兩種模式分別制定了調(diào)研計劃。

3. 管理報表

管理報表是企業(yè)管理軟件的核心組成部分，同時，考慮到大部分關(guān)鍵業(yè)務(wù)數(shù)據(jù)最終都會以報表的形式呈現(xiàn)，因此，盡早進行管理報表調(diào)研，也可以反向驗證我們是否遺漏了重要流程和業(yè)務(wù)邏輯。

在業(yè)務(wù)流程調(diào)研的同時，小張找客戶要了相關(guān)報表的樣表，并逐一進行了分析和溝通。

其中有一張銷售業(yè)績報表引起了小張的注意。

示例（字段和數(shù)據(jù)均屬虛構(gòu)）

報表本身很普通，但客戶提出，存在以下情況：

1）銷售人員會在部門間調(diào)動。

比如張三去年在B組，今年調(diào)動到A組。

2）A、B組所負(fù)責(zé)的銷售區(qū)域，每年都可能調(diào)整。

比如2020年A組負(fù)責(zé)abc三個區(qū)域，2021年可能負(fù)責(zé)abef四個區(qū)域。區(qū)域覆蓋的商圈范圍可能也會調(diào)整。

因此，當(dāng)需要比較A組2020年與2021年的業(yè)績時，由于A組的組織架構(gòu)、負(fù)責(zé)區(qū)域和銷售人員都在變動，2020年的“A組”和2021年“A組”，就失去了可比性。

但是，為了考核“A組”的績效，與去年業(yè)績進行同期對比是必要的。權(quán)衡之下，客戶認(rèn)為，相對于區(qū)域，人員在部門間的調(diào)動影響較小。因此，決定按“A組所包含的人員”進行往年同期對比。

比如，A組有張三、李四、王五三位銷售人員，就將這三位銷售人員2020年的銷售業(yè)績之和，作為A組2020年的銷售業(yè)績，并與A組2021年的銷售業(yè)績進行對比。

這樣的對比毫無疑問存在偏差。

比如張三去年實際是在B組，他去年的銷售業(yè)績，根本不應(yīng)該歸屬于A組。但是客戶認(rèn)為這種誤差是相對可控的，因此5年來，一直采用這個邏輯。

小張知道，這個邏輯涉及到部門業(yè)績的核算，雖然誤差“可能”不大，但由此可能導(dǎo)致的一線部門抱怨甚至糾紛，將給企業(yè)管理帶來很大隱患。

同時，萬一客戶后期又發(fā)現(xiàn)更好的方案，就意味著報表的底層邏輯要大改，那么無疑將會造成巨大的研發(fā)浪費。

考慮到這些，雖然客戶一再強調(diào)“按照原有邏輯處理就好”，小張仍然決定從底層重新思考報表的邏輯。

小張認(rèn)為，深度分銷的基本邏輯，是將客戶劃片（比如按商圈劃片），再將商圈組成區(qū)域，分配給銷售小組進行覆蓋。而這個邏輯的基礎(chǔ)，則是客戶（夫妻老婆店）是相對穩(wěn)定的。雖然也會存在客戶從a商圈搬遷到b商圈，但是這種情況發(fā)生的概率極其低。

因此，小張認(rèn)為，相對于部門和銷售人員，客戶才是最穩(wěn)定的。如果將客戶所屬的商圈，作為對比的依據(jù)，就可以更多準(zhǔn)確的判斷“A部門”在今年的銷售業(yè)績，究竟比去年更好還是更差。

比如，A部門今年負(fù)責(zé)了10個商圈，我們只需要找到這10個商圈在去年的銷售數(shù)據(jù)，就可以判斷A部門今年的表現(xiàn)情況了。

這種邏輯，在A部門組織架構(gòu)、負(fù)責(zé)區(qū)域和銷售人員都存在較大變動的情況下，應(yīng)該是最合適，也最符合深度分銷邏輯的。

心里有底了，小張決定和總部銷售管理部的負(fù)責(zé)人，也是本次項目的負(fù)責(zé)人，好好談一談。小張知道，要說服客戶并不容易，因為他們是快消品行業(yè)最頂尖的企業(yè)，一直都是他們指導(dǎo)供應(yīng)商，從來沒有供應(yīng)商“指導(dǎo)”過他們的。

4. 系統(tǒng)集成

大企業(yè)往往存在多套“現(xiàn)有系統(tǒng)”，而它們也可能影響到新的SaaS系統(tǒng)的設(shè)計和部署。比如：

1）現(xiàn)有系統(tǒng)將被新SaaS系統(tǒng)替代

2）現(xiàn)有系統(tǒng)將與新SaaS系統(tǒng)集成

小張詳細(xì)詢問了用戶對現(xiàn)有分銷管理系統(tǒng)的評價，他發(fā)現(xiàn)，用戶對現(xiàn)有系統(tǒng)的反應(yīng)遲緩、操作復(fù)雜怨氣很大。毫無疑問，用戶體驗將是這次設(shè)計的重點，因為用戶一定會將新SaaS系統(tǒng)與現(xiàn)有系統(tǒng)進行對比。

小張也詳細(xì)了解了需要與新SaaS系統(tǒng)集成的系統(tǒng)，其中最重要的是Oracle ERP系統(tǒng)。小張明白，了解集成系統(tǒng)的業(yè)務(wù)流程和表結(jié)構(gòu)非常重要，否則在集成的時候，流程或者數(shù)據(jù)接口就會出現(xiàn)問題。

在小張公司原有的SaaS系統(tǒng)中，允許一個訂單行的商品存在多個單位（比如3箱8瓶）。系統(tǒng)按照“錄入單位”進行數(shù)據(jù)存儲：比如銷售3箱8瓶A商品，雖然6瓶等于1箱，但是仍然按照3箱和8瓶存儲在一個訂單行，而不會進行換算，也不會拆分為兩行。

這樣處理主要是便于經(jīng)銷商核對實物，即：8瓶和1箱2瓶在實物上是不同的。自動換算或者拆行，都可能影響用戶體驗。

但是，在客戶的Oracle ERP系統(tǒng)中，一個訂單行就只有1個單位。而且，不管訂單行錄入什么單位，最終都要換算成“基本單位”進行存儲（也會保留錄入的單位）。比如錄入了60瓶，系統(tǒng)也會換算為10箱（6瓶等于1箱），并根據(jù)10箱進行后續(xù)的供應(yīng)鏈和核算處理。

小張意識到，新的SaaS系統(tǒng)也有必要引入“基本單位”的概念，并對訂單行進行單位換算和存儲，否則和Oracle ERP的集成將會遇到麻煩。

5. 后記

經(jīng)過一周的調(diào)研，小張認(rèn)為已經(jīng)對客戶的相關(guān)業(yè)務(wù)和系統(tǒng)有了較為全面、深入的認(rèn)識。于是，他提前約了客戶的項目負(fù)責(zé)人，將梳理的調(diào)研文檔與客戶進行了逐一溝通，并對其中的一些細(xì)節(jié)問題進行了補充和糾正。

和傳統(tǒng)軟件項目不同，小張并沒有要求客戶對文檔進行簽字確認(rèn)。小張知道，在SaaS項目中，產(chǎn)品經(jīng)理需要承擔(dān)起更多的責(zé)任——因為這個項目最重要的意義，并不在于服務(wù)好某一個特定的客戶。而是在于打造一個真正優(yōu)秀的SaaS產(chǎn)品，從而服務(wù)千千萬萬的客戶。

本篇完。下一篇，我們接著講SaaS產(chǎn)品的整體方案如何編制。

#專欄作家#

王戴明，微信公眾號：To B老人家，人人都是產(chǎn)品經(jīng)理專欄作家，多年互聯(lián)網(wǎng)產(chǎn)品與信息化管理經(jīng)驗。

本文原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自 Unsplash，基于 CC0 協(xié)議