接下来详细拆解ERP常见的“加一个字段的需求”

编辑导语:作为一名SAAS产品经理,如何通过用户提的“一个加字段”需求能全面做需求分析,给出不同抽象高度的产品方案?SAAS常见的“加一个字段的需求”,以此来启发产品经理做到“以点带面,用标准化的产品方案来解决一类问题”。但是对于已经是从事供应链方面的产品经理三年以上的同学至少要能通过用户提的“一个加字段”需求能全面做需求分析,给出不同抽象高度的产品方案。SAAS常见的“加一个字段的需求”,以此来启发产品经理做到“以点带面,用标准化的产品方案来解决一类问题”。于是在产品需求文档中写着要加这三个字段。

编者介绍:作为SAAS产品经理,如何通过用户提出的“一加领域”需求,综合分析需求,提供不同抽象层次的产品解决方案?本文详细拆解ERP SAAS中常见的“添加字段需求”,以期启发产品经理“用标准化的产品方案解决一类问题”。一起来看看吧。

接下来详细拆解ERP常见的“加一个字段的需求”

在多年ERP SAAS系统的产品设计工作中,供应链产品资深人士发现,对于“添加字段”的需求有很多,其实对于这样的需求,可以有不同抽象层次的产品解决方案。每个解决方案没有对错,只有优点和缺点。产品经理只需要根据实际业务、产品架构和开发资源来选择哪种解决方案。

但是,对于从事供应链工作三年以上的产品经理的同学,至少要能够通过用户提出的“一加领域”需求做一个全面的需求分析,提供不同的产品解决方案。抽象层次。

下面我将详细拆解ERP SAAS中常见的“添加字段的要求”,以启发产品经理“用标准化的产品方案解决一类问题”。

一、业务场景

在ERP系统的一个采购订单的新页面中,为了突出产品明细的字段,我省略了基本信息和供应商信息的字段原型,用占位图代替。

假设当前商品详情中的库存字段只有“合格仓库库存”,销售字段只有“30天销售”,某天,买家小A向产品经理阿杰提出请求, “在添加采购订单的时候,产品信息,需要添加一个字段【 in 】,那么面对这个需求的阿杰将如何处理呢?

接下来详细拆解ERP常见的“加一个字段的需求”

二、产品方案1.我最喜欢画原型

阿杰是一个很真诚的人,会为用户的需求着急,所以他马上写了一个需求,并画了一个原型安排来开发和宣传这个需求。我看到他在需求文档中写道:在新的采购订单中,在编辑页面和详情页面的产品信息中添加一个字段“在途数量”。具体位置见原型。

(1)优势分析

作为业务与开发之间的沟通麦克风,它直接将用户的需求转化为产品需求,高效解决了这个问题。

(2)劣势分析

用户的需求不是分析而是直接执行,导致用户后续对这个采购订单的字段要求不断增加,比如添加“合格可用库存”、添加“最近60天”销量等等。

有时用户提出的需求并不是真正的产品需求,需要产品经理深入分析。如果产品经理在企业里不怎么分析需求,其实不需要产品经理,开发可以直接面对用户。

(3)供应链产品资深评论

这让我想起了多年前还在深圳经营时遇到的一个产品经理小姑娘。记得当时作为一个运营,我提出了做官网的要求,然后产品经理让我提供文案,UI草稿,每个菜单的页面内容。我花了大约 2 周的时间将这些提供给她,然后我看到她花了大约 2 个小时来绘制它们并将它们放入开发计划中。

当时我在想,既然做产品经理就像画原型那么简单,那我也去做吧,因为产品经理的薪水比运营高出差不多40%。

在互联网公司中,还有相当一部分产品经理处于这个阶段,即“需求端让我做什么,产品经理就是画原型,剩下的时间就是摔跤”随着发展”。

这种类型的产品经理在工作中最直接的表现就是“拿到一个需求就画个原型不假思索,把原型里的逻辑推敲,逻辑一改就修改原型,导致反复折腾原型。”

这一点,我不是在批评这个级别的产品经理,我也来过这里,就像《射雕英雄传》里的郭靖,在成长过程中只修炼绝世武功。但也正是因为这个职级的产品经理太多,产品经理培训机构特别喜欢培养原型,导致外界普遍认为产品经理是原型。

2. 能不能多想

这时候阿杰正在分析为什么用户需要添加一个字段【在途数量】。其实就是输入采购数量的价值才合理。除了在途数量外,还要求合格的仓库可用数量和账面库存(仓库总量+店铺数量)。有存货)。所以在产品需求文档中写了添加这三个字段。

能够通过用户提出的一个需求来诊断需求背后的业务场景,想到用户没有想到的,这已经是一种进步,已经进入了需求分析阶段。方很满意。

(1)优势分析

能够通过用户的一个请求来诊断需求背后的业务场景,想到用户没有想到的,这已经是一个进步了,已经进入了需求分析的阶段。如果不是SAAS产品,这已经可以让需求方更加满意了。

(2)劣势分析

分析不够全面。其实,为了让用户购买合理数量,核心是参考仓库的库存量、各店铺的总/单独库存、过往销售额、库存上下限、历史购买记录。这样的分析只需要添加二十或三十个字段即可。

因此,这个方案并没有完全解决这个问题。作为同类型问题的SAAS产品,未来不同用户或同一用户会反复增加相关领域的要求。

(3)供应链产品资深评论

智能硬件产品经理和互联网产品经理_产品经理怎么做SEO_产品经理 市场推广 seo

作为供应链产品经理和2C产品经理,最大的核心区别是“实事求是,从商到商”。从这个产品方案可以看出,阿杰已经知道如何从一个需求点去思考开花几个点排成一列,但是还没有从一个点到一个点做全面的业务需求分析。

或许是因为需求的本质(采购数量是基于什么)没有看透,或者是思维中的综合思维角度不够。

3. 能想到一张脸

阿杰在综合需求诊断后发现,用户的本质需求是“应该用什么字段来指代购买数量”,所以得出的结论是,如果都添加到产品中,需要添加二十或三十个字段采购订单详情 不可以,因为查看太多产品详情字段会让用户很麻烦。

所以阿杰用抽象思维来思考他是否可以抽象出一个包含这些字段的组件。于是阿杰在需求文档中写了这个需求,“封装了三个弹窗,分别是采购入库记录、库存汇总、库存批次明细。在产品明细行的最后,用户可以点击按钮打开这三个弹窗分别是“查询相关数据的弹窗”。

接下来详细拆解ERP常见的“加一个字段的需求”

做了这个要求后,阿杰发现对于采购订单的详细信息,用户基本提不起添加字段的要求,因为他需要参考的字段都添加了。

(1)优势分析

这个需求是从用户提出的需求中挖掘出一类问题,用标准化的方案解决这类问题。产品经理阿杰初步具备了综合分析业务的能力,也能抽象出标准化的解决方案。,能够在SAAS产品中做到这一点,就等于不仅解决了这个问题,还解决了其他用户没有提出的需求。

这样一来,客户就不需要针对某一类问题反复提出要求,很容易获得客户的信任。

(2)劣势分析

思维受到采购订单方面的限制。没想到库存查询页面、发货单、店铺订单等其他文档也需要这三个按钮弹窗。产品架构用于提出需求。用白话来说,还是缺乏全局观。

(3)供应链产品资深评论

一个产品有一个结构,就像一个立方体有六个面。如果产品设计除了立足于某一方面,还能综合考虑,那就很好了。

以本例为例,如果只考虑采购订单端,其他库存查询页面和相关单据的用户也会提出这样的问题,然后要求相关产品经理做需求分析,甚至可能造成重复. 造轮子的资源是不能互通的,因为在做SAAS产品的时候,需要考虑方案的互通性,这样才能降低开发成本。

4. 可以综合考虑

阿杰对商业比较熟悉。用户除了知道采购订单的产品明细中需要查看库存汇总、库存批次明细、采购入库记录外,还知道以下场景也需要,即“缺货记录、库存相关报表、配送清单、店铺请求清单等,于是他协调负责这些业务的产品经理,完美地执行了这个标准化的产品计划。

如果你是一个企业的产品经理来做这个是很好的,因为你不仅可以综合分析业务,还可以综合设计产品,在做需求的时候可以考虑产品架构,而不是那种“别人负责的模块,我没关系,我会自己照顾。”

假设不这样做会导致同样的问题,不同的产品经理重新创造轮子,每个人制造不同质量或风格的轮子,这将导致系统被一遍又一遍地修补。这就是所谓用标准化的产品方案解决同类问题,让用户或需求者以后不能提出问题,如果是像SAAS产品这样的解决方案,就很有价值了。

5. 可以带动业务

现阶段,阿杰已经按照上述综合考虑方案进行,但他仍然认为还不够。他认为,用户手动下单主要是根据经验和客观数据来确定要购买哪些产品,要购买多少数量,以及购买价格。购买多少和哪个供应商是合适的。

如果系统只满足这个基本的下单需求,那么系统的本质还是工具属性,SAAS产品的本质是提供行业解决方案,哪怕是很小的需求也是行业解决方案。

想到这里,他顿时兴奋起来,心想如果能做出智能采购的算法模型来辅助买家采购,那岂不是锦上添花。所以我花了我的时间和业务专家研究行业中的许多算法模型,然后将算法模型商业化。

这其实相当于达到了产品经理的高层次。这个级别的产品经理可以带动业务,也就是说,他们不仅可以诊断业务问题,还可以带动业务人员和事情高效地做。

这个排名与行业的沉淀有关。即使你是超级工厂的产品经理,不是同行业的,短时间内也很难达到这个级别。

也就是说,做产品经理在每一行工作中都不尽相同。你是这个行业的产品专家,你可能是另一个行业的学生。如果你不承认这一点,很容易把企业里的产品搞砸,尤其是你是产品经理的时候。供应链相关的 SAAS 产品。

三、总结

在与供应链相关的产品实际工作中,添加字段的需求非常普遍。以上五种方案中的每一种都会有客观存在的意义。每个方案背后的产品经理,其实都是在不同的产品领域,不是没有能力的。. 每个产品方案没有绝对的对错,只有优缺点。在实际工作中,需要结合业务场景、产品架构、开发资源、业务价值来决定选择哪种方案。

此外,每个产品经理也可以客观地面对自己的职级。没有人一入职就成为武林高手。一路走来都是练出来的,尤其是供应链是要练的,不是训练的。

但是,如果你做供应链相关的产品,尤其是SAAS产品,千万不要把自己迷惑成“产品经理画原型”,而是要全面分析业务,深入挖掘业务场景,然后像行业解决方案一样提供产品解决方案.

当然,这一切都是基于对业务的熟悉程度。如果对业务不熟悉,即使掌握了大厂各种老板专家的产品经理培训课程的方法论,估计也只能达到“多想几个点”的阶段. . 所以,如果你即将转行做供应链产品经理或者已经入行,希望你能静下心来,实事求是,多研究业务场景,进行业务积累。

免责声明:本文来自网络用户投稿,不代表本站观点和立场。如有侵权请发送邮件至tzanseo@163.com告知本站删除,本站不负任何责任及承诺。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。

发表评论

登录后才能评论