2023年供應(yīng)鏈產(chǎn)品經(jīng)理：拆解一個ERP SAAS需求給你

供應(yīng)鏈產(chǎn)品經(jīng)理：拆解一個ERPSAAS需求給你一、業(yè)務(wù)場景

在多年的B端ERPSAAS產(chǎn)品經(jīng)理工作中，“供應(yīng)鏈產(chǎn)品老兵”發(fā)覺面對一個業(yè)務(wù)需求，通常會有多種不同抽象高度的產(chǎn)品解決方案，而這每一種方案都無對錯，都存在著肯定的優(yōu)勢和劣勢，供應(yīng)鏈產(chǎn)品經(jīng)理只是需要結(jié)合詳細業(yè)務(wù)、系統(tǒng)架構(gòu)和開發(fā)資源來選擇詳細哪種方案。

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

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

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

二、產(chǎn)品方案

方案A

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

1）優(yōu)勢分析

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

2）劣勢分析

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

供應(yīng)鏈產(chǎn)品老兵覺得阿華同學(xué)這種“用戶提啥就做啥”的產(chǎn)品經(jīng)理工作方式，簡單讓外界認為“產(chǎn)品經(jīng)理就是一個把需求方的需求轉(zhuǎn)化成原型的中轉(zhuǎn)站而已，即產(chǎn)品經(jīng)理就是畫原型的”，假如是畢業(yè)2年以內(nèi)的無可厚非，假如是2年以上就需要沉靜下來，實事求是多熟識業(yè)務(wù)、多思索了。

方案B

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

1）優(yōu)勢分析

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

2）劣勢分析

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

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

供應(yīng)鏈產(chǎn)品老兵覺著阿華同學(xué)這種“對于用戶提出的一個問題，只想到這一個用戶的問題，不去想其它用戶對此關(guān)聯(lián)的問題”的產(chǎn)品經(jīng)理工作方式，簡單導(dǎo)致解決一個問題又制造了若干問題。

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

方案C

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

1）優(yōu)勢分析

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

2）劣勢分析

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

供應(yīng)鏈產(chǎn)品老兵覺著“阿華同學(xué)”此時已經(jīng)初步具有了從一個問題挖掘一類問題的力量，但是其挖掘的深度與廣度還可加強。

方案D

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

1）優(yōu)勢分析

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

2）劣勢分析

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

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

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

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

方案E

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

查“庫存數(shù)量100或1000或10000”查“可用數(shù)量100或1000或10000”其它查詢列表的數(shù)字類字段也有類似上述1、2的場景于是在綜合考慮這一類場景問題，根據(jù)SAAS產(chǎn)品設(shè)計的原則抽象出標準化的解決方案，即每一個數(shù)字類、金額類字段都做一個按大小搜尋的小彈窗，如下圖所示：

1）優(yōu)勢分析

到了這個階段阿華同學(xué)已經(jīng)具有了通過用戶提出的一個問題發(fā)覺一類問題的業(yè)務(wù)診斷力量，也具備了抽象出一套標準化方案解決一類問題的力量。

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

2）劣勢分析

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

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

方案F

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

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

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

假如用戶進來間或按不同條件來搜尋查詢，且條件具有共性化，那么根據(jù)以上篩選器配置后點擊【搜尋】就可以按已設(shè)置的條件去查詢過濾數(shù)據(jù)，不需要存模板。

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

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

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

1）優(yōu)勢分析

用可配置的標準化方案一次性解決了全部列表或報表的查詢場景，不需要用戶反復(fù)多次提需求，用戶臨時沒想到的業(yè)務(wù)場景阿華同學(xué)也想到了，具有較完善的SAAS產(chǎn)品經(jīng)理業(yè)務(wù)診斷力量與高度抽象的產(chǎn)品方案設(shè)計力量。

2）劣勢分析

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

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

三、供應(yīng)鏈產(chǎn)品老兵總結(jié)

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

假如是做乙方的ERPSAAS系統(tǒng)，這樣的ERP就不僅僅是一個工具屬性還是一個行業(yè)的完整解決方案，行業(yè)解決方案是需要多年的業(yè)務(wù)積累才能沉淀的。而且一個需求經(jīng)常對應(yīng)的就是一個解決方案，這樣的解決方案要眾口能調(diào)，即盡最大的力氣讓全部客戶都滿足，這樣才是完整的整體行業(yè)解決方案。

但是是實際工作中部分產(chǎn)品經(jīng)理由于對業(yè)務(wù)場景不是很熟，對產(chǎn)品設(shè)計的抽象力量