先试穿再购买的电商平台订单模块的重构心得

　　当原有系统过于冗杂且原有功能不再适用当前需求时，重构系统的需求油然而生。于是笔者就和我们分享了订单管理模块重构的心得。
　　从事电商行业，是一个女装类自营电商平台，结合虚拟试衣技术，和线下试穿服务，为用户提供一种不用出门就可以享受逛店试穿的服务。
　　用户首先购买平台会员，在会员有效期内可以在平台上将喜欢的衣服加入试衣盒子，盒子满5件时可以在不付任何费用的情况下寄给用户，用户拿到盒子后，试穿这些衣服，再决定是否购买，然后将不买的衣服装入盒子再寄回平台，往返包邮。
　　这篇文章产生的背景，这篇文章是在做订单管理模块重构的时候产生的，好像所有系统建立的第一个版本都是暂时符合现在版本的APP，然后需求越来越多，不停的往原来的系统上加功能。
　　有一天终于发现加不了了，老系统由于可扩展性太弱，承受不了奇奇怪怪的功能。
　　于是开始想办法一个模块一个模块地梳理，开始着手重构的事情。
　　但是此时重构已经工作量巨大，任何一个功能都已经在线上运行，一个都不能砍，耗时巨长。
　　所以我认为，重构的事情越早进行越好，做不到第一个版本就规划得很清楚的时候，功能越少，越没有历史遗留问题的时候，做重构的事情越好。所以就借订单部分重构的档口，来小结下订单管理相关的问题。
　　重构必要性：
　　当前将单一原始单拆分不同状态的产品形态已经无法覆盖所有交易类型的订单处理。
　　将订单拆分为不同类型，不同类型分别定义后台状态，方便不同业务部门有针对性的处理订单。
　　订单拆分将可扩展性增强，随着业务形态多样化，可以在不同类型的订单及其状态上优化，如＂7天无理由＂需求可能涉及的＂售后＂类型的订单问题。
　　重构步骤：
　　原始订单拆分为不同类型的订单
　　分别梳理不同类型订单的流程和相应状态
　　类比常规电商各节点把控的关键信息，并根据业务特殊性将其移植嫁接
　　先来梳理下常规电商的状态流转：
　　1. 待付款：
　　用户选好商品下单，但未付款的状态。
　　预判到用户下一步可能是付款行为，所以在下单同时锁定库存，但由于用户未付款，我们不知道用户是否会买下，所以仓库只是暂时替用户留货，但不会扣减，当用户付款后，货才会真正成为用户的货。
　　但是由于用户有可能下单但迟迟未付款，被占用的货不能卖给其他用户，造成了损失，所以待付款订单会有实效性，只为用户保留一小段时间。
　　这段时间的长短根据不同平台有不同的考量，比如外卖平台由于时效性更高，可能只保留15分钟的订单；对于服装电商对时效性要求也是很高，所以通常都会给出24小时的锁定时间，24小时后再不付款就自动取消订单了。
　　2. 待发货：用户付款后，商品未发货的状态。付款后，库存扣减，仓库备货。
　　3. 待收货：仓库包好商品并交到快递小哥手中，订单开始更新物流信息。
　　4. 待评价：用户确认收货后，钱款打给卖家，用户可以评价订单。
　　5. 售后：用户付款后，不管货有没有发出，用户都可以将钱款退回，此时的退款或退货申请均作为售后状态，创建相应的售后工单，会有对应的售后服务人员跟进。
　　值得注意的是用户在每个订单状态下的退款和退货行为：
　　首先，下单未付款状态下，用户可以直接取消订单，订单终态是＂已取消＂，不会再流转至后续的订单状态中；
　　在付款后，未发货的状态下，用户申请退款可以直接退，仓库拦截出库成功就可以直接退款，订单终态也是＂已取消＂或者叫＂已关闭＂；
　　在发货后，用户再取消订单会直接走售后流程，创建退换货单，推到仓库，仓库根据退换货单给退回的货品审核并做入库处理，再给用户替换出新货。
　　以上是常规电商的订单状态的梳理，下面来看看我们平台的订单中，哪些流程可以直接抄，哪些流程具有自己的特点。
　　首先，我们的盒子，是一去一来（平台 → 用户 → 平台）是一个正常的流程，因为我们提供的服务是让用户挑选5件衣服，打包成一个盒子，然后寄回家中试穿，试好后再决定是否购买，然后再把不喜欢的衣服退回来，而且往返运费全免。
　　经过一定的调研和统计，最终用户5件衣服全买的概率是很小的，留货量在2、3件的用户居多。
　　也就是说，退货的行为是一个常规的行为，退货发生的概率可以达到九成，盒子的一个来回也可能不涉及交易，而交易订单也有可能不与盒子关联（比如购买会员服务或其他增值服务等）。
　　所以我暂且把盒子订单和交易订单分开，此文主要详细说盒子订单。我方的盒子订单正向流程如下图所示：
　　一、待发货状态
　　在一般电商中，用户选货后进入＂确认订单＂的页面，目的是为了让用户检查所选SKU是否有误，以及给用户一个最终决定的过程，因为他的下一步是去付款，要谨慎为好。当用户确认订单后，生成交易单，同时锁定库存，用户在一个时间段内支付后库存扣减，取消订单或超时未支付则锁定库存释放。
　　与一般电商相同的是，订单创建后，要占用实际的库存，所以看起来确认订单同时锁库存的操作是相同的。
　　但是，订单创建后用户不需要支付任何费用（因为本质是试穿，到货才可能产生交易），不生成支付单，这是相比于一般电商不同的地方，就是我们在这一步没有＂从支付单创建到支付/不支付＂的过程，也就是锁定库存的过程。
　　因此，我们可以不做锁定库存的操作。
　　但是这会遇到的问题是：用户在选货到创建订单那一步，可能会发生选到的SKU被别人选走导致缺货的情况，这样就要返回重新选择，再重新生成新的订单，体验不太友好。
　　所以在没有支付订单的情况下，我们是否需要在生成原始订单前、在选款结束到订单最终确认前做库存锁定操作？
　　锁的话锁定多久？会不会让别的想要这件SKU的用户想选的时候可用库存已经没了，而犹豫半天的用户最终又没要，为这部分用户锁定库存造成了资源的浪费？
　　考虑到我们初期的库存很浅，每个SKU最多5件，用户有很大的概率会在确认订单时，刚选的SKU被另一个用户秒下单而缺货，发生次数多了用户一定会觉得我们做的是假电商（骗我进来看看又不让我买那种）。
　　对于已经进入确认订单步骤的用户来说，我们会先检验库存，保证了他们决定下单的SKU一定有货；对于还未进入确认订单步骤的用户来说，没货了尽早告诉他们，让他们心里有数，不会进到确认订单的步骤，节约时间成本，也不会有太大的负面情绪。
　　所以我们决定还是为用户锁定库存，在选好SKU后进入确认订单的页面同时，我们就为用户锁定了库存。
　　如果用户最终确认了订单后，订单创建，库存扣减；用户如果在确认订单的步骤中放弃了，订单创建失败，锁定库存释放。
　　订单创建后，推送至仓库ERP系统，仓库确认，并将订单拣货通知下发至WMS，由相应的拣货人员拣货、包装、称重等一系列流程后，最终出库，交给快递小哥手中，订单状态变为＂已发货＂。
　　二、已取消状态
　　在商品发货前可以取消订单。订单创建后创建相应的发货单，并推送至仓库WMS，可能已直接发货，状态未及时更新，在一般电商中，如果直接给用户退款，而仓库已经直接发货，有可能造成货款两失，所以应该先暂停订单出库，在仓库调度中查询订单是否推送至仓库。
　　若尚未推送，则停止推送；若已经推送，则应该到WMS拦截发货，暂停出库流程；若拦截失败，则应该拒绝＂取消订单＂申请，因为订单已经实际出库了。
　　在我们电商的待发货状态取消订单，由于用户尚未支付，取消订单也不会发生货款两失的情况，所以只要是在商品没有实际出库的情况下，我们都是可以直接暂停的，此时库存会相应的加回来。
　　以上是订单出库之前的状态，接下来会涉及到的是订单在路上和反向的过程。
　　三、已发货状态
　　订单在快递小哥手中时会显示这个状态，并且根据发货物流单号获取物流的动态信息。
　　一般的电商中，这个状态下用户可以确认收货，若在物流状态更新为＂已签收＂后的一段时间内，比如9天未确认收货，订单会自动确认收货。
　　我们平台的订单不会给用户主动确认收货，因为对于用户来说，他们只是叫了几件衣服到家试穿，购买行为是后置的。
　　如果用户迟迟未购买也未寄回，会造成资源大大的浪费，而且服装容易过季，超过半个月再返架，返架前还需要运送、审核、清洗等一系列流程，此时的服装不一定在售了。
　　所以我们会给用户一个比较短的时间试穿，并且这个时间以物流信息＂已签收＂为准。
　　但是由于我们接了第三方物流查询接口，获取的物流动态做不到实时更新，而且非常有可能是快递小哥送到了但是用户没时间取货，那如果直接按照物流＂已签收＂状态开始倒计时，用户也不太能接受。
　　所以我们定的时间是＂从物流更新为＂已签收＂的次日凌晨0点开始的72小时＂为用户可以试穿的时间，超过这个时间若未将衣服买下或退回，则订单逾期，要有相应的记录，给我们做用户分层和风控中心做参考信息。
　　因此，逾期的订单只要一旦逾期了，就会一直跟着这笔订单，未必对用户可见，一方面对那些真的有特殊原因不小心逾期了（比如说，工作日家里没人，只能预约到周末，但是到了周末就超时了），此时如果用户看到自己的逾期不良记录可能会产生消极的情绪；另一方面对于那些恶意买家，给他看到逾期也不会改变什么，所以逾期的记录只要内部工作人员可见即可。
　　从本质上来说，一般电商的＂确认收货＂基本等于我们的＂购买＂，因为同样是确认把钱款付给卖家，一般电商是支付平台把钱打给卖家，我们是实际收到用户的款项。
　　四、已付款状态
　　如上所说，我们的购买行为是后置的，用户只有自己实际拿到货时才决定是否购买，所以此时交易订单创建同时不需要锁定库存，这是跟一般电商不太一样的地方。
　　我们原来是不想做＂交易订单＂这件事的，因为当时希望的是用户尽快地进入付款的流程，多一步操作搞不好就不买了，这是老板提出的论调，我很理解老板的担心，但这一步存在一定有它的理由：
　　一般电商需要这一步除了要锁定库存外，还要锁定商品价格、优惠信息，这两个信息时效性很高，即便我们这步不用锁库存，但也要锁定价格、优惠信息，很有可能用户下单寄出时是这个价格，到手后要付款了是一个价，实际支付的时候又是另一个价，支付系统也不知道收哪个。
　　而且我们有些优惠信息时效性更高，可能1分钟后不真的付款，不创建交易单来锁定的话，万一由于网络原因支付失败了，返回再重新进入交易流程，优惠信息没了，岂不是很不开心，后台开发人员在系统设计时也会创建交易订单，只是是否对用户可见。
　　而且，一般电商都有创建交易单的操作，用户也已经被市场教育得很认可了，没有必要再做改变。
　　接下来，就进入了订单的反向的流程。如前文提到的，这样区分是向仓库方面靠拢，仓库的各方面业务都比较完善，比如反向流程可能不仅仅是退货，后续还会有换货，所有的套路都很完善，所以就捡成熟的方案用起来。下图是反向订单流程：
　　五、待寄回
　　在我们的平台中，用户付好款后（或一件都看不上的），可以直接在APP中预约快递，只需要填写上门取件地址和时间，就会有快递小哥上门取件，取件后，用户可以继续叫盒子，保证用户一次只能叫一个盒子，但是再会员有效期内可以叫多次。
　　在预约快递，到快递小哥实际揽件的状态为＂待寄回＂状态。从这里开始，订单开始走反向流程，即一般电商中的退换货/售后流程。
　　用户将不需要买的商品勾选好后，预约快递，选择取件时间和地址，退货单创建，同时创建物流单。退货单创建同时推送至仓库ERP系统，仓库操作员根据退货单号、物流单号、应退商品等信息进行验货、清洗以及入库操作，平台根据ERP对商品的审核状态将订单置为＂已完成＂。
　　在退货单创建前，也就是成功预约快递之前，都是可以购买商品的，并且可以分多次购买，因为发现女生的购物习惯很不确定，5件衣服中经常会有个一两件衣服想买但是又不太舍得买，但是放了几天后想想还是买下吧，有点像淘宝退货，申请退货后还是支持用户取消申请的。
　　此时一个盒子订单就可能与多个交易相关联，这也是把盒子订单和交易订单分开的原因，业务的可扩展性增强。
　　六、寄回中
　　快递小哥取件后，到快递被仓库签收的过程为＂寄回中＂。
　　七、待审核/异常/已完成
　　仓库签收退回货品，到验货完成之前，订单状态为＂待审核＂。
　　商品从用户手中退回的时候不一定全为完好无损的，可能是奇形怪状的，有的可能沾有口红印子，有的起球严重。
　　完好无损的货品是经过清洗、熨烫以及再次包装的操作后可以直接入库变为可销售库存；奇形怪状的货品经过审核后确定无法还原后，不能入库变为可销售状态，只能进入次品仓。
　　当然相信大部分用户都是正常用户，退回的商品基本都是良品，少数用户会退回次品，也很少有平台会跟消费者扯皮，通常都是自认倒霉，只是完善的电商平台会有自己的风控系统，某个用户退回的次品过多，协商未果，就认为这个用户信用不好，或是拉黑等等，他们以后的购物也会受到影响。
　　当然不管是良品还是次品，我们都需要得到一个统计的结果，退货单中每一件商品都是良品时，订单自动完成；有次品出现时，订单会先到＂异常＂状态，由客服去协商了解情况后，手动将订单完成，并填写备注。
　　订单的各个状态间的流转就是以上了，总的来说自己摸索着做还是有些难度，但是工作了这两年现在才算是有了点步入专业的感觉，不是说做出来的系统有多么专业，而是说在摸chao索xi的过程中做到了仔细思考，为什么别人这么设计，这一步为什么不能直接移植过来？要做出哪些改变？这样设计是最优解决方案吗？是否还有更完善的方案等等？这才是产品经理应该做到的工作吧。希望以后多做出这些总结，然后跟大家一起成bao长fu！