逆向解构万里牛电商ERP,实践可推导产品分析方法
编辑导语:这篇文章作者从系统全局分析、系统详细分析和熟悉的系统原型设计三方面入手,详细地向我们展示如何逆向解构万里牛电商ERP,通过自己的实践推导出其产品分析方法,作者把书里的知识学以致用,非常值得我们学习借鉴,一起来看一下吧~
在此我想感谢谭云杰老师的《大象—Thinking in UML》,我深受这本书的启蒙,这本书不是单纯的讲UML,而是讲软件过程,软件分析方法。反复研读后,我把书中的思想慢慢内化成自己的产品分析方法,实现可以一步步推导的分析方法,并运用在本次文章上。
本文有1.3万字,请保持耐心。
此次本着学习的态度解构万里牛ERP(专业版),我是从万里牛的页面和功能入手,逆向分析得到关键输出物和原始需求,以此深入学习电商ERP的业务。
获得关键输出物后,本文是以正向设计的逻辑进行描述,还原从需求到原型的设计过程。
本文按分析粒度大小,分为三部分,如图1:
- 系统全局分析,分析粒度保持在模块管理,目的是获得系统的全局认识。
- 系统详细分析,分析粒度变小,保持在增删改查功能的粒度,目的是获得全部系统用例。
- 熟悉的系统原型设计,分析粒度变小,保持在页面和元件交互,目的是获得可交付的原型和标注。
图1 分析逻辑
一、系统全局分析
系统全局分析,分析粒度保持在模块管理,目的是获得系统的全局认识。第一节是从业务的角度获取需求和用例,第二节是从系统的角度获取需求和用例,我称这个粒度为一级用例,第三节和第四节是在前两节的用例基础上分析主流程和对象。
1. 业务用例
在软件项目里,业务范围和系统范围是不同的。业务范围指这个项目所涉及的所有客户业务,这些业务有没有计算机系统参与都是客观存在的。系统范围是指软件将要实现的那些对应于业务功能的系统功能,从功能性需求来说系统范围是业务范围的一个子集,但是一些系统功能则会超出业务范围,例如操作日志,有没有操作日志并不影响业务目标的达成,客户也不一定会提出这个要求,但从系统角度出发,操作日志会使得系统更加健壮。
——来自《大象—Thinking in UML》
在引入计算机系统之前,业务也一直跑得很顺畅,因此在初始阶段,不引入系统的角度,纯粹站在业务的角度,分析业务的主流程场景,获取业务用例。
获取业务用例需要分析出业务主角和用例,业务主角即参与到业务流程中的角色,例如采购员、售前客服等。用例即业务主角需要在业务流程中完成的事情,这里需要注意用例的粒度,我经过思考,系统全局分析阶段,建议使用管理一类事物的粒度,例如销售订单管理,这个粒度仅供参考。
开始获取业务用例,以下是一段商家工作内容的场景。
店长小明想开一家网店,在商品上架销售前,小明做了以下准备工作:
- 在淘宝注册一个店铺;
- 选择想要做的品类和卖的商品,并维护商品信息;
- 找合作快递公司,用于发货给客户;
- 找仓库,用于存储采购的商品;
- 店长还需要关注店铺各业务的运转情况,即查看销售、采购、库存、资金的报表。
除此之外,还招了6个岗位一起合作:
- 采购员,负责采购商品补充库存;
- 售前客服,主要为买家介绍商品特性和解答销售方面的问题,买家下单后审核订单;
- 发货员,对通过审核的订单进行配货打包,进行发货;
- 售后客服,主要为买家解答售后方面的问题,并审核买家发起的退换货申请;
- 仓库管理员,记录商品的出入库和管理商品库存;
- 财务员,记录销售订单和采购的资金出入。
团队到位了,可以开展工作了。
采购员根据店长选好的商品进行采购工作,联系供应商采购商品,即提交采购订单。采购订单的货品到了之后,需要仓库管理员记录采购入库单,并为商品安排库位和增加商品的库存。商品入库后,采购员和供应商登记结算单。如果到货的商品有问题则进行退货处理,即提交采购退货单,采购商品出库时需要仓库管理员记录采购退货出库单,并减少退货商品的库存。
至此,把商品上架在淘宝,就可以开始接单了。当买家在淘宝下单并支付后,订单的处理就交给售前客服和发货员了。
首先售前客服会审核订单,如有注意事项可对订单进行备注,例如有什么赠品、指定发什么快递等,通过审核的订单即流转给发货员。发货员在仓库中进行配货并打包,最后打印快递单,进行发货。发货时,需要仓库管理员记录销售出库单,并减少销售商品的库存。
另外小明还希望发展一下线下大客户,所以有的售前客服在线下开拓客户。客户可直接和售前客服下单,售前客服创建订单,然后流转给发货员。发货员在仓库中进行配货并打包,最后打印快递单,进行发货。发货时,需要仓库管理员记录销售出库单,并减少销售商品的库存。
以上是正向的交易流程,买家下单,商家发货。当买家提出退换货的时候,就需要售后客服介入。买家在淘宝提交了退换货申请,售后客服进行审核是否同意退换货,审核通过后,买家寄回商品。寄回商品到达指定退货仓库后,仓库管理员记录退货入库单,并更新商品库存。如果是退货,售后客服进行退款处理,如果是换货,售后客服根据售后单,手动创建销售订单,然后该销售订单正常发货。
仓库管理员日常工作除了记录销售订单、采购订单的出入库单外,平时需要维护仓库的基础数据,库区、库位等,并且记录商品的摆放位置。每次商品出入库都会更新库存,定期查看各商品的库存数量。还会为了保证商品数量安全,定期对仓库的商品数量进行盘点。如果商品的成本近期发生变化,还会对商品进行调价。当前小明拥有两个地方的仓库,有时候需要进行商品调拨,即仓库管理员把A商品从甲仓库调拨到乙仓库,调拨出库和入库时也都需要记录调拨出库单和入库单。
以上是采购订单和销售订单的场景,每次商品出入库,都伴随着资金的收支变化,所以财务员有以下日常工作。首先,财务员需要维护资金账户基础数据,其他主要工作就是收款、付款、账目对账检查。
收款主要是收取销售订单的钱,有三种收款方式:现金收款、充值款消费(预收款)、赊账(记录应收款)。现金收款是买家下单时进行支付费用,例如淘宝订单。充值款消费是买家提前充值费用存在该客户的账户上,然后下单时进行扣减,主要适用于线下订单。赊账是买家下单时不进行付款,客户账上也没有充值款可以扣减,这样就会记录该客户的应收款,然后定期收款,并记录收款单,适用于月结的客户。
付款是支付给供应商采购订单的货款和支付给快递公司的快递费。有三种支付方式:现金支付、充值款支付(预付款)、赊账(记录应付款)。现金支付是采购订单到货后现金支付货款给供应商。充值款支付是预存充值费用在某个供应商那,每次采购单到货后选择使用充值款支付货款。赊账是采购订单到货后不支付货款给供应商,然后记录该供应商的应付款,定期付款,并记录付款单,适用于月结的供应商。
快递费目前是选择月结的方式结算。为了保证账目的准确,财务员会定期进行快递单对账。
有时候需要转移资金,即财务员把资金从A账户转到B账户,则进行转账。财务员在有资金往来的时候都会记录资金流水。
基于以上场景,获取业务主角和提炼一级用例,如图2。
图2 业务用例
1)店长
是店铺的管理者,会管理基础数据和查看报表:
- 注册淘宝店铺,即管理店铺;
- 选择销售的商品,即管理商品;
- 选择合作的快递公司,即管理快递公司;
- 确定仓库,即管理仓库;
- 查看报表。
2)采购员
负责采购商品,会管理采购相关的事项有:
- 选择供应商进行采购,即管理供应商;
- 提交采购订单,即管理采购订单;
- 采购商品入库后和供应商进行结算,即管理采购结算单;
- 如有商品需要退货,提交采购退货单,即管理采购退货单。
3)售前客服
是销售订单的跟进人,会管理订单相关的事项有:
- 线下开拓客户,即管理客户;
- 审核销售订单,保证订单顺利完成,即管理销售订单。
4)发货员
负责对销售订单进行配货、打包、发货:
- 参与管理销售订单的发货流程;
- 打印快递单,进行发货。
5)售后客服
负责审核售后单,即管理售后订单。
6)仓库管理员
负责仓库商品的库存安全,会管理仓库相关的事项有:
- 维护库存的存储区域,会参与管理仓库;
- 采购商品到货后,记录采购入库单,即管理采购入库单;
- 采购退货商品出库时,记录采购退货出库,即管理采购退货出库单;
- 销售订单商品发货时,记录销售出库单,即管理销售出库单;
- 销售退换货商品退回仓库时,记录销售售后入库单,即管理销售售后入库单;
- 记录商品库存更新记录,即管理库存;
- 定期盘点商品库存,即管理库存盘点单;
- 定期盘点商品成本,即管理成本调价单;
- 把商品从甲仓库调拨到乙仓库,即管理库存调拨单;
- 调拨商品出库记录,即管理调拨出库单;
- 调拨商品入库记录,即管理调拨入库单。
7)财务员
负责资金的往来,会管理财务相关的事项有:
- 管理资金账户;
- 帮助客户充值预收款,记录每次消费或充值后,客户预收款余额,即管理预收款单;
- 客户订单未支付结算,会记录应收款,即计算应收款;
- 对销售订单的应收款进行收款,即管理收款单;
- 充值到供应商的预付款,记录每次付款或充值后,供应商预付款余额,即管理预付款单;
- 采购订单未支付结算,会记录应付款,即计算应付款;
- 对采购订单的应付款进行付款,即管理付款单;
- 定期进行快递单对账,即管理快递对账;
- 记录资金转账,即管理转账单;
- 记录资金往来,即记录资金流水。
2. 系统用例
得到业务用例后,虽然能看到业务主流程的雏形,但要完成系统的闭环还需要站在系统的角度去补充用例,例如系统权限管理的需求,业务用例中并没有体现出来。
系统用例也是需要获得角色和用例,这个阶段的用例粒度和上一步骤的业务用例保持一致,即管理一类事物。
开始获取系统用例,我站在系统的角度,从三个方向分析系统需求:
- 系统管理的需求
- 系统易用性的需求
- 系统扩展性的需求。
于是我列出了以下场景的需求:
- 万里牛ERP是一款SaaS产品,会服务多家公司的客户,所以需要创建一家公司才可使用系统。
- 每个系统都需要考虑权限管理,所以系统管理员需要维护角色权限,才能够管理公司员工的权限。
- 系统管理员需要创建员工,为员工分配账号,员工才可以登录系统开展工作。
- 万里牛ERP服务多家公司,各家公司的需求会存在差异性,需要做到高可配置化来支持差异化需求。
- 每个用户需要注册、登录、修改密码等账号相关的功能。
- 用户想及时得到订单状态更新、库存预警等消息,方便跟进,提供消息通知功能。
根据上述场景的需求,获取到系统用例,和业务用例放在一起,展示所有一级用例,如图3。
图3 一级用例
1)系统管理员
- 需要创建公司才能使用该系统,由他管理公司;
- 需要管理员工的权限,由他管理角色;
- 需要维护员工信息,由他管理员工;
- 需要配置系统以实现差异化的功能,由他管理系统配置。
2)全部用户
- 每个用户都需要进行注册登录,进行管理账号;
- 每个用户都需要获取消息通知,支持消息通知。
3. 主流程分析
主流程就是按某种逻辑把主要的一级用例组合起来,归纳出几条主流程,验证是否可以实现业务目标。得到主流程可以对系统有全局的认知,也能辅助后续的对象分析。
电商日常主要处理两大业务,采购和销售。采购和销售都有正向流程和逆向流程,即采购主流程、采购退货主流程、销售主流程、销售售后主流程。这4条主流程中都会引起库存更新和资金收支,所以除了商品出入库过程,也要关注库存变化和资金收支。
外加一条系统管理主流程,合计5条主流程。
1)采购主流程
主要是提交采购订单,到货后进行入库,并更新库存和支付货款,如图4。
图4 采购主流程
- 提交采购订单:①采购员在管理供应商模块创建供应商,供采购订单引用;②采购员在管理采购订单模块创建采购订单,需要选择在哪家供应商采购什么商品;
- 货品入库和更新库存:③提交采购订单后,仓库管理员在管理库存模块增加该商品的在途数量;④待采购商品到货后,仓库管理员在管理采购入库单模块创建采购入库单;⑤入库后,仓库管理员在管理库存模块增加商品库存;
- 支付货款:⑥财务员在管理资金账户模块创建采购资金账户;⑦入库后,采购员确认采购商品没有问题,在管理采购结算单模块创建采购结算单,支付金额为0,计算应付款;⑧付款日期到了,根据结算单,财务员在管理付款单模块创建付款单进行付款;⑨付款后,财务员记录资金流水。
2)采购退货主流程
主要是提交采购退货单,退货商品出库,并更新库存和收回退款,如图5。
图5 采购退货主流程
- 提交采购退货单:①如果采购商品存在问题需要办理退货,采购员在管理采购退货单模块创建采购退货单;
- 退货商品出库和更新库存:②提交采购退货单后,仓库管理员在管理库存模块增加商品的锁定数量,可用库存等于【商品在库数量】减去【锁定数量】;③退货商品出库,仓库管理员在采购退货出库单模块创建采购退货出库单;④出库后,仓库管理员在管理库存模块减少商品库存;
- 收回退款:⑤出库后,采购员在管理结算单模块创建采购退货结算单,让供应商退款;⑥若供应商没有退款,根据采购退货结算单,财务员在管理付款单模块创建退款单收回退款;⑦退款后,财务员记录资金流水。
3)销售主流程
主要是处理销售订单,进行发货,并更新库存和订单收款,如图6。
图6 销售主流程
- 审核订单和发货:①售前客服在管理客户模块创建客户,客户供线下订单引用;②售前客服在管理销售订单模块创建线下订单,或者审核线上淘宝订单;③订单审核通过,发货员在管理销售订单模块进行配货、打包、发货等工作;④发货时,发货员为订单打印快递单,用于快递运输;
- 订单商品出库和更新库存:⑤新增销售订单后,仓库管理员在管理库存模块增加商品的锁定数量,可用库存等于【商品在库数量】减去【锁定数量】;⑥发货时,仓库管理员在管理销售出库单模块创建销售出库单,如果订单之前没有支付过,计算应收款;⑦出库后,仓库管理员在管理库存模块减少商品库存;
- 订单收款:⑧财务员在管理资金账户模块创建销售资金账户;⑨如果出库后,订单没有支付过,根据销售出库单和应收款,财务员在管理收款单创建收款单进行收款;⑩收款后,财务员记录资金流水。
4)销售售后主流程
主要是审核销售售后单,等退货商品入库后,更新库存和售后单退款,如图7。
图7 销售售后主流程
- 审核售后单:①如果有客户发起退换货售后单,售后客服在管理售后单模块审核售后单;
- 退换货商品入库和更新库存:②同意退换货后,仓库管理员在管理库存模块增加该商品的在途数量;③收到客户寄来的退换商品,仓库管理员在管理售后入库单模块创建售后入库单;④入库后,仓库管理员在管理库存模块增加入库商品库存;
- 售后单退款或换货:⑤收到退换货的商品无误后,如果是退货,售后客服在管理售后单模块操作退款,如果是换货,售后客服在管理售后单模块直接创建销售订单进行换货;⑥如果退款,财务员记录资金流水。
5)系统管理主流程
主要是创建公司并邀请员工加入公司,之后进行系统配置和维护基础数据,如图8。
图8 系统管理主流程
- 系统管理员首次登录系统时创建公司;
- 系统管理员在管理角色模块创建角色和配置权限;
- 系统管理员在管理员工模块创建员工或邀请员工,并为员工分配角色;
- 员工在管理账号模块接受邀请进入公司,并登录系统;
- 系统管理员在系统配置模块配置自定义的参数;
- 店长维护基础数据供采购流程和销售流程引用,在管理店铺模块创建店铺、在管理商品模块创建商品、在管理快递公司模块创建快递公司、在管理仓库模块创建仓库。
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协议
非常牛逼
非常的优秀!!!
牛逼
期待更多这类的系统分析文章,nice
写的很好,期待更多干货
前辈这拆解花了多久啊,可以加个好友吗?
学习理解系统、转化成自己逻辑、最后输出成文章,花了两个月。微信公众号:王世翔,公众号中有微信号。谢谢。
加油加油向前辈学习
感谢支持。
干活满满~~~
🐮
感谢支持!
再次拜读,干货满满,感谢
感谢支持,哈哈。
谢谢分享,给到了一个拆解产品的思路和方法
今天再次拜读了文章,有个疑问:为什么流程图内是从一级用例归纳出主流程呢?
主流程是客户本身的主体业务流程,正如文章所说“不引入系统的角度,纯粹站在业务的角度,分析业务的主流程场景,获取业务用例。”
这是个好的点。我个人的理解是,如果公司本身就有一套主流程,那是最好的了。但是现实情况往往是因为各个部门或者岗位之间的不了解,并没有存在一个清晰的主流程,只能访谈各个角色,串联各个角色的场景,获得主流程,算是一个重新梳理主流程的过程。总结就是如果业务方直接告诉你主流程,就用他的,如果没有就只能靠自己了。
非常感谢,文章很受用。
最近也在看大象uml,感觉你把这本书吃透了。
我按照文章的思路,自己也在整理一篇关于B2C的进销存系统框架分析
大象值得反复看,读书过程中,有疑问也可以一起探讨哈,关注我公众号,可以随时联系到我,共同进步。
公众号是哪个
公众号:王世翔。
很有意义
很详细,感谢分享
感谢认可。开心😃。