从0到1,学习订单管理体系

12 评论 34286 浏览 327 收藏 11 分钟

订单系统是看似简单,实际上是一个逻辑复杂的系统,具体的流程设计,应与自身的业务紧密结合,同时涉及到与其他各大系统的紧密配合,需要不断的去优化,让各个系统的配合更加流畅多样。

一、概述

接受客户订单信息,以及仓储管理系统发来的库存信息,然后按客户和紧要程度给订单归类,对不同仓储地点的库存进行配置,并确定交付日期,这样的一个系统称为订单管理系统。

订单管理是物流管理的一部分,是电商体系的核心部分,它承载着服务与客户交互的整个过程记录。本文是近段时间的学习和总结,希望通输入-计算-输出的模式,加强对内容的理解。

二、订单系统与其他系统的关系和架构

订单系统的作为整个电商体系的中游,对上承接用户信息,将用户信息转化成产品订单,同时管理并跟踪订单数据;对下与各个系统配合协作,实现整个电商体系的闭环,在整个电商平台起着承上启下的重要地位。

三、订单管理解构

1. 订单信息

由支付信息、商品信息、订单基本信息、优惠信息、收货信息、用户信息、物流信息和其他信息,这些信息来源于其他系统的信息,一起构成全面的信息记录。

2. 订单状态和状态机

订单状态是交易进展的反馈,是订单流程的一个个连接点。不同业务类型的订单状态,例如机票、服务订单、商品服务订单等,和最常见的纯实物商品的订单状态会有所区别,但订单状态总体有以下几种类型:(下图是来源网络)

状态机是订单状态逻辑的工具。状态机可以分为三个要素:现状、动作、次态。

  • 现状:指当前所处的状态;
  • 动作:指状态发生转变的操作;
  • 次态:动作满足后新产生的状态。

状态机是流程的一种补充,其设计也需要结合平台的实际业务场景,以一个商品订单为例:

通常,订单的状态的变更伴还随着订单的推送,涉及到的信息包括:

  • 推送对象(用户,商家,仓库)
  • 推送方式(站内消息,push,短信,微信模板消息)
  • 推送节点(状态机变更)

3. 订单流程

订单流程是指整个订单从产生到完成的整个流转过程。不同的服务模式对应的订单流程都会根据自身的业务进行调整。

从典型的电商订单流程切入,拆解为:正向流程、逆向流程。

(1)正向流程

正常下单,下图为订单完整的的流程:

拆单流程:拆单,指客户在下单之后,出于发货和结算的角度,对订单进行拆分。

1. 拆单的影响因素

  • 商家:商品不属于同一家商家,需将订单拆分,便于商家的结算、和发货管理。如淘宝多家商品一起结算,会以商家为基线,拆成不同的订单。
  • 仓库:同一商家,不同仓库,发货配送不同,商品物流信息和到货时间不一致。
  • 品类:产品为特殊品类的,如易碎品,需与其他商品分开包装。
  • 物流:不同的物流公司对单个包裹的重量或体积有特殊要求,需要根据sku的毛重和体积计算包裹重量和体积,超出物流公司限制的也需要拆单。

2. 拆分规则

  • 父单必须拆净,即父单商品数量等于子单商品数量之和。
  • 父单商品金额、运费、支付金额、虚拟币金额、优惠金额要与子单金额相等。
  • 子单实付大于0。
  • 第三方订单按商家维度拆分、自营(不包括虚拟和厂商直送、线下交易等特殊订单类型)按库房维度拆分。
  • 赠品不分摊优惠,延保必须跟主单。

3. 拆单流程图

(2)逆向流程

在订单生成之后,订单在各个状态的流转过程中,都可能会出现逆向流程,分为:仅退款和退货退款。

在不同节点发生,系统的处理方式不同。

1. 待付款取消订单

当用户提交订单后主动取消订单或者用户超时未支付时,订单的状态变更为“已取消”,无需经过客服审核。

2. 待发货取消订单

当订单在“待发货”状态时,用户申请取消订单,如下图所示,由于用户在支付订单后,发货单可能已经推送至仓储系统,甚至已经交接发货,状态未及时回传更新。为避免货款两失要进行订单拦截,若拦截失败,则拒绝“取消订单”申请,回复原因“订单已库”;若拦截成功,“取消订单”申请通过,进入退款流程,同时通知调度中心该订单取消,订单进入返库流程。

3. 待确认收货/交易完成

在待确认收货中申请退款,一般商品已经进入物流配送环节到达用户手中,此时的逆流程分为退款/退货退款,下面分别就两种情况进行说明:

退款

这种场景一般是:物件损坏、快递丢件、错发漏发。

退货退款

在待收货或者交易完成后的退款,流程如下,卖家同意退款前的流程与退款的流程类似,但在同意退款后,买家端会看到卖家的退货信息,包括姓名、地址、电话等退货相关信息,用户在寄出商品后,商家会进行验收确认,确认无误后再进行退款,如果在验收环节有问题的话,一般会走线下协商,要么将货品发回给用户,要么退部分款项。

以上为主要的售后场景流程,但订单的逆向流程复杂多样,需要兼顾业务场景。期间涉及到与仓储系统、财务系统的配合协作。保证数据变化的可追溯性,每一次数据的变化,都不能直接在原数据上直接修改,而需要生成相应单据凭证。

4. 订单数据

订单沉淀下的数据和信息,对平台的运营和产品的改善起着关键的指导作用。可分为常规统计和流量分析统计。

(1)常规统计

常规统计,一般指财务数据方面的统计,主要包括销售额、毛利、成本、纯利润、客单价等。

(2)流量分析统计

侧重于指导平台运营的数据,如访客数、浏览量、支付转化率等。

在订单流量分析中又分为三个维度,分别从订单交易纬度、商品纬度、订单来源等三方面来分析。

  1. 订单交易维度:订单销售额、订单数量、客单价、下单用户数与支付用户数、订单金额分布梯度、地域分布;
  2. 商品维度:被下单商品数、被支付商品数、被访商品数、商品收藏次数、商品销量统计;
  3. 订单来源:订单的来源媒介和用户端,记录每个订单的产生流程,追踪订单来源。

四、总结

订单系统是看似简单,实际上是一个逻辑复杂的系统,具体的流程设计,应与自身的业务紧密结合,同时涉及到与其他各大系统的紧密配合,需要不断的去优化,让各个系统的配合更加流畅多样。

经过这一段时间的学习,也只能了解到一些基本的要素和流程,希望通过整理和输入,帮助自己更好的学习和掌握,也希望对他人有所帮助。

参考资料:

《电商经理产品宝典》

《订单系统:从0到1设计思路》

百度百科

 

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

题图来自 Pexels ,基于 CC0 协议

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 写的很详细,从标题的目的来看,从0到1的认知,绝对满足了,

    回复
  2. 请问泳道图是用什么工具画的,谢谢。

    来自北京 回复
  3. 一个地方不是很了解,为什么拒绝取消订单,就直接到结束了呢,不是订单按照正常发货流程走吗?

    回复
    1. 那里指的是取消订单流程的结束

      来自广东 回复
  4. 没有确认订单环节吗?不是确认下单前要检查库存。确认订单后再一下检查库存,若无库存,下单失败,有库存下单成功。

    来自上海 回复
    1. 要结合商品看,有些场景可以不用校验库存的, 常规的一般都需要校验库存。库存的校验,是订单能否生成的关键因素,题主可能没怎写这块,更多都是订单履单层面的东西

      来自广东 回复
    2. 什么场景下不用校验库存呀

      来自广东 回复
    3. 在线教育虚拟产品,不需要校验

      来自广东 回复
  5. 订单发生状态改变时。需要记录动作?场景如下审核点单是,点开订单后查看,并没做出审核同伙或者驳回,状态要记录为审中吗?这就结束了?

    来自上海 回复
  6. 你们的商家结算规则会在订单中提现吗?比如结算价的计算规则、佣金的计算规则

    来自浙江 回复
    1. 这个不是财务系统的内容吗

      来自广东 回复
    2. 先分清什么系统做什么事情。两个系统交互。唯一标识符是什么

      来自中国 回复