电商后台产品经理——订单中心

订单管理包括以下几部分。

1、订单下单

2、订单拆单

3、订单售后（退款退货）

4、线下服务订单

5、订单数据统计

6、扩展：购物车

订单中包含商品、优惠、用户、收货信息、支付信息等一系列的订单实时数据。通过订单中心，实现对线上订单、线下订单及第三方订单的管理，支持订单接收、订单自动合并与拆分、自动匹配仓库、库存控制、自动匹配快递、结算与支付等订单生命周期中的一系列协同作业。

扩展资料

依靠灵活多变的订单产品设计架构，可满足电商企业百万级的订单业务处理需求，提升订单流转的工作效率。

在订单生成之后，会随着订单的流转更新状态。不同业务类型的订单状态，例如机票、服务订单、商品服务订单等，和最常见的纯实物商品的订单状态会有所区别。以实物商品为例，我们来讨论一下订单状态的流转。

参考资料来源：百度百科-订单管理

在网上购买商品下单成功后，过一段时间再次浏览时，有时会发现你的订单会变成两个或多个，这就是系统做了拆单而导致的。

拆单，就是将一个大的订单依据某些规则的集合，将其分解成两个或多个子订单的过程，原来的订单称之为父订单。

拆单的重要性

通常我们所说的拆单一般情况下是指用户的销售订单，但在实际业务中，拆单情况随处可见，如采购订单的拆分、调拨单的拆分等等。本篇后续都是以销售订单的拆单讲述的，请知悉！

在互联网电商系统中销售订单是与C端用户关联最紧密的，单据量是最大的，是影响用户体验的，且拆单的规则相对来说是比较复杂的。

折单要求数据 准确、及时 ，因为拆单后的子订单是需要流入到仓储进行生产作业的，它会进行 拣货、出库、配送 等一系统的流程， 它也是后续财务系统对账或结算、数据分析的重要数据来源 。

拆单的场景

用户在APP等平台下单后，由于商品的库存数量不满足，可能在前端进行拆单，即用户自己选择是否需要拆单，可以按 最快送达 或 最小拆单 的规则进行。

看到这里您可能会有点疑惑， 库存不足时还能下单吗？ 现在很多网站上当商品不足时用户需要自行修改数量，然后才能下单。

确实如此，现在这种场景少了，但是有的商家为了提升客户体验，对于商品可以多仓发货时。因为单仓缺货而需要拆单时，由用户来选择决定是否购买，这应该也是为了 提高转化率 的一种方式。

还有一种场景，订单涉及多商家，需要单独付款的情况下，前端会直接进行拆单，但现在基本上都是合单支付了，这种拆单会使用户体验降低。

此外，有的商家既卖国内商品，也卖海淘商品，如果都混在一块，那么在支付前是需要进行拆单的，因为海淘商品要求用户的身份认证等信息的检验。

在多数情况下，都是用户下单完成后，由系统进行在后台进行拆单，拆单是要结合公司业务场景去考虑的。

用户购买涉及几种拆单

拆单除了以上几种场景，对于用户下单时系统上还会有什么操作吗？

有一种情况即用户下单时系统要根据用户选择的收货地址、商品等信息，判断是否有库存，订单应该归属哪个仓库，是否可以购买等，这个服务严格来讲应该归属于商品库存服务，但是也可以将其称为 预拆单 。

预拆单一般是调用仓储服务进行库存的判断，同时还要根据促销活动进行一些优惠计算，所有的这些都需要前端系统在处理时对订单商品进行一些标识，以便当用户支付成功后，订单流转到OMS系统进行物理拆单。

前端用户下单成功后，订单经过OMS的拉单服务快速流转到订单中心，便开始订单的再生成过程，订单拆分后的子订单会展示给用户，原订单一般不需要再展示，便于用户跟踪和查看。

所以在从用户角度来看，一种是可以直接看到结果的拆单和一种无感知的预拆单过程。

拆单的时点与地点

预拆单是伴随着购物流程进行的，这里不多讨论，因为这个究竟是否属于拆单也是要看我们如何定义。正常情况下用户选购商品完成后，系统不会拆单，因为用户有可能取消订单或未支付成功。

拆单的时点是要在  "订单支付成功"  后进行，且需要前端订单已经流转到后端生产库，在订单中心进行处理。

在前面有一种场景，如果购物中心不能合并支付时，在购物车中便拆分为几个订单，这时的拆单可以定义为 一次拆单 ，也可以归属于购物流程，因为用户不提交就不会生成订单号，不会保存各个订单的数据。

在用户支付成功后，各个订单同样是要向后台流转，经过拆单服务的处理才可以继续进行下面的生产。

在前面讨论拆单场景时提到一种 缺货拆单 ，这种场景的拆单是在用户下单支付成功后，订单有可能已经拆分为不同的子订单，但因某种原因仓库无货而导致的拆单。

这时拆单的时点是灵活的，一般是在客服系统中，根据用户的反馈确定是否拆单的。

缺货是影响用户体验的，但是缺货是始终客观存在的。

拆单分几级

从上图看，拆单应该为 三级 ，即用户创建的订单为父订单，然后经过拆单服务正常的分为多个子订单为第二级，后续因为缺货等原因子订单再次拆分为子（孙）订单。

在数据设计上，一般情况子订单与父订单的关联都通过ParentID来进行关联，但三级以上时，涉及原始订单的查询较麻烦。

具体看数据结构如何设计了，可以再增加一个原始订单号来记录最初的订单号，方便统计查询等，负责拆单服务的同学可以详细讨论下。

为了避免订单的复杂度及系统的查询、统计、分析等数据处理的难度， 订单最好最多到三级，不宜过多 。

拆单状态

以前专门梳理过订单状态的文章，详见《 订单信息与状态流转看这个应该足够了! 》,在拆单过程中也涉及订单状态的变换。

当父订单拆分为子订单后，子订单生效，父订单应该置为无效。

子订单或父订单经过缺货拆单后，原订单状态是无效还是其它？

订单拆单后状态应该置为“待下发”即需要通过下发服务，将订单推送给仓库发货。

如果订单已经下发到仓库后需要缺货拆单，单据状态应保留原状态。

这些都属于细节，但不得不考虑，因为订单的状态涉及到其他业务系统的计算和统计。

如：财务系统在应付报表时是根据支付订单进行统计和对账的，如果订单状态是无效的，那么系统如何获取此部分数据。

BI有些统计分析是按状态和订单数量等进行统计的，如客单价、有效订单数等等。

所以针对拆单而导致的订单状态是否应该区分原有的订单状态分别标识，是需要综合考虑的。

拆单原则

拆单的原因我们已经清楚，拆单的目的是为了保证履单，拆单的原则是什么？

首先是最小拆单原则， 即能拆两单，不能拆成三单，因为多拆一单不仅是单据数量的增加，它会增加系统的复杂度，降低用户体验，加大仓库作业量，增加运费费用等。

最快送达原则， 拆出的子订单要快速生产，快速送达，这个是增加用户体验的最好办法。但是快速送达，依赖于仓储物流的布局，这个在多仓可以发送到一个城市时尤为重要。

一般情况下，拆单要遵循这两条原则，同时我们也看到拆单服务，是依赖于基础信息配置的，电商系统最复杂的是很多地方都有关联。

拆单规则

拆单的规则因每个公司的业务不同而不同，这里罗列一些常见的规则供参考。

（1）不同商家的订单需要进行拆分

这个主要应用于平台型的电商，一般情况用户购买商品都进入不同的店铺，创建的订单也是归属这个商家的。但有的平台采用合单支付，即用户选购不同商家的商品，但支付是一次的。

这个和淘宝有些不同，淘宝上每个商家的收款账号是不同的，所以不能一次支付，但平台商家是平台代收款的，所以可以一次支付后再拆单分摊金额。

（2）不同仓或不同供应商的商品需要进行拆单

仓库不同订单需要分开，对于不同的供应商订单主要是指由供应商直接发货的订单即商品不存储在仓库，由供应商直送到用户，这个和平台商家类似。但是区别是签署的合同不同，一个是购销合同，一个是佣金扣点合同，细节不展开了，有兴趣可以留言交流。

（3）商品类型不同需要拆单

一般区分奢侈品或有特殊要求的商品，这个需要业务根据商品要求进行设置。因为商品要求不同，后续在物流环节采用的物流产品类型也不同，物流费用也不同。这部分也可以根据商品信息，在仓储进行处理，但最后在上位能够提前区分。

（4）商品温控属性不同要进行拆单

此部分一般是指生鲜电商而言，同一个仓库有常温仓、冷藏仓、冷冻仓，存储着不同的商品，商品的拣货、包装等都有不同的要求，所以需要进行拆单。

（5）大件商品拆单

大件商品与普通商品不同，它在仓库的存储位置、拣货方式、包装、运输都有所区别，所以大件商品需要每一件都拆单，大件商品一般遵循最快送达，不需要最少拆单原因的限制。

（6）根据库存拆单

这个是针对缺货商品进行的拆单，即有库存的一单，无库存的一单，如果是二级订单，则父订单相同，子订单衍生出子订单，子订单1的过程。

（7）线下门店商品不拆单

如果是线下门店购买商品，则不需要拆单。

（8）组合商品不能拆单

在促销活动中，有时会有一些大礼包等商品的组合销售，即A,B,C等商品经过仓库的组合包装后出库，所以针对此类商品不能拆单。

在拆单服务中需要调用物料单信息，进行判断，具体的要看系统如何设计了。

拆单的规则很多，在系统处理时，要依赖于规则设置的优先级来进行。

拆单算法

（1）稀缺商品算法

找所有商品在所有库房最稀缺的商品，获取该商品的阶数。

（2）降阶

找稀缺商品的都需要仓库组合，这些仓库是必须发货的，把这些仓库计入发货列表，这样就降阶了，剩余仓库再计算组合，减少运算数量。

（3）抽屉原理算法

找第一阶的仓库列表（发货量最大的仓库），这个库房的库存是必须要发的，然后再找次发货量最大的仓库，以此类推，用于后面的组合计算。

（4）找组合

按照仓库顺序逐渐增加仓库个数找组合。

算法也只是拆单过程中的一个路径参考，且算法依赖于拆单的规则而制定，无论如何要保证拆单的结果准确，拆单的速度要快。

拆单服务两步重要工作

以上一直在讨论拆单是由 1变2 ，由 2变4 的一些内容，在具体的拆单服务系统中要考虑哪些内容， 又有哪些工作？

前面所说的都应该在设计时考虑，而且最重要的是要依赖规则进行设计，数据的流转，时序等等。

金额分摊是拆单中最重要的一部分工作，也是最复杂的。

父订单的拆分，商品的重新组合，生成新的订单是第一步，第二步就是要将父订单的金额合理的，正确的分摊到各个子订单上。

订单一般分为订单主表和订单商品表、订单支付明细表和订单活动表。

订单金额有几个主要的部分 ：订单商品金额、折扣金额、礼品卡支付金额、积分支付金额、优惠券支付金额、订单支付金额等几个部分。

运费 是订单表中一个特殊字段，运费如何分摊是要特殊考虑的，一般情况是按金额占比进行。所以生成的子订单中各部分金额，也要保证与父订单金额一致。

订单商品表、支付明细表、活动表属于明细信息，要根据原始订单明细表的数据和标识进行计算分摊。

子订单的金额要保证 横向、纵向 都正确才行， 横向 是指子单的合与父单金额一致， 纵向 是指子单订单主表与明细表金额一致。

此外，在金额分摊计算过程有一项重要规则不可避免，即开票金额的考虑。

这部分金额的分摊与公司缴税息息相关，单据与发票要一致，要考虑商品信息、活动规则等等，非常复杂。

有的拆单服务将金额分摊独立出来，以降低对拆单的影响，提高订单流转速度。

拆单的速度要求

由于拆单后订单才会下发到仓储或商家进行生产，所以对于速度要求就是 快 。

在系统设计时可以依据规则等综合考虑，多线程是最常用的方法，但多线程需要考虑资源竞争和安全性。一般情况，如果下单后已经确定了仓库，那么可以按仓库启动多个服务，这样可以避免程序的难度。

对于拆单和下发在系统上也要有数据监控，不能出现积压的情况。如果拆单有异常时，在定时任务中，很多情况都是依赖一个信息字段的状态来进行循环处理，在服务中要有 容错处理 ，不能一直停滞不前。

拆单的影响

什么是拆单？为什么拆单？如何拆单？前面说了很多， 但对于拆单有什么影响呢？

先说一个场景，公司搞促销活动，买A赠B，但A与B商品的温控属性不同，所以用户下单后一定会拆单。

拆单后仓储拣货、发货是根据子订单进行的，很有可能赠品B先发货了，A后发货。用户先收到B签收了，然后A进行拒收或取消。此时，如果在拒收或取消A时不判断关联子订单，那么公司就会损失B。

如果判断关联子订单的状态，那么系统的复杂度将会非常之大，因为实际场景中一个父单拆为多单时是很常见的。

拆单后，子订单数量增加，对于客单价、统计分析等报表需要考虑其影响，维度和统计口径不同，数据结果必然不同，从而会影响到经营分析及决策。

影响，对于不同的业务有不同的理解，作为产品研发应该在拆单设计时还是需要要将利害与业务说清楚，尤其是运营人员(活动方面重点考虑），虽然这属于一个后台服务。

总结

拆单是复杂的，合理的拆单会加快订单的流转，友好的用户体验，过度拆单则会产生冗余的数据，增加订单的复杂关系，统计、计算、售后等各个环节。

以上是我对拆单的一次梳理与总结，感谢您的阅读！

其中类似于票务类订单的出票过程、酒店的预定过程在这里也归结到物流流转过程中了。

这里先解释一下第一行的流程，从用户角度来看只有三步：提交订单，选择支付方式、支付，但是背后的逻辑其实挺复杂的，毕竟用户的一小步，产品的一大步。

对于订单生成时核心信息为商品和金额，而订单设计到物流结算、供应商结算等问题，因此一般都会进行拆单，分为主订单和子订单，从逻辑分析的角度来看可这样理解：

从系统角度来分析，应该是这个样子（基于之前提到的各个系统介绍，优惠系统1代指金币系统，优惠系统2代指礼券系统，其中会员折扣金额是业务系统自己根据会员折扣规则直接计算出来的，订单中心不再进行二次计算）：

一、用户选择商品后进入订单结算页，此时需要判断：

1、根据商品结算信息计算订单总金额；

2、结算信息中是否有可用的礼券，选择礼券后需要计算礼券抵扣的订单金额；

3、判断用户的会员身份，计算可享受会员优惠的订单金额；

4、判断用户自由币账户是否有可抵扣金币，选择使用金币抵扣后计算金币抵扣的订单金额；

根据这些结算信息，得出订单金额明细，确定用户最终需要支付金额。

这四步背后的计算逻辑为：

1、该页面对应服务端是各个业务系统，业务系统可直接获取商品信息和会员抵扣金额信息；

2、选择可用礼券，进入礼券选择页面后礼券系统根据获取到的商品信息判断可用礼券，用户选中后业务系统根据礼券选择结果计算出礼券抵扣金额；

3、客户端请求自由币系统获取该用户可用结果，用户选择使用后，业务系统计算出金币抵扣金额；

二、用户提交订单后，业务系统将订单信息根据订单拆分结构穿给订单中心，包括：商品基本信息、礼券信息、自由币信息、商品总金额、礼券抵扣金额、金币抵扣金额、会员抵扣金额、运费等

首先，订单中心根据订单拆分结构将主订单进行拆单；

然后，金额拆分：

关于金币，请求金币系统，根据金币系统返回的金币可抵扣金额，将抵扣金额拆分到每个子订单上；

关于礼券，需要请求礼券中心，以便确定订单中的哪些商品可参与礼券抵扣，根据返回结果将礼券抵扣金额拆分到每个子订单上；

关于会员折扣:由业务系统直接拆分好每个商品可抵扣的金额，订单中心拆单后直接计算出每个子订单的会员抵扣金额；

关于运费：不参与任何优惠金额抵扣，业务系统需指定好每个子订单的运费信息。

根据订单拆分规则和金额拆分规则，订单中心可以完成订单拆分，生成主订单和子订单

三、订单提交后，进入收银台：

订单基于主订单进行支付，支付完成后交易中心通知订单中心订单支付成功，订单中心更新订单支付状态（包括子订单），然后订单中心通知业务系统订单支付成功，业务系统也会更新订单支付状态，以便订单生效后进入后续状态

总结如下：

互联网应用的根本目标在于提高效率，现在市场上几乎所有的应用都有这个特点，实现这个目标是通过两个途径做到的，其一是网络协同，其二是数据智能网络协同在实现层面需要各个角色在恰当的时间点作出恰当的操作，无论网络有都么智能，它在BtB 领域总是需要具体的人来作出操作反馈的，所以信息流在线下线上的交互流转是我们在设计系统的时候需要充分考虑的一点，事实上简单的把需求方的线下业务搬到线上很多情况下不但不能提高效率，反而会发生负的外部效应

至于数据智能，绝大部分客户其实并不满足数据采集、数据清洗和数据分析的条件，最大程度上只能做到一些自动化统计功能

在实际业务中，我们会涉及到生态、平台这一类的说法

我自己的感受是90%以上关于上述课题的说法仅仅是扯淡而已。首先来看生态， 比如一片草原，无论面积多么辽阔如果只有一种花草它是经不了风霜的，而生态的第一个属性就是反脆弱性，反脆弱性决定了只有异质物种才能组成生态，所以滴滴体量再大始终成不了阿里

再来看平台，某些客户会说我要做某个行业的平台，我想成为某个垂直领域的阿里。平台的本质含义是去中介化或者再中介化，然而中介这个交易链路在整个贸易历史上从商品经济诞生的那一天开始就有了，中介能够给交易环节赋能，能够为商品赋予独特的价值，这是理解中介的立足点，任何只看到中介成本而没有分析中介价值的平台都是耍流氓，大幅度低估了传统供应链渠道的价值以及新模式推广的难度

1. 概述

1.1 文档范围

侧重于站在产品经理的角度描述BtB 模式电商领域，在业务架构阶段可采用的一些方法和需要注意的细节，并会为此列出若干实例

本文档所述的BtB 包括 BtBtB 和 BtB2C 模式，也会涉及到 StBtC 模式

1.2 文档目标

从逻辑上完整的描述从业务映射到系统的过程

目标在于为项目实操开发提炼出一套切实可行可落地的工作方法，能够绕开上述模式电商领域建设中一些坑

1.3 涉及到的名词

1.4 行文风格

有些是现在写的，比较口语化，有些是摘抄我以前写的博客的，比较书面化

2. tB 电商说明

2.1 用户属性

B端客户决策维度多，达成交易的最低要求高，但流程标准化，输出可靠性高；而C 端客户的决策维度少，达成交易的最低要求低，但流程不标准，输出可靠性低。这是tB和tC用户属性的核心区别

2.2 了解供应链

2.2.1 传统供应链的价值

正如上述用户属性说明，tB 业务用户决策的维度多，流程长，直接从终端对接终端的交易效率太低，成本太高，所以就在供应链上产生了的很多"客户-供应商"关系链条，把这些因素降维成生意与生意之间的信任关系，虽然流程变长了， 但实际决策效率却变高了。我们可以说，各种供应商实现了为整个交易链条赋能的功能

2.2.2 启示录

①对项目所处的行业，其中的全体参与者进行分类分析和研究，搞清楚哪些人在什么条件上有价值，哪些人在市场条件下没有价值。如果要替代掉供应链上的环节，当然是从最没有价值的环节入手，提供给最有话语权的用户看重价值的其他环节。分析的五个维度：

②为这个产业链提供某些原本不存在的价值，有效提升整个产业链的效率

2.3 tB 电商的本质

完整的tB 电商系统本质上就是一个信息化供应链，有完整的传统供应链内容， 同时也有具备电商特色的功能，比如促活拉新和内容模块等

2.4 tB 电商的结构

2.5 电商业务全流

2.6 业务架构原则

模块隔离，应对扩展和需求变更

2.7 产品成功的一个公式

好产品的价值=（新体验-旧体验）-替换成本＞0 这个公式我记得是梁宁提出来的

3. 业务架构实务

3.1 指导思想

将业务单元高度抽象，每一个业务都划分为类和实例，利于后期修改以下将我认为需要注意的点提出来捋一次

3.2 前台和后台

这是个相对的概念，注意这个概念的主语更容易识别用户的真实意图

3.3 商品中心

3.3.1 各种关系

3.3.2 要点说明

①SKU 和 SPU

现在很多电商平台都以SPU为基本展示单位，但是在初期还是建议以SKU为基本展示单位，在视觉效果上显得商品比较丰富

②商品类目

可以大致分为前台展示类目和后台管理类目，两者之间需要对应一个松耦合关系，前台展示类目最好考虑周全一点，方便运营在做活动的时候随时调整

3.4 订单中心

关键是拆单的逻辑，拆单之后原订单会生成多个子订单，此时原订单和子订单的状态表述需要根据具体业务去协调

订单中心拆单的逻辑和WMS 中的分仓是紧耦合关系

3.5 支付中心

多数都是调用第三方支付的接口，没什么好说的，需要注意的是落实到具体的B 端公司，几乎每一个公司的财务制度都是不同的，那么怎么和客户的财务系统对接才是最大的工作量

3.6 调度中心

3.6.1 调度库存结构

3.6.2 库存调度说明

调度层相当于订单的分配中心，将订单转化成发货单，按照调度规则决定哪些SKU 由哪个仓库发货，发货仓的优先级设定

敲黑板，调度库存全部都是实物库存

3.6.3 库存调度的本质

解决供应链路中存在的反应速度和敏捷性的矛盾

3.7 库存中心

3.7.1 电商库存结构

3.7.2 库存同步

自上而下：从销售到调度再到仓库

自下而上：主要是入库问题，采购入库、退货入库、调拨入库

3.7.3 影响因素

销售订单、售后退货、预售、盘盈盘亏、仓间调拨、采购

3.7.4 设计重点：销售库存

可销售库存、锁定库存、已销售库存、活动库存、预售库存，预售的订单需要备货之后再推送到调度层

3.8 促销中心

促销的功能大致可以分为两大类：拉新和促活无论哪一类总结为三个字，坑很多

尤其是逆向流程，一不小心就会留下漏洞，例如在平台满额减的情况下，涉及到退货，退款的额度就是个很大的问题了

3.9 CMS

内容管理系统，主要目标是页面动态配置模块化、组件化、乐高化

3.10 采购中心

3.10.1 采购业务活动图

  3.10.2 我踩过的坑

①采购入库，很可能是批次入库的，那么在做库存同步的时候，自下而上库存数据推送就需要分批次了

②多数客户的货号都使用条形码，但是少数客户会有自己的货号编码规则，这样采购入库的时候就会多一道贴码的工序

3.11 仓储系统

包括WMS、TMS 和 OMS，主要功能是将订单转化为拣货单、发货单、入库单

等，以及分仓、分区域，并做仓位管理，生成拣货路线，根据拣货路线生成拣货波次，太复杂了，都可以写一本书，在此略过不提

3.12 物流中心

大部分项目都会直接对接快递100,可是要明白一点，快递信息有两个层面的含义，一是反馈实时空间位移距离，二是缓解买家在等待到货这个过程中的焦虑， 所以真正要设计一套完成的物流反馈信息还是很有难度的

3.13 风控中心

记录用户行为，分析规避可能产生的违法行为，比如诈骗、利用系统漏洞刷单刷钱

3.14 总结一下

设计整套电商系统需要遵循一个铁律：单据驱动数据

4. 方法论

4.1 一个原则

服务于BtB 模式下的互联网产品首先是受客户的具体业务约束的，这一点有别于纯粹 2C 的产品有很大发挥空间

一般情况下在MVP版本，电子商城或者整个电商系统就是为客户的实体业务做素描，在还原度达到80%以上的基础上再求创新

本质上这是一种受约束的小范围小粒度的创新

4.2 两种方法

4.2.1 概念上的方法

作为BtB 领域的业务架构师，岗位职责就是完成从业务到系统的映射关系，概念上产品开发方法是这样的：

①几乎所有的互联网产品都起源于一个想法，有逼格的人把它叫做 IDEA

②尽快完成这个想法涉及到业务的闭环（MVP），包装成产品，投入市场

③全方位采集用户在使用过程中的数据，分析之后作为迭代的依据和验证标准

4.2.2 实操层面的方法

①要注意一点，系统活动≤业务活动，很多业务需求考虑成本和效率并不需要在系统层面去实现

②整个过程就类似于一个反向的涟漪，从外圈向内圈蔓延，这也是一个抽丝剥茧的过程

4.3 实操指南

4.3.1 业务调研

问怎么做的时候更要问为什么这么做，同样一个问题对于不同岗位的意义都是不一样的，360°的调研才能真正理解一个问题

提醒一点，不要迷信市调。一方面市调的样本肯定是有限的，有限的样本不一定能够反映市场的特征；第二方面，被调查的对象能够告诉你的永远都是已经发生过的事，而我们通常想做的产品都是面向今后的市场，昔日往事可以借鉴，要是用来指导将来就有的你好看了

业务调研完成后，最好输出一张服务蓝图，将客户所有与本项目有关的业务全部列出来，类似这样的东西：

4.3.2 业务分析

最好是懂技术，你会发现事半功倍，基本思路就是讲调研所得转化为系统实现，输出业务事件清单和业务用例（BUC）

业务事件清单列明了所有干系人和相邻系统与本产品之间的互动，罗列了产品需要输入和输出的各种数据流，定义了数据流的类和属性，通过数据流的类和属性计算出功能点，用来估算工作量，估算工作量的公式：

工作量（人月）=（功能点数量÷150）×功能点数量的 0.4 次方

4.3.3 系统分析

通过对业务用例的解读，得到产品用例（PUC），现在可以根据产品用例来建模了，这时候曾经抽象的蓝图式的产品概念开始具象化，开始向可分解的工作流靠拢

4.3.4 一张图总结

5. 补充内容

5.1 管理需求

需求并更是再正常不过的了，在实际操作中其实并没有一招制敌的方法，强行安利一种的话一般是这么干的：

①为每一个需求表明分值，表格如下

满意度从1 到 5 递增，愤怒值从 5 到 1 递减

②召集涉众为该需求评分

③分别计算出满意度平均值和愤怒值平均数

④两者相乘，乘积就是该需求的总体得分，接下来让客户自己选吧

5.2 客户的那些事

5.2.1 客户画像

5.2.2 客户特点

5.2.3 实操影响

①通常情况下，客户指定和我方对接的负责人一般都是中层管理者，并没有最终决策权，对跨部门的业务了解程度并不深刻

②通常情况下，被指定和我方对接的负责人并不需要为项目的成败负担直接责任，权责也不是很明确

③在业务之外，还需要注意人事利益关系，这一点对项目能否顺利准时验收交付是很重要的。

④牢记一点，客户并不一定就是用户，客户需求是大于用户需求的，甚至于是冲突的，两者之间的关系分寸需要认证对待

（文/罗）

使用场景

在Zookeeper中的监听回调机制，以及分布式锁，都是使用了观察者模式。

基于zookeeper去做分布式锁

（1）系统A尝试获取zookeeper上的一个锁，获取到了

（2）系统B尝试获取zookeeper上的一个锁，被系统A给锁了，没有获取到锁，此时系统B在zookeeper上可以注册一个监听器（观察者）

（3）系统A一旦将锁给释放了，zookeeper感受到锁被释放了，就会立即通知系统B注册的那个监听器

（4）系统B就立即被通知到了，系统A释放了锁，系统B可以重新尝试在zookeeper上加锁

电商系统里，也有这种场景，如果两个系统之间走了异步请求，那么可以基于上面那种观察者模式现在一个进程内实现监听，以后拆分微服务分布式架构了，可以改成基于zookeeper来做分布式协调。

系统A发送了一条消息到内存队列，系统B获取了消息开始执行操作

但是系统A需要知道系统B的一个执行的结果如何，

此时系统A需要注册一个观察者到系统B上去，系统B执行完了之后，将执行的结果，反过来通知给系统

我们就可以基于观察者模式去做。

与to  C 的产品设计有本质不同，C端用户更注重界面设计和用户体验，所以很多公司在后台系统快速迭代的过程中经常忽略原有的要求，或者说根本没有UI去设计，认为后台系统只要可以正常使用就上线，但这样真的就行了吗？

商户平台管理系统是 供应商和商户在平台上进行合作 ，链接上游供应商到下游商户的公共平台，其中供应商主要是各大保险公司经销商，采购商主要是基于场景化的公司，将产品放入他们流量渠道中的商户，所有的商户分销渠道都是在商户系统中管理的，如果没有一个较好的功能与体验，将减少商户使用和操作。

B2B商户平台管理系统

商户平台对于采购商功能会比较多，这里主要讲述围绕采购商（下面称商户）对产品推荐、申请产品、授权管理、引流管理与结算的体系，公司目前主要具有以下几大模块结构：

商户首页：新手引导、企业采购、关注场景、最近使用功能、平台公告、待办事项

账户中心：账号设置、资金账户、我的申请、我的合同、开发者权限

运营管理：申请产品、引流管理、订单中心、开发者高级功能、统计概览、财务结算、活动中心、其他功能

自助卡：自助卡管理、自助卡管理新系统

文档资料

这里说明一下开放API接口：具备一定开发实力的商户可以自行在原有功能上进行扩展，相较于提供统一的功能与交互，开放API接口可以切合他们自己的流量平台，提供更优质的方案。在这过程中主要提供产品关相关字段、商户ID等信息，要注意同步开关及权限，处理信息自动同步和手动设置之间的问题。

商户平台设计

商户平台设计中应该遵循以下几点：

在首页，商户认证注册会有三种状态显示，分别是未实名认证、已实名未申请合作产品、已实名已申请合作产品，在进行功能设计前要了解商户认证注册流程。

商户认证注册流程

商户邮箱登陆后进入首页后是未实名认证，需要进行企业实名认证流程，记录其存储的企业名称、法人证件号、营业执照以及联系方式，提交之后系统会向对公账户打入一笔金额，在收到金额后输入打款金额再次提交后通过审核，此时商户认证注册是已实名未申请合作产品。

然后商户可以在首页中进行产品申请，挑选一或多个保险产品申请合作，审核通过后会自动生成盖有公章的合同，此时商户认证注册是已实名已申请合作产品。

了解了上述内容之后开始进行此次首页改版，需求发现商户在首页使用率不高，而运营人员也经常跟我抱怨说很多商户打电话询问认证流程具体操作，哪一款产品引流费高。

因此整合出以下改版目的

在功能、交互以及视觉上做了一系列调整

功能上

最近使用功能：是商户状态记忆的目录，记录商户上一次点击查看的目录，在这个系统中头部导航里会有二级目录和三级目录多达30多个，商户在点击查看各个目录之后，首页中最近使用功能排放顺序也会不同，对用户来说并不能养成习惯性操作，所以在之后做成了常用功能，商户可以自定义添加删除目录；对于未注册成功的商户功能也只展示一部分。

推广产品：为了节约开发成本前期是在后台数据中固定四种产品，对商户吸引力度不够，现在按销量和新品排行；‘查看更多’按钮放在右上角，区别于操作按钮‘申请开通’。

视觉上

页面布局：之前采用左右两栏结构类似于微博这种形式，但右侧一栏元素较少，页面上内容本来就少且固定，过于浪费页面空间，因此改变布局将页面充实变得有质感，并增加了banner轮播图。

平台公告：单独放于右侧，排列展示不是很有吸引力，因此之后横幅展示，动态轮播。

关注场景和企业采购：这一块是入口按钮，跳转进入行业场景的宣传，统一整合放在banner右侧。

交互上

新手引导：这一块在后续整理流程时发现实际有三部操作，因此增加最后一个步骤，并添加文档说明引导客户在不了解具体操作的情况下可以查看文档，采用横幅展现减少占位；已认证注册成功的商户此模块不显示。

通过改版后的首页变成了让 页面层级更少，信息更集中，设计更合理 。作为一款处在成长时期的商户平台，不同的商业策略需要有不同的交互方案，配合公司的目前现状，直接影响着产品的形态，并进而对产品的发展产生影响。

以上欢迎留言讨论～

一. 商品展示

站内搜索(搜索提示，搜索规则，搜索成功页，搜索不成功页，相似推荐)

导航(频道导航，其他导航如销售排行，广告位，推荐位，文字链，also buy等)

商品分类(品牌分类，品类分类，属性分类如剪裁形式)

登陆页(商品列表页，商品详细页，商品活动页)

这里的访问逻辑是：a /b/c分流消费者去往相对个性化的页面，由登陆页体现商家的核心诉求和价值传递，完成call-to-action的第一步。

二. 内容展示：内容展示较为简单，对纯购物品牌而言包括：

公告区

帮助中心

论坛(如需商城与论坛发生交互，则需自行开发，否则可集成discuz做同步登陆即可)

三. 订单确认

订单确认，就是帮助消费者正确提交订单信息的环节，看似简单，实则非常复杂，需要对很多信息逻辑判断和处理，一般由2个部分组成：

购物车

订单提交(返回购物车，收货地址&地址薄，支付方式判断，配送方式，发票，订单标记，实付金额计算等等)

四. 支付系统

与一般的想象不同，支付系统其实并不简单等于第三方支付工具接入：

外部支付系统(支付宝将接口，财付通接口，网银直联端口，信用卡分期端口)

内部支付系统(账户余额，积分，礼品卡，优惠券)

支付系统的逻辑设计不但需要考虑到各种极端情况的发生(如一张订单先用礼品卡，再用积分，最后网银支付)，还要预留财务做账所需的相关字段，并充分考虑订单取消之后如何回滚各类内部账户。

五. 用户中心 

注册&登陆(快速注册，完整注册，注册有礼，推荐注册，密码找回，主站id登陆，open-id登陆如qq，新浪微博等)

订单中心(历史订单状态，中间状态订单修改，物流追踪)

服务中心(各类自助服务如退款申请，退换货申请，建议与投诉等)

信息管理(用户基本信息管理和账户信息管理)

一. 商品&促销

商品管理(品类管理，品牌管理，单品管理)

促销管理(活动管理和自定义活动模板管理)

在上述模块中，最重要的是2个部分：单品管理中的批量产品生成的自动程序和活动管理中“共享与互斥”管理。前者用于大幅提升上新速度，后者避免促销活动失控。

二. crm ：crm是对b2c核心资源—会员的管理，服务与再营销系统，包括如下部分：

会员管理(会员信息的增删改查和到其他系统的链接)

用户关怀(条件触发和人工触发相关edm &短信&ob)

定向营销(会员分组和营销活动管理)

客服管理(内容非常多，集成所有需前台与后台交互的功能，详情还是看图吧)

呼叫中心(ivr，坐席管理，统计报表，参数传递与窗口嵌入)

值得注意的，edm和短信通道市面上已经有成熟的外包服务商，一般都会外包；呼叫中心和在线客服自行开发成本太高，特别是呼叫中心系统，业务初期也都是外包的。

三. 订单处理：订单处理是在订单未正式进入仓储部门处理之前，对订单的前置性处理环节。

订单录入(电话订购，网上下单，外部团购订单，无金额订单录入如礼品单)

订单审核(自动审核和人工审核)

rma处理(rma申请单和rma处理单)

四. wms(warehouse management system仓库管理系统)

wms的流程很长，功能模块也很多，大致分为入库管理，库存管理，出库管理和票据管理4个模块四个模块

五. 采购管理

供应商管理(供应商信息管理，合同发票管理)

采购单管理(po单管理，负po单管理)

库存管理(库存查询，库存占用单，库存变动log)

六 .财务管理：b2c的财务管理，主要是对供应商，渠道和内部费用支出的成本控制。

供应商结算

渠道结算

配送结算

内部结算

七. 报表管理： 报表是b2c业务的宏观表现，理论上说，每个部门的kpi都应该从中找到。

搜索报表(站内搜索量查询)

销售报表(多个维度销量查询，优惠券使用情况，报表导出)

财务报表

客服报表(客服日报和坐席报表)，前者反映与消费者发生的日常交互(包括正常与异常)，后者考核客服的工作绩效

仓储物流报表，这几块报表，是业务运作的核心，涉及到公司机密，就不能写的太细了，见谅。

八. 系统设置：这块大家都知道是干嘛的，也就不多说了，分成三块。

基础设置(和业务有关的一些字段值)

权限设置(不同账号的操作权限和操作记录)

其他设置

九. wa系统(web analytcis)

网站分析系统，几乎全是外购，很少有能够自建的，即使自建，最多做几个简单的模块。用于实战的，要么是免费的ga(google analytics)，要么是昂贵的omniture。

  电商后台是由若干个部分组成，包含商品中心、订单中心、支付中心、会员中心、调度中心、库存中心、促销中心、内容管理系统、评价中心、店铺管理、采购中心、财务管理、仓库管理（WMS）、物流中心、风控中心、客服系统和权限管理。好的产品框架具备“可复用、可扩展”的特性，能够支撑业务拓展，降低维护成本。

  随着公司业务的发展，会不断扩展功能模块。由于每个子系统不是相互孤立的，产品架构决定需求和设计，技术架构决定技术框架与性能。

  随着业务的发展，需求和功能也在不断迭代，所以也就要求产品架构和技术架构可扩展性强，不能够“写死”，能够随着业务和需求的变化而变化。产品架构将这些不同用途的功能进行聚类整合，将电商后台拆分成多个子系统，明确业务边界，尽量减少系统之间的耦合，高效支撑前端业务。当电商的体量越来越大，公司就会将各子系统独立出来，由专人进行维护运营。