供应链产品经理:拆解一个erp saas需求给你带来什么「供应链方向产品经理」

今天给大家普及一下供应链产品经理:拆解一个erp saas需求给你带来什么「供应链方向产品经理」相关知识，最近很多在问供应链产品经理:拆解一个erp saas需求给你带来什么「供应链方向产品经理」，希望能帮助到您。

编辑导语：作为供应链产品经理，在面对一个业务需求时，往往会有多种不同高度的产品解决方案，此时便需要结合具体业务来决定需要哪种方案。本文作者详细拆解了供应链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要不要查询”这一个业务场景以外，还有以下业务场景：

查“库存数量>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协议。