江苏龙网

  1. 首页 > 人文 > >

『设计』解密「零售」系列（二）：产品架构( 四 )


由于订单状态的重要性 ， 其在设计之初要特别小心 。 个性化状态不能加到主干流程 ， 可作为订单扩展数据存在 。 每个状态的流转需有前置和后置状态的合法性校验 ， 且作为可配置 。 如能从状态1到2 ， 但是不能从状态3到2 。
4. 履约引擎 所谓的订单履约就是按照订单上的承诺来履行和用户的一个承诺的约定 。 而通常为了考虑履约成本 ， 且由于商品所在物理上并不是一个不可拆分的单元 ， 也即：它不是一个颗粒度最小的实体 ， 可以进行多种形式的分解 ， 具体如何分解根据不同的业务场景 ， 可以进行不同形式的拆分 。
『设计』解密「零售」系列（二）：产品架构
本文插图
（1）订单拆分
订单拆分是通过客户在前台提交的订单 ， 把客户承诺的合同或履行约定 ， 拆成货主可生产的一系列子单 ， 其实最核心的是拆信息、拆资金、拆实物 。 其实不同的平台拆分维度很多 ， 不做赘述 。 拆分后 ， 比如说仓库生产、配送环节、售后环节 ， 实际上都是参照子单去进行操作 。
1）实物拆分
像双11或者618等这种大促的时候 ， 我们的购物车可能一次性会有10个甚至有若干个东西要购买 ， 最后发现被拆成多个订单 ， 什么原因呢？
维度1：库房位置
即使针对同一个货主 ， 也有可能其不同品类的商品由于储存环境等因素会被放到不同的仓 ， 这样就会带来一个拆分 ， 这是最主要的一个维度 ， 即库房 。
维度2：货主不同
京东为例 ， 京东现在有自营和POP ， 而POP里边有不同的商家 ， 京东为了要给不同的商家进行结算 ， 不可能在一张订单上同时存在两个商家的商品 ， 这将导致京东无法跟商家做结算 。 因而 ， 京东会根据商家去进行拆单 。
维度3：特殊业务
有些是业务本身的特殊性 ， 需要单独履约 。 比如用户下单买了A和B商品 ， 但是B暂时无货 ， 那么可以选择有货先发 ， 那么就会被拆开分别履约 。
2）信息拆分
将原始订单信息复制或者分摊计算到子单 。
3）资金拆分
基本365天都会有不同类型的促销 。 比如买个东西 ， 满199减 100啊（活动预热） ， 大家都会凑单凑到199 。 于是 ， 用户就会买食品凑够199然后减掉100 。 假如用户买了10件商品 ， 减了100元 ， 那么具体这100块钱怎么减呢？
对于客户来说 ， 他们不理会平台怎么操作这个优惠折扣 ， 只要这100块钱在自己结算的时候抵扣即可 。 比如 ， 用户花了200块钱 ， 而实际只是收了用户100块钱 ， 这就可以了 。 但对于平台来说 ， 这100块钱并不是直接减100这样来登记的 ， 其不在订单里 ， 是以商品的金额订单里 ， 商品金额的比例分拆优惠的钱 。
（2）订单履约计划
订单转移可以理解为订单的计划 ， 其是为了实现订单履约 ， 而制定的生产方案 。 一个合理的生产计划 ， 能在保证时效承诺的前提下 ， 起到优化生产 ， 降低成本的作用 。 由于平台越来越开放 ， 不同的订单来源于不同渠道 ， 需要由不同的生产系统来履约 。
那系统是如何确定以什么方式为客户履约？
其实订单履约计划是履约的一个核心环节 ， 将待履约的订单按照履约计划分发到不同的库房去生产 。 但对于库房来说 ， 不可能来了一张订单就生产一个订单 ， 这样的库房是没有计划性的 ， 容易导致生产混乱 ， 所以订单都会按照履约计划成堆生产 ， 而不是单独去生产 。
FTP ， 即Fulfill to Promise ， 即针对现货去做履约计划 。 ATP ， 即Availableto Promise ， 即针对没有现货去做履约计划 。 未来的趋势一定是ATP的比重会变大 ， 就是怎么把供应商的库存 ， 怎么把在途的库存 ， 怎么把一些计划里的东西 ， 都能实际的用起来 。
在大促期间 ， 用户的第一的需求是我能买到这个货（因为便宜） 。 可能就对时效的要求不高 ， 有一些东西会通过让用户选择牺牲时效 ， 而把一些在途的库存或在供应商仓库里的库存 ， 都会去把这个东西认为是可以生产履约的库存 。 最后 ， 会让消费者真正的能享受到这个实际的优惠 。


推荐阅读


上一篇：「深扒财经圈」易观方舟：数据技术赋能城市出行服务升级

下一篇：「蓝血研究」华为伙食补贴：管理就是要让大家捞到好处