下面这篇是笔者整理分享的关于多平台电商订单履约系统设计的文章，包括订单履约系统架构设计、订单履约业务流程、订单履约系统订单状态流转等相关内容，感兴趣的同学可以来看看哦！
最近终于完成了自己所负责的SaaS产品的电商订单履约系统模块重构，原本以为对该模块已沉淀了一年，吃透了竞品、聊过了用户、梳理过了旧逻辑，那么做起来应该十分顺利。结果，还是逃不过几个通宵的写方案和该方案。
这篇文章我们一起聊聊电商订单履约系统设计，以此也总结复盘一下我的第一个大项目。
首先，为大家简述下这款SaaS产品的背景。它是一款面向中小微商家的多平台电商及自建商城订单履约系统。由于定位于中小微商家，系统并没有涉及预分仓、仓库/门店下发等功能。
但是，我仍然选择这次重构在系统架构设计上将履约全流程纳入设计范围，只是在业务功能实现的时候，我们做功能的精简、流程的跳过以及根据实际产品情况做改动。原因很简单：升维设计，降维打击。这样子设计出来的系统虽小可大，具备拓展性。（谁也说不准，明天老板就让做一个供应商代发的系统)。
何为订单履约？订单履约就是从订单交易产生后，交付给用户包括售后的全过程。系统的主要实现目标是能高效、准确、透明的完成订单履约全过程。
我们的系统主要承接了两部分的订单来源：第三方电商平台和自建商城。第三方平台是用户在淘宝、天猫、拼多多等平台上开的电商店铺。自建商城是用户自行搭建的商城系统，通过API的方式将订单导入到的系统。
订单进入到系统后，用户的业务目标是：
那么，根据用户的业务目标，我们可以设计以下的系统架构：
However，通过阅读了《实战供应链》全局了解了订单履约全流程后，发现“订单打印”放在订单履约中心并不妥当。我们可以先从下图看订单履约全流程：
可以看到，在履约全流程里面订单打印是在下发库房后发生的，结合业务场景来看，包括快递单在内的各类单据打印确实是在库房里面进行，以及该系统操作背后是有拣货、打包等作业流程。
如果将订单打印放在订单履约中心的话，后续若增加分仓发货、波次生成等功能时，会导致订单履约中心职责不明确、订单混乱（若按仓库拆分订单的话，库房会单独成单。放到履约系统的话，会影响到原本的父子结构）。因此，我们可以做以下调整：
在这个架构中，我们将【订单打印】抽出来成为“WMS”。
不过，此WMS非WMS，按照当前的公司战略来看，“WMS”只需要承载订单打印（包括但不限于快递单、发货单、拣货单、拿货单）。当然，也可以迭代一个【扫码核对并发货】的功能在”WMS“中，辅助用户打包核对与回传单号到电商平台/自建商城。
总而言之，这样的架构设计无论后续用户/业务方/老板想增加什么样的功能，功能都会有其合适的”归属“了。
其次，就是【仓储路由中心】，按照当前的公司战略和重构目标是可以先不实现的。
但是，作为SaaS产品经理来说，还是要看的更长远一些，虽然当前的产品定位做的是SMB，但是如果哪天转型做电商erp或者孵化分销代发erp且要联动现有产品的话（大概率），该模块必不可少。因此，在设计之初产品和开发大哥们需要关注它。
由于我的产品并不涉及订单履约全流程，所以该部分内容主要阐述我的系统所承接的履约节点，其他节点会有所提及但不会深入。如果想要深入了解的，强烈推荐阅读罗静老师的《实战供应链》~当然，最有效的还是到现场多学多看多问~
对一个中小微电商商家来说，一个订单会经历以下节点，中间仍然会涉及到销售平台、订单转化中心、订单履约中心等多个系统。系统设计目标如上文提到的：能高效、准确、透明的完成订单履约全过程。进而，让供应链各个节点通畅协同。
订单系统接到新单的状态，此处根据业务分为两块逻辑处理：第三方平台订单，自建商城订单。
第三方平台订单：客户在第三方平台上完成支付后，订单系统接收第三方平台同步的订单。如果是预售或定制订单的话，应当待用户付完尾款后再进入订单系统。
自营平台订单：客户提交订单后，订单系统便生成一张新订单。
用户在电商平台上一次购物，通常会将多个商家的多个商品作为一个订单支付，但是一张订单里面会包含多个商家、多个供应商的商品，因此需要对订单进行拆分。
履约流程设计图中订单拆分发生在新订单后，但是在实际业务中会出现在订单履约的多个环节中的，场景较多也比较灵活，图中仅代表其首次拆分的节点。那么，在系统设计上，可以部分场景系统做自动拆分，部分场景提供人工拆分，看具体的业务情况。以下是订单拆分考虑的几个维度：
为降低运费成本和库房作业成本，会根据自动合并条件，将多笔订单合并为一笔订单进行物流发货。
通常，订单合并我们会设计自动合并+手动合并。新订单进来时，系统先自动合并。为避免用户操作失误取消合并或系统异常没有执行合并，仍会保留自动合并操作按钮。
常见的订单合并条件：同销售平台、同收货地址、同收货人、同手机号、同出库仓库、同订单类型（如普通订单、预售订单）、同配送方式（自提/配送）
不给过，除了根据业务划分出来的订单信息相同合并以外，还要考虑订单各类状态是否可以合并，如打印状态的未打印和已打印是否可以合并，发货状态的未发货和已发货是否可以合并等。
打单员按照消费者需求/公司要求/仓库作业流程，将每张订单的快递面单、纸质发票、发货清单等各类单据打印出来。
对于订单数量大，仓库分区多的商家，通常会采用波次拣选。根据波次生成分拣任务，打印批拣单后拣货员进行拣货。拣货过程可以”先拣后分“或者”变拣边分“，分完后再将【订单打印】环节的单据对应打包和贴单。
对于订单量适中，但是仓库分区简单、动线不复杂的商家，通常直接生成拣货单给拣货员进行拣货。后续过程与上面一样。
对于订单小，仓库也小【仓库规模基本上是一个人和一个小铺面】的商家（我的产品所服务的主要客群），则是直接打印快递单进行拣货（最省事）。
仓库人员按照拣货打包要求在系统里面对订单做筛选，筛选出A条件订单后进行批量打印快递单，根据快递面单自定义区的商品信息去拣货、打包贴单。然后再用B条件筛选订单，往复循环至当天要发出的订单打包完成。
发货员将包裹交由快递员揽收，并在系统中操作发货。发货以后，若实际发货物流有变化，回传实际的物流公司及物流单号至履约系统，履约系统再通过订单转换中心将物流信息回传销售平台。
不过现在的第三方电商平台对于商家的发货履约规则制度越来越完善，加上商家为了降低运费成本选择一些快递黄牛发货，如果等有揽件记录再回传到履约系统和销售平台，可能会发货履约超时导致罚款。
但是，平台也对物流商履约做了约束，如果过早回传单号到平台，在一定时间内物流没有产生轨迹，那么会被判为揽收超时，同样会被罚款。因此，在设计订单发货功能时，可以增加一些自动化规则配置/定时任务给到商家使用，商家可以结合自己的发货安排和物流商履约承诺来选择适当的时间点在系统进行发货。
物流公司快递员收到包裹后，将包裹带回揽件网点在快递系统中操作揽件。揽件网点将揽收的包裹打包集中，然后通过小型运输车辆将揽收的包裹送到就近的揽件中心。
揽件操作信息可由配送系统调用物流公司提供的接口获取，解析完后回传到订单系统中。
到达揽件中心（也称分拣中心，是大规模的包裹集散中心）后，对于到达本地的包裹，揽件中心根据包裹的详细地址，将包裹分发给对应的派件网点。对于发往外地的包裹，揽件中心根据包裹的行政区，如省、市、区/县，将包裹分发给对应的派件中心，从揽件中心分发到派送中心的包裹，通常通过大型运输车辆专程运送。
从揽件中心发出，也代表包裹正式进入物流运输。
包裹到达派送中心后，派送中心根据包裹的详细地址，将包裹分发给对应的派件网点。派件网点根据包裹的详细地址，指派指定的派件员进行派送，将包裹送到收货人手中。
包裹送达客户手中，完成签收。
根据罗静老师的《实战供应链》一书得知，订单履约系统状态有如下：
不过，根据我的产品定位、目标群体和其他客观情况，我的电商订单履约系统的订单状态做了一些调整。订单状态由三种独立状态共同组成：正向的发货状态，逆向的售后状态，快递单打印状态。发货后的物流揽件、运输、派件、签收由订单的独立物流状态承接。
发货状态：分为待发货、部分发货、已发货三种状态。
若父订单中的子订单（子订单对应的就是一个sku）都没有发货，则为待发货；若父订单中的仅部分子订单发货，则为部分发货；若父订单中的所有子订单发货，则为已发货。
发货状态的区分可以让用户知晓哪些订单未回传到销售平台，这关乎到用户的发货履约。
售后状态：由于系统主要还是以正向的发货状态为主，售后状态只区分用户申请售后（即售后开始）、售后成功、售后失败。
当用户发起无论何种类型的售后时，订单会标记为”用户申请售后“，前端也会透出；当售后成功时，订单会标记为”售后成功“，前端也会透出；当售后失败时，订单会标记为”售后失败“，但是前端不透出。
售后状态的区分可以让用户知晓哪些订单可以正常发货，辅助用户在订单打印流程中筛选有效发货订单，避免多发导致资损。
快递单打印状态：分为未打印和已打印。
其主要记录订单是否打印了快递单，如上述中小微商家是通过多次筛选进行批量打印的，而非全部订单一次性批量打印，因此记录订单打印状态流转十分有必要。如果打印状态流转不正确，那么就会导致多打一张面单，多发一个包裹导致资损。
那么，为什么要通过三种独立状态进行组合成订单状态呢？
首先，通过上述三个状态的介绍可以看出，这三个状态无非就是告诉商家哪些订单可以打印、哪些订单还没发货回传这两件事情。而打印和发货也是整个订单履约仓库发货环节要实现的业务目标，因此是很核心的。
再结合中小微商家订单打印、拣货、核对打包的业务场景与流程，【订单筛选】是个高频核心的系统操作。
那么，如何将这三种独立状态实现高效的订单筛选呢？
答案就是组合成虚拟的订单状态。何为虚拟的订单状态？即将后端的这三种独立状态组合成前端界面上的tab标签，tab标签名字即虚拟的订单状态，其本质是三种独立状态预置条件筛选的结果，这通过接口入参控制十分好实现。虚拟的订单状态既实现了核心状态的高校筛选，也降低了用户对系统的理解成本，十分适用于中小微商家了。
除此之外，还有一个原因：因为我们是做SaaS产品的，用户或其上下游可能会使用其他产品对订单进行处理，即不一定每笔订单的每个节点流转都是由我们的系统发起。因此，无法像罗老师梳理出来的订单状态来设计该产品后端的订单状态。
因此，所谓订单状态是虚拟的订单状态，具体流转设计如下：
此次项目让我对订单履约系统有了进一步的深入了解，不得不感叹前辈们留下的丰富经验背后到底踩了多少坑。供应链系统的庞大和复杂，只有沉下心、多钻研、多思考、多总结才能成为优秀的供应链人呀！
本文由 @Kuang扶正义的匡 原创发布于人人都是产品经理，未经许可，禁止转载
题图来自 Unsplash，基于 CC0 协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。