编辑导读：2B又称B2B，也有写成BTB，是企业对企业之间的营销关系。2B企业发展至今，他们的发展状况如何呢？本文作者从时间和空间两个方面，对2B企业的发展进行了梳理，希望对你有帮助。

我这里说的2B是完全脱离2C属性的B，那些伪2B的不在我讨论的范围，有些虽然叫2B但是却能找到很明显的2C的影子；我这里定义的2B体量为年销售额大于1千万以上的2B，小于这个体量的大概率呈现一定2C的属性，可以用2C的理论框架概况，并基于2C的思维框架提出解决方案，当然也不是1千万已下的就没有2B的性质，只是其表现的大多数的属性可以用2C的产品思想建模出解决方案。

我讨论的2B体量主要集中在年销售额在5亿以上的IT和互联网产品。

为了让各位看官有一个直观的认知，列举了一张表来对比下，大家可以感受下。

2B产品标志性的产品可以分成如下几大类：ERP、OA、MES、WMS、PLM、SRM、CRM这个级别的产品在企业中的应用关系如下：

产品间的关系（一）

产品间的关系（二）

这些产品的主要呈现形式大概率是在设备级别上是联动的，PC端、移动端、电视端、PAD端等需要联动，其中PC端是全局的功能和全场景解决方案，其他端呈现的功能、解决方案大概率是PC端的30%~50%左右。

我们可以想想，普罗大众的上班族还是8小时上班时间，他们上班的时候都有一部台式电脑、或者笔记本在工位上办公；非PC端的场景，电视和PAD可以理解为与PC端类似，除非你的产品是CS模式的，否则就类似；移动端的场景基本是需要即时处理、单笔业务的场景处理场景，因此相对来说场景简单很多，复杂的场景都在PC端。

但是2B端产品的对各业务场景间的数据打通基本在“0”容忍上，只要是相互间需要用到数据的都必须在IT层面做到无缝的衔接，为什么2C不会碰到数据打通0容忍，而2B会碰到，因为2B的各个动作操作者不是同一个人，而是由多个人协作完成，如果数据间不打通完全就不知道对方在什么状态，我这个环节该做哪些。

大家可以粗略的感受下下面的图，每条线代表一种业务类型，如果一个50亿左右的企业，如果他们自己统计下，他们各个系统间的接口之和应该不少于200个，如果少于这个数量级，基本上就只是一些基础层面的数据交互，用户的感觉就是，我要登录多个系统去操作，或者查数据。

大家会发现在2C端这个情况就少很多，比如淘宝、和京东、美团、携程的数据都不打通，但是对于我们使用者来说好像没啥，那是因为我们的使用者都是自己同一个人，可是对于你家那位来说，是多么希望你这些数据都打通了，在一个平面看到哦，可是对于你自己来说却无所谓，你是业务、数据的第一产生者和使用者；如果你是这些业务场景的第二使用者，那就多么希望这个业务能放一起了！

如果你们家有3口人，1人管淘宝，1人管携程，1人管钱，你会发现问题来了，有2人需要知道，购买的商品是否付款了，有2人需要知道是否预定了酒店，有2人需要知道是否购买了物品；如果3人的账号在各个产品上的账号还不一致，那基本上三个人就疯掉了。

可是2B这样的场景太普通了。采购的肯定不会去做财务的事情，可是采购却是要知道供应商付款情况；生产管产品制造，可是采购需要知道还差哪些原材料，销售需要知道生产出多少产成品了等等。

而且2B产品经理苦逼的还不只这些，你会发现企业里的一个采购，干一辈子采购的工作，也许就只是管一个细分类别物料的采购业务，而这家企业里像他这种细分的采购业务却还有十几个分支；问题是人家干了一辈子的工作，你却需要给他在IT系统上提出一个解决方案你是不是SB了！

这还不够即使你搞清楚了他们公司的几十个分支，当你去其他企业时你发现你又SB了，他们相互间通用性不大如果你是一个2C产品狗那就就要骂娘！这还没结束当你换一个行业时你又要继续SB了！

而2C是完全不同的，我们自己就是滴滴用户、美团用户，我们就是自己的产品经理，可是对于2B来说，你不是自己的产品经理，你是别人的产品经理，而具体操作这个业务的人连啥叫产品经理都搞不懂！在放一次这张图给大家感受下！

上面主要阐述了，2B和2C的差异，也引出了2B产品的复杂度和2C完全不是一个维度，下面我们就进入正题了，构建时间轴+空间轴的百年2B。

我们可以纵观下全球2B公司中，有两家妖孽一样的公司SAP、Salesforce存在，这里主要谈的是做IT应用产品的，当然Orcale除了数据库部分也算。

这种2B产品的公司，除了销售，都存在2大业务部门，产品、交付，产品就是具体研发IT应用产品的，交付就是把这个研发的IT应用产品在B端指导用户用起来的，别告诉我B端的产品不需要交付、实施就能用起来，那种B端的产品，不是我这里讨论的，那种级别产品基本上年销售额1千万以下的，在我看来就是2C的产品！

这两家妖孽公司，一家1400亿美金、一家1900亿美金，我们可以比较下，这两家公司在时间轴，和空间轴的情况：

交付、实施：空间轴+时间轴

SAP比Salesforce早成立很多年，但是他们都在时间轴、和空间轴上做到类似的成功。

空间轴上主要的表现：不但自己做交付，而且还发展合作伙伴、大量的第三方参与交付实施自己的产品，如果对这行不了解，可以百度搜索下SAP或Salesforce实施，NB的是即使做他们产品的交付、实施居然还有很多上市公司。

时间轴上：他们的交付积累各种行业各个企业的解决方案，而其中SAP更是强调自己的最佳业务实践，在时间轴上，把各个时间段，各个交付人员的智慧沉淀下来，以备后续的交付团队复用，重复变现。

如果大家没有感觉的话，我问大家一个问题，如果你是2B公司，而且对交付有一定的了解，那么你听下我的问题“你们公司2年前离职那个交付专家做过的那几个成功的项目，在你们公司还有多少人知道，是如何做的，交付方法论是什么？有那些行业特点？如何在下个项目可以复用；现在2年过去了，他的成果还在为你们公司创造价值么？如果有还有多少，你们能复制他的能力么？”

如果是SAP的话，我可以告诉你他们几十年前的解决方案现在还在为SAP公司赚钱，如果说的不好听一点，也许当年创造价值的员工，现在都已经不再人世了！而你们家公司才过了2年！

问题二，和你们家合作交付的公司，他们从你们公司获得多少行业解决方案，他们又为你们家交付方案库补充了多少解决方案，以备后续使用。

截图看下SAP在时间+空间轴上的沉淀：

这样的SAP解决方案在时间轴上沉淀下来的问题解决方案不计其数；大家可以想象，如果要超越他们，如何做到弯道超车？至少在这个维度上很难，2B这个行业在交付这个维度就是曾国藩的战略“结硬寨、打呆战”，没有捷径可走，如果不信邪，在看看那张2C VS 2B的对比图。

2B公司的一大业务场景交付的时间轴+空间轴就介绍到这里，我们再来分析下产品的时间轴+空间轴，还是来比较下这两家妖孽公司。

两家公司在产品维度上，在时间轴+空间轴的表现，发现他们的区别很大了，这两家公司，Salesforce后来者居上，后来者超过前辈500亿美元，超过的部分可能有很多原因，但是我可以肯定产品上面肯定是大大的因素，其一产品以云模式VS本地模式，SAP落后产品上输了一筹，这种商业战略层面的输我这里不做过多分析，我这里主要分析他们在应用层面的不同。

SAP在市面上的形象以提供丰富、无所不包的解决方案出名，他们的产品策略在制造业确实做到了，可是做的没有Salesforce那么彻底，SAP产品的更新迭代靠自己的研发人员或收购来丰富自己的产品，这样也确实保证了输出产品的质量，可是在包罗万象的2B场景中即使NB如SAP公司也无法搞定千奇百怪的需求，SAP的强势行业在生产制造类企业，在中国一些大型互联网科技公司都不是SAP的客户，而基本上90%生产制造企业都是SAP的客户； SAP的解决方案过于局限于在这一古老的领域，而新兴发展起来的领域他们的解决方案却没有跟上。

在来反观下Salesforce他们的产品策略完全不同，一来云模式产品架构上就更胜一筹，当然这一筹不能怪SAP，当年SAP叱咤风云的时候，还没有云这个产物，此处不表；其次在产品更新迭代上又出现了不一样的思路，Salesforce依托自己的PaaS平台完全开放应用，让无穷无尽的第三方来更新迭代他的功能，也就是说Salesforce把产品更新迭代教给千千万万个公司，而SAP更新迭代都靠自己，当然Salesforce 的400万个应用，在质量上肯定有很多是垃圾，但是架不住量多啊；当然SAP出品也不一定全是精品，400万找灯塔应用，和10万找灯塔应用，这完全不是一个级别的较量。

可以肯定是这两家公司，在产品维度上都做到了时间轴的积累，Salesforce更是在空间轴上探索出一条新路，于是筹齐了产品这个维度的时间轴+空间轴的双抽叠加。

我们还是回到自己了解的2B公司问“你们家是否经常换开发平台，以前是VB、C#、JAVA、Python”“你们家研发是否经常给你整一个高大上的名词“产品重构””“2年前开发的功能或者代码，还在为你们家争挣钱？”；可以明确告诉大家SAP在1986年开发的功能现在还在给SAP挣钱，还是一样当时开发这个功能的人，估计也不在人世了吧！

在ERP这个细分领域SAP依然是全球当之无愧的王者，虽然他市值被Salesforce超越了，但是在在ERP这个领域SAP用时间轴构筑起了无比高耸的壁垒，当然这也是他的问题，因为他为了坚持持续构筑这样的壁垒，导致他们的产品技术平台是老爷爷辈的了！

对应我辈2B大神们掌握着最新的技术，我们需要的是用最新的互联网技术做到弯道超车，把握住最新互联网技术这个弯道超车的技术变量，同时还要把这两家妖孽公司优秀的基因继承下来叠加在弯道超车技术上+产品/交付（时间轴+空间轴）上构筑属于我们的百年2B！

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

题图来自 Unsplash，基于 CC0 协议