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

一、業務場景

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

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

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

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

二、產品方案

方案A

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

1）優勢分析

前端開發無開發量，后端開發只需要執行一行簡單的delete SQL語句就行。

2）劣勢分析

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

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

方案B

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

1）優勢分析

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

2）劣勢分析

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

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

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

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

方案C

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

1）優勢分析

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

2）劣勢分析

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

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

方案D

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

1）優勢分析

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

2）劣勢分析

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

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

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

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

方案E

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

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

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

1）優勢分析

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

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

2）劣勢分析

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

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

方案F

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

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

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

補充說明

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

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

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

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

1）優勢分析

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

2）劣勢分析

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

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

三、供應鏈產品老兵總結

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

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

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

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

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

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

題圖來自Unsplash，基于CC0協議。