編輯導語：作為供應鏈產品經理，在面對一個業(yè)務需求時，往往會有多種不同高度的產品解決方案，此時便需要結合具體業(yè)務來決定需要哪種方案。本文作者詳細拆解了供應鏈ERP中的一個需求分析與實現(xiàn)的過程，來分析如何解決這類問題，希望能給你帶來啟發(fā)。

一、業(yè)務場景

在多年的B端ERP SAAS產品經理工作中，“供應鏈產品老兵”發(fā)現(xiàn)面對一個業(yè)務需求，通常會有多種不同抽象高度的產品解決方案，而這每一種方案都無對錯，都存在著一定的優(yōu)勢和劣勢，供應鏈產品經理只是需要結合具體業(yè)務、系統(tǒng)架構和開發(fā)資源來抉擇具體哪種方案。

那么接下來我將詳細拆解供應鏈ERP中的一個需求分析與實現(xiàn)的過程，以此來啟發(fā)讀者對ERP SAAS系統(tǒng)產品設計的領悟出“通過標準化的產品方案解決一類問題而不是一個問題”。

在ERP SAAS系統(tǒng)中一般都有一個菜單“倉庫庫存批次列表”，這其實是一個查詢“商品編碼+批次號+庫存數(shù)量”的功能，關鍵用戶是采購、倉庫管理員、財務。

有一天采購員小佩給產品經理阿華提出了一個需求：我經常使用“倉庫庫存批次列表”查數(shù)據，但我不需要查詢“庫存數(shù)量=0”的數(shù)據行，這些“庫存數(shù)量=0”的數(shù)據行嚴重影響了我的查詢效率，麻煩你幫我去掉。

二、產品方案

方案A

產品經理阿華是一個很實誠的人，他的思維基本就是“用戶讓我干啥我就干啥”，于是他非常高效地寫下一個產品需求“倉庫庫存批次列表中把庫存數(shù)量=0的數(shù)據在數(shù)據庫中刪除”。

1）優(yōu)勢分析

前端開發(fā)無開發(fā)量，后端開發(fā)只需要執(zhí)行一行簡單的delete SQL語句就行。

2）劣勢分析

其它頁面需要展現(xiàn)這種庫存數(shù)量為0的數(shù)據就獲取不到了，比如報損報溢單-報溢。這就是典型的用戶提出一個業(yè)務場景時，產品經理就只想到這一個業(yè)務場景，且不怎么思考分析就執(zhí)行用戶的需求。

供應鏈產品老兵覺得阿華同學這種“用戶提啥就做啥”的產品經理工作方式，容易讓外界認為“產品經理就是一個把需求方的需求轉化成原型的中轉站而已，即產品經理就是畫原型的”，如果是畢業(yè)2年以內的無可厚非，如果是2年以上就需要沉靜下來，實事求是多熟悉業(yè)務、多思考了。

方案B

與方案A的區(qū)別是，阿華此時知道“報損報溢單-報溢 ，需要使用庫存數(shù)量為0的數(shù)據”，于是他寫下一個產品需求“倉庫庫存批次列表中 不展示庫存數(shù)量為0的數(shù)據行”。

1）優(yōu)勢分析

后端開發(fā)無開發(fā)量，前端開發(fā)寫死過濾掉庫存數(shù)量為0的數(shù)據也很簡單，也能滿足小佩這個用戶的需求。

2）劣勢分析

其實還有一種用戶或客戶喜歡在倉庫庫存批次列表中查詢“某商品編碼，如果查無數(shù)據就表示未購進過；如果查出來的庫存數(shù)量=0就表示購進過 ”。

方案B直接把庫存數(shù)量為0的數(shù)據過濾掉了查不出來，那讓這類用戶豈不是很不滿意，這其實是解決了一個問題又制造了一個問題，做SAAS是不能這樣同一個功能讓一部分客戶滿意讓一部分客戶不滿意的，要大家都滿意才是一個標準化的功能。

供應鏈產品老兵覺著阿華同學這種“對于用戶提出的一個問題，只想到這一個用戶的問題，不去想其它用戶對此關聯(lián)的問題”的產品經理工作方式，容易導致解決一個問題又制造了若干問題。

如果需要突破這種局面還是需要沉靜下來全面熟悉業(yè)務場景，這樣就少了一點拍腦袋了。

方案C

阿華同學通過業(yè)務調研發(fā)現(xiàn)”要不要查詢庫存數(shù)量為0的數(shù)據“是一個通用的問題，而且有些用戶要查有些用戶不查，于是果斷寫下一個產品需求“查詢條件新增一個勾選框，即是否查庫存數(shù)量為0的數(shù)據”。

1）優(yōu)勢分析

解決了查庫存數(shù)量為0和不查0這2個問題，對別的業(yè)務場景不構成傷害，且查不查由用戶選擇，開發(fā)量也很小。

2）劣勢分析

沒有解決某個用戶要查“庫存數(shù)量 >100”或“可用數(shù)量>0”這類問題，也就是沒有解決一類共同的問題，導致相似問題后續(xù)又需要用戶提需求，不符合做SAAS產品需求是要“用標準化方案解決一類問題”的原則。

供應鏈產品老兵覺著“阿華同學”此時已經初步具有了從一個問題挖掘一類問題的能力，但是其挖掘的深度與廣度還可加強。

方案D

阿華同學在想既然不能刪數(shù)據庫的數(shù)據（方案A），又不能在這個頁面寫死不查庫存數(shù)量為0的數(shù)據（方案B），那我就做一個參數(shù)控制“要不要查庫存數(shù)量為0的數(shù)據”，這個參數(shù)控制做到“客戶+角色”的維度。由于每一個賬號是關聯(lián)角色的，那么每一個用戶進入這個“倉庫庫存批次列表”都會根據參數(shù)配置來判斷能不能查庫存數(shù)量為0的數(shù)據。

1）優(yōu)勢分析

解決了這一個問題不同用戶不同的訴求（查0或不查0），且參數(shù)配置好后用戶體驗上沒有感知，進入頁面后由參數(shù)來判斷，用戶只管查詢數(shù)據就行。

2）劣勢分析

在業(yè)務場景分析這塊思維還是沒有跳出通過一個問題發(fā)現(xiàn)一類問題，即還是在研究“用戶要不要查庫存數(shù)量為0”這個問題，“庫存數(shù)量 >100或1000”、“預留數(shù)量>100或1000”這一類問題沒有去一起分析。

性能方面比較差，比如用戶進入這個頁面查詢時，前端會帶著搜索條件和參數(shù)的接口去請求后端查詢接口，如果這期間參數(shù)的接口報錯那么就會導致查詢失敗，也就是說這個查詢頁面太依賴其它模塊的接口了，這數(shù)據量一旦大起來就會造成性能不好。

供應鏈產品老兵建議“阿華同學”在工作中要多與開發(fā)溝通，了解一些前后端交互的技術常識，這樣在產品方案設計階段就能融合技術方案以保障產品方案的可落地。

所謂的產品經理學技術不是比登天還難的事，不是要去敲代碼，只需要平常在與開發(fā)溝通中要擅于總結、以求知之心多向開發(fā)請教其實幾年下來也是算半個開發(fā)了，記得工作中的開發(fā)是產品經理最好的技術老師而不是某本書某個課程。

方案E

阿華同學通過對多個用戶調研，發(fā)現(xiàn)除了“要求庫存數(shù)量大于0要不要查詢”這一個業(yè)務場景以外，還有以下業(yè)務場景：

1. 查“庫存數(shù)量>100或1000或10000”
2. 查“可用數(shù)量>100或1000或10000”
3. 其它查詢列表的數(shù)字類字段也有類似上述1、2的場景

于是在綜合考慮這一類場景問題，按照SAAS產品設計的原則抽象出標準化的解決方案，即每一個數(shù)字類、金額類字段都做一個按大小搜索的小彈窗，如下圖所示：

1）優(yōu)勢分析

到了這個階段 阿華同學已經具有了通過用戶提出的一個問題發(fā)現(xiàn)一類問題的業(yè)務診斷能力，也具備了抽象出一套標準化方案解決一類問題的能力。

不但解決了“倉庫庫存批次列表”的數(shù)字類字段查詢問題，還解決了其它所有列表數(shù)字類字段查詢的問題。

2）劣勢分析

用戶每次進入查詢頁面需要去點擊“庫存數(shù)量”然后輸入最小值操作才行，這樣具有一定的刻意性，體驗不是很好。還有就是沒有解決類似“查詢庫存數(shù)量>0且預留數(shù)量大于0”這樣的問題。

供應鏈產品老兵覺著此時的“阿華同學”已經初步具備了用標準化方案解決一類問題的能力，但這個一類問題梳理的還不夠全面，所謂以點帶面看到的還只是正方體的4個面還有2個面未曾看到。

方案F

怎樣既能用標準化方案解決一類場景，還能讓用戶在體驗上不刻意為之呢，阿華同學綜合以上5種產品方案思考出第六種高度抽象的SAAS化解決方案，即由架構師去低代碼平臺中開發(fā)出篩選器功能，然后由用戶在頁面中自由配置，不需要各業(yè)務模塊的開發(fā)參與。

如果用戶要實現(xiàn)“查詢庫存數(shù)量>0且【預留數(shù)量 < 可用數(shù)量】”的需求，具體從用戶角度操作與交互如下：

1. 點擊“倉庫庫存批次列表”頁右上角的【篩選器】按鈕，彈出篩選器彈窗
2. 在篩選器彈窗左邊的篩選條件，點擊“庫存數(shù)量 右邊的+”，這樣右側新增一行，運算符選擇大于，值填寫0，關系（或且非）選擇“且”
3. 在篩選器彈窗左邊的篩選條件，點擊“預留數(shù)量 右邊的+”，這樣右側新增一行，運算符選擇小于，值選擇“可用數(shù)量”，關系（或且非）選擇“且”

補充說明

如果用戶進來偶爾按不同條件來搜索查詢，且條件具有個性化，那么按照以上篩選器配置后點擊【搜索】就可以按已設置的條件去查詢過濾數(shù)據，不需要存模板。

如果用戶的查詢條件僅對他自己具有一定的通用性，比如查“查詢庫存數(shù)量>0 且 【預留數(shù)量 < 可用數(shù)量”，那么在上面篩選器的配置中配置完成后點擊底部的【存模板】這樣就會把這個篩選器保存為一個模板，從而每次進入到這個頁面可以在列表頁右側的【模板】按鈕中選擇自己的模板列表按需查詢，就不用每次進來都配置篩選器了。

如果用戶的查詢條件對同客戶的所有用戶都具有一定的通用性，那么在上面篩選器的配置中勾選“是否設為公用模板”然后存模板就行，這樣就同一家客戶所有用戶都可以使用此模板了。

如果用戶需要每次進入這個頁面就調用某個默認的模板來查詢，那么在上面篩選器配置中勾選“是否設為默認模板”就行。

1）優(yōu)勢分析

用可配置的標準化方案一次性解決了所有列表或報表的查詢場景，不需要用戶反復多次提需求，用戶暫時沒想到的業(yè)務場景阿華同學也想到了，具有較完善的SAAS產品經理業(yè)務診斷能力與高度抽象的產品方案設計能力。

2）劣勢分析

開發(fā)成本較高，如果沒有類似低代碼平臺恐怕難以開發(fā)出來；用戶不怎么會操作，后期培訓成本較高。

供應鏈產品老兵認為此時“阿華同學”已經具備了比較完善的供應鏈業(yè)務診斷能力與高度抽象的SAAS產品方案設計能力，但其用戶體驗設計的能力要加強，還需要考慮開發(fā)成本，畢竟很多互聯(lián)網公司是沒有低代碼平臺這類開發(fā)資源的。

三、供應鏈產品老兵總結

供應鏈占了B端的一大頭，而ERP系統(tǒng)常常是包含了供應鏈的所有模塊，比如商品、訂單、采購、倉儲、配送、庫存、財務、促銷等。如果只是做甲方自營的供應鏈ERP系統(tǒng)，那么對于產品經理大可不必要求“用標準化的解決方案解決一類問題”，因為如果這樣做 高度抽象出來的產品方案應用少且開發(fā)成本太高了。

如果是做乙方的ERP SAAS系統(tǒng)，這樣的ERP就不僅僅是一個工具屬性還是一個行業(yè)的完整解決方案，行業(yè)解決方案是需要多年的業(yè)務積累才能沉淀的。而且一個需求常常對應的就是一個解決方案，這樣的解決方案要眾口能調，即盡最大的力量讓所有客戶都滿意，這樣才是完整的整體行業(yè)解決方案。

但是是實際工作中 部分產品經理由于對業(yè)務場景不是很熟，對產品設計的抽象能力不夠 導致輸出的產品方案難以解決一類問題，從而讓不同用戶對同一類問題反復提需求，對系統(tǒng)就是相當于反復打補丁。

我是供應鏈產品老兵，做了供應鏈這塊的“ERP+SAAS+低代碼+wms”累計超過6年，我不擅于分享宏觀方法論和各種商業(yè)分析，只知道分析需求是怎樣做的，期望以需求實戰(zhàn)的內容分享來引導供應鏈產品經理特別是做SAAS的產品經理來逐步養(yǎng)成“用標準化的產品方案來解決一類問題的原則”，從而提升業(yè)務診斷能力和抽象思維。

作者：產品老兵，公眾號：供應鏈產品老兵

本文由 @供應鏈產品老兵 原創(chuàng)發(fā)布于人人都是產品經理。未經許可，禁止轉載。

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