前言
互联网应用的根本目标在于提高效率，现在市场上几乎所有的应用都有这个特点，实现这个目标是通过两个途径做到的，其一是网络协同，其二是数据智能网络协同在实现层面需要各个角色在恰当的时间点作出恰当的操作，无论网络有都么智能，它在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 实操影响
①通常情况下，客户指定和我方对接的负责人一般都是中层管理者，并没有最终决策权，对跨部门的业务了解程度并不深刻
②通常情况下，被指定和我方对接的负责人并不需要为项目的成败负担直接责任，权责也不是很明确
③在业务之外，还需要注意人事利益关系，这一点对项目能否顺利准时验收交付是很重要的。
④牢记一点，客户并不一定就是用户，客户需求是大于用户需求的，甚至于是冲突的，两者之间的关系分寸需要认证对待
（文/罗）