供应链产品经理：拆解一个ERP SAAS需求给你

一、业务场景

在多年的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要不要查询”这一个业务场景以外，还有以下业务场景：

查“库存数量>100或1000或10000”查“可用数量>100或1000或10000”其它查询列表的数字类字段也有类似上述1、2的场景

于是在综合考虑这一类场景问题，按照SAAS产品设计的原则抽象出标准化的办理方案，即每一个数字类、金额类字段都做一个按大小搜索的小弹窗，如下图所示：

1）上风剖析

到了这个阶段 阿华同学已经具有了通过用户提出的一个问题创造一类问题的业务诊断能力，也具备了抽象出一套标准化方案办理一类问题的能力。

不但办理了“仓库库存批次列表”的数字类字段查讯问题，还办理了其它所有列表数字类字段查询的问题。

2）劣势剖析

用户每次进入查询页面须要去点击“库存数量”然后输入最小值操作才行，这样具有一定的刻意性，体验不是很好。
还有便是没有办理类似“查询库存数量>0且预留数量大于0”这样的问题。

供应链产品老兵觉着此时的“阿华同学”已经初步具备了用标准化方案办理一类问题的能力，但这个一类问题梳理的还不足全面，所谓以点带面看到的还只是正方体的4个面还有2个面未曾看到。

方案F

若何既能用标准化方案办理一类场景，还能让用户在体验上不刻意为之呢，阿华同学综合以上5种产品方案思考出第六种高度抽象的SAAS化办理方案，即由架构师去低代码平台中开拓出筛选器功能，然后由用户在页面中自由配置，不须要各业务模块的开拓参与。

如果用户要实现“查询库存数量>0且【预留数量 < 可用数量】”的需求，详细从用户角度操作与交互如下：

点击“仓库库存批次列表”页右上角的【筛选器】按钮，弹出筛选器弹窗在筛选器弹窗左边的筛选条件，点击“库存数量 右边的+”，这样右侧新增一行，运算符选择大于，值填写0，关系（或且非）选择“且”在筛选器弹窗左边的筛选条件，点击“预留数量 右边的+”，这样右侧新增一行，运算符选择小于，值选择“可用数量”，关系（或且非）选择“且”

补充解释

如果用户进来偶尔按不同条件来搜索查询，且条件具有个性化，那么按照以上筛选器配置后点击【搜索】就可以按已设置的条件去查询过滤数据，不须要存模板。

如果用户的查询条件仅对他自己具有一定的通用性，比如查“查询库存数量>0 且 【预留数量 < 可用数量”，那么在上面筛选器的配置中配置完成后点击底部的【存模板】这样就会把这个筛选器保存为一个模板，从而每次进入到这个页面可以在列表页右侧的【模板】按钮中选择自己的模板列表按需查询，就不用每次进来都配置筛选器了。

如果用户的查询条件对同客户的所有用户都具有一定的通用性，那么在上面筛选器的配置中勾选“是否设为公用模板”然后存模板就行，这样就同一家客户所有用户都可以利用此模板了。

如果用户须要每次进入这个页面就调用某个默认的模板来查询，那么在上面筛选器配置中勾选“是否设为默认模板”就行。

1）上风剖析

用可配置的标准化方案一次性办理了所有列表或报表的查询场景，不须要用户反复多次提需求，用户暂时没想到的业务场景阿华同学也想到了，具有较完善的SAAS产品经理业务诊断能力与高度抽象的产品方案设计能力。

2）劣势剖析

开拓本钱较高，如果没有类似低代码平台恐怕难以开拓出来；用户不怎么会操作，后期培训本钱较高。

供应链产品老兵认为此时“阿华同学”已经具备了比较完善的供应链业务诊断能力与高度抽象的SAAS产品方案设计能力，但其用户体验设计的能力要加强，还须要考虑开拓本钱，毕竟很多互联网公司是没有低代码平台这类开拓资源的。

三、供应链产品老兵总结

供应链占了B真个一大头，而ERP系统常常是包含了供应链的所有模块，比如商品、订单、采购、仓储、配送、库存、财务、匆匆销等。
如果只是做甲方自营的供应链ERP系统，那么对付产品经理大可不必要求“用标准化的办理方案办理一类问题”，由于如果这样做 高度抽象出来的产品方案运用少且开拓本钱太高了。

如果是做乙方的ERP SAAS系统，这样的ERP就不仅仅是一个工具属性还是一个行业的完全办理方案，行业办理方案是须要多年的业务积累才能沉淀的。
而且一个需求常常对应的便是一个办理方案，这样的办理方案要众口能调，即尽最大的力量让所有客户都满意，这样才是完全的整体行业办理方案。

但是是实际事情中 部分产品经理由于对业务场景不是很熟，对产品设计的抽象能力不足 导致输出的产品方案难以办理一类问题，从而让不同用户对同一类问题反复提需求，对系统便是相称于反复打补丁。

我是供应链产品老兵，做了供应链这块的“ERP+SAAS+低代码+wms”累计超过6年，我不擅于分享宏不雅观方法论和各种商业剖析，只知道剖析需求是若何做的，期望以需求实战的内容分享来勾引供应链产品经理特殊是做SAAS的产品经理来逐步养成“用标准化的产品方案来办理一类问题的原则”，从而提升业务诊断能力和抽象思维。

作者：产品老兵，公众年夜众号：供应链产品老兵

本文由 @供应链产品老兵 原创发布于大家都是产品经理。
未经容许，禁止转载。

题图来自Unsplash，基于CC0协议。