编辑导读：2B又称B2B，也有写成BTB，是企业对企业之间的营销关系。2B企业发展至今，他们的发展状况如何呢？本文是系列文章的第二篇，讲述“基于共性搭建可在时间轴+空间轴积累的系统架构”，希望对你有帮助。

2B行业包罗万象，各个企业在细致末梢的处理办法更是千变万化，在2B这个行业应了那句“一千个人心中有一千个哈姆雷特”，不同行业完全没有可比性；即使相同行业，不同公司对同一业务的处理都会有两种完全不同的解决方案，即使同一家企业在不同的体量、不同的阶段对同一业务的处理都不同，即使同一种业务、同一个时期换了不同的主管可能处理方式就不同。

例如A领导是一种放权的领导风格，那么他在审批这个场景上几乎和一个强调控制性B领导的解决方案完全不同；在解决方案层面你会发现A领导主导下的业务，层级少的多，B领导主导下的业务基本都需要直达顶层；A领导主导下的系统解决方案灵活、讲究松耦合讲究快速高效横向协同；B领导主导下系统，强调卡控、层级分明等级严明，落到系统层面就是校验、控制、结点卡控就会非常明显；系统在A和B两个领导主导下的运作是完全不同的！

如果从这个层面看全是不同，如果我们站的更高一点来研究企业，我们发现他们却能抽象出很多共同的特性。

第一节： B端遵循一套相同的语言体系“企业语言”

富士康郭台铭说 “什么是企业管理？就是单据流跑顺了！”这当中有一句非常重要的话“单据流跑顺了！”

如果把这句话拆分来看他的构成元素有“单据”“流”“跑”“顺了”！这是最小颗粒度的拆分，我们分析下，其中唯一的名词是“单据”如果我们在2B解决方案这个领域工作久了就会发现，这个词太有概括性了，企业中最基础的业务单元不就是它么“生产订单”“出货单”“采购订单”“销售订单”“报销单”“付款单”“收款单”“请款单”“.…”

我们发现在我们构建的系统里全是这些琳琅满目的单据，企业里这种单据类型多的几百上千，少的也有几十种；不分企业、不分行业、不分国家只要是2B类的解决方案，全都大量的有这样的单据存在。

“单据流跑顺了”这句话中我们对“单据”这个名词进行了解剖分析，提取出一个共性！这当中还有貌似两个动词“流”和“跑”，我们在逐一分析下，我们发现“流”这个词代表的一层含义，这个单据有先后顺序，而不是随意杂乱无章的，而且还得满足一定的规则或要求，才能叫“单据流”；还有一个字“跑”这就是一个完完全全的动词了，名词“单据”用副词“流”定义好，那么就得让他动起来于是“跑”就出现了，“跑”却不能乱跑而是要“顺了”。

于是这样分析下来，我们是否就可以得到我们在企业解决方案中经常出现的一种叫“流程图”的东东。

上面画的流程图，是最简单的此处只做案例讲解不对业务场景做过渡深入的探讨，我们从该图可以发现，这条流程中，出现了多张单据，而且相互间还存在流转关系；如果我们在进行下抽象，有没有发现这条流程中，“单据”是最小颗粒度的对象，而这一张图，却表述清楚了一条B端的业务流程；我们是否可以理解为这就是B这个属性个体在描述他们自己的事物行为的一种记录的工具或者干脆叫语言？

我们按照这个思路深入思考下，我们每个企业其实都是一个智能体，一个独立的智能体，这个智能体的“大脑”是谁？CEO、董事会！这个智能体的四肢是谁？销售、采购等！这个智能体的躯体是谁？财务、生产、后勤等！既然他是一个智能体，他是怎么记录自己的行为的？他是怎么和自己的同类进行交流的？人类有属于自己的语言汉语、英语进行记录、沟通属于人类这个群体的方方面面的事或物；而企业这个智能群体的语言是什么了？人类语言最小颗粒度是单词！而这个群体语言最小颗粒度是什么了？

接着上面的论证我们发现，这个群体描述一个行为时最小颗粒度就是上面我们说的“单据”，单据和单据相互间按照一定的先后顺序、规则串联起来，居然就能清晰的描述这个群体的一个业务事实，这是否就等于我们人类用汉语、英语书写了一句话？如果还是没感觉，可以在回到我们上面那张流程图看看，是否就是用这个群体独有的语言体系，写了一句这个群体语言体系下的一句话，现在大家把这句话叫“流程”！

有人对语言进行了维度层面的划分：

• 英语：一维语言，只有他的读音代表意思
• 汉语：二维语言，不但读音代表意思、字形也代表意思（汉语比英语维度高一维，听说一个佐证，用英语写的著作翻译成汉语字数都会少很多）
• 企业语言：多维语言，简单来看，大家随便拿一张企业里的单据来看看，里面有多少个字段，很多种数据才能组成一张单据，例如一张采购订单，里面有多少维度看下图，每一个维度都代表着一个意思。

实例：

模型化一下：

当然企业语言也有属于自己的语言体系，这里进行了一些粗略的划分，当然不全只是一点盖面论述这一概念，如下图：

到这里完成了第一个共性的建立，企业这个群体是一种智慧的独立个体的认知模型，且拥有属于自己的语言体系“企业语言”！

第二节：基于分形理论的自相识性特性构建认知模型

大家是否知道“分形理论”的认知模型，初略解释下在路上你看到一颗树，即使你不知道它具体是什么树种，但是你一定会认出他是一颗树，而不会认为它是一颗草，这就是分形理论最粗显的解释；一般分形理论解释为海岸线的场景，海岸线不管是在1万米高空俯视海岸线，还是在10米相对微观层面他们都存在一定的自相识性；而2B企业虽然多如牛毛，但是他们同样存在一定的自相识性；一个2B的企业，你一定不会把他认为是一个人，你一定会认为他是一家公司！当他们存在这一自相识性后，我们就可以用分形理论，对2B在架构层面进行IT建模，并基于这样的模型提出IT解决方案。

我们发现在2B尺度内如果用IT视角看的时候，他们存在类似分形理论下宏观到微观的自相识性，并可以基于本层的自相识性的构件组合成单据、业务解决方案、IT系统。

第三节：基于分层模型构建2B系统架构

对世间万象的问题计算机领域确实可以用穷举法进行罗列，并最终找到特定穷举法下的解决方案，现在大家为B端做的项目型系统、解决方案，我认为就是这样的思路；我们可以反思下为A企业开发的系统或者解决方案能原封不动的copy到B企业让他直接使用么，如果不行，那和我们IT领域常说的穷举法有什么不同？

现在一些专门做企业定制化的公司就是这样的思路，当然这些公司也很成功，比如东软、赛意等，按照项目甲方的需求进行定制开发，每个项目都是定制化业务，这就是IT领域典型的穷举法，只是这样的穷举法解决方案什么时候是结束了？

咱们NB哄哄的IT人士既然知道用穷举法，当然也知道用建模的思维，我们的价值就是要杀掉穷举法这种lowB的做法，我们需要的是窥探到本质从这些中找到他们的共性建立属于2B端的IT模型，从而推导属于B端的解决方案。

如何把一个复杂的问题分析清楚，其实中国有一个很NB的成语叫“抽丝剥茧”，但是对于我们这种IT的脑袋没办法悟透这种玄学层面的东西；20世纪最伟大的发明之一“互联网”在全球要组织起这么复杂的网络结构，他是如何解决的？我们是否可以从中找到一些可参考性的思维架构了？当年的那些大牛为了解决这么复杂的问题，提出了什么样的模型？

大家看到这个模型时，不知道有什么感觉？咱们2B的解决方案提取共性，和网络7层模型有什么关系？

2B解决方案共性模型，和7层面模型是真没关系，但是咱们需要借鉴的是他分析解决问题的思维方式“分层”，我们分析下这个模型我们会发现，这个模型每一层只解决一种问题，而不是把所有问题放在一起解决，这就是我们需要构建的思维模型。

我这里采用分层的思维模型，对2B类的IT+互联网解决方案共分了4层，以及对应的系统架构。

第一层：功能代码

最底层：功能代码层，也是最基础层，这里对各种代码进行最小颗粒度的封装，比如数字在2B这个领域喜欢用千分符，那么这里就直接对数据格式化千分符分装成一个“function”以后只要谁有千分符的需求，直接引用这个“function”，而在这一层基本只处理这个颗粒度的模块封装，这块SAP做的非常的好，我们看一下他们做了多少这样的模块化封装：

他这里封装的2万多个小模块，都是一个个小功能或处理，如果把每一个小模块比喻为一个汉字的话这代表什么？大家知道4大名著，总共只使用了7千个不同的汉字，如果按照IT的说法，这有2万多个小模块，对应到汉字2万多个汉字，写4大名著绰绰有余，但是人家只用这些组合出一套系统而已！

第二层：业务模型

在第一段我已经论证了，企业中有属于自己的语言体系，最小颗粒度单词为“单据”“操作”“主数据”这些对象，而本层需要解决的，就是构建起这些对象的IT模型，一个企业这样的单据多则几百上千，少则也有几十，我们需要做的就是构建起能托起这些最小颗粒度的IT容器；

从第二段分形理论，我们发现，只要是单据他们都存在某种自相识性，在加上第一段论证的企业语言单词的定义，我们发现我们本层需要解决的就是装下各种单据的IT化容器，从分形理论往下缩放，我们发现，他的下一层是表，表的下一层是字段；那么我们在本层需要构建的IT模型就是如何构建起多个字段、多张表组合起来的一个业务模型，而有多少种这样的业务模型，将取决于我们有多少种业务单据，也就是我们常说的单词的个数，至于这个单词里要表达多少种维度的意思或者数据，就取决于这个模型和数据表代表的复杂程度和对应数据诠释出来的业务意义。

第三层：解决方案层

当我们在第二层构筑起不同业务模型后，那么就进入实际的业务建模阶段，这里以ERP场景中的采购订单为例；

我们在第二层建立起采购订单业务模型，那么在这一层我们需要构建的将是具体采购订单在实际业务中应用解决方案；企业采购订单场景中，对不同行业的采购订单数据、控制、在各种场景下都不一样；那么这一层我们又将如何利用第二层的成果？

比如在服装行业，订单需要区分大码、中码、小码，蓝色、红色、绿色，因此他们就比其他行业多了一个字段叫网格；在药品制剂行业，相同的制剂有不同的含量，相同制剂不同含量使用不一样，那么他们也特有一个字段标注这样的情况，这个字段叫“含量”；类似这样的差异太多了，这里就不在过多的列举了；

那么在一层，我们需要做的是，配置出各种这样的解决方案，如果是传统项目型的，这些都是采用代码一行一行来实现，可是我们要做百年2B，就不能把这些变成代码，这些将要变成我们的数据，当这些是一条条数据的时候，我们在下家公司碰到时，直接把这些配置数据复制过去就OK了。

其次这次的解决方案我们也通过这样的方式积累、沉淀下来了，这样逐个解决方案的积累，我想全球采购订单场景，应该不超过2000种把，随着在时间轴+空间轴合作伙伴的一同积累，当真的积累起2000种采购订单场景的时候，全世界在采购订单这个细分解决方案领域，全球还有谁比你更加NB；采购订单场景我们可以这样，那么销售订单可以么？生产订单场景可以么？对账单场景可以么？……..

当我们基于上面的三个宏观的共性构筑起这样一套IT系统体系后，剩下的就需要在时间轴+空间轴上的积累了，形成各种业务的解决方案仓库，什么企业都能在里面找到或者可以借鉴的解决方案。

当然还有第四层，这一层将是基于下面三层架构构筑起来的产品树上结的累累硕果的业务数据了，这里就不在论述！

这套2B的IT架构，是基于云模式构建还是基于本地模式构建其实都是可以，当然最好是基于云模式的互联网架构是最NB的，实在不行最少保证一、二、三层在云端，第四层在企业本地，也就是我们常说的混合云！其实做大B生意要“讲武德”的！

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

题图来自 Unsplash，基于 CC0 协议