订单体系作为商业活动的关键纽带，正随着业务发展和技术进步而演变。从涵盖全生命周期的业务架构，到拆单、拣货、售后等核心场景的精细化管理，未来订单中心将朝着稳定、高效、智能的方向发展，借助先进技术提升并发处理与业务拓展能力，重塑商业运营模式。
订单是一份合约，代表着消费者、平台和商家达成了某个协议；同时也是个载体，是仓库、物流、财务等多业务的基础和源头。
业务架构全景图
订单体系覆盖完整生命周期：创建 → 支付 → 履约（仓储/物流）→ 完成 → 逆向（售后）
从订单的全生命周期来看，订单连接了包括客户、营销、仓库、财务、支付等多个上下游，下面会挑几个核心场景来讲解怎么和上下游进行深入的交互。
拆单
什么是拆单
一个大的订单，按照某种规则，将其分解成两个或更多订单的流程，旨在提升履约灵活性和运营效率。
拆单策略
拆单目的是为了数据隔离、节约成本、提升业务效率。通常拆单分为2种拆单，系统自动拆单和人为手动拆单。
自动拆单
业务类型：不同业务类型，履约方式不同，需要进行拆单；
店铺：通用拆单原理，方便卖家跟踪订单与结算，以及实现店铺数据隔离；
支付方式：不同的支付方式会有不同的结算方式和结算周期，拆单便于财务对账；
商品：按商品拆分的场景又可以分类，比如商品所在的仓库不同、商品源头供应商不同（以销代采）、库存不足等；
物流：比如生鲜水果、奢侈品、大件、数量超出单包裹最大重量或体积等，一般都会进行拆单。
手动拆单
手动拆单是人工干预，保证业务的灵活性：
创建订单后：客户个性化要求；
仓库作业时：发现库存误差等，手动拆单；
配送时：响应包裹、快递要求拆单等。
拣货
订单拆单后，通过子单将信息精准传达到下游仓库，经过仓库复杂的工作流，将正确的商品送到客户手中。
拣货流程
标准作业流程：组波次-派单-拣货-分拣-复核-打包，每一步都会对应生成相应的单据和信息流转，而这些单据，都是基于原始的子订单生成或者核对。
简单梳理了订单拣货流程，后续可以基于仓库内部作业详细讲解仓库的设计。
实体关系
基于订单和仓库的对应关系，构建了一个订单域和仓库域与财务域主要单据的对应关系。支持多种支付方式、多收货状态、多售后的模式。
售后
售后是很繁琐，但是售后是用户体验的重要组成部分。日常接触较多的售后就有很多种，退货退款、仅退款、换货、维修等。
售后价值
平台的售后处理方式是窥见其整体战略倾向的重要窗口，反映了平台的客户价值主张，长期战略选择以及品牌定位。举几个例子：
售后体系
在设计售后单时，可以从业务场景以及售后责任方思考，梳理清楚售后场景。
1）业务场景
- 是否已经完成正向订单的支付
- 客户是否已经收到商品
- 已经收到的商品是否需要退回
基于以上业务场景，可以将售后类型分为以下：
2）责任方
商家责任
质量问题、发错商品、描述不符等。需要商家承担全部成本，包括订单金额全额退回、退回运费补偿、商家评分降低等。
客户责任
不喜欢、无理由、不想要了、使用不当等。客户会承担相应成本，例如退回运费、部分退款等。
售后设计
在理清了所有业务场景后，就可以开始设计售后流程，不同的售后类型，对应的业务流和资金流是不一样的。
1）业务流设计
例如仅退款，在用户申请仅退款后，商家同意后，可以直接进入结算环节；
退货退款，在用户申请仅退款后，商家同意后，就要引入物流环节；
换货，在用户申请仅退款后，商家同意后，需要引入2次的物流环节，买家退回商品后，卖家需要再次发货。
2）资金流设计
设计资金流时，主要考虑退款金额，包括正向订单中商品金额+运费以及退货和产生的运费。
例如，在1688等平台，售后是不退正向运费，且退货的运费也需要用户承担。
总结
如今订单的设计已不再是一个疑难杂症，对于订单中心，最核心关注的是：
- 稳定和高并发，业务的可拓展性；
- 订单效率的提升；
- 交易转化率的提升。
基于这三点，可以从以下方向着手：
1）借鉴行业最佳实践
借鉴阿里巴巴中台架构经验，采用领域驱动设计（DDD）思想构建订单中心，实现业务解耦与能力复用。
2）紧跟技术演进
向智能化、自动化方向发展，如利用AI算法优化波次分组策略，通过RPA技术简化人工拆单流程。
本文由 @诸葛铁铁 原创发布于人人都是产品经理。未经作者许可，禁止转载
题图来自Unsplash，基于CC0协议
