【后端PM入门示范】手把手教你从0~1搭建电商/新零售/O2O ERP店仓管理系统

1.前言

为了保持写文档的手感，这边撰写一个关于后端PM的入门教程；

背景设置：公司由原来的B2B2C电商业务，为完善线下体验闭环，增设线下店仓，提供收货寄存服务、商品展示供选；
因此，完成本前置仓ERP系统配套；

• 本教程为入门使用，不考虑版本迭代、多人合作问题；
• 直奔需求分析、原型设计及需求说明撰写。

系统性质：电商/新零售/O2O店仓ERP系统；
适用环境：PC浏览器；
使用人群：我司店员;

下图为店仓实体承载的核心业务：

2. 根据核心业务，进行相应挖掘后理出框架

坚持从用户角度开始分析，请各位认可这个出场顺序；

2.1.1 寄存列表及新建寄存

• 发现问题：用户进店，如何查询是否有寄存货品？
• 解决方案：搭建【寄存列表】；

2.1.2 新增寄存

发现问题：那么查询的寄存货品，是从哪里来的呢？

• 解决方案：是送货到店的时候，录入的信息呀~
  搭建【新增寄存】，用来录入寄存的到店时间、归属账户等；

• 寄存的货品信息来源，其实有很多种思路可尝试，例如送货师傅操作，自动入库之类，此处不展开讲，以最简单常见的案例入门；

2.2.1 货品列表

• 发现问题：用户想买26个箱 位于 A区5号柜第2排上的牛奶，前置仓里有没有这么多现货？
• 解决方案：搭建【货品列表】；用于记录货品信息，例如5号柜第2排，【货品名】为【伊利纯牛奶28袋装】，【条码值】是【78327893945】，这件货品在本店的可售【库存】一共是78件；

2.2.2 新增货品

• 发现问题：那供查询的信息，是如何得到的呢？
• 解决方案：可以通过【新增货品】功能来实现；

2.3.1 创建订单

• 发现问题：假设流程顺畅，仓库里有26箱牛奶，根据用用户采购习惯，采用线下扫码支付，那么订单如何生成和统计？
• 解决方案：需搭载【创建订单】功能；

2.3.2 订单列表

• 发现问题：那么之前产生过哪些订单呢？这么重要的信息一定要能够查询呀
• 解决方案：搭建【订单列表】功能；

2.4.1 补货申请

• 发现问题：26箱牛奶被用户带走了，按照往常一天50箱的平均水准，库存很快就会影响营业额，如何处理？
• 解决方案：搭建【补货申请】功能，向总体申请货品配送；

2.4.2 补货申请列表

发现问题：相邻周期的补货需求往往相似，可以直接在系统里查询吗？这样就不需要每天一一统计了

• 解决方案：搭建【补货列表】

2.5.1 入库

• 发现问题：过了一天，公司送来了100箱牛奶；直接堆放到对应仓位，谁可能一直记得现在一共多少箱了？
• 解决方案：搭建【入库】功能，用来记录库存的增加；

2.5.2 出库

• 发现问题：又过了一天，附近的一个体验店打来电话，说有个用户着急要10箱牛奶，但是他们没有那么多，找我们调剂一下？
• 解决方案：都是帮公司赚钱嘛，所以搭建【出库】功能，用来区分和订单售出不一样的库存减少；

2.6 账号登录/退出

• 发现问题：体验店一般开在有人来往的地方，万一来个熊孩子，乱点系统搞幺蛾子怎么办？
• 解决方案：搭建【账号登录/退出】功能，有店员看着就好了，不用时退出；

3 PC版还是手机版

3.1 前端形态

门店一般配置1台电脑，从普适性、更新门槛、技术成熟等角度考虑，web系统为第一考虑方案；

3.2 系统框架尺寸

根据查询相关资料，主流办公屏幕，真的可能出现较窄的屏幕，故功能将集中在中部，约1200px即可，或者找UI同学寻求意见；

3.3 设计顺序

结合功能的重要性和使用频率，抽象出以下几个模块：
【登录/退出】【订单管理】【货品管理】【出入库】【补货】
看到这里，恭喜你完成了基础需求分析环节，继续加油；

4 开始写PRD

4.1 PRD文件框架

打开AXURE，新建2个基础文件夹，分别用于存放业务流程图和原型页

• 在业务流程图文件夹中，新建1个页面用于存放流程图，便于程序们爸爸们理解业务，另1个文件夹放上一节总结的5个模块的内容，如下图；
  

• 创建一个母版，画出系统公共框架，以便重复调用
  

• 所有列表中，几乎都需要用到条件检索，所以笔者也创建一个检索条件区，也作为母版供重复调用；
  

4.2 需求撰写

4.2.1 登录页

登录页简版如以下原型图图；
右附笔者常用需求文档表，清晰明了，详见图中参考；
需求点的描述，可以从【数据】【逻辑】【交互】【其他】4个维度进行完整刻画；
较为复杂的流程，可以增设流程图，存放在4.1规划的文件夹中；

4.2.2 订单模块

• 订单模块有两个主要功能，1是列表，2是新增订单； 由于列表的数据，来源于新增的订单，所以先从新增开始着手；

4.2.2.1 新增订单

• 创建一个页面，用来描述新增订单的功能点；
  
• 那么问题来了？新增订单需要如何设计呢？
  新增订单，需要记录哪些信息呢？卖出的商品，名字叫啥？单价多少？卖出多少件？实收多少钱？
  认真想象，就会发现键盘输入的执行效率极低；
  所以每个商品本身，都带有唯一编号（经常叫货号 / 商品ID），找找这个号，就可以快速查询到商品信息；
  如图所示，通过【新增商品】按钮，把客户选择的商品信息加进来，通过【删除】键抹掉用户不要的商品；
  
  以下为新增商品和数量示范：
  
  对于重要操作，需要对使用者进行提示【已新增】【已删除】；
  另外考虑到选购过程的数量，常常变化，可以设计 修改数量功能；

选购商品和数量明确后，客户怎么把钱给我们？你扫我还是我扫你？
见图中新模块及右下角按钮
a、店内扫码枪扫描客户
b、客户扫描我们的收款二维码（本文不用此示范，因为存在管理风险，一般会在私人店铺使用）

如果早期考虑到，兼顾扫支付码和扫描商品ID，偏向于采用扫码枪解决方案；

• 假设扫码支付成功，客户便可拿走相应货品；
• 那么，如果客户在我们支付过程中，发现余额不够支付，想取消购买其中两件商品呢？
• 或者媳妇儿发现老公在这偷偷买烟，还没来得及扫，就被揪走了耳朵，后面的订单咋整啊？
• 所以，增加取消收款功能，另行新建订单，如图（后期增加需求，在订单种直接减少其中两件商品，此版暂且不考虑）
  

我们有了扫码枪，所以添加商品时，可连续扫描，来提高效率，那么应该如何触发扫码枪添加呢？
考虑到扫码枪的使用更加便利，所以笔者将扫码枪功能直接独立出来，使用按钮触发，见图；

通过不断挖掘和修改迭代，新增订单功能的原型图，已经基本完整；
页面搭建定型后，就可参考登录页的需求撰写表，进行需求打点和详细刻画啦~~

5.小结

以上便是一个完整的店仓系统1.0的整个设计过程，及首个子模块的原型和文档攥写过程；
跟着学到这里，就相当于，学会了print (‘Hello，world’)，甚至是print (‘Hello Mary，Im Jack，Nice to me you~’)；
接下来请开始举一反三了；
加油嗷嗷嗷，欢迎给笔者留言；