逆向解构万里牛电商ERP,实践可推导产品分析方法

24 评论 8786 浏览 105 收藏 55 分钟

编辑导语:这篇文章作者从系统全局分析、系统详细分析和熟悉的系统原型设计三方面入手,详细地向我们展示如何逆向解构万里牛电商ERP,通过自己的实践推导出其产品分析方法,作者把书里的知识学以致用,非常值得我们学习借鉴,一起来看一下吧~

在此我想感谢谭云杰老师的《大象—Thinking in UML》,我深受这本书的启蒙,这本书不是单纯的讲UML,而是讲软件过程,软件分析方法。反复研读后,我把书中的思想慢慢内化成自己的产品分析方法,实现可以一步步推导的分析方法,并运用在本次文章上。

本文有1.3万字,请保持耐心。

此次本着学习的态度解构万里牛ERP(专业版),我是从万里牛的页面和功能入手,逆向分析得到关键输出物和原始需求,以此深入学习电商ERP的业务。

获得关键输出物后,本文是以正向设计的逻辑进行描述,还原从需求到原型的设计过程。

本文按分析粒度大小,分为三部分,如图1:

  1. 系统全局分析,分析粒度保持在模块管理,目的是获得系统的全局认识。
  2. 系统详细分析,分析粒度变小,保持在增删改查功能的粒度,目的是获得全部系统用例。
  3. 熟悉的系统原型设计,分析粒度变小,保持在页面和元件交互,目的是获得可交付的原型和标注。

图1 分析逻辑

一、系统全局分析

系统全局分析,分析粒度保持在模块管理,目的是获得系统的全局认识。第一节是从业务的角度获取需求和用例,第二节是从系统的角度获取需求和用例,我称这个粒度为一级用例,第三节和第四节是在前两节的用例基础上分析主流程和对象。

1. 业务用例

在软件项目里,业务范围和系统范围是不同的。业务范围指这个项目所涉及的所有客户业务,这些业务有没有计算机系统参与都是客观存在的。系统范围是指软件将要实现的那些对应于业务功能的系统功能,从功能性需求来说系统范围是业务范围的一个子集,但是一些系统功能则会超出业务范围,例如操作日志,有没有操作日志并不影响业务目标的达成,客户也不一定会提出这个要求,但从系统角度出发,操作日志会使得系统更加健壮。

——来自《大象—Thinking in UML》

在引入计算机系统之前,业务也一直跑得很顺畅,因此在初始阶段,不引入系统的角度,纯粹站在业务的角度,分析业务的主流程场景,获取业务用例。

获取业务用例需要分析出业务主角和用例,业务主角即参与到业务流程中的角色,例如采购员、售前客服等。用例即业务主角需要在业务流程中完成的事情,这里需要注意用例的粒度,我经过思考,系统全局分析阶段,建议使用管理一类事物的粒度,例如销售订单管理,这个粒度仅供参考。

开始获取业务用例,以下是一段商家工作内容的场景。

店长小明想开一家网店,在商品上架销售前,小明做了以下准备工作:

  1. 在淘宝注册一个店铺;
  2. 选择想要做的品类和卖的商品,并维护商品信息;
  3. 找合作快递公司,用于发货给客户;
  4. 找仓库,用于存储采购的商品;
  5. 店长还需要关注店铺各业务的运转情况,即查看销售、采购、库存、资金的报表。

除此之外,还招了6个岗位一起合作:

  1. 采购员,负责采购商品补充库存;
  2. 售前客服,主要为买家介绍商品特性和解答销售方面的问题,买家下单后审核订单;
  3. 发货员,对通过审核的订单进行配货打包,进行发货;
  4. 售后客服,主要为买家解答售后方面的问题,并审核买家发起的退换货申请;
  5. 仓库管理员,记录商品的出入库和管理商品库存;
  6. 财务员,记录销售订单和采购的资金出入。

团队到位了,可以开展工作了。

采购员根据店长选好的商品进行采购工作,联系供应商采购商品,即提交采购订单。采购订单的货品到了之后,需要仓库管理员记录采购入库单,并为商品安排库位和增加商品的库存。商品入库后,采购员和供应商登记结算单。如果到货的商品有问题则进行退货处理,即提交采购退货单,采购商品出库时需要仓库管理员记录采购退货出库单,并减少退货商品的库存。

至此,把商品上架在淘宝,就可以开始接单了。当买家在淘宝下单并支付后,订单的处理就交给售前客服和发货员了。

首先售前客服会审核订单,如有注意事项可对订单进行备注,例如有什么赠品、指定发什么快递等,通过审核的订单即流转给发货员。发货员在仓库中进行配货并打包,最后打印快递单,进行发货。发货时,需要仓库管理员记录销售出库单,并减少销售商品的库存。

另外小明还希望发展一下线下大客户,所以有的售前客服在线下开拓客户。客户可直接和售前客服下单,售前客服创建订单,然后流转给发货员。发货员在仓库中进行配货并打包,最后打印快递单,进行发货。发货时,需要仓库管理员记录销售出库单,并减少销售商品的库存。

以上是正向的交易流程,买家下单,商家发货。当买家提出退换货的时候,就需要售后客服介入。买家在淘宝提交了退换货申请,售后客服进行审核是否同意退换货,审核通过后,买家寄回商品。寄回商品到达指定退货仓库后,仓库管理员记录退货入库单,并更新商品库存。如果是退货,售后客服进行退款处理,如果是换货,售后客服根据售后单,手动创建销售订单,然后该销售订单正常发货。

仓库管理员日常工作除了记录销售订单、采购订单的出入库单外,平时需要维护仓库的基础数据,库区、库位等,并且记录商品的摆放位置。每次商品出入库都会更新库存,定期查看各商品的库存数量。还会为了保证商品数量安全,定期对仓库的商品数量进行盘点。如果商品的成本近期发生变化,还会对商品进行调价。当前小明拥有两个地方的仓库,有时候需要进行商品调拨,即仓库管理员把A商品从甲仓库调拨到乙仓库,调拨出库和入库时也都需要记录调拨出库单和入库单。

以上是采购订单和销售订单的场景,每次商品出入库,都伴随着资金的收支变化,所以财务员有以下日常工作。首先,财务员需要维护资金账户基础数据,其他主要工作就是收款、付款、账目对账检查。

收款主要是收取销售订单的钱,有三种收款方式:现金收款、充值款消费(预收款)、赊账(记录应收款)。现金收款是买家下单时进行支付费用,例如淘宝订单。充值款消费是买家提前充值费用存在该客户的账户上,然后下单时进行扣减,主要适用于线下订单。赊账是买家下单时不进行付款,客户账上也没有充值款可以扣减,这样就会记录该客户的应收款,然后定期收款,并记录收款单,适用于月结的客户。

付款是支付给供应商采购订单的货款和支付给快递公司的快递费。有三种支付方式:现金支付、充值款支付(预付款)、赊账(记录应付款)。现金支付是采购订单到货后现金支付货款给供应商。充值款支付是预存充值费用在某个供应商那,每次采购单到货后选择使用充值款支付货款。赊账是采购订单到货后不支付货款给供应商,然后记录该供应商的应付款,定期付款,并记录付款单,适用于月结的供应商。

快递费目前是选择月结的方式结算。为了保证账目的准确,财务员会定期进行快递单对账。

有时候需要转移资金,即财务员把资金从A账户转到B账户,则进行转账。财务员在有资金往来的时候都会记录资金流水。

基于以上场景,获取业务主角和提炼一级用例,如图2。

图2 业务用例

1)店长

是店铺的管理者,会管理基础数据和查看报表:

  1. 注册淘宝店铺,即管理店铺;
  2. 选择销售的商品,即管理商品;
  3. 选择合作的快递公司,即管理快递公司;
  4. 确定仓库,即管理仓库;
  5. 查看报表。

2)采购员

负责采购商品,会管理采购相关的事项有:

  1. 选择供应商进行采购,即管理供应商;
  2. 提交采购订单,即管理采购订单;
  3. 采购商品入库后和供应商进行结算,即管理采购结算单;
  4. 如有商品需要退货,提交采购退货单,即管理采购退货单。

3)售前客服

是销售订单的跟进人,会管理订单相关的事项有:

  1. 线下开拓客户,即管理客户;
  2. 审核销售订单,保证订单顺利完成,即管理销售订单。

4)发货员

负责对销售订单进行配货、打包、发货:

  1. 参与管理销售订单的发货流程;
  2. 打印快递单,进行发货。

5)售后客服

负责审核售后单,即管理售后订单。

6)仓库管理员

负责仓库商品的库存安全,会管理仓库相关的事项有:

  1. 维护库存的存储区域,会参与管理仓库;
  2. 采购商品到货后,记录采购入库单,即管理采购入库单;
  3. 采购退货商品出库时,记录采购退货出库,即管理采购退货出库单;
  4. 销售订单商品发货时,记录销售出库单,即管理销售出库单;
  5. 销售退换货商品退回仓库时,记录销售售后入库单,即管理销售售后入库单;
  6. 记录商品库存更新记录,即管理库存;
  7. 定期盘点商品库存,即管理库存盘点单;
  8. 定期盘点商品成本,即管理成本调价单;
  9. 把商品从甲仓库调拨到乙仓库,即管理库存调拨单;
  10. 调拨商品出库记录,即管理调拨出库单;
  11. 调拨商品入库记录,即管理调拨入库单。

7)财务员

负责资金的往来,会管理财务相关的事项有:

  1. 管理资金账户;
  2. 帮助客户充值预收款,记录每次消费或充值后,客户预收款余额,即管理预收款单;
  3. 客户订单未支付结算,会记录应收款,即计算应收款;
  4. 对销售订单的应收款进行收款,即管理收款单;
  5. 充值到供应商的预付款,记录每次付款或充值后,供应商预付款余额,即管理预付款单;
  6. 采购订单未支付结算,会记录应付款,即计算应付款;
  7. 对采购订单的应付款进行付款,即管理付款单;
  8. 定期进行快递单对账,即管理快递对账;
  9. 记录资金转账,即管理转账单;
  10. 记录资金往来,即记录资金流水。

2. 系统用例

得到业务用例后,虽然能看到业务主流程的雏形,但要完成系统的闭环还需要站在系统的角度去补充用例,例如系统权限管理的需求,业务用例中并没有体现出来。

系统用例也是需要获得角色和用例,这个阶段的用例粒度和上一步骤的业务用例保持一致,即管理一类事物。

开始获取系统用例,我站在系统的角度,从三个方向分析系统需求:

  1. 系统管理的需求
  2. 系统易用性的需求
  3. 系统扩展性的需求。

于是我列出了以下场景的需求:

  1. 万里牛ERP是一款SaaS产品,会服务多家公司的客户,所以需要创建一家公司才可使用系统。
  2. 每个系统都需要考虑权限管理,所以系统管理员需要维护角色权限,才能够管理公司员工的权限。
  3. 系统管理员需要创建员工,为员工分配账号,员工才可以登录系统开展工作。
  4. 万里牛ERP服务多家公司,各家公司的需求会存在差异性,需要做到高可配置化来支持差异化需求。
  5. 每个用户需要注册、登录、修改密码等账号相关的功能。
  6. 用户想及时得到订单状态更新、库存预警等消息,方便跟进,提供消息通知功能。

根据上述场景的需求,获取到系统用例,和业务用例放在一起,展示所有一级用例,如图3。

图3 一级用例

1)系统管理员

  1. 需要创建公司才能使用该系统,由他管理公司;
  2. 需要管理员工的权限,由他管理角色;
  3. 需要维护员工信息,由他管理员工;
  4. 需要配置系统以实现差异化的功能,由他管理系统配置。

2)全部用户

  1. 每个用户都需要进行注册登录,进行管理账号;
  2. 每个用户都需要获取消息通知,支持消息通知。

3. 主流程分析

主流程就是按某种逻辑把主要的一级用例组合起来,归纳出几条主流程,验证是否可以实现业务目标。得到主流程可以对系统有全局的认知,也能辅助后续的对象分析。

电商日常主要处理两大业务,采购和销售。采购和销售都有正向流程和逆向流程,即采购主流程、采购退货主流程、销售主流程、销售售后主流程。这4条主流程中都会引起库存更新和资金收支,所以除了商品出入库过程,也要关注库存变化和资金收支。

外加一条系统管理主流程,合计5条主流程。

1)采购主流程

主要是提交采购订单,到货后进行入库,并更新库存和支付货款,如图4。

图4 采购主流程

  • 提交采购订单:①采购员在管理供应商模块创建供应商,供采购订单引用;②采购员在管理采购订单模块创建采购订单,需要选择在哪家供应商采购什么商品;
  • 货品入库和更新库存:③提交采购订单后,仓库管理员在管理库存模块增加该商品的在途数量;④待采购商品到货后,仓库管理员在管理采购入库单模块创建采购入库单;⑤入库后,仓库管理员在管理库存模块增加商品库存;
  • 支付货款:⑥财务员在管理资金账户模块创建采购资金账户;⑦入库后,采购员确认采购商品没有问题,在管理采购结算单模块创建采购结算单,支付金额为0,计算应付款;⑧付款日期到了,根据结算单,财务员在管理付款单模块创建付款单进行付款;⑨付款后,财务员记录资金流水。

2)采购退货主流程

主要是提交采购退货单,退货商品出库,并更新库存和收回退款,如图5。

图5 采购退货主流程

  • 提交采购退货单:①如果采购商品存在问题需要办理退货,采购员在管理采购退货单模块创建采购退货单;
  • 退货商品出库和更新库存:②提交采购退货单后,仓库管理员在管理库存模块增加商品的锁定数量,可用库存等于【商品在库数量】减去【锁定数量】;③退货商品出库,仓库管理员在采购退货出库单模块创建采购退货出库单;④出库后,仓库管理员在管理库存模块减少商品库存;
  • 收回退款:⑤出库后,采购员在管理结算单模块创建采购退货结算单,让供应商退款;⑥若供应商没有退款,根据采购退货结算单,财务员在管理付款单模块创建退款单收回退款;⑦退款后,财务员记录资金流水。

3)销售主流程

主要是处理销售订单,进行发货,并更新库存和订单收款,如图6。

图6 销售主流程

  • 审核订单和发货:①售前客服在管理客户模块创建客户,客户供线下订单引用;②售前客服在管理销售订单模块创建线下订单,或者审核线上淘宝订单;③订单审核通过,发货员在管理销售订单模块进行配货、打包、发货等工作;④发货时,发货员为订单打印快递单,用于快递运输;
  • 订单商品出库和更新库存:⑤新增销售订单后,仓库管理员在管理库存模块增加商品的锁定数量,可用库存等于【商品在库数量】减去【锁定数量】;⑥发货时,仓库管理员在管理销售出库单模块创建销售出库单,如果订单之前没有支付过,计算应收款;⑦出库后,仓库管理员在管理库存模块减少商品库存;
  • 订单收款:⑧财务员在管理资金账户模块创建销售资金账户;⑨如果出库后,订单没有支付过,根据销售出库单和应收款,财务员在管理收款单创建收款单进行收款;⑩收款后,财务员记录资金流水。

4)销售售后主流程

主要是审核销售售后单,等退货商品入库后,更新库存和售后单退款,如图7。

图7 销售售后主流程

  • 审核售后单:①如果有客户发起退换货售后单,售后客服在管理售后单模块审核售后单;
  • 退换货商品入库和更新库存:②同意退换货后,仓库管理员在管理库存模块增加该商品的在途数量;③收到客户寄来的退换商品,仓库管理员在管理售后入库单模块创建售后入库单;④入库后,仓库管理员在管理库存模块增加入库商品库存;
  • 售后单退款或换货:⑤收到退换货的商品无误后,如果是退货,售后客服在管理售后单模块操作退款,如果是换货,售后客服在管理售后单模块直接创建销售订单进行换货;⑥如果退款,财务员记录资金流水。

5)系统管理主流程

主要是创建公司并邀请员工加入公司,之后进行系统配置和维护基础数据,如图8。

图8 系统管理主流程

  1. 系统管理员首次登录系统时创建公司;
  2. 系统管理员在管理角色模块创建角色和配置权限;
  3. 系统管理员在管理员工模块创建员工或邀请员工,并为员工分配角色;
  4. 员工在管理账号模块接受邀请进入公司,并登录系统;
  5. 系统管理员在系统配置模块配置自定义的参数;
  6. 店长维护基础数据供采购流程和销售流程引用,在管理店铺模块创建店铺、在管理商品模块创建商品、在管理快递公司模块创建快递公司、在管理仓库模块创建仓库。

4. 对象分析

神盾局特工第四季里有一个概念是虚拟数字世界:框架(Framework),看过的朋友就很容易理解:软件系统就是在计算机世界模拟现实世界,现实世界中的物体会映射成计算机世界里的对象。

这里使用面向对象分析方法(OOA),也是《大象—Thinking in UML》中的分析步骤之一,意图是将现实世界中的物体映射成计算机世界中的对象,在系统中使用这些对象去解决需求。比如分析对象需要哪些属性和功能来解决需求,在后续的步骤会详细分析这些对象。

获取到主要的对象,还可以帮助我们对系统有整体的认知。从以上的用例和主流程中进行抽象,我把得到的一级对象按业务分成6类:采购、销售、快递、系统管理、仓库、财务,对象内容如图9。

图9 一级对象

上图无法描述对象之间的关系,在下图展示对象的关联关系(有连线代表有关系)。

由于对象太多,关系线太多,无法绘制到同一张图中,所以有些对象会重复出现。延续采购和退货、销售和售后、系统管理5个主流程,并补充了用例中提到的仓库仓内管理、财务管理业务相关的对象关系。

①采购和采购退货,包含采购入库、采购退货出库、库存更新、结算付款,如图10;

图10 采购和采购退货相关对象

②销售和售后,包含销售出库、售后入库、库存更新、收款,如图11;

图11 销售和售后相关对象

③系统管理,如图12左一;

④仓库仓内管理,如图12左二;

⑤财务管理,如图12右一。

图12 系统管理/仓库仓内管理/财务管理相关对象

二、系统详细设计

系统详细分析,分析粒度变小,保持在增删改查功能的粒度,目的是获得全部系统用例。

第一节,把系统全局分析里的用例进行细化,即用例流程分析,可以发现基本的二级用例;

第二节,搜集所有的二级用例,即在流程中体现的用例以外,再补充其他必要的二级用例,例如删除、导入、导出;

第三节,为了满足高可配置化,还需要引入配置对象,例如商品自定义属性;

第四节,找到配置对象的用例,我称为三级用例,例如创建商品自定义属性,以满足配置需求。

1. 用例流程分析

用例流程就是用例的实现方式,是常用的需求细化方法,即细化上述一级用例的粒度,流程分析的目的是可以从中发现下级用例,现在开始分析流程,下图列出一级用例和对应的流程图,如图13。

图13 一级用例对应流程图

图14 基础信息维护相关流程

图15 采购相关流程

图16 销售相关流程

图17-1 管理库存流程

图17-2 仓库管理相关流程

图18-1 预收款单和收款单流程

图18-2 预付款单和付款单流程

图18-3 财务相关流程

图19 系统管理和用户相关流程

2. 二级用例

完成流程分析后,已经获得一部分细化的二级用例,但对于整个系统的闭环还是不够的,这节就补充完善二级用例。

现在获取的用例粒度,保持在主要对象的增删改查即可。获取二级用例从两个角度分析,一是从上述的流程中进行提取用例;二是专注分析的对象,然后围绕该对象设想一些场景以获得需求,例如删除、导出、打印、批量处理等在流程中找不到的需求,开始获取二级用例。

沿着一级对象的6个业务类别:采购、销售、快递、系统管理、仓库、财务,把业务类别中的对象一个个进行分析。

1. 采购

如图20。

图20 采购相关二级用例

  • 供应商,补全供应商的新增、查看、修改、停用、启用、删除,另支持设置供货商品、导入供应商、导出供应商、导入供货商品;
  • 采购订单,补全采购订单的新增、查看、修改、关闭,提供审核功能:提交审核、审核、查看审核信息,另支持复制、导入、导出、批量关闭、打印采购单;
  • 采购入库单,补全采购入库单的新增、查看、修改,另支持快速导入、直接入库、导出;
  • 采购退货单,补全采购退货单的新增、查看、修改、关闭,提供审核功能:提交审核、审核、查看审核信息,另支持复制、导出;
  • 采购退货出库单,补全采购退货出库单的新增、查看,支持直接出库、导出;
  • 采购结算单,采购结算有两种类型:采购结算、采购退货结算,提供新增采购结算单、新增采购退货结算单,支持查看详情、导出。

2. 销售

如图21。

图21 销售相关二级用例

  • 店铺,补全店铺的新增、查看、修改、停用、启用,需获得淘宝店铺的授权才可以同步线上的商品、订单、售后单,所以支持店铺授权;
  • 客户,补全客户的新增、查看、修改,支持复制、导入;
  • 销售订单,①订单操作,创建销售订单有两种方式:系统新增销售订单、下载店铺线上订单,另支持查看、修改、审核、打回、挂起、恢复、拆单、合单、提交异常、关闭订单、导入订单、批量修改、指定操作员;②发货操作,支持整个发货流程:生成快递单、打印快递单、打印发货单、打印配货单、配货、拣货、验货、打包、称重、发货;
  • 销售出库单,补全销售出库单的新增、查看,支持打印出库单、导出;
  • 销售售后单,创建销售售后单有两种方式:新增售后单、下载店铺线上售后单,支持售后流程操作:查看详情、同意换货、同意退货、同意退款、拒绝申请、审核、打回审核、入库、换货下单、关闭售后、售后完成,另支持批量操作:批量入库、批量换货下单、导入售后单、导出售后单、指定操作员;
  • 销售售后入库单,补全销售售后入库单的新增、查看、修改,支持导入、导出。

3. 快递

如图22。

图22 快递相关二级用例

a)快递公司,补全快递公司的新增、查看、修改、停用、启用,支持运费成本设置、导出;

b)快递单,补全快递单的新增、查看,支持打印快递单。

4. 系统管理

如图23。

图23 系统管理相关二级用例

  • 公司,补全公司的新增、查看、修改;
  • 角色,补全角色的新增、查看、修改、删除,支持编辑角色权限:修改操作权限、修改数据权限;
  • 员工,①补全管理员维护员工的操作:新增、查看、修改、删除、停用员工,还有其他新增用户的方式:复制员工、邀请员工、同意员工加入,还有管理员设置:设为管理员、取消管理员、转让超级管理员;②另支持用户视角的用例:激活员工账号、注册账号并申请加入公司、登录、忘记密码、修改密码、修改手机号;
  • 消息,触发系统规则后发送消息、用户收到消息并查看;
  • 商品,为了支持线上的业务,除了维护系统商品外,还需要关联淘宝店商品,进行对应。①维护系统商品:补全商品的新增、查看、修改、删除、停用、启用,提供“复制商品”的快捷新增操作,提供批量、导入导出、打印操作:批量修改、导出条码、打印条码、导入商品、导入商品价格、导出商品;②关联淘宝店商品:“下载线上商品”并“关联系统商品”,系统没有的商品支持直接根据线上商品“生成系统商品”,建立好关联商品后,可以查看关联商品、更换对应关系、解除对应关系、导出对应关系、导入对应关系。

5. 仓库

如图24。

图24 仓库相关二级用例

  • 仓库,补全仓库的新增、查看、修改、停用、启用,支持导出仓库信息;
  • 库存,库存是管理商品的数量,实际库存代表实际仓库中拥有的库存量;在途库存是尚在运输途中,还未入库的库存数量;锁定库存是待出库的数量,不可操作;①因此需要提供三类库存的更新:增加锁定库存、减少锁定库存、减少实际库存、增加在途库存、减少在途库存、增加实际库存,②还需设置期初库存:设置期初库存、导入期初库存、导出期初库存,③提供基础查看库存、导出库存功能,④库存需要同步至淘宝店,提供上传库存功能;⑤库存不足时发送预警消息,提供库存预警功能;
  • 库存盘点单,补全盘点单的新增、查看、修改、审核、关闭,另支持导入、导出、打印;
  • 成本调价单,补全调价单的新增、查看、修改、审核、删除,另支持导入、设置期初成本均价;
  • 调拨单,实际调拨,需要发快递进行出入库,虚拟调拨不需要发快递,直接调整仓库的库存。支持新增实际调拨、新增虚拟调拨、查看调拨单、修改、关闭、审核、导入、导出、打印调拨单;
  • 调拨出库单,补全调拨出库单的新增、查看,另支持打印调拨出库单、导出;
  • 调拨入库单,补全调拨入库单的新增、查看,另支持打印调拨入库单、导出。

6. 财务

如图25。

图25 财务相关二级用例

  • 资金账户,补全资金账户的新增、查看、修改、停用、启用,支持设置初始余额、设为默认账户;
  • 预收款单,预收款单有三种类型:充值、消费和提现,提供新增预收款充值单、新增预收款消费单、新增预收款提现单,另支持查看、打印、导出;
  • 收款单,补全收款单的新增、查看,另支持打印收款单、收期初欠款;
  • 预付款单,预付款单有三种类型:充值、消费和退回,提供新增预付款充值单、新增预付款消费单、新增预付款退回单,另支持查看、导出;
  • 付款单,付款单有两种类型:付款给供应商、付款给快递公司,提供新增供应商付款单、新增快递付款单,另支持查看、打印、付期初欠款;
  • 快递对账单,补全快递对账单的新增(导入)、查看、修改、删除,另支持结算、查看快递单对账结果;
  • 转账单,补全转账单的新增、查看;
  • 资金流水,资金流水有两种类型:收入和支出,提供记收入流水、记支出流水,另支持查看和导出。

3. 补充对象

以上的二级用例,基本已经解决业务的需求,业务可以闭环流转了。但还需要考虑一些非功能性需求,例如系统的配置需求、安全需求等。

万里牛ERP提供的是SaaS服务,使用一套系统服务所有客户,就需要提供强大的配置化功能,以满足不同客户的个性化需求,一般有两个配置方向,一个是对象的上下级对象和属性配置,二是配置一些用例场景的规则。

从之前获取到的对象进行分析,聚焦每个对象的场景,得到以下对象有强烈的可配置化需求,并提取补充对象,如图26。

图26 补充对象

  • 供应商,①供应商需要分组来归类,引入供应商分组;②为了适应更多用户各自的业务,引入供应商自定义属性;
  • 采购订单,①审核采购订单时,不同企业的规则不同,需要设置有几级审核,以及每级的审核人员,引入采购审核规则;
  • 店铺,①店铺需要分组来归类,引入店铺分组;
  • 客户,①为了适应更多用户各自的业务,引入客户自定义属性;
  • 销售订单,①不同企业的发货流程可能不同,大企业发货流程较长,小企业发货流程较简单,支持设置发货流程,引入发货流程;②订单出库会附带发货单,支持配置发货单的内容项,引入发货单模板;③订单配货时,需要配货单,支持配置配货单的内容项,引入配货单模板;④为了加快销售订单审核的效率,希望无异常的订单可以自动审核通过,引入订单自动审核规则进行设置;⑤有些订单需要拆单发货,例如大件商品,或者商品在不同仓库,希望可以自动拆单,引入自动拆单规则进行设置;⑥有些订单可以合单进行发货,例如同一客户下了两个地址一样的订单,希望可以自动合单,引入自动合单规则进行设置;
  • 售后单,①用户的售后单审核通过后,退货地址希望自动匹配到某个最适合的收货仓库,引入退货仓库匹配规则;
  • 快递公司,①每个快递公司都需要设置运费,而快递的运费规则差别不大,为了方便设置运费时调用模板,引入运费模板;②用户下单支付后,希望自动匹配到某个最适合的快递,引入发货快递匹配规则;
  • 快递单,①销售订单出库时,需要打印快递单,但是每家公司的快递单都不同,所以支持配置快递单的内容项,引入快递单模板;
  • 商品,①店铺的商品存在分类,引入商品分类;②不同商品的规格可能不同,例如衣服的规格是颜色、尺码,手机的规格是颜色、内存,所以规格支持自定义,引入规格;③不同商品的品牌也不同,所以品牌支持自定义,引入品牌;④不同商品的计量单位也不同,例如饮料最小单位是1瓶,12瓶一箱,而零食最小单位是1包,25包一箱,所以计量单位支持自定义,引入计量单位;⑤为了适应更多用户各自的业务,引入商品自定义属性;
  • 仓库,①一个仓库很大,一般会分为3级,分别是区域-库区-库位,区域和库区统称库区,用于业务隔离和区分作业功能,引入库区;②库位就是仓库中最小的定位标识,一般属于某库区下,引入库位;③仓库需要分组来归类,例如属于华东仓、华南仓等,引入仓库分组;④用户下单支付后,希望自动匹配到某个最适合的发货仓库,引入发货仓库匹配规则;⑤为了适应更多用户各自的业务,引入仓库自定义属性;
  • 库存,①库存中有二级用例是上传商品库存至线上店铺,由于用户可能同时运营多家店铺,每家店铺有订单出库了是会影响到其他店铺的库存的,需要配置上传库存的规则,所以引入上传库存规则,;
  • 资金流水,①记录资金流水时,需要记录收支科目,为了适应更多用户各自的业务,引入自定义收支科目;
  • 最后,还考虑一些简单的配置项,某些功能、规则的开关,例如出库单、入库单是否需要审核的开关。这样简单配置项有很多项,如果设计一大堆对象,但每个对象永远只有一条记录值,每增加一个配置项,就新增对象,还是永远只存一条记录值。所以这类配置项不适合分别单独作为对象管理,需要引入一个通用的配置项对象进行管理,配置项一般是系统内置的规则,进行规则的开关、或者选用某种规则。

4. 三级用例

得到补充对象后,就继续分析以上补充对象的用例,我称为三级用例,这样就完成该粒度层次的分析。

三级用例粒度是补充对象的增查改删,例如新增商品分类,是新增商品分类供商品调用,达到配置的目标。该粒度的用例比较有规律,大概有新增、查询、编辑、 删除、复制、排序、停用、启用、默认等功能。如图27,列出了补充对象的用例。

图27 三级用例

三、原型设计

系统原型设计,分析粒度变小,保持在页面和元件交互,目的是获得可交付的原型和标注。在原型设计前,需要梳理功能清单,一来可以展示系统的全貌,二来可以了解工作量和分配各模块的执行人。

1. 功能清单

功能清单就是把上文分析的所有用例按某种展现逻辑组织起来,而这种展示逻辑就是导航设计,所以在列功能清单前先进行导航设计,然后把用例放置到相应的导航菜单中,即可完成功能清单。

导航设计的粒度保持在一个比较高的层级,可对照到上文系统全局分析中的主流程和一级用例,以及系统详细设计中的补充对象,站在用户的角度,把主流程、一级用例、补充对象进行分类结构化。

功能清单的粒度则保持在操作的层级,可对照到上文系统详细设计中的二级用例和三级用例,站在用户的角度,把二级用例、三级用例放置到相应的导航菜单中。这样上文的所有分析就发挥作用了,功能清单被自然的推导出来了,如图28。

在完成功能清单后,即完成产品规划的部分,就可以按模块分配给多名产品经理,设计各个模块。

图28 功能清单设计思路

1)导航设计

参考5个主流程:采购主流程、采购退货主流程、销售主流程、销售售后主流程、系统管理主流程,可以看出电商日常高频率的工作是销售和采购,伴随着仓库和财务管理。采购工作的正向流程和退货流程合并成一个菜单(采购),所以常用的业务菜单如图29。

图29 常用业务菜单

c常用业务菜单但在开展业务之前,需要设置基础数据及系统配置,所以加入基础信息、商品、设置、个人中心四个菜单放置系统管理主流程的功能。另外,店长需要关注经营情况,需要看报表,增加一个报表菜单,最终的一级导航菜单如图30。

图30 一级导航

把上文系统全局分析中一级用例,和系统详细设计中的补充对象归类放到一级导航下,就是完整的导航菜单,如图31。

图31 导航菜单

2)功能清单

在导航菜单的框架下,按模块填充二级用例和三级用例。例如商品相关的常规功能(二级用例)放在商品信息菜单中,商品相关配置功能(三级用例)就放在各自的配置菜单下,如图32。

图32 商品功能清单

完整功能清单写在腾讯文档,请访问 https://docs.qq.com/sheet/DQUdWUUtUeHl1VWpi。

说明:图32和腾讯文档中的功能清单是最终系统上的功能清单,所以菜单并不完全和导航设计中的一致,是在实际设计中根据用户场景进行了调整。

2. 原型设计

不知道各位是否有这样的困扰,在原型设计时会有这样的卡顿,例如查询列表页要展示什么字段,创建页要展示什么字段,就有被打断的感觉。因此建议在开始原型设计之前,先根据对象的场景,分析对象的属性。我个人习惯是先分析对象属性再画详细的原型,这样是比较顺畅的。

1)对象属性

分析对象属性,并不是轻松的过程,每个属性都有针对的场景,这里用“商品”这个对象举例。提示:一种商品下可以有多种规格,也就是一个SPU下可以有多个SKU,例如一款手机,有白、灰、黑3种颜色,手机就是SPU,三种颜色就是3个SKU。

① 商品信息

  • 名称,商品名称;
  • 商品编码,SPU级别编码,有唯一性要求;
  • 货号,商品的款号,常用于记录供应商的编码;
  • 分类,商品分类,用于区分商品类别;
  • 品牌名称,商品的所属品牌;
  • 单位,商品使用的计量单位,例如件、瓶、箱等;
  • 备注,使用文本记录商品的注意事项;
  • 创建时间,商品创建时间;
  • 更新时间,商品信息最新修改时间;

② 规格信息

  • 规格名称,SKU的名称,例如一款手机,有白、灰、黑3种颜色;
  • 规格编码,SKU级别编码,精确到每个规格的组合,有唯一性要求;
  • 条码,国际标准条码,也可以使用内部自编条码,用于内部识别;
  • 图片,规格商品图片;
  • 标准售价,当前零售价格;
  • 批发价,给批发客户的价格;
  • 参考进价,进货时可以参考的采购价格,系统第一次采购时可以默认带出此价格作为参考;
  • 重量,寄快递称重时会参考商品重量;
  • 体积,货品的体积大小,用于适配合适的快递物流及运费计算;
  • 长宽高,用于适配合适的快递;

③ 自定义属性:可根据各自业务添加自定义属性进行标记;

可以看出,属性很多,靠自己想是行不通的,这也是分析行业系统的价值,把行业系统常用的对象和属性学来,也就入门这项业务了。

其他主要对象的属性写在腾讯文档,请访问https://docs.qq.com/sheet/DQVVBR2dTd2l4cUxs。

2)原型设计

最后进行原型设计,并编写文字标注,补充业务规则和交互规则等。做PC web网页设计时,这里推荐Element UI组件,记住常用的组件,会提高写标注的效率。为了体会万里牛ERP的规则和交互,我把万里牛的页面进行截图,并标注了万里牛的帮助文档,原型放在蓝湖,请访问 https://lanhuapp.com/url/g9n4K。

【尾巴】各位看官,由于是在现成的系统上进行分解推导,因此会存在一些上帝视角,有些用例和对象出现的逻辑没有那么顺畅,请大家见谅。另外,这些逻辑不顺畅的点,可能就是此类系统的行业知识,当你见过之后,也就认识和学习了这个行业的业务知识。

 

本文由 @王世翔 原创发布于人人都是产品经理。未经许可,禁止转载

题图来自Unsplash,基于CC0协议

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 非常牛逼

    来自广东 回复
  2. 非常的优秀!!!

    来自重庆 回复
  3. 牛逼

    来自广东 回复
  4. 期待更多这类的系统分析文章,nice

    来自湖北 回复
  5. 写的很好,期待更多干货

    来自广东 回复
  6. 前辈这拆解花了多久啊,可以加个好友吗?

    来自浙江 回复
    1. 学习理解系统、转化成自己逻辑、最后输出成文章,花了两个月。微信公众号:王世翔,公众号中有微信号。谢谢。

      来自广东 回复
  7. 加油加油向前辈学习

    来自浙江 回复
    1. 感谢支持。

      来自广东 回复
  8. 干活满满~~~

    来自浙江 回复
  9. 🐮

    回复
    1. 感谢支持!

      来自广东 回复
  10. 再次拜读,干货满满,感谢

    来自湖南 回复
    1. 感谢支持,哈哈。

      来自广东 回复
  11. 谢谢分享,给到了一个拆解产品的思路和方法

    来自湖南 回复
  12. 今天再次拜读了文章,有个疑问:为什么流程图内是从一级用例归纳出主流程呢?
    主流程是客户本身的主体业务流程,正如文章所说“不引入系统的角度,纯粹站在业务的角度,分析业务的主流程场景,获取业务用例。”

    来自广东 回复
    1. 这是个好的点。我个人的理解是,如果公司本身就有一套主流程,那是最好的了。但是现实情况往往是因为各个部门或者岗位之间的不了解,并没有存在一个清晰的主流程,只能访谈各个角色,串联各个角色的场景,获得主流程,算是一个重新梳理主流程的过程。总结就是如果业务方直接告诉你主流程,就用他的,如果没有就只能靠自己了。

      来自广东 回复
  13. 非常感谢,文章很受用。
    最近也在看大象uml,感觉你把这本书吃透了。
    我按照文章的思路,自己也在整理一篇关于B2C的进销存系统框架分析

    来自广东 回复
    1. 大象值得反复看,读书过程中,有疑问也可以一起探讨哈,关注我公众号,可以随时联系到我,共同进步。

      来自广东 回复
    2. 公众号是哪个

      来自浙江 回复
    3. 公众号:王世翔。

      来自广东 回复
  14. 很有意义

    回复
  15. 很详细,感谢分享

    来自北京 回复
    1. 感谢认可。开心😃。

      回复