編輯導語：作為供應鍊産品經理，在面對一個業務需求時，往往會有多種不同高度的産品解決方案，此時便需要結合具體業務來決定需要哪種方案。本文作者詳細拆解了供應鍊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協議。

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部