时间: 2021-08-03 08:31:37 人气: 13 评论: 0
编辑导读：2B又称B2B，也有写成BTB，是企业对企业之间的营销关系。2B企业发展至今，他们的发展状况如何呢？上面两章在宏观架构和微观架构上说明了如何构建起时间轴+空间轴的可被积累的框架，下面详细论证在此架构下如何落到实地，并基于这样的架构构建起百年2B。
再细化下4层模型在实际落地中对应各个角色的运作模式：
第一层是承载技术积累，也是最基础的部分，这里是由一行一行代码堆积起来的，或由一条一条与技术直接相关的配置数据堆积起来的；一些与控件相关的产品技术体系，由研发来主导建立，比如前面提到的搜索帮助体系、消息管理体系、多语言体系、模块化函数体系、标准化界面体系、权限体系等等技术标准的构建+工具的构建+防呆模式的构建等都由研发的角色一行一行的代码构建出来，而这些将**考验一个架构师的能力；
对2B架构师来说不但要考虑海量的数据问题，还要考虑海量功能的问题，如何能在同一套系统架构下搞定两个海量，就看CTO、架构师们的功力了！
滴滴当年有个案例，当进行补贴大战时，产品和服务器架构都搞不定，于是**率领2百人听说2周就对滴滴从头到脚翻新了一次，可见从功能应用层面2C是非常简单的；而相对2B到现在为止为什么SAP还不敢换他们上世纪80年代的技术平台和架构？
那是因为没有任何人敢用其他语言、或技术架构重构一次SAP的代码！这又是为什么了？
做开发的人都知道，写到系统里的每一行代码都代表着一种业务场景的处理、逻辑判断、业务控制等情况，你如果搬迁的时候没有把这行代码理解透彻，那么对应的业务场景就没有搬迁过来，那么就等于在搬迁过程中真实地产生了一个BUG或人为地产生了一个功能缺陷、缺失；不管是用其他的开发语言、还是相同的开发语言不同的架构重新开发一次，你也不能确保所有的代码是copy过去的，更何况是选择不同的开发语言，那多年沉淀的2B的解决方案、场景基本上是毁于一旦；这其实既是SAP的优势，也是SAP不可逾越的巨大劣势！
也是现在被大家攻击的痛点，可是为什么还得使用他，还是因为他一直不换开发平台，在上面积累沉淀了几十年，积累下全球45万家企业的解决方案并沉淀到IT产品里；各个行业，各个体量的，都固化在他的系统里或叫代码里了，任何一名员工都是在给他添**加瓦，员工的流失对这套产品体系没有任何影响，每一位员工的智慧、聪明才智都固化成代码沉淀到SAP的产品里，变成了看得见摸得着的“固定资产”！
做SAP的人都知道，在制造业对于一个具体的业务SAP一定有他的标准系统解决方案，如果你发现没有，打算用开发的方式实现，大概率是你自己对SAP研究的还不够透彻，这也是衡量资深顾问和普通顾问的区别，资深顾问**选择用SAP已有的功能并说服客户使用同时说明为什么，而普通的顾问**选择按照客户的需求开发出客户当时想要的功能，然后在未来的日子里一直在新开发的功能上打补丁、修BUG；而资深的顾问用SAP标准功能，提出的解决方案，在未来的日子里无论客户如何变化，都被SAP囊括其中了，毕竟SAP在其他很多地方都碰到过，他们选择了最好的几种解决方案固化到产品里；到最后你就有种孙悟空再厉害也没跳出如来佛手掌心的感觉！他们能做到这些那也是被45万家客户虐得遍体鳞伤居然不死还能升华重生之后才获得的能力，否则他们肯定无法做到如此强悍的适应能力！
反过来想想，你在客户那里刚开发的功能，只是刚刚出生的新功能，而人家在45万家客户中受虐过，已经是身经百战的老水手了，什么样的都见过了，所以才能囊括住接下来发生的种种情况，而你这新开发的功能才刚刚出生连一个客户的洗礼都还没走完，人家却被45万客户洗礼过了。
我对比这个的目的是想告诉大家，定好2B最基础的产品技术方向，并在最早期就搭架起可被沉淀的技术框架是多么的重要，他将是2B产品赖以生存百年的基石，如果没有这样的技术框架，那么对SAP来说也就是做了45万个项目而已，而不是把45万最终沉淀成“一”，唯一的“一套产品”他们能把海量最后化繁为简最终被收拢为唯一的一个“一”的产品！这才是真NB的地方，当然他们也能从这一个“一”拆分出45万！
下面我们来讨论另一种基础类型控件：技术的归技术、业务的归业务，即存在技术+业务的双属性的产品控件体系。
还是滴滴有一个很经典的案例，滴滴司机在滴滴平台需要提现，于是出现了滴滴平台真没钱的情况，技术上就是账户的余额小于本次提取的额度，于是滴滴就直接弹出了一个提示“滴滴余额不足，无法提现！”在技术上，这个消息没有错，他真实的反映了当前的实际展示的技术结果；但是实际却是“我就提2千元啊！”就这么一个提示在司机传开了，反而引起了疯狂的提现，都是这样的提示，于是滴滴司机们就“爆炸”了！当然后面程维找**借到钱化解了这个危机！
于是后面他们在产品层面就做了一个改动，当出现没钱的时候提示变成了“系统维护，请明天再提现！”这个案例告诉我们其实消息提醒不是一个IT问题，是一个纯粹的业务问题，特别是在2B领域往往一条消息是指向一个明确的业务问题，而作为一个开发者是肯定不知道如何引导用户的，所以也绝对不能用“技术语言”展现出来，因此技术只负责呈现该消息最原始的技术结论，具体的展现和如何处理以及引导等与直接用户接触的是需要交给专业人士来做！
我们来看那一个案例：
技术展现：
这里的消息提醒是：2021年4月没开账！
点开消息，针对这个消息有一整套解决方案的指引：
当然这只是一个消息，我们来看下他建立起来的这套产品体系：
F5这套消息数据里有几百个这样的消息，刚爆出这个是第201的消息：
针对这201的消息具体的解决办法是这样的：
而这个F5-201的消息，被这么多地方引用到了：
这条消息，在9个地方被引用到，而这9个地方可能是嵌套进某些程序小模块的，又将**有多少真正地方引用可想而知了；而在这么多被引用到的地方，其被爆出的消息提醒是一模一样的，对用户来说，不需要再去适用，只要一次就够。
引用这条消息的某个函数，被37个地方引用了：
这里只是列举了一条消息，而像这样的消息在消息产品体系中沉淀下来的有：英文的664,393条消息，可见其多么的庞大，当然这么多数据也不是一朝一夕就做起来了，SAP也是积累了30多年才到这个量，但是最重要的却是他构建起了这套可被积累沉淀的体系，剩下的就是在时间轴+空间轴上的积累；而这样的积累也不需要多么复杂的技术，需要的只是长年累月的堆积，而对于时间长河上的员工都是为这套体系贡献储备的一个个的“蚁工”，不管谁都一样，这才是NB的架构、NB的产品！
因此在第一层需要架构师搭建起可被积累的技术体系，剩下的要么就是普通的开发人员一行一行的丰富小模块代码或数据，要么是产品经理、或项目经理、或交付顾问、或最终用户一条一条的丰富这套体系下的技术级的配置数据，最终构筑起在时间轴+空间轴不可逾越的2B产品。
总结来说最底层，也是第一层，现在可以划分4大类：
第二层PAAS建模：这一层我们需要积累的是具体的业务解决方案模块，具有业务的抽象意义，不具有行业特性。这个维度将考验产品经理的建模能力，他需要高度概括一种业务场景的公共属性，或解决方案集合，并基于这些共性构建业务模型。
这一层以我目前的研究，并与实际相结合，目前共总结出两种方法，一种是直接用代码建模，一种用图形化编程建模，当然这里的建模，都是在第一层体系架构基础之上的。
对具体的业务抽象成模型、以及抽象出来后进行具体的IT建模，都是对产品经理巨大的考验，我认为拥有这样的能力，才是一个2B产品经理真正NB的能力，而不是具体的搞定某个功能（搞定某个功能叫项目经理或项目顾问）；2B产品需要的是构建该种业务场景解决方案的模型，当构建好这个模型后，基本上就做到了在这个小的业务场景，完整意义上的全部搞定，不管类似问题是否已经出现，全可以理解为搞定，因为已经从本质层面提出解决方案模型了。
比如就好像空气动力学和飞机的关系，只要是飞机就必须遵循空气动力学的**模型，对于你来说就是找到了这个业务场景下的“空气动力学”的模型！至于后面的各种类型飞机，那都是具体的一个一个实际的案例，当然这些实际的案例都无法与“空气动力学”相比肩！
我这里以采购订单举例，构建一个模型：
这是组成一张采购订单的4大部分；功能操作部分、订单头、订单行项目、以及订单行明细，这是第一层大的模型。
我们先对订单头进行分析、建模：
我们**发现对于订单来说，这里有很多的属性，每一种属性也许代表对应某个行业、或某个企业、或某种业务场景的解决方案、或处理逻辑，因此我们需要构建出一个可被承载订单头数据的一个模型，这个订单头模型，拥有上面说的那些能力，我这里大概分析了下：
这里我们分出对应订单头，可能**附属这些业务场景，但是具体在什么行业、什么规模、什么区域、什么采购业务等情况下，具有这当中的哪些业态，我们是无法确定的，因为在还没碰到具体的某个行业、具体规模、具体区域、具体场景下，我们都是无法确定的。
如果实在无法理解，比如我们现在做了一个杯子，这个杯子**被用来装酒、水、咖啡、甚至是汤，杯子里装的东西是装了一小杯、半杯、还是一整杯等等这些事情，对于造杯子的人来说，是完全不可知的，具体这个杯子用来装什么？装多少？都是由具体使用这个杯子的人来决定。如果装什么、装多少都被定义好了，那么这叫定制化，当然在我这里他叫“穷举法”！
当我们梳理出这些模型后，我们需要做到三个层面的建模：
1）定义好各个业务板块必须的和公共的字段
是指公共字段或叫标准字段，不能删除，IT处理逻辑是锁死的，比如订单编号，必须有、而且是基于顺序号自动产生等；至于具体有哪些被列入标准处理逻辑字段具体业务模型，具体分析。
2）定义好各个模块必须的和公共的业务处理逻辑
定义好对于订单头公共的处理逻辑，不**随着行业或业务形态的变迁**有所不同，比如单头数据必须要进行保存的动作，订单必须要有审批的动作，修改必须要有记录的动作，这些处理，不因为任何行业、企业的变化而有所不同，因此这些都叫公共处理逻辑。
3）定义模型可被自由添加的字段
上面第一条定义好各个业务板块公共字段、标准字段后，我们**发现在实际业务中**有各种各样的特色字段，比如服装行业有“网格”，医药“含量”等等行业特色字段。接着上面列举大家能明白的案例，还是我们造的那个杯子，在一家咖啡店使用，装咖啡时只能装到350ML的位置，而杯子上却没有350ML的标识，那么这时我们就在杯子上350ML这个位置画上一条横线标上350ML，以后每次都只装到这个位置就不装了；虽然这个杯子和其他的杯子是同一批出厂的杯子，但是他们却已经不同了。
而画出的这条横线就叫在具体行业、具体企业、具体场景下的个性化解决方案，我们需要提供的就是他可以在这个杯子上画这条横线。那么回到我们这里在我们的这个模型里，需要做到不但有标准字段，还得有个性化字段，至于在使用场景中具体可被定义多少个这样的个性字段，我们在模型里不做限制。
其实在实际应用只增加字段是不够的，还得需要对这个字段定义特殊的逻辑。就好比这个杯子为了达到必须是350毫升，我在350毫升这里不是画一圈的线，而是打一圈孔，只要**过350毫升，就**自动溢出，从而做到绝对的每一杯都是350毫升。
这个**孔的动作，在我们这个模型里叫“增强”，我们可以对我们新增加的字段自定义任何的业务处理逻辑，具体是什么样的逻辑，由实际业务来决定。这个时候不但标准字段有业务处理，我们新增的字段也有特定的处理逻辑，而这个新增的业务处理逻辑就叫行业解决方案、或叫个性化，但是他对我们整个订单的构架模型却没有任何影响。
上面是对订单头进行建模的分析和处理过程，对应订单行、和订单明细的建模过程也是类似的分析处理方法；
订单行部分：
订单行明细部分：
订单行和订单明细，这里就不做强分析论证，大家可以按照分析订单头的思维模型，进行建模；
有关数据部分我们已经完成了建模，现在需要的是对逻辑处理部分进行建模。对于采购订单场景，处理上分成三大块：
业务上游和业务下游间的数据流、业务流的转换，是2B业务很常见的处理方式。具体由哪些业务数据和流程实现他们的转换这是不可控的，在各个企业、各种业务场景上的具体方案都存在或多或少的差异。因此对于产品建模的角度来说，是不能锁死逻辑的，他们之间的转换逻辑在产品维度是一种松耦合的组合状态，只有确定具体企业、场景后才能锁定具体的数据流、业务流解决方案；
所以在模型上我们需要可以灵活产生各种上、下游转换的逻辑，和流程链路；数据转换，其实有很多方式可以实现，当然我认为比较“屌”的方式是这样的：
采用图形化的方式，对各个字段间的转换采用拉线的方式进行匹配转换，而且对每条线上的转换若存在特殊的处理还能写代码自定义转化逻辑，当然实际是否能做到这么“屌”我不能确定，但是采用稍微LOW一点的是一定可以的，包括每条转换上都可以写自定义逻辑。
其二构建业务处理逻辑，具体的处理逻辑按照我们对当前构建的业务模型，囊括下的业务大概有多少种公共处理逻辑，并封装成一个一个的处理，具体如何处理这里不做细节的分析，因每种业务模型抽象出来的处理逻辑各不相同，到本采购订单而言大概如上图列举的6种处理，然后就是用代码一行一行地实现。
上面阐述了第一种基于代码模式的建模，下面概述基于PAAS思想的建模；
我这里把计算机编程进行了4代的划分：
第一代：面向机器（汇编语言…）
第二代：面向过程（C语言…）
第三代：面向对象（J**A…）
第四代：面向应用（图形化编程语言）（低代码、无代码）
我这里谈的PaaS平台建模，即基于第四代编程语言，第四代编程语言，将不再是程序员的专业，它将是普通大众都拥有的技能，就好像20年前使用电脑是一个专业行为，但是现在使用电脑是一个大众行为，而用第四代语言编程产生功能应用将是一个大众行为。
我认为的大众行为不是那种随便在街上拉一个阿猫、阿狗就行的，还是需要有一定专业底蕴的。比如上面提到的企业语言，将是针对企业这个群体的特定的编程语言，只要是从事2B领域的不管是谁，都可以用企业语言进行编程，产生属于自己的应用，只是他们产生的应用基本是局限在自己所属的业务细分板块，比如干财务的，肯定无法产生一个好的生产管理板块的应用；采用这里编程语言产生应用的前提还是基于自己的专业基础底蕴的。
这样的功能应用产生平台可以长得像这个样子的：
在使用该模式进行业务建模时首先需要，当然还是第一层记录的小模块足够的多，就很容易构建起这样一个应用，如下的流程是我认为企业语言的编程平台的大概操作流程：
具体细到每个框往下细分都可以延伸很多内容，这里不做过多的阐述，这块目前我的经验还不够充足，我自己大概实现这个图的50%~60%吧，但是具体到每个框我都找到具体的案例，或实现模型。现在需要把这些整合起来形成一套完整的企业语言开发工具，当然就这一句话，换成实际可操作、落地的东西我估计也要好几年吧。
在第二层我们需要构建各种这样的业务模型，当然在产品最初我们可以集中构建一批这样的模型，然后在时间轴上随着接触到实际业务的增加、积累出更多的各种各样的业务模型，覆盖更多的解决方案，最终达到构建出2B这个领域的所有业务模型。我认为即使2B很繁多，但是在这个层级抽象出的业务模型，应该不**过1千个业务模型吧，至少我分析了SAP最经典的5大模块解决方案，按这样的思维结构对几大板块抽象出来的业务模型不**过100个！
本文由 @汪仔5908 原创发布于人人都是产品经理，未经作者许可，禁止转载。
题图来自 Unsplash，基于 CC0 协议
