编辑导读：2B又称B2B，也有写成BTB，是企业对企业之间的营销关系。2B企业发展至今，他们的发展状况如何呢？上面两章在宏观架构和微观架构上说明了如何构建起时间轴+空间轴的可被积累的框架，下面详细论证在此架构下如何落到实地，并基于这样的架构构建起百年2B。

我们再来剖析第三层

基于企业语言思维架构构建出具体的场景模型，那么现在就需要带入具体业务场景：

我们还是以采购订单场景为例，在第三层，更多的使用者是项目PM或者项目顾问，他们需要基于项目实际的需求，构建出具体的解决方案，例如上面列举到的9种场景，都是实际业务会碰到的，而且他们之间的处理方式也确定不同；

构建处理方案时，我们总体分成四大部分：

基础数据、操作部分：

这部分比较简单，主要是对本方案的基本信息的记录以及本方案的管理动作必须的行为，比如增删改查等动作，这里不做过多的解释。

关联处理部分：

这部分比较关键，主要分成3种类型的关联处理，这三种处理在配置上没有先后顺序之分。我们先来谈审批流，在2B中大概率的场景只要是流程都涉及到审批，而相同单据在各种企业、或者是相同企业在不同体量时期、或者不同的管理风格领导下都会呈现不同的样子，因此这里的审批流将是千变万化的，不能固定死；于是最好的策略就是引入可配置化的审批流，而审批流和单据模型采用的是松耦合关系，只要把审批流赋予该场景或者解决方案，就能使用，而具体是什么样的审批流，控制层级这些都不用该单据模型操心，都由具体的审批流配置工具搞定。

比如引入类似于这样的流程设计工具，这也是一种分层的思想，专门的事交给专门的人去做，我们只管把他这一层产生的成果拿来使用即可。

其次是格式化数据呈现（打印的表单等），在企业中业务需要在现实中流转，免不了需要打印，或者纸质档文件签字、存档的处理，而具体采用何种打印模板进行最终打印的输出，也是会出现不同企业、不同流程下输出的格式完全不一样。这里我们同样需要引入类似流程编辑工具的表单打印编辑工具，这样的工具市面也是不少，我们需要的是通过这些工具，编辑好打印表单的格式，并给到该表单进行引用。

我们采用类似这样的格式化报表打印工具编辑好打印模板，让对应的业务解决方案进行引用。当然实际中，这样的模板会构建很多很多，随着时间的推移，将在系统里构建起这样的打印模板库，我想这也是一笔不小的解决方案资产积累。

最后一部分，就是对该方案的全局增强，在实际应用中，我们会发现，我们构建的模型是通用化模型，当应对一些特殊的需求时这种通用化模型是无法解决的，这时我们就需要引入特定解决方案的增强模式，在第二层专门列举了一个杯子的案例，这里就不在重复；对应的增强相对构建的模型，将是行业、或者企业、或者方案的特色，或者叫定制化，这里我以SAP举例。

这是SAP订单场景中：ME23N T-CODE下包含的增强点的，我这里只列举了SAP最传统的增强技术手段，其实SAP还有很多其他增强的技术手段我这里不一一列举，但是SAP的增强还是有一定的缺陷，只能在他预留有增强的地方做个性开发，如果没有预留的地方我们是无法做的，当然他预留的已经足够多了。

我们点开一个看下：MM06E005：Customer fields in purchasing document

这个板块的接口向下，我数了共有13个增强出口，其中10个是代码层面的增强出口，3个是界面层面的增强出口。

这就是为什么SAP是一套标准品他却可以适应全球42.5万家企业的一大原因：他首先保住了标准品的足够强大的基础上，还能让你在其强大的能力上玩出其他花样；可以这样理解，他是一个巨人，并且还给了我们一个梯子让我们可以很轻松的站在他的肩上看得更远。

1）深化、传承、繁衍

当我们依据这套模型构建起几百种解决方案后，我们如何让这样的解决方案成为真正可被其他项目，以及之后新开的项目引用、参考，那么就需要当时产生这个方案的人，记录下足够多或者完善的信息，将会至关重要，深化、传承部分，共分成2部分。

2）方案讲解和再现

这部分主要基于三种手法，PPT文档承载方案、Word文档描述细节逻辑和操作手册、视频文件重现方案的各种细节，尽量做到全方位立体地呈现该方案第一手的感觉，而不是被人重复地以讹传讹，需要真实地重现当时的情况。当我们采用这样的办法，记录成百上千、甚至几万个方案时，某一个人或者几个人是完全无法掌握这么庞大的解决方案的。

这样积累下来的方案，才是有价值的、可被传承的，就好像你给唐朝的人一台电脑，对他们来说就是垃圾，不会使用也不能给他带来价值，再好的东西对他都是无价值的东西，和垃圾没有区别。为了让当时产生方案的人，能把第一手最新鲜最原汁原味的解决方案沉淀下来以供后面的人参考引用，就得做好这些知识传承资料；这样的传承、积累体系，才不会随着时间流逝、员工的离开等等因素而消失，他将变成这一体系的养分、变成铸就竞争高墙的一砖一瓦，变得牢不可破、不可撼动！

3）构建“方案”生命周期繁衍生态系统

在方案的生命周期中，被录入到这套体系的那一刻开始，代表这一方案的生命周期的开始，当然我们需要构建的这一体系，肯定是不希望她开始的一天也就是她结束的一天，我们希望这个方案在往后的岁月里不断地迭代、成长、追求这个方案在该细分领域成长为最完善的解决方案；

基于这样的思维理念我们就需要给予这个方案在生命周期中拥有可供迭代升级的环境或场景，于是我们为每一个方案开辟了独属于自己方案的讨论主题板块。当使用该方案时有任何问题、疑问，或者使用过程中有更新的想法时，都可以在这里讨论，大家在基于实际的情况、基于碰到的实际项目，进行方案迭代，或者干脆基于本方案衍生出其他全新的方案！

同时我们也构建起一套基于该方案的支持、服务体系，如果有即将要使用该方案的人了解PPT、Word、视频资料后，还可以去论坛看看，已经使用该方案的人对该方案的评价、或者建议、或者踏过的坑、以及该方案历程、也许最终发现基于该方案的衍生方案才是最适合自己项目本次需求的；重点是我们需要构建一套让方案基于实际的被引用和项目构建起一套自我循环迭代的机制，让每个人、每个项目都成为方案的养分，最终随着在时间轴上的持续积累，空间轴上的持续复制、扩张构建起不可撼动的方案仓库，而该方案库随着时间+空间的发展，已经存下了全球所有的解决方案，这样的一套体系，还有谁能撼动！

4）明细解决方案构建

方案明细板块，对解决方案进行最细微颗粒度的定义：

方案明细部门分成三板块：

1）数据字段板块

数据板块大致分为三部分，单头、单身、附加数据，单头总体定义该种数据综合属性、或者公共属性项，如单据编码、日期、创建者等字段；单身主要定义业务具体明细数据，比如物料号、金额、数量等；单头，或者单头的附带属性数据；当然每种数据都有属于单据本身系统默认字段，是不允许定义，是标准字段；这些标准字段在建模的时候都已经定义好，并且也已经固定逻辑，直接可以使用

数据板块总体分成三大部分：

基本信息定义：

基本信息定义主要字段名称、多语言、排序等，重点是添加的字段必须经过管控，不能随意添加，集中从字段库中添加，如果字段库没有，需要在第一层添加字段，然后再进行引用。

操作类似属性定义：

字段定义出来后在操作部分，将定义出具体操作属性，比如操作习惯下拉框、筛选框等，业务界面的呈现，比如该模型中，有新增、删除、修改三个业务场景，那么该字段需要在哪些业务场景出现，如只在新增界面出现，其他界面都是不出现；显示、必输校验、输入校验、防呆校验等，以及权限校验的定义，具体涉及的对该字段的操作的都在这里定义。

增强类定义：

上面的定义，都是基于该模型自带的逻辑进行定义，因此从大方向来说不存在企业级别的个性化，也许存在行业级别的个性化（行业级个性化可以开一个全新的模型）；当然定义完这些后，还是存在字段级企业级的个性化时，我们就需要进行增强开发了，总体自定义开发分成4种类型：

1. 界面增强：这类增强需要在标准模型的界面基础上新增界面，或者在标准模型基础上对标准模型界面进行修改、调整等。
2. 进入增强：在打开该界面时需要处理的逻辑，在标准模型的逻辑上增减一部分的逻辑处理。
3. 检查增强：在标准模型校验基础上，对依然不足以满足需求还需要进行检验，在这里进行增强。
4. 保存增强：当触发保存类按钮时，不但执行标准模型的处理逻辑，还需要处理增强类的逻辑。

在第一大类板块需要配置出来的将是类似的板块。

2）数据逻辑处理板块

我们在第一部分讲解了字段，在实际操作业务时，单据的产生基本都由上游数据转换过来的，然后再附加上其他维度数据，当然也有全新产生一张单据数据的，最终经过各种数据组合成一张新的业务单据：

如采购订单模型中，产生采购订单，可以有8种模业务单据源。

如果我们以采购申请为例，那么产生采购订单需要组合多少数据？在采购申请基础上+价格数据+供应商数据最基本的三种数据最终才能成为采购订单；而在实际业务中我们是不可能每个字段都手工输入的，我们更多需要的是输入某个主要字段系统将自动带入相应的数据。如本场景中，确定了采购申请号后，其他数据自动带入，确定价格单号后，其他数据自动带入，输入供应商号后其他数据自动带入；那么是如何做到自动带入的了？这里我们就需通过配置匹配相应的字段了。

当然这也得转换配置，最屌的配置模式，我觉得是这样的：

这种配置有多屌我这里不详细论述，前面的章节有讲到。

本单据中的数字字段，除模型本身拥有的处理逻辑外，跟随业务附加的计算逻辑：

在实际业务中，字段间存在各种逻辑处理，比如一个总金额字段，在行项目上，有数量、单价，那么总金额就能自动计算出来，但是在设计是无法知道是否一定需要总金额字段，那么类似这样基于现有字段，进行数学公式级别的计算需要进行配置，当然如果计算很复杂，也可以直接采用写增强算法的形式，得到结果。

3）单据流转转换板块

单据依据操作，改变自己的状态，而且各种状态间相互形成处理闭环，在构建模型时无法预知在各种场景下，状态的多少，以及状态间的流转的逻辑处理，当然模型本身可以默认一个状态流转，当需要优化或者修改时，可以将该模型进行修改、替换。

实际业务中状态流是很复杂的，类似于审批流一样的机制，状态流描述单据在业务流程中的位置、状态、以及接下来需要处理的动作。

在时间轴+空间轴构筑产品的细节，这里我就写到这里，当然还有很多细节，有兴趣在继续探讨；产品这个维度我做一个简单的总结：

在这套架构下，采用什么样的开发语言、以及对应语言的开发框架，都是无所谓的最重要的是选择了最基础的开发底层后，就不能换，否则又是从0开始，其实我们构筑的是一个飞轮效应的产品架构。

我们会发现，如果从下往上看，往上的每一层都是数据，只要数据积累得越多就越是强悍，比如对开发平台来说，第一层是无数的程序模块、无数的字段集合、无数的消息、无数控件等；第二层是无数的业务模型建模；第三层是无数业务解决方案；第四层是无数的业务交易数据；

如果是从上往下看，发现往下的每一层，都是配置的模块，都是基础的构成部件；第四层为什么能产生那么多有业务含义的数据，因为有第三层对应的方案配置；为什么会有第三层的方案，那是因为有第二层的模型构建；而为什么有第二层的业务模型，那是有第一层各种技术组件、技术数据，堆砌起来的业务模型。

在《规模》书中有一段说城市基础设施加油站、煤气管道等这些基础设施当增长到一定程度后，不再随着城市的变大、人口的增多变成线下增长；反而是越大的城市，这些设施反而平均拥有成本越低。因此我们会发现当一个对象是组成一个庞大系统的最小颗粒度元素时，当该最小颗粒度元素在该系统中增长到一定数量后，将不再随着该系统的增长而增长，相对来说既是规模越大，重复利用这种最小颗粒度元素的频次越高，即对于这个系统来说成本也就越低；回到我们本章节的产品，当我们产品积累得足够多的代码块、业务模型、解决方案后，后面交付的项目花费的时间、交付的成本反而是降低的，就像现在的SAP一样，交付再多的新项目，对产品本身的改动却很小，那是因为对于SAP产品来说就是一座城市，组成这座城市最小颗粒度元素类似加油站的基础设施已经构建得足够的丰富了，增加再多项目都不会对产品有什么改动；

《规模》这本书还阐述了另一个概念“升维”，表现形式是，当这种最小颗粒度足够多时，他们全部汇集在一起将涌现出区别于原来性质的新的属性，比如一滴水，和无穷多的水这是完全两个不同的事物；

我们不能用认知一滴水的方法，去认知无穷多的水，当他们完全变化了，就上图那可是载重12万吨的铁疙瘩啊，但是缩小后还是一滴水！

所以这套架构其实就是在各层里通过时间轴+空间轴，通过人+项目来积累各层的数据，当积累下这些数据后，无论是人员的流动、还是时间的流逝，产品本身都没有影响，这些在时间轴+空间轴积累下来的数据，最终都成为这条万里长城的一砖一瓦，最终在产品这个维度随着时间轴+空间轴的延续，成长成一款无可撼动的强大产品！当然积累起这么多庞大、各层级的数据，最终升维后会涌现出什么样的新特性，其实我也不知道，就好像古人在看到一滴水的时候，肯定无法想象到这滴水可以承载起12万吨的铁疙瘩，我只希望尽快看到这天的到来！

本文由 @汪仔5908 原创发布于人人都是产品经理，未经作者许可，禁止转载。

题图来自 Unsplash，基于 CC0 协议