前言
本文内容对大佬们来说只是基础常识，纯分享自己的一些学习过程的方法和结果
在部门里，应该没有人比我更“零基础”了，在入职之前，我对电商可以说是零了解（感谢龙哥给我学习机会），同时，我也是“零经验”。刚刚入职的时候，连“测试环境”“代码分支”等名词都搞不明白，更不必说“门店日结”“分货表”这些词汇了…
在入职这三个月里，在做原型设计以及后期沟通的时候，我发现有新同事和我刚进来的时候一样是这样的状态：看原型和说明好像看懂了，但其实没有真正的理解。有一些词汇含义，在产品看来可能是非常“天经地义”地易懂的，在开发、测试看来是很难理解的。举个例子：在一月份更新的助手原型中，为了方便店长店员进行到家次日达商品订单的履约，我在次日达订单的筛选项中新增了一个“含门店商品”的选项。这里所说的门店商品其实就是到家次日达商品，这样的描述其实对产品组看来是几乎“不言自明”的，但到了开发、提测阶段，却发现其实大家没懂，什么是门店商品？大家其实也没懂，为什么会有到家次日达商品的存在？
其实背后的本质是，很多新同学（包括旧同学），都不太理解业务在做什么。这是正常的，毕竟不能要求研发与测试都从自己的工作时间里抽出精力去全程陪着产品和业务部门对接。但这也是不正常的，代码当然可以完全按照原型去写去实现，但不理解自己自己在做什么，在测什么，为什么这样做，这对自我迭代沉淀也没有帮助。
之前亮均推荐我看的一本书叫「决胜B端-产品经理升级之路」，里面有句话非常精彩。
和个人习惯有关，我在学习的过程中非常需要让我的知识系统化，简单来说就是心里有框架，每遇到一个新名词都需要容纳进我的框架中，碎片化的东西令我感到很失控。总结框架的过程其实就是这本书里面说的“对客观世界的抽象理解”。为什么会提到这些呢？是因为我觉得，像我这样零基础的人，之所以这么难、这么慢才大概“啃”明白了电商中台系统，是因为我一直没有办法把业务、名词等具象的系统词汇，去和真实世界对应起来。也有很多同学像我一样，好像理解了各种各样的系统词汇，对业务逻辑也信手拈来，但还是“失控”的。我所说的失控，是指失去与客观世界的映射关系。这里再举个例子，在三个月的工作中，最令我感到迷茫的词汇TOP（排名分先后），就是“门店日结”、“WMS”、“供应链”、“验收单”、“未知损耗”，如果你具体问我这些名词的含义，我当然也可以说，我也不下百次请教过敬威（主要因为敬威离我最近，每天都会被我各种问题骚扰），但我心里却是没底的，这些名词，没有办法与真实世界相对应。特别是敬威之前讲解的“次日达手动下单”流程，我当时就理解了为何要做这个需求，但当我过了一段时间再回归时，我却发现我忘记了，为什么这个需求可以解决门店未知损耗高的问题？
后来经过三个月来的经验和一直回归查看原型、说明、线上问题的聊天记录，终于总结出自己心中的模型，可以分享给新同学。（还是那句，应该没有比我更零基础的同学了）
客观世界：一切从门店说起
只有理解门店每天要做什么，才能理解系统如何帮助业务方解决问题。门店的日常也是我之前觉得最陌生的范围。
其实在我看来，我就简单地把门店的任务分为两块：“订货”和“卖货”。其余衍生出来的旁支末节先不理会。这两个任务，就涉及到三大系统的交互：电商中台、WMS和OMS。
门店关心自己如何订货、订多少货，关心自己订的货卖得怎么样、损耗多少、赚多少钱。这就是真实的客观世界。
我们只需要这样简单地去理解，具体的细节先不管。
真实世界与我们的系统有什么关系？
这是我自己画的一张图：
门店订货、卖货，“货”是什么？这里就涉及到线下线上的区分了。门店每天会通过其他系统去订购在门店售卖的商品，系统收到订购单，由供应商配送到仓，仓再统一配送到门店，这是大致的流转流程（可能会不精确）。我们理解这部分门店自己订购自己售卖的商品为“门店商品”，就是我们每天在店里看到的货架上的菜肉，在pos机销售，从七点开始打折。
而在自研商城售卖的次日达商品呢？为什么要创建次日达计划呢？为什么要推送分货表？
次日达商品，与门店订购商品不一致在于，订购的主体不一样。之所以叫次日达计划，其实这就是一个订购计划。由电商运营人员在电商中台创建次日达计划，分配好每个sku的计划量（库存），发布到指定的门店去售卖。这部分的商品，是在自研商城上下单的、由运营部门计划的，我们简单理解为“电商商品”。分货表的意义在于，供应链需要知道明天每个门店需要送什么货。每天截单后，收集这些订单信息，推送数据到供应链，这就是我们中台所做的事。
简单来说，门店商品门店售卖，电商商品线上售卖，订购主体也不一致，这是两条相对独立的业务。
在这个基础上，及时达商品也很好理解了，把门店自己订购的商品放到网上卖而已。及时达商品也是门店商品，只不过被标记了线上售卖的属性。于是到家次日达商品便呼之欲出，到家次日达商品，本质上是门店自己的商品，只是让顾客在今天订购明天的门店商品而已，属于预售的一种。
理解商品的本质，只需要从售卖渠道与订货主体去理解。
除了订货，门店关心到货数量与质量以及自己一天下来赚了多少钱。这里就涉及到与其他系统的交互了。门店每天一早会根据“验收单”去验货（验收单我没有具体见过长什么样，这是由其他部门负责的，但大概也可以猜想到会写明每个商品会到货的数量），检查到货数量质量和分货（细心留意，门店会有“电商次日达”专用货架，当天到货的次日达商品会预先分到此货架上，这叫做订单的“履约”），分好货，卖完一天的货，到底赚了多少钱呢？这里就涉及到“门店日结”了。每天都在听门店日结这个词，到底是什么意义？
店长可以查看自己的日结报表，上面会有订货成本、销售额、毛利额、毛利率、损耗等字段，可以大概看到每天赚了多少钱。日结报表的数据如何统计？三大系统终于交汇。
简单来说，利润就等于销售-成本。成本如何可知？供应链的出库价会告诉你，这里是和WMS系统的交互，我们假设供应链的验收单就标明了每个商品的出库价、数量等字段。销售又如何统计？上文已经提到，门店销售分为线下和线上，线下用pos机进行销售的订单会推送到OMS系统（这么多系统如何分辨？用英语就可以，简单记住O代表order，W代表warehouse），线上的订单呢？这就是电商中台所说的日结了。电商中台会汇集所有的线上订单，推送到OMS系统。综合线上线下所有订单，就可以计算出销售情况了。通过OMS的销售（销售额）减去WMS的验收单（成本），就得出了毛利，这就是门店最关心的盈亏状况了。
如此一来，就可以找到系统与现实的映射关系了。记住客观世界的玩法，线上的问题与业务逻辑的理解，都可以在这个框架中找到对应的位置，去理解问题出现在什么地方。（可以翻上去去再看看上面的图）
线上问题举例Q&A
1、为何运营群总是有反馈到家次日达商品没打印小票的状况？为何到家次日达商品的小票如此重要？
其实不是小票重要的问题。问题出在“履约”，履约是做生意非常重要的环节。我们知道，到家次日达商品，是让顾客在小程序上提前预订明天门店售卖的商品，那么，门店如何去履约呢？每天那么多订单，怎么可能每一张都去查看呢，更何况有一些是已经履约过的了。产品设计是通过打印机在凌晨五点打印小票，去提醒店长留出这一部分订单的菜品（正好门店在这个钟数开始分货验货）。这个时候，万一打印机失灵，整个履约过程就跑不通了，所以才有了一月份助手上的“秘书”功能。
2、为什么要有次日达分货表？为什么次日达订单在提货日推送日结，而及时达订单却是当天推送？
我们之前提到的门店订货、销售两个日常任务，对于电商运营部门来说也是一样的。次日达分货表，其实就是向供应链订货。只是次日达商品比较特殊，门店还没有到货，就已经同时在销售了。所以为什么要在提货日推送日结，而不是当天实时推送销售单呢？那是因为，门店当天次日达商品还未到货，如果把销售单实时推送，一定会出现负毛利的情况。（这是我从自己的框架里总结的原因，当初设计的原因不太清楚）
3、为什么会开发次日达手动下单的功能？为什么没有这个功能就会导致门店未知损耗高？
虽然说次日达业务是先销售后订货（有多少销售订单就订多少货），理论上并不会造成库存积压，但我们需要知道供应链的反应是有时效性的，特别是做到次日达，一定不会是完全理想化的根据销售单去下采购单。出现库存积压时，电商运营的同事会向门店、顾客清货，怎么清货呢？大概率会在当天计划商品标题上写“买一送一”，顾客买一份收到两份，同时运营部门在WMS录入两份商品配送到门店。对于中台来说，只会推送销售量为1，但是对于供应链来说，订购的商品为2（只是其中的1份不收货款），这会有什么问题？我们来看看损耗的公式：（采购量-销售量）×进货价。所谓已知损耗与未知损耗，只关乎日结报表有无记录的对应字段，我们假设店长主动报损的损耗部分被系统记录了就是已知损耗，未知损耗则是没有被记录的部分。如果采购量远远大于销售量，损耗就会高。如果中台能够实现买一送一，也推送一个“2”，与供应链的订购量“2”匹配，就刚好抵消。我们所做的次日达手动下单，解决的就是未知损耗的这个问题。实际上，未知损耗不影响毛利，只是影响店长的心情。
…更多问题待补充…