作者：程亮，曾任京东开放平台产品机构原负责人，负责开放平台后台业务产品建设，代表作有“商家后台”、“POP供应链”和“O20等创新产品”。第1章 业务运营之道零售运营业务闭环供应链如果按照企业的经营模式来划分，则企业可以分为生产型企业，如服装生产厂商、OEM（Original Entrusted Manufacture，原始委托生产）商等，以及电商平台或零售型企业，如京东、天猫、一号店等。上述企业的运作逻辑有一定的交集，也有各自的特点。对于生产型企业来说，其供应链环节涉及商品制造、渠道销售、消费者购买。在生产型企业中，商品制造包含很多因素，如原料商、生产商、品牌商。供应链是一个企业合作的价值传递链条。整个链条连接了供应商、用户、销售渠道等，可以通过物流、资金流、信息流的贯通让产品在链条上流通，并给链条的相关企业带来收益。链条的增值效应是维系这条供应链的基础。供应链上的各个企业可以通过对物流、资金流、信息流的控制，实现商品和价值的流动。供应链管理会涉及采购管理、进销存、物流配送三大职能流程。目前，我国的物流行业基本分成3种模式，即城际运输、同城物流和即时配送。同时，从供应的角度来看，不同的运输模式对应的车源类型不同，比如，城际运输对应专业公路运输司机和社会化重载卡车，同城物流对应专业公路运输司机和社会化城市物流用车，而即时配送服务对应常见的快送员和短途机动运输工具。各类物流模式的特征图解城际运输可以细分为城际整车货运、城际零担货运、干线物流等。城际整车货运是指一批货物的重量、体积、性质、形状等较大，需要采用整车运输的运输方式；城际零担货运是指货主需要运送的货不足一车时采用的运输方式，在进行城际零担货运时，承运公司出于成本考虑，会将不同货主的货物按同一到站凑整一车后再发运；干线物流是利用铁路、公路的干线，大型船舶的固定航线进行的长距离、大数量的运输，是进行远距离空间位置转移的重要运输方式；同城物流可以细分为同城B端物流、同城C端物流；除此之外，还有综合物流、冷链物流等。物流层面的成本大体上来说有以下几种。（1）仓储管理成本：包括卸货费、QC（Quality Control，质量控制）费、条码费、入库检核上架费、储位费、批量退库费、盘点费等。（2）订单处理成本：包括分拣费、配单费、打包费、指派费、交接费、RMA （Return Merchandise Authorization，退货产品授权）费和耗材费等。（3）配送成本：包括干线物流费和分区配送费。（4）其他成本费、固定资产的分摊费等。物流管理就是要针对物流网络各个环节进行优化，如运输、车队、仓储、订单履约、库存管理等，并最大限度地对物流成本进行优化。而最终物流的成本，往往也决定了最终商品销售的成本策略。在供应链运作流程中，库存会在各个节点产生，因此，对于供应链管理来说，其“管理”的核心就是库存。库存既不能高，也不能低，而且绝对意义上的零库存也是不存在的。现代企业库存的管理技术包括以下3个方面。（1）动态库存控制技术。动态库存控制技术，即在采购、订货、销售供应的过程中，会对库存量产生影响的一种技术。动态库存控制技术既要对采购、订货的过程进行监控，又要控制销售过程，从而达到精确的库存管理目的。比如，在保证用户需求的情况下，为了在采购和订货过程中控制库存，可以通过控制采购、订货的批量和频次来达到目的。这就是所谓的OTB计划（Open-to-Buy，采购限额计划）。采购订货策略的基本内容包括3个方面：什么时候订货，即订货时机；订多少，即订货量；如何实施，即订货操作方法。（2）静态库存控制技术。这里主要涉及公司内部库存管理，比如，订货提前期的缩短，区域之间的调拨等。（3）供应链管理库存控制技术。比如，本企业和上游供应商的联合，本企业和下游客户的联合；企业本身对于上下游的管理，以及供应链响应时间的动态把控等。应用较多的策略包括供应商拥有库存（VOI，Vendor Owned Inventory）、供应商管理库存（VMI，Vendor Managed Inventory）、联合管理库存（JMI，Jointly Managed Inventory）。这3种库存控制策略存在一个共性：打破了企业界限，致力于降低，甚至消灭供应链上的中间库存，提高企业间的信息共享与协同，乃至整个供应链的竞争力。库存管理常见的核心指标包括现金流、仓库使用率、滞销率、动销率、现货率、残损率、周转率和售罄率等。库存管理流程企业的OTB计划，就是企业根据预估营业额、利润率和商品周转率来规划采购金额和数量。企业的OTB计划是衡量线下企业管理水平的一把标尺。OTB计划怎么做？其最终产出物是什么呢？1.定基比：定基比，就是将固定的某期设为基数，其后各期与该基数进行对比得出的数值。2.损益平衡点：损益平衡点，一般指的是全部销售收入等于全部成本时的产量。零售企业OTB计划的思维就是从经营角度出发，根据企业的状况计算损益平衡点，结合渠道层面的业绩规律和计划，最终确定预估销售库存，最大限度地提高采购效率。OTB计划是在线下企业商品运营过程中非常关键且专业的一步，是决定企业品牌调性及成本结构的起点。OTB计划通常会经历销售目标预测、时间段选择、分解大类占比、旧商品销售回顾、新品销售计划设定、企业定位回顾、确定存货水平等步骤，其核心还是根据损益平衡点来进行尺度的把控。补货补货点，就是补货的时间节点，也就是什么时候开始补货补货点示例图补货点补货有个缺陷：它不是一个提前的计划，补货点补货是指只有当库存量低于补货点的库存量时才会进行补货。定时补货，就是固定一个时间点来补货，和补货点补货不同的是，定时补货按照周期来补货。补货点的库存量、补货数量、目标库存三者共同组成了采购的三要素。供应商的能力也决定了补货数量。在补货的场景里，我们需要记住几个影响补货周期的概念。（1）备货周期（BP）：即一次采购量可覆盖的销售天数（也可以理解为采购周期），是一个补货的参数。（2）VLT：Vendor Lead Time，指供应商送货时长。（3）NRT：距离下次可下单日的时长。补货数量的计算方式如下。（1）目标库存=预测日销量×（备货天数+供应商送货时长+采购周期）。（2）安全库存=日均销量×（供应商送货时长+采购周期），当库存量低于安全库存量时，触发补货操作。（3）补货数量=目标库存-当前现货库存-在途库存（采购未到货）。仓储将仓储的所有运作环节概括起来就是5个环节，即入仓、上架、盘点、库存管理、差异处理。入仓，即通常所说的验收商品入仓；上架，即围绕发货进行的一系列作业，包括订单处理、拣货、复核、包装到出库的所有环节；盘点，即库存盘点；库存管理，包括库位的设置、移库、补货等围绕库存进行的作业；差异处理，是指仓库里的异常处理，包括退换货处理、库存、发运等仓库内的一切异常问题处理。货位编号是货位信息化的基础，是指将库房、货场、货架、料区、货垛等按照地点、位置顺序进行统一编码的编号。货位编号的一般方法包括区段式编号、品项群式编号和地址式编号。目前，地址式编号较为常用，常见的货位编号为“X-X-X-X”，例如，“13-15-2-26”表示13号库、15号货架、第2层、第26号货位。仓储的库位管理是WMS和业务流程的基础之一，库位管理是仓储作业与管理系统的结合点。果采用了库存商品编码方式（即每个产品都贴上按前述方式产生的库存商品编码），加之严格对应的库位管理，则任何商品都是拣货可指引、出库可校验、商品可追溯的。月台的建立是为方便车辆的卸货和装货。拣货区通常是根据货位存放商品的地方，拣货人员通过系统提示的商品和货位的映射关系进行拣货。分播暂存区是用来暂时存放拣选区所选定的商品的地方，以便进行二次分拣。发货区的工作是将收集上来的商品打包、称重，粘贴面单和快递单，准备发票等，然后将包裹放置到发货暂存区。当有商品退货入库后，仓库会收到入库申请单，这部分和采购流程类似，退货的商品会进入退货区，一般来说，退货特别是自营类型的商品退货（如京东），都会有一个验收过程，以便分辨出哪些商品可以二次上架，哪些商品只能进行残次品处理。收货暂存区是提供给集中送货的车辆进行排序等待的区域，让送货车辆在收货暂存区等待，待仓库准备完毕后再调度车辆入场。现代电商仓储所定位的功能更多的是“周转”而非“存储”，也就是说货物在仓库内快进快出是大型电商仓储的核心策略。在上架过程中，往往会出现差异，那么对于差异，我们需要把握以下处理方法。（1）在周转箱商品的实物数量小于系统数量时，需要和当时的质检员/供货商确认是以实物数量为准还是以系统数量为准。（2）如果待上架库位有A商品，则可以采用两种解决方法。第一种方法是将待上架库位的A商品进行移库处理，整理出库位给待上架商品。具体操作步骤为：制单员下发A商品的盘点单，并在盘点完毕后，更正系统中A商品的待拣数量；同时下发A商品的移库单，整理A商品的库位；最后，将待上架商品进行上架操作。第二种解决方法是不使用A商品所占用的库位，重新生成上架单。核心的库内作业包括盘点、移库和补货。盘点是一个仓库管理手段，也是一个财务手段。盘点主要是解决实物数量及位置和系统数量及位置的一致性问题，其目的是保证库存准确性。盘点的目的是发现差异并及时纠正，因此盘点的结果调整也是重要的工作之一。盘点结果与账面库存结果之间的差异主要包括数量差异、存放位置差异和存货质量差异。补货，目的是为了提高订单履约率。移库主要是库内的位置调整，一般发生在提高拣货效率、优化拣货路径的场景中，移库一般分为两大类：一类是货架之间的移动，另一类是区域之间的移动。出库，就是商品从仓库发出给客户的库内作业过程，常见类型包括销售出库、采购退货出库、调拨出库、盘亏出库、其他出库等。常见的拣货任务类型包括普通订单出库拣货任务、大宗订单出库拣货任务、合约订单出库拣货任务、退供应商拣货任务、内配拣货任务、大库出备件库拣货任务、赠品出库拣货任务等。拣货逻辑往往涉及3种拣货模式，即总拣式拣货、播种式拣货、摘果式拣货。仓库一般会根据存储商品的特性、品类等分成不同的仓库类型。以京东为例，其仓储体系大致可以分为以下几类。（1）中小件仓：京东存储中小件商品的仓库。（2）大家电运营中心：京东存储大家电含大件商品的仓库。（3）CDC：Central Di stribution C enter（中央配送中心）的简称，产地仓在离供应商50km范围内开设CDC，从供应商处把货先采买到CDC，并根据销量预测、各个RD C的预测，按匀速的节奏补充到FDC，防止爆仓情况。（4）RDC：Regional Di stribution C enter（区域配送中心）的简称，京东的六大区域（华北、华东、华南、西南、华中、东北）的物流系统，被称为六大区域配送中心。（5）FDC：Forward Distribution Center（前置配送中心或前置仓）的简称，它是基于RDC将产品向更靠近客户的区域进行存储的新型物流运作模式。FDC承担存储、生产、分拣、配送的职责，但是它的商品入库主要来自上游RDC的调拨，通过基于销量预测系统的补货管理系统，每日小批量地向FDC补货，用20%的SKU数量满足80%的订单，实现FD C的快速周转和较高现货率。（6）协同仓：是合理整合第三方、商家等社会仓储资源，京东订单信息流拉动协同仓的生产物流，库存协同管理的新型电子商务合作模式，可以大幅度降低库存持有水平，提高库存资金周转，并提高现货率。（7）EPT海外仓：配合京东海外站，用于生产海外订单的仓库。（8）开放平台仓：配合京东仓储开放，用于为非自营商品提供仓储服务的仓库。（9）亚洲一号：京东集运营办公、商品存储、订单处理、分拣配送功能于一体的，亚洲范围内B2C行业建筑规模和自动化程度最高的现代化物流中心项目，可以实现海量存储、海量订单、高密度集约化的现代化物流中心。（10）品类仓：按照商品品类划分的一种仓库类别，如3C仓、食品母婴仓都属于品类仓。（11）分拣中心：连接仓库和站点的物流节点，根据客户送货需求，从事订单包裹的分货、拣选、配货，以高水平实现销售或供应的现代流通设施。造成电商仓储物流与传统零售物流存在较大差异的关键因素主要包括各自面向的客户、客户的订单量、订单行数、订单实时性、订单精准性、订单波动性、退换货等。第2章 产品架构为天产品经理应该懂技术，所谓“懂技术”不仅是要懂得某种编程语言或某个数据库特性等，更重要的是要掌握一种思考方式，一种兼顾产品和技术的多样性视角。而这个视角便是架构的思想。一个好的产品架构需要产品经理在理解业务的基础上进行深入思考和设计。一个好的产品，是要从业务抽象成模型，再落地到细节的。这样每个环节的逻辑才能够做到环环相扣。懂业务同时也懂技术的产品经理最值钱。架构是承载业务流程的技术结构。架构更加关注的是“结构”上的问题。架构就是产品或系统的顶层设计结构，有了架构，产品就有了方向和思路，产品经理除了理解业务逻辑架构。当产品经理对领域问题进行业务建模之后，技术人员是怎么来思考架构的事情的呢？架构的最终目的是解决业务复杂度的问题。业务复杂度的根本来源是业务领域模型，也就是业务逻辑。在研发人员看来，除了要了解领域模型，还要注意复杂业务场景会在代码层级带来性能、可用性、扩展性方面的问题。随着业务领域的发展，对“高性能、高可用性、高扩展性”的需求就会越来越强烈，同时，架构也会随之进化。产品经理的设计过程就是将业务领域问题转化成产品解决方案的过程。在业务领域中，产品经理的主要任务是找到该业务的核心逻辑和现阶段主要面临的问题，并通过分析相关需求场景得到一个业务层面的解决方案，即领域模型；而在技术领域中，则需要产品经理通过一系列具体的方法和工具，将领域模型转化成产品解决方案，并且保证产品解决方案是可以进行技术开发的。领域模型与产品解决方案的转化领域即业务范畴，是一个特定边界内的业务总和；领域模型则是对领域中的关键事物和它们之间的逻辑关系进行可视化所得到的解决方案。建立领域模型的目的是准确定义问题，为产品系统建设制定统一认知和标准，是业务场景到产品系统的映射。领域模型可以帮助产品经理提炼业务的本质，可以更好地指导产品系统解决用户需求。领域是业务范畴；领域模型是以业务需求为源头，从相对多变和复杂的业务场景中找出领域中的核心问题并进行产品化所得到的解决方案。RBAC模型所表达的整体思想为：什么人拥有什么角色对什么进行操作。RBAC模型领域建模是一种思维方式。我们通过领域建模来搭建领域模型，可以弥补业务和技术之间的差距，促进团队进行合理的分工协作，同时也可以实时、真实地反映我们所要解决的问题的变化，让我们构建的系统富有价值和生命力。产品经理建模工具——UML领域模型对于复杂的业务场景来说是一个很好用的思想工具，使用领域模型可以更好地对业务逻辑进行封装，提升业务的内聚性和重用性并促使复杂和隐性的业务逻辑得到简洁和显性的表达。领域模型的核心价值在于有效控制产品的复杂度。一个好的模型应该建立在对业务深入理解的基础上建模的本质是让业务核心简单化、统一化。面向对象的设计方法的核心要义是将业务抽象成一个个含有属性和操作的概念模型。以“进销存”系统为例，在采购系统中，采购单是一个核心业务模型，而原材料是一个辅助业务模型；在库存系统中，入库单或出库单是一个核心业务模型，原材料或成品是一个库存物品概念模型。UML（Unified Modeling Language，统一建模语言）提供了一种领域模型的建模标准，相当于一套“协议”，一种“语言”，可以通过一种标准来描述产品系统设计，使得抽象出来的模型“统一化”。领域模型的建立UML最初的确是应用于软件设计行业，然而，如今互联网行业的产品设计与传统的软件设计并没有本质性的差异，所以UML这种经典的工具仍然可以发挥其威力。对于产品经理来说，熟练掌握UM L的好处如下所述。● 梳理产品需求及其业务流程。● 梳理产品实现价值及其运用场景。● 准确向设计及开发传达产品需求和边界。UML是产品经理必备的利器之一。UML包括用例图、类图、对象图、状态机图、顺序图、活动图、时序图、部署图、构件图、包图、通信图。在产品需求阶段，主要采用用例图来描述需求场景。在产品逻辑分析阶段，主要采用类图来描述产品结构，以及抽象类之间的关系和链接。采用对象图来表达类图中的类在某一静态时间点上的关系。采用状态机图来描述某个业务模型对象的状态变更。采用顺序图来描述整体业务的顺序流程。在架构设计阶段，主要采用构件图来描述产品内部物理结构；采用部署图来描述如何部署产品的IT基础环境；采用包图来描述开发的接口设计。用例图（Use Case Diagram）不关心功能细节如何实现，而是用来将业务场景转化成领域模型的，它从用户的角度出发，强调产品的场景和对应的功能。用例图要体现的是价值而非具体动作。为了表达业务之间的逻辑关系，用例图提供了关联（Association），包含（Include）、扩展（Extend）、继承（Generalization）、聚合（Aggregation）和组合（Composition）等关系（1）关联（Association）。关联关系是简单的用例之间的联系，一般使用实体线条连接用例，线条包括有箭头的和无箭头的，有箭头的关联关系代表驱动关系，箭头指向被驱动方；而无箭头的关联关系仅代表两者之间有联系，不强调驱动关系。（2）包含（Include）。包含关系表示B在A的基础上进行复用的行为。（3）扩展（Extend）。扩展关系表示用例的分支场景。扩展关系在没有父用例时，是不能独立存在的。但是，父用例在没有扩展的子用例时，也是完整的。（4）继承（Generalization）。继承关系表示被继承的类的相关特征，如属性、操作等对于继承于它的类同样有效，类似于祖先和后代的关系。“会员”和“非会员”都是继承于“用户”的，所以，“用户”的属性，如姓名、性别、年龄等同样会被“会员”“非会员”所继承。（5）聚合（Aggregation）和组合（Composition）。聚合关系用实心菱形表示；组合关系用空心菱形表示。聚合关系意味着如果“鸟”不存在了，则“翅膀”也不复存在；组合关系意味着“鸟群”和“大雁”没有强关系，“大雁”可以属于“鸟群”，也可以属于其他群体。类图（Class Diagram）一般用来描述产品中的静态关系，之所以说是“静态”，是因为在分析系统结构时，需要产品经理根据业务需求和问题抽象出一个模型，并静态地展示系统的全景图，这个静态的模型就是类图。类图是业务对象在系统中的实例化，而关于对象的概念我们在面向对象中已经阐述过，可以被看作系统/产品的参与者（可以作为使用者参与，也可以作为子系统参与）。在将对象实例化成类后，参与者的特征和操作也被相应地实例化成属性和方法。类图是用于描述系统和产品结构化设计的静态图形，显示了类、类的方法、类的接口，以及它们之间的静态结构和关系。在面向对象的思想中，每个业务实体对象都扮演了一个角色，并为其他成员提供特定的服务或执行特定的操作。这些业务实体及其场景、功能经过归类之后，即可抽象成类。而类通过图形进行展示就是我们所说的类图。类名（名称）是指每个类都有一个唯一的名称；属性是指已被命名的类的特性，它描述该类实例中包含的信息；操作（方法）是指类所提供的服务，它可以由类的任何对象请求以影响其行为。流程图（Flow Chart）的基本原则，一般使用矩形代表流程中的节点，使用菱形代表分支判断，使用圆形代表流程开始，使用含实心的圆形代表流程结束。在实际场景中，可能含有更多部门协同的关系，此时流程图中会增加“泳道”来进行协同方的划分。包图（Package Diagram）主要用来聚合类图，是一种组织归类的工具，可以把相关的事物放在同一个包内。包图是一种结构化思维的体现，是站在更高、更抽象的视角来组织散乱的UML图形。包图相当于一个容器，可以用来组织和容纳类图、用例图等其他UML元件。在实际工作中，包图往往用作系统模块设计，使用包图能够形象地表达类图或用例图的所属关系。顺序图（Sequence Diagram）核心用途在于描述系统各个业务对象之间如何交互，以及消息如何在对象间传递的过程。顺序图可以用来解释业务流程，特别是当流程中涉及多角色交互时，顺序图是最佳选择。用户修改信息顺序图UML可谓“重剑无锋，大巧不工”。第3章 核心系统落地类目系统类目就是商品的分类。从用户的角度来看，类目系统能够方便用户定位目标商品。而从平台的角度来看，首先，类目系统可以让平台对海量的商品进行划分，以便管控和维护；其次，为了提升销售效率，平台运营往往需要根据季节、人群等因素不断调整、变换前台商品的分类场景，目的是最大限度地减少用户筛选商品的路径，快速进行转化，因此，就有了前台类目和后台类目的架构；最后，落到宏观层面，公司是为了盈利，电商企业也不例外，平台往往在提供服务的同时，会根据自身特点制定相应的商业模式和战略规划。而类目系统可以根据平台战略来灵活控制微观层面的业务逻辑。不同类目对于电商平台的战略贡献意义不同，所以需要类目的业务逻辑细节进行相应的差异化调整。常见的差异化调整策略包括不同类目的佣金比例根据平台收入分解目标做出调整，不同类目的资质上传和审核、不同类目系统保证金收取额度有区分，以及承载电商的其他业务规则。而所有业务的支持，都离不开类目系统这个底层架构。类目的属性是用来细分和形容叶子类目的参数维度，由“属性名称+属性值”组成（全面、适用性、无重复、有重点）。类目的属性是类目的核心，其设计原则是可扩展的。不同的类目有不同的属性定义，原则上支持任意级类目定义属性，但是一般会把类目的属性挂在叶子类目下。属性的类型包括关键属性、一般属性、销售属性，又可以称为不变属性、可变属性、与价格有关的属性。（1）关键属性：通过关键属性能找到确定的SPU（Standard Product Unit，标准化产品单元）。比如，我们在笔记本类目下，定义了品牌、系列、型号3个关键属性。那么，通过这3个关键属性及其值，就能找到对应的SPU，如“联想T60笔记本电脑”就是一个SPU。再比如，将服装品类中的品牌和货号这两个属性值组合起来，即可形成一个唯一确定的产品模板。（2）销售属性：能够确定唯一的一个SKU的属性或属性组合，如服装品类的SKU属性就是颜色和尺码，这两个属性能够确定一个最小的库存单位。（3）一般属性：有一些属性，如新旧程度、保修方式、附加服务等，与SKU、SPU都无关，只与商家的销售场景和特点有关，属于商品的补充信息。属性也有从属关系，因此，属性也是树状结构。前台类目和后台类目来源于线下管理，然后被淘宝引入系统中，具体来说，平台会有两套类目系统：一套是后台类目，相当于一个线下的仓库，是一个强大的商品数据仓库；另一套是前台类目，是供用户使用的类目导航，可以让用户以最短的时间找到自己想要的商品。后来，该思路被标准化，成为搭建类目系统的一个统一思想。简单来说，后台类目是商品的物理分类方式，和商品本身相关；前台类目是灵活多变、可重叠、可删除的，和业务场景相关，相当于建立了一个虚拟类目，该类目通过与后台类目映射而间接和商品产生关联。后台叶子类目是前台类目的搭建基础，前台类目架构是引用后台各个叶子类目后再进行排序而得到的，由后台叶子类目和属性组成。一个前台类目可以包含多个后台叶子类目，一个后台叶子类目也可以映射多个前台类目。前台类目不直接挂载属性模板，它所对应的属性来自后台叶子类目的公共属性。这样，前台类目和后台类目就形成了分离，一方面可以保证后台类目的稳定性，另一方面可以保证前台类目的灵活性。一旦前台类目和后台类目分离，就可以调整前台类目而不影响后台类目。这样一来，电商平台运营人员就可以根据季节、营销策略、节日等对前台类目进行灵活调整，保持商品分类的动态变化，以适应导购需求。最终，用户在购买商品时看到的类目就是灵活多变的前台类目了。类目数据表结构示例类目管理主要是定义类目树的层级关系，每一级子类目均与父类目通过唯一的ID进行关联，形成一套标准的树状结构商品系统商品系统是支撑整个电商平台的核心，与其他系统之间存在千丝万缕的联系。商品系统层级SPU即标准化产品单元，是一组可复用、易检索的标准化信息的集合。该集合描述了一个“产品”的特性。通俗来说，属性值、特性相同的商品就可以称为一个SPU。一般来说，类目系统中的关键属性（品牌、货号等）能够确定一个SPU，例如，iPhone 6就是一个SPU，诺基亚N97也是一个SPU，这与商家无关，与颜色、款式、套餐也无关。SPU的属性是分类属性的子集。只要用户在SPU中定义了属性，那么用户在录入商品时，就不需要再次录入，也不可以更改。需要注意的是，SPU没有销售属性。对于电商开放平台来说，因为商家众多，所以在SPU下层一般会增加一个商品的维度，这个商品的维度在淘宝叫item，在京东叫product。商品特指与商家有关的商品，商品是挂靠在SPU下的，每个商品有一个商家编码，每个商品有多个颜色、款式，并且可以有多个SKU。商品中的库存是所有SKU库存的累加。报价是所有SKU报价中最低的价格。商品信息分为以下几个部分。（1）基本信息：所有商品都有，如商品名称、广告语等。（2）关键属性：继承类目属性中的关键属性，如品牌、货号等。（3）销售属性：继承类目属性中的销售属性，所有商品都有，目前大部分是颜色和尺码这两种。（4）扩展属性：继承类目属性中的扩展属性，一般与商家销售场景有一定关系，比如，是否能开增值税发票，是否提供保修等，由运营人员根据分类进行配置维护，可以用于展示，也可以用于列表页搜索。（5）规格参数：由运营人员根据分类进行配置，用于单品页展示。商品数据表结构示例SKU即单品/最小库存单元。SKU是库存进出计量的单位，一般以件、盒、托盘等为单位。SKU就是库存的最小单位。在服装行业，“单款单色单码”是一个SKU。商品是SPU的具象化。SKU、商品和SKU数据表结构示例京东是以商品为维度进行管理的，淘宝是以SPU为维度进行管理的，而这两种商品结构对商品售卖会产生很大影响。商品的信息一般分为基础信息、SKU销售信息、功能设置等模块。销售属性与库存、价格相关。SKU的生成遵循“笛卡尔积”，每个SKU需要进行价格和库存的设置在完成所有的商品信息设置之后，就形成了完整的商品中心，该商品中心在底层技术层面相当于一个商品数据池子，我们称之为商品主数据。图3-27 商品页解构（一）商品页解构（二）商品页产品数据关系架构商品中心是电商平台商品核心业务数据的汇聚地，商品中心的可用性会在很大程度上影响商家、开放接口、其他兄弟部门等调用方的业务的正常运行。商品中心一般承担的主要业务包括以下内容。（1）商品业务：商品发布编辑、商品上/下架、商品删除、商品打标等。（2）SKU业务：SKU的创建、删除、恢复、图片设置等。（3）运费模板：设置/取消商品的运费模板。（4）库存：设置库存数量、增减库存数量、开启分仓等业务。（5）价格：商品的销售价、市场价、进货价的维护。（6）其他业务：店内分类、自定义销售属性、限购或可购区域、关联版式、广告词等。如果商品中心前期规划不周全，则后期会导致产品存在很多问题。订单系统用户挑选到心仪的商品后，即可经由购物车进行结算或直接进行结算。在填写订单信息页面中，京东会根据自身优势提供在线支付和货到付款两种支付方式。一般来说，用户每次提交订单的时间控制在100ms以内。在如此短暂的响应时间内，后台系统经历了非常复杂的业务逻辑：恶意用户检查，库存状态校验，库存预占，支付密码校验，扣京豆、余额和优惠券，生成订单号，更新购物车，保存订单等，涉及的系统数量多达上百个。用户的一次提交订单的动作就是一条最高优先级的指令。交易系统引擎会根据用户的下单动作，安排行程并通知订单中心（用户可以在订单中心随时查看整个生产过程）、财务中心（需要准备多少钱）、仓储中心（由哪个库房生产等），保证用户的订单有条不紊地进入后续生产流程，而整个过程的最长耗时为300ms。在用户提交订单之前，时效系统会为用户计算出精准的送达时间，同时，会根据发货仓库、配货中心、送货地址、地图、实时路况等核算出最佳路线，并给出适合的时间。为了更快、更好地把货物送到用户的手里，订单履约系统承担着订单生成后的履约工作，以确保实物流转和订单信息的秒级精准同步。订单履约系统主要完成过滤存在风险的订单、准备生产信息、制订生产计划等工作，最后把满足生产条件的订单传递到库房进行物流生产。同时，订单履约系统还承担着下游系统主数据、订单处理状态回传给订单中心、库存中心等工作，可被称为用户订单业务中最核心的后台支撑系统。在订单生成之后，并不会立刻下传到库房，而是会经过拆分、时效计算、转移、预分拣、发票数据准备、面单数据准备等一系列步骤。用户可能通过一张订单购买了很多商品，如电脑、图书、日常用品等，然而为了方便管理，这些商品是被存放在不同仓库的。这就需要将一张大订单拆分成多张小订单进行生产，即订单拆分。系统可以根据用户所购买的商品的种类、大小、有无现货，以及所在仓库距用户的远近等，综合计算出一个最优方案，并以此对订单进行拆分。同时，用户在下单时使用的优惠券、京豆、礼品卡等也要合理地分摊在每张新订单上。在订单拆分之后，不仅可以让用户更快地收到商品，而且可以降低运营成本，可谓一举两得。在拆分订单时，系统会发出电子发票的任务，这里需要注意的是，不同商品品类要对应不同的工商或税务要求。在订单拆分完成后，订单履约中心会调用订单时效模块，逻辑上会考虑生产时效、生产成本、库存、用户体验等多个因素，给出一个优化的方案；原则上会在满足订单履约承诺的基础上尽量节省生产成本。在确定配送中心后，就可以联合库房号来确定具体的库房，同时要注意明确订单是否到了生产时间，没到生产时间的订单和库存不满足的订单会继续处于等待状态。然后，订单履约中心会调用青龙物流系统的预分拣模块，通过匹配用户填写收货地址和配送站点，并考虑生产能力和负载情况，分配最佳的配送站点。最后订单履约中心还会调用订单时效模块，修正订单可到达用户处的时间；调用发票模块，准备好发票数据；调用面单模块，准备好面单数据。在一切准备工作就绪后，订单履约中心下传模块会将符合生产条件的订单立刻下传到库房。订单状态变更为“您的订单已经进入***库准备出库”“您的订单预计***日送达您手中”。上述流程为京东自营配送的产品处理流程，而第三方商家的入仓订单的处理流程相对简单，不需要判断是否满足生产条件，只要经过预分拣环节，确定京东可配送后，就可以下发到商家的后台系统，由商家完成订单后续的备货、发货流程。在经过库房拣货组、复核组、打包组进行的订单库房生产环节后，订单状态变更为“您的订单已拣货完成”“扫描员已经扫描”“打包成功”。在订单拣货完成后，会回传一条“拣货完成”的消息。为了提高人工拣货效率，减少拣货人员在库房的行走路程，通常会将多张订单同一商品进行合并拣货，再将所有的商品分拣到相关订单中，这个过程叫“分货”。然后，复核人员在复核台上将订单商品进行扫描确认，并进行商品打包操作。同时，在商品复核、打包操作完成后，由复核人员回传状态给订单跟踪系统。到目前为止，库房内生产操作基本完成。库房生产还有一项非常重要的工作是打印发票。打包完成的商品会被送往分拣中心，由分拣中心将送往配送中心的所有订单准备就绪。此时订单状态变更为“您的订单在【***分拣中心】发拣完成”“您的订单在【***分拣中心】发货完成，准备送往【***配送站】”。当商品打包完成后，会通过龙门架对接分拣机传送到分拣中心，通常分拣中心就在库房隔壁；分拣中心会对包裹进行收货、验货、分货、装车、发车，同时将状态回传给订单跟踪系统；订单经过几个小时的车程抵达配送中心，由相关工作人员完成验货；最后由配送员将订单按照分配的地址送达用户手中，至此，一个完整而详细的订单流程就结束了。产品本身是业务服务，它是一个流程性的整体。购物车的业务基本可以概括为商品管理、场景营销两个层面。购物车的业务流程图购物车的排序：首先购物车中按商家店铺进行排序；其次每个商家店铺中按商品排序。结算页与周边系统关系常见的订单提交要素包括地址、支付方式、配送方式、虚拟资产、价格等。订单不仅涉及线上各个系统中众多数据的流转过程，如ERP、商品数据和订单状态等，还涉及支付、结算、退款等财务相关的“钱”的流程，并且如果订单顺利完成，则订单还会涉及货物入库、出库、运输、退货、报废、报损等货物流转过程。因此，订单交易系统就是一个集合信息流、资金流、物流的统一中心平台。订单交易系统是电商平台的心脏。如果说订单流程是组成订单交易系统的“分子结构”，那么，订单流程中核心的“原子”即订单状态。产品经理了解订单交易系统的切入点就是订单流程和订单状态。按场景维度区分订单状态订单拆分，就是在用户提交订单后，将不满足在同一个订单生产的商品进行拆分。拆分原因有很多，比如，京东的商品有很多类型，有些商品直接由厂商送货，有些商品由京东配送，而京东配送的商品会根据商品类型的不同而存在于不同的仓库中。所以，京东的订单拆分系统可以实现一种功能：当用户提交订单后，系统会根据商品的类型将其拆分为各种子订单，并且计算出每个子订单的价格、优惠等信息，再由下游系统直接对子订单进行生产，并将多个子订单分开进行配送。拆分的主要目的是将不同的库房、商家、商品特殊属性、库存状态的订单分开。订单拆分流程关于订单金额均摊计算的方法，总的原则是按照商品价格比例进行均摊。如果商品有优惠，则优惠价格按照商品金额比例进行均摊。如果存在多种优惠方式，则按照一定的分摊策略顺序进行核算，一般来说，分摊顺序是满减、价保、运费、运费劵、优惠券、礼品卡、余额、积分金额、其他等。在进行订单优惠分摊前，先将当前需要计算的SKU按价格从小到大排序并按SKU价格比例进行金额分摊，并将结果四舍五入。然后，优惠金额按照分摊顺序进行分摊核算即可。举例说明：小明在平台买了一个U盘和一本书，U盘的价格为80元，书的价格为20元，选择了货到付款支付。在下单过程中，小明使用了40元礼品卡，16元余额，满20元减5元的限图书品类的优惠劵，系统对订单进行了拆分，子订单A含U盘，子订单B含书，那么，子订单A和子订单B分别需要支付多少钱？根据上述信息，小明的优惠政策有满减券、礼品卡、余额，那么按照逻辑，应该优先计算满减优惠，然后再分摊礼品卡和余额。首先，我们计算出书的实际金额，即使用了满减券后的价格为20-5=15元；然后，我们按照金额均摊礼品卡，根据价格比例均摊原则，我们得到15/（15+80）×40≈6元（四舍五入取整），即书均摊了6元的礼品卡，从而U盘均摊的礼品卡价格为40-6=34元，此时，U盘的价格更新为46元，而书的价格更新为9元，最后，我们按照同样的逻辑均摊余额，即按照比例均摊余额得出，U盘均摊的余额为46/（46+9）×16≈13元（四舍五入取整），从而得到书均摊的价格为16-13=3元，至此，订单内所有的优惠政策均已核销，最终得出结论，子订单A的U盘在优惠后价格为33元，子订单B的书在优惠后价格为6元。暂停参考场景订单下传是用户从平台下单，通过交易系统推送数据给下传系统，然后，在下传系统处理后将符合库房生产条件的订单传给库房进行生产。订单中心下传业务在整个订单流转中，起着承上启下的作用。其中，“承上”指订单中心的履约模块需要接收网站交易系统推送的订单；“启下”指订单经过拆分、转移、预处理、发票同步、预分拣、预分拣回写、获取面单、离线发票环节，最后将符合生产条件的订单下传到WMS中记录的库房进行生产。库房生产主要包括打印集合单、拣货、复合扫描、打包、发货、处理病单等环节，具体介绍见第4章相关内容。订单生产流程订单配送系统主要包括分拣中心的配送系统（DMS）和站点的配送系统（TMS），主要负责把包裹配送到用户手中或从用户手中返回到仓库中，以及一些物流报损。订单系统表结构图例库存系统产品经理在设计库存管理系统前，需要构建库存逻辑的“点—线—面—体”架构：首先，需要从基础上理解库存的各种定义；其次，将所有概念放在业务流程中串成一条业务线；再次，需要将仓储配送体系纳入库存管理系统，形成一个完整的剖面；最后，结合电商前端、后端，形成一个立体的视角，从而更好地设计一个完整的库存系统。库存和商品详情页对应关系可售库存公式仓库系统管理的是仓库中商品的实际数量，库存系统管理的是商品的可销售数量。当电商平台达到一定体量时，一级库存（FDC）往往无法正常满足庞大的订单体量。所以，发展出了二级库存（RDC）。其中，RDC和FDC分别是区域配送中心和前置配送中心促销系统促销引擎主要对外提供促销的查询和计算，所有需要获取促销的系统均需要调用促销引擎。促销引擎就像大脑一样，会自动帮助用户选择最合适的促销模式。将促销引擎进行分解，其核心任务就是要解决商品和SKU上相关促销信息的查询，以及促销优惠计算。促销引擎分解图电商系统的促销规则都离不开几种类型的优惠方式：代金券、满减券、活动。促销管理系统分解图第4章 支撑系统心法供应链系统采购系统集成了采购业务、商品管理、结算管理、售后管理、价格管理等采销人员经常使用的业务逻辑。采购系统用于采销部门向供应商采购商品，并且提供了多种创建采购单的方式，以及采购单审批、回告、下传、回传等业务功能。采购系统的价值在于向供应商采购商品来增加库存，并满足库存周转和客户订单的销售，属于供应链非常重要的环节。采购系统的核心是采购单的生命周期管理和维护。采购单是平台采销人员或运营人员向供应商采购商品而生成的单据。采购单对应供应商的订单和库房的入库单。采购单的信息包括采购的供应商、采购的SKU及其数量和价格等。采购单会经过新建采购单、审批、回告、待签收、预约、TC转运、WMS上架等几个业务环节。WMS“供应链”的概念非常庞大，其复杂度可谓电商之最。如果将供应链看作电商的核心，那么仓储可谓供应链的基石与核心。WMS能够将仓库的“收、发、盘、存、异”所有环节有效地衔接起来，WMS与仓库的适配度直接决定了一个仓库的作业效率的高低。WMS可以将仓库内所有作业信息进行详细记录。每一次操作（入库、上架、下架、盘点）都会被明确地记录在系统中。WMS是通过入库业务、出库业务、仓库调拨、库存调拨和虚仓管理等功能，综合运用批次管理、物料对应、库存盘点、质检管理、虚仓管理和即时库存管理等功能的管理系统。该系统有效控制并跟踪仓库业务的物流和成本管理全过程，实现完善的企业仓储信息管理。不同的企业所使用的WMS在仓库操作上的策略和各个仓库之间的协同作业流程具有差异。所以，鉴于业务特殊性，各个公司的WMS一般具备唯一性，甚至仅仅适用于自身公司。入库是所有WMS的入口，任何商品的仓储流程都是从入库开始的。入库按照业务来源分为采购入库、内配入库、退货入库等。入库环节可以分为签到排队、卸货验收、商品、上架等模块。在商家到达收货仓库后，首先进行签到，然后WMS开始分配收货队列，收货队列分配的核心目的就是定位货位，即WMS根据定位规则给出建议货位。定位规则将会按照入库单类型、货品属性、包装层级对应到具体的收货上架策略。仓库中会设置几种不同的定位规则来满足不同的上架要求，如零头定位规则、整箱定位规则、冷藏品定位规则、药品定位规则、残次品定位规则、赠品定位规则等。卸货验收时，库房工作人员会在使用PDA手持终端扫描周转箱后开始扫描商品，主要是进行来货登记，需要登记的内容包括批号、有效期、价格、数量等内容。在登记完成后，ERP系统会把来货登记信息下发给WMS并生成入库单，其中包含入库单号、货品、批号、有效期、价格、数量、库号等信息。WMS中的入库单会与ERP系统的来货登记保持一致。因为在验收阶段都是通过栈板、料箱等容器进行验收，所以在验收完成后，我们称之为容器完验。只有上架完成才能形成实物库存。在整个入库单的货品全部上架完成时，入库单会自动关闭，此时WMS会将实收数据反馈给ERP系统，ERP系统将WMS反馈的实收数据按品规、批号汇总后，替换原先的数据。至此，电商平台的实物库存正式产生。在大件仓储场景中，仓库分为平库和立体仓库两种，一般来说，平库就是我们见到的大部分库房，一般有钢筋混凝土结构、钢架金属屋面结构等，主要由基础站台、装卸货平台、雨棚、通风装置、基础设施等组成。而立体仓库也被称为高架库或高架仓库，一般是指采用几层、十几层乃至几十层高的货架储存单元货物，用相应的物料搬运设备进行货物入库和出库作业的仓库。由于这类仓库能充分利用空间存储货物，故将其形象地称为“立体仓库”（简称“立库”）。立库往往采取自动化上架，因此，在上架流程中往往会用到类似AGV（自动运输车）、堆垛机等一系列自动化控制系统。对于自动化仓储的WMS来说，上架流程会有很大不同，关键在于WMS和相关自动化设备的通信与关联，业务的“一小步”，就是后端的“一大步”。出库单类型包括普通销售、采购退回、调拨出库、抽检出库、客户自提等。所有的出库单都由ERP系统下载到WMS，订单明细里会指定货品的出库批号。从业务上来说，出库业务基本上都会经历初始化订单、定位波次、出库任务分配、拣货、复核、打包出库等环节。WMS出库涉及的用户一般包括仓库搬运人员和拣货人员，对应的场景分别为：在托盘从立库口出来后，搬运人员通过叉车将商品搬至暂存区或复核区，并通过显示屏查看托盘流向，不操作系统；而拣货人员从暂存区领取拣货任务。在销售出库时，WMS先定位月台，然后在系统内部组建生产波次后进行库存定位分配；在定位库存时，WMS按照播种区汇总需求量并判断仓库是否有立库储区库存，如果仓库有立库储区库存，则将需求量按照库存进行整托定位，同时将定位明细按容器返回给WMS。随后WMS更新立库库存占用明细，如果立库储区库存不满足，则生成补货需求，触发紧急补货，并在补货后进行定位。如果仓库没有立库储区库存，则直接在平库按照同品多仓的方式定位。一个库房不可能针对一张订单进行生产，这样的库房是没有计划性的。这是因为所有库房都需要工人操作，有生产环节，采用上述生产方式容易导致生产混乱。所以，库房的生产计划采取的是波次生产—订单都会批量生产，而不是单独生产。处理波次的过程往往会伴随分配策略等。在需要执行的细节层面，往往涉及以下几个方面。（1）生成波次；（2）指定分配规则；（3）库存分配；（4）补货；（5）创建货箱；（6）创建补货任务；（7）创建拣货任务；（8）创建装载；（9）结束波次。拣货模式分为通拣模式和播种模式两种。通拣模式意味着全仓都是拣货位，一个SKU可以分散在各个拣货位上，而播种模式意味着存储位负责向拣货位补货，存储位不参与拣货。根据商品上架存储的颗粒度，可以将拣货分为先拣后分、边拣边分、整箱拣货3种维度。复核工作可以分为“发货任务复核”和“拣货任务复核”，简单来说就是寻找差异。在复核完成后，仓库会在当天将所有的销售单配货并移入笼车，然后由配送人员在第二天将各自送货线路的货品装车并配送。配送主管会根据当天的发货情况，人工调整送货顺序和打印装载清单，然后由配送人员领取各自送货线路的装载清单，清单上包含装载号、出库单号、笼车位置（整箱集货位）、包装数（整箱数）等信息。仓储运营人员持RF设备扫描装载清单上的装载号和出库单号，系统会提示该出库单的包装（整箱）所在的笼车位置（整箱集货位），以及每个位置上的包装数（整箱数）。接着，配送人员根据RF设备提示到对应的笼车（整箱集货位）提货并逐个扫描发货标签，系统会将已扫描的包装（整箱）状态置为“已装车”，直至该装载清单中的包装（整箱）全部扫描完毕。在发车时，司机在系统中进行“装载发运”操作，此时系统将该装载清单中的出库商品出库。库内作业一般包含盘点、库内返架、补货、仓间调拨、库存调整、商品管理等。WMS模块划分图物流系统配送系统的整体结构物流配送系统通常需要满足解封车扫描、解封车异常收货、验货扫描、验货异常、返调度入站、再投入站、拒收入站、货物出站、货物妥投、货物退货、货物拒收、逆向装箱、站点交接、第三方交接、返调度交接、站点封车、封车标签打印、配送员交款、站点交款等功能，可以说，配送系统需要涵盖站点配送业务的大部分场景。“封车”，即在物流运输前交接完毕并确认可以运输的环节。在封车时，首先，工作人员在PDA手持终端上创建封车任务，然后把商品搬运到车辆上。其次，工作人员在配送系统中确认输入封车号码并完成封车任务，此时整车的封车信息就可以作为之后配送站点验收的初始信息。最后，工作人员根据商品交接单核对系统封车号码，确认无误后，进行发车。当商品从分拣中心运输到配送站时，就可以进行解封车操作了。在配送系统中，需要解封的车辆可以由工作人员扫描封车标签，并由配送系统自动记录解封车扫描时间，根据此时间可以确定货物到站点的时间。一般在配送系统中，“解封车扫描”操作只有站长或站长助理有权进行。在解封车操作中，工作人员在进行解封车扫描后，都会检查货物的详细情况。配送系统在明示“解封车货物详细”时，需要列出该封车标签所关联的所有箱号与包裹号，用于站点工作人员打印清单并进行核查。在收箱扫描环节，配送系统可以根据批次号或封车号进行差异对比，以确保本次收货是针对当前批次进行的。支付清结算系统任何电商的本质都是经营活动，而经营活动离不开支付、结算等经济行为。支付清结算涉及3个概念，即支付、清分、结算。客户是指一个自然人或一个公司机构等社会实体。而用户是指开通了某个服务或签署了某个协议的“客户”，比如，一个商家自身就是一个“客户”，当他入驻京东或天猫后，会签署入驻协议并开通相关服务，他就成了平台的一个“用户”。用户与账户是一对多的关系；但是一个账户只能属于一个用户。一个客户可以开通多个服务，也就是一个客户对应多个用户，但是一个用户只能属于一个客户。用户可以是企业，也可以是个人。当客户开通业务，成为平台用户后，即可开通账户。从产品边界来看，一个狭义的支付系统应提供支付渠道管理、支付网关、基本支付/退款/转账能力、支付记录/明细及其相关的监控运维功能。而所谓的账务清算、对账、账户体系、风控体系、现金流量管理等功能，可以纳入业务领域的清结算系统中，也就是我们所说的广义“支付系统”。支付系统基本架构支付网关，就是承接支付请求的第一道“门”，相当于关卡。这道“关卡”承担起了承接业务支付请求的责任。外部业务系统提供了各类业务接口，如快捷支付接口、退款接口等。而内部业务系统可以将业务的支付请求分发到对应的渠道模块上，生成相应的支付订单。可以说，支付网关是支付系统的核心功能之一。支付网关常见于交易平台类产品中，其设计相当于接口中心。在支付网关的设计中，核心在于对接口的设计，包括制定接口的信息承接规则、接口的处理逻辑和响应方式等。支付路由也是支付系统的核心之一，如果说支付网关是“关卡”，那么支付路由就是“交通指挥”，它负责交易机制的衔接。支付路由管理的核心功能就是以收益、用户体验为主，保障成本、收益和支付成功率，实现在支付环节的利益最大化，支付路由就是让支付系统选择正确的渠道来做正确的事情。支付路由可以放在支付网关中，成为支付网关的一部分。但是，随着微服务的兴起和松耦合的需求发展，目前将支付路由作为独立的服务来维护部署是一种常态。支付渠道，是支付行为的通道。对于电商平台来说，支付渠道是提供给用户完成交易的最终支付和资金流转的载体。在支付系统产品设计中，常见的主流支付渠道包括第三方支付、银联、网联、银行、手机支付等。所谓支付协议，就是支付过程中应该遵循的履约流程。通俗来说，就是支付过程对支付服务的封装，其中包括支付过程中的核心要素，如产品编码、支付编码、支付处理流程、收付款信息、渠道信息等。当交易系统进行收单交易时，往往先通过支付系统，根据产品编码和支付编码生成一个支付请求，再通过交易系统和支付协议生成一个付款订单。然后支付系统将付款订单转化为支付指令去调用下游系统。会计是以货币计量为基本形式，对会计主体（企业、事业、机关、团体等单位）的经济活动进行核算和监督的一种管理活动。会计要素可以分为资产、负债、所有者权益、损益（包括收入、费用）、利润5个类别。