电商后台系统流程如何设计?

电商后台设计的业务较多,功能模块较为复杂, 一个完整的电商系统设计用户、供应商、订单、物流、理赔、纠纷、退换货、物品、推荐、品牌、品类、支付平台、促销、日志、刷新、安全管理等业务功能模块。 我想
阅读全文
请先 登录 后评论
  • 0 关注
  • 0 收藏 79 浏览
  • 略问用户 提出于 2020-10-22 17:36:03

8 个回答

xxxxxa

我认为,要想画出清晰的流程图,需要经历:定义角色、定义实体、定义实体状态、定义行为、定义分支条件、绘制流程6个步骤。

1、定义角色

就是明确在整个流程中,都有哪些人,或哪些系统会参与。以电商为例:

按参与人分,可以是:

前台:消费者、卖家、平台客服

后台:卖家、代理商、供货商、库管、物流人员、财务人员

按参与系统分,可以是:

前台:电商网站、账户中心、支付系统

后台:商品管理系统、订单系统、客户关系管理系统、客服系统、工单系统、供应链系统、财务系统、物流管理系统、库存管理系统等等。

一般来说,人和系统角色,需要同时出现在流程图中,以人在系统中的任务流转为主,系统和系统间的任务流转为辅。

2、定义实体

实体,就是各角色在系统中执行任务的承载物,通常是线下流程实物在线上的虚拟替代。比如消费者购买的“商品”,购买时产生的“订单”,客服处理的“工单”,财务处理的“发票”,物流处理的“运输单”、库存处理的“货架位置”。

3、定义实体状态

角色在执行任务时产生的实体,会根据不同条件,产生不同状态。如“订单”这个实体,就会有“待支付、已支付、已发货、已收获、申请退款、已退款、已完成”等状态;“工单”实体,会有“待指派、已指派、已处理、无需处理、已完成、已关闭”等状态。需要产品经理根据不断和业务方沟通,把可能场景下的状态都穷尽罗列出来。

4、定义行为

就是指角色在业务流中需要执行的操作,比如对于客户,有:放入购物车、下单、支付、收货、评价等;对于卖家,有:采购商品、录入商品、上架商品、确认订单、取消订单、发货、退货等,不同行为,会对不同实体产生不同状态的变更。

5、定义分支条件

所谓分支条件,就是指角色在执行操作,产生行为时,由于进行了不同条件的选择,而触发的实体状态的变更。比如客户在下单后,如果执行了“取消订单”行为条件,订单状态就会变更为“已取消”,如果执行了“支付”行为条件,订单状态就会变为“待支付”;进一步,如果条件为“支付成功”,订单状态变为“已支付”,如果条件为“失败”,订单状态仍旧是“待支付”;再进一步,如果条件为“支付超时”,订单状态就变为“已取消”。

6、绘制流程

把每个角色,每个行为,在不同分支条件下,产生的实体,及实体状态,全部绘制出来,用线连接起来,就是一套完整的流程图了。 

请先 登录 后评论
xxxxxa

关于这个问题,我是这样来看的。首先做电商系统的产品实际上是一个你了解业务的过程,对于电商系统的设计是否合理、全面;主要取决于你对于要做的这块业务了解有多深;

从后台结构上来说从两个方面来梳理,第一从业务角度来看:你首先要确定业务有哪些、部门有哪些?同时对应的它可能会存在哪些场景,其次你需要知道在这些业务里边,哪些是能够功能化的,哪些是场景涉及流程及相关的部门人员。

第二,从数据结构来看,哪些环节、业务节点内容涉及到多系统的协同工作、以及数据流向及系统间的整体运转。

举例说明:就退换货而言,一个较为完整B2C流程会涉及到 电商系统,工单系统,ERP系统、WMS 系统,那么同一个订单在这些系统之间是如何流转,与原订单关系是否存在冲销,状态的变更是在既有数据调整还是创建新数据;这些都需要根据实际业务场景来设计。

关于后台角色、状态、类型,我是这样看的

角色的设计是以业务场景这个维度来展开的,主要来看你具体有哪些人在使用这个系统、以及角色之间的关系;

类型是否完整取决于2个方面,1呢就是你在需求阶段通过对业务流程的了解是否掌握了足够的信息,其次同类型竞品的分析;2呢类型在产品框架上是需要灵活去配置,以避免以后业务灵活变动造成的既有的处理逻辑调整

举例:订单类型就有:换货、退货、普通、线下、赠品、领用、合约、团购、预约),这里边每一个类型都是一个场景。

状态是否正确,可以通过流程来判断(例如:退款,是否需要有审核,审核是否需要做成2级审核制度),再者,订单创建是否需要确认

请先 登录 后评论
xxxxxa

那么多功能模块貌似杂乱无章,其实是有一条暗线把他们串联起来的。

我是这么想的,这些系统其实只是一个支撑作用。一家夫妻小卖店,找批发商,谈进货价,进货,订售出价,摆上货架(什么位置放什么商品),成交,退货,核算利润,再周而复始这个循环。这是线下商家的业务流程。

粗略地以这个业务流程为线索,移植到线上来。每个环节用系统来改造,具体如下。

①找批发商、谈进价---->反应到系统上,这个模块就是供应商管理:内容包括供应商列表,包括评分、能供什么货、库存多少、最低价格多少等。

②进货--->看两点。一看与供应商的协议,是代销还是自销。二看商品类型,如果是实物,涉及仓储物流。如果是票务、旅游线路等虚拟商品。那就没有仓储什么的。

③订售出价---->看与供应商的协议。如果是经销商,那么供应商可能会有统一管控,价格需要全国统一,卖出一件有返点多少。如果是买进自卖,那么价格可以自己来定,“售出价-进货价-其他”就是这件商品的利润,其他包括服务费什么的。

④摆上货架---->就是上架商品放到网站上,什么坑位放什么东西。

⑤成交---->用户下订单并支付

⑥退货---->管理订单

⑦核算利润---->财务对账啥的。

粗略对应系统就是,

①②就需要供应商管理系统。货物进回来之后,

③④就需要商品后台管理系统,来定义编号、统计库存、定售价、上货架

⑤交由C端网站来完成。

⑥交由订单管理系统。主要管理订单,需要记录所有订单的所有状态,一般状态包括:待支付、已支付、已发货、申请退款、已退款、已完成等。这个是核心模块。

⑦需要收款系统,或者拉出报表。主要依据单位时间内已完成的订单,核算售出价与成本价,来计算。

其他的,存在系统,就会涉及权限,有权限就会有角色之分。主要根据他能在系统里看到什么,不能操作什么来分。建议从最底层开始划分。比如,客服只能查订单,能协助用户进行退货操作。比如运营人员,需要上架货品和定义售价,那么可能后台管理系统就需要所有权限。等等。

再说做运营活动,需要有商品运营系统,这个就是快捷工具,需要达到一定体量,后期才需要。

通用的我理解就这些,欢迎补充。

请先 登录 后评论
xxxxxa

针对第一个问题:

第一步,首先要梳理主要的业务流程,包括正向流程和反向流程。可以模拟一件商品,从采购入库,从用户在前端浏览下订单支付,到后台接单,最后到用户手中,中间经历了哪些流程。这是一个正向的流程。但电商还涉及到一个反向的流程,就是用户收货后退货或拒收的情况下,商品返回的一个流程。结合正向流程和反向流程,可以梳理出核心的业务模块。

第二步,在确定主要的核心模块后,要考虑到很多极端情况。比如前端短时间内涌入大量订单,超过库存,要怎么处理等情况。由此,完善主要的核心模块。

由上面可以看出,做后台一定要熟悉业务。不仅要对核心业务流程聊熟于心,同时对核心流程之外的流程也要熟悉。核心流程可以多和运营商务的同事沟通,而极端情况可以和客服多交流。客服处理的很多情况都是极端情况。

其次,做后台对数据结构也要有一定的理解。后台的字段从数据库哪张表传递过来,订单的状态从哪里传递过来又传到哪里去,要有一定的理解。懂得数据结构,做后台如鱼得水。

针对第二个问题:

其实回答第一个问题同时也回答了第二个问题。

比如做采购管理,可以模拟下采购流程。下采购单的是采购人员,审核订单的是财务人员。不同的岗位配置不同的权限。采购单的状态,有发起采购、采购单审核、采购单审核通过、采购单审核不通过等等。采购单的状态和人员权限的分配是相对应的。熟悉了业务,自然对角色、类型和状态的设置清晰了。

请先 登录 后评论
xxxxxa

下个ecshop自己梳理一遍。

请先 登录 后评论
xxxxxa

1,要先确定,是有电商平台,在有业务,还是现有业务,再有电商平台,前者可以参考下目前成熟的平台,如果是后者,那比较被动了,现有的业务体现是否完成,要自己评估,挪到电商来,根据业务有什么坑在,都要自己研究了。
最好还是用VISIO这里的聊描绘一个个销业务体,脑图只是告知别人有什么模块,模块和模块间有什么关联,(个人小见解)


2,后台的角色,都是按功能区域来划分权限,利润仓管的, 审单的,销售提单的然后他们分别使用什么功能呢,功能点能使用的范围(可看,可批之流)根据角色的定位来定义平台中他管辖范围

请先 登录 后评论
xxxxxa

最近也在做电商项目,我的思路是先了解所有正在使用这套系统的人以及他们做的事(或者即将),然后按照角色将他们个人的业务线用流程图画出来,之后再在这个基础上将业务主流程梳理出来。 这个完成以后就可以用脑图来画框架了。

这个阶段,为了让后台模块更清晰,我使用的是 MATRIX 模板来画。 这个继续往下梳理就可以把所有页面的信息都涵盖进去,之后再画后台原型图对照这个就可以了。

Screen Shot 2016-11-25 at 8.41.12 AM.png

请先 登录 后评论
xxxxxa

image.png

请先 登录 后评论