互联网进入下半场后，ToB/ToG市场成为各大互联网公司逐鹿的新战场，但对于靠C端业务起家的互联网厂商来说，转型ToB和ToG并不是件容易的事情。被现实毒打过后，才能认识到ToB/ToG和之前的ToC业务是完全不一样的战场，“简单、极致、快”、“小步快跑，快速试错”、”网络效应“等互联网思维，在B端场景下都遇到不同程度的挑战。B端和C端市场到底有啥不同？ToC转ToB/ToG需要面临哪些方面的挑战呢？
一、认识ToB/ToG业务
1）B端项目的形式
项目制（政府和大型企业）
B端和G端的项目有多种运作的方式，政府和企业为了规范采购行为，提高采购资金的使用效益，都有具体的政策、法规、制度，以保护资金被合理、合法的使用。目前实行的《中华人民共和国政府采购法》里规定了政府采购的方式有以下几种（一）公开招标；（二）邀请招标；（三）竞争性谈判；（四）单一来源采购；（五）询价；（六）监管部门认定的其他采购方式。《中华人民共和国招标投标法》则规定大型基础设施、公用事业等关系社会公共利益、公众安全的项目，全部或者部分使用国有资金投资或者国家融资的项目，都 必须采用招标的方式 来进行。除去标品或特殊情况，中大型的私营企业的项目也都采用招投标制度进行。
SaaS产品（中小B为主）
大型企业或政府的定制需求比较多，基本是项目制，但中小企业则倾向于使用标准化的产品。一方面标准化的产品能快速地满足需求，另一方面中小企业也没有专门的资金建设长期发展的项目（小B自己的生存能力就不强）。满足这种场景最合适的是SaaS化的产品，一般客单价相对也不太高，虽然一样有ToB的销售、渠道等问题，但是对技术和产品的思路与toC比变化不大，小步快跑、持续迭代的ToC的方法还是有效的。SaaS模式对B端厂商比较友好，边际成本较低。
本文要讨论的项目制的ToB/ToG业务，一个项目的成交价格可以从百万到上亿级别，通常还伴随物理设施（硬件、施工等）的实施和交付，主要以招标的方式运作的项目。
2）B端项目的特点
决策链条长
C端的客户一般是一个个体，做出购买决策相对比较容易，解决了他的问题，或者满足了他的某种感受，就能做出决策。也有一些利用人性的某些弱点，来影响客户做一些冲动决策，总体来说是以感性决策为主的。但项目制中的甲方则是一个组织，都有严格的采购制度和审批流程，不存在C端的冲动消费。
利益关系比较复杂
对于C端的客户，决策者和使用者通常是一个主体（有少数例外），但B端情况下不但有多个角色，比如 决策者、使用者、利益相关者 ，而且这些角色是分离的，各自有各自的考虑。决策者最关注的就是做这个项目的收益、成本和风险，从投资和回报（ROI）来看问题（靠项目贪腐的除外），先要达到他的目的，然后再看预算是否能cover住项目成本，项目失败的风险多高。决策者要应付各方面的挑战，有时为了规避一些责任风险，甚至不一定会选择最适合的。使用者通常没有决策权，但是他最懂业务的痛点、有建议和影响的作用。其他利益相关者，也会从各自的利益角度起着阻碍或推进的作用。
项目周期长
C端的业务，不管是广告变现模式，还是会员模式，一旦建立起了商业模式，获得新客户基本就等同于获得了新收入，可以算是即时的反馈。而B端的项目一般跨越周期比较长，从几个月到几年的都有。从早期的竞标，到完成实施交付，中间充满了不确定性，一旦某个环节出了问题，整个项目的回报就归于零。
信息不对称
之所以有项目需求，一般是甲方为了解决某个问题或新开展一项业务，但是甲方本身并不具备这方面的技术能力，需要通过招标找其他的合作伙伴来帮他们来实现。甲方虽然是需求方，但是对于如何用技术来解决他们的问题并不是很清楚，甲方并没有相应的专业知识来评判乙方东西的好坏与价值。首先，甲方通常对于软件的价值就没有一个清晰的判断，软件底层的东西，看不见，摸不着，而且长期以来被盗版软件、免费软件轰炸，观念上就有软件应该是免费或不值钱的思想。B端厂商不得不把自己的软件和硬件打包，做成软硬一体的系统来售卖，提升价值感，甚至有过在主机里面增加一个铁块来增加重量来体现价值的案例。
即使客户认可了软件的价值，但好的软件系统和差的软件系统差异客户也并不太能感知出来。大部分项目都没法事先给一个成品供客户体验，顶多弄一个POC样机或系统证明可行性，或者展示一下其他成熟落地的案例，并不能真正的体现好不好。一般情况下，好不好用并不是在验收时刻能体现出来的，验收的人也不一定是最终的实际使用者。好坏的差异更多的体现在极端、非常规、以及灵活应对变化的场景，是需要真实投入使用后才知道的，正所谓鞋好不好穿只有脚知道。
反过来，乙方则是在竞标过程中站在信息不利的地位。甲方为了保证竞争的公平性，是不能透露其他竞标厂商的信息的。甲方也不知道把信息透露到什么程度，才能既不影响乙方做方案，又不暴露过多的非必要信息。在实际的招标过程中，由于缺乏有效的监督机制，还存在通过控标项、串标、围标等手段获得中标的现象，这个时候去竞标只是充当了一个方案咨询和陪标的角色。
信息不对称会影响信任建立，从而增加交易成本（项目的招标过程本身就是交易成本），C端业务可以通过打造品牌来降低交易成本，B端虽然也可以树立声誉，但是每次项目都不完全一样，还是要招投标，交易成本并没有降低多少。
二、ToC转ToB/ToG的挑战
1）产品和技术
客户关系与产品实力哪个更重要?
在做ToB项目的时候，给项目团队画饼最常见的一种方式就是说关系比较“硬”。那么在真实的项目里，客户关系和自身的产品实力到底哪个更重要呢？我的看法是都重要，客户关系是敲门砖，有良好的客户关系能在前期项目调研、需求分析和沟通中，获取到更多更真实的信息，更有利于竞标。但是真要落地实施时，产品实力也要硬，客户关系再好，产品的交付和效果数据不过关也是徒劳。客户关系可以看成是一项先天优势，但并不就是决定了一切。
产品：方向选择
对于互联网企业，积累的技术沉淀很多，但是这些技术还是比较偏底层，并没有整合成一个具体垂直场景的解决方案产品。从ToC业务转型来做ToB/ToG的业务，并不是一上来就知道哪个场景靠谱，可是垂直场景那么多，该做哪个呢？每个行业领域都有自己的”Know How“知识，如果没有长期的行业积累，就没法做出符合客户需求的产品。如果没有已经成型的产品，光靠C端业务背书或PPT方案去打单的话，又缺乏说服力，打单会比较困难。如果先瞄着一个具体的垂直场景去投入，万一瞄错了，拿不到单子，投入就白费了。个人看法还是要有战略取舍，根据市场需求趋势和自己的优势来选定赛道，在这个赛道上先打造基础的产品，后续再根据项目和市场的需求来调整。毕竟，纯靠C端产品背书或PPT方案就能拿下单子的可能性并不高，真有这实力，那就天天忙着接单，也不用操心做哪个场景了。
技术：软件架构
互联网toC业务，对技术架构来说，最大的挑战是规模，因为所有的数据都是用一套系统来管理的，随着用户规模增加，数据量必定是越来越大，而且用户之间还会存在关联关系（最典型的如社交关系），规模每翻一倍，几乎肯定会冒出来新的问题。
B端项目制的情况下，数据规模通常并不是最重要的问题，因为大家都是私有化独立部署的，一个套系统只给这个企业使用。数据规模增长有限，各个企业间的数据也不存在关联。相对C端的数据规模而言，项目制的B端业务数据量基本就是毛毛雨。但是对于B端的技术架构却会碰到另外一个挑战： 千差万别的定制需求 。每个企业都有自己独特的场景需求，而且需求还是在动态变化的，如果整个软件系统不是构架在一个合理的架构上，应对复杂的需求将会是一个灾难。所以个人认为ToB项目在技术方面最大的挑战就是架构设计，要让架构足够灵活来适应复杂的需求和变化。软件迭代的代价也直接影响项目的边际成本， 销售能力决定了ToB企业的收入，产品和技术架构能力决定了ToB企业的利润 。架构能力体现在很多方面，这里讨论两个近几年比较热且影响比较大的方向：
APaaS平台（Application PaaS）
APaaS平台是一种特殊的PaaS，它把某个行业通用的东西进行抽象，当遇到一些有定制需求的客户时，也只用通过很少量的二次开发就能满足需求，极大的降低了开发和交付的成本。但是APaaS平台不是一蹴而就的，需要积累了足够多的行业经验后才能做好这层抽象。如果一上来就朝着APaaS来做，可能会让系统变得复杂，影响交付速度和质量。
无代码/低代码平台
很多时候，客户的一些定制操作可以通过可配置的方式来满足，从简单的一个参数值的修改，到一个复杂的业务流程结构，都可以通过可视化的方式来配置（比如通过拖拽和连线操作就可以定义流程和参数）。要应用这种模式，就需要提供一个可视化的操作界面，让不太懂开发的人就能配置自己需要的”工作技能“，这个平台的模式在技术上被称之为“无代码平台”，如果还需要写少量的代码逻辑，比如编写自己的插件模块，就是”低代码平台“。无代码/低代码平台固然是个好东西，但是从头搭建这么一个平台还是比较复杂的。目前也有一些通用的开源软件框架，比如NodeRed项目，ToB厂商可以基于这个框架来开发自己的无代码/低代码平台。
2）组织
杨三角里有个公式，企业的持续成功=战略*组织能力，不同的业务类型，对组织能力的要求是不一样的。ToC的市场，通过标准化的产品满足客户的需求，客户的增长一般是指数规模的增长，对应的边际成本递减。C端业务需要的最重要的组织能力是敏捷、技术力、产品力、创新能力。项目制的B端场景，项目运作的周期长，除了技术和产品，还有客户关系、招投标、项目实施、后期的客户成功等等方面，最重要的组织能力是协同综合、整合能力、政商关系、伙伴联盟等。B端业务的增长一般不像C端业务那样以指数增长，差不多只能是线性增长的方式。C端和B端业务特点不同，决定了组织管理模式的不同。C端业务更需要创造力，需要把权利下放到中基层；B端业务注重整体协同和流程，需要从上到下推进组织的分工与协同，设计能打破部门壁垒的组织结构与业务流程，强调整体目标的对齐，激励政策上也更加强调对全局的贡献。
对于曾经依靠ToC获得成功的互联网企业，转型ToB还需要面临额外的挑战： 能力分散在不同组织，协同起来比较困难。 对于有一定规模的传统互联网公司综合能力比较强，但是技术能力一般都分散在不同的部门，比如安全、AI、云与大数据、物联网等技术都是独立部门或事业部，B端项目则是需要一个整体的交付，必须从上到下来整体协调，有着完善、健全的流程和机制才行。但是对于大集团里的各个部门，他们各自的目标并不是一样的，不能完全力往一处使，各个部门间的来回拉扯形成内耗。即使项目成了，也还存在各个部门间利益分配的问题。业务的转型一般会伴随组织的调整，比如腾讯2018年的930战略升级。如果组织没有随之升级，以原有ToC的组织架构去应对B端的业务，肯定是会出问题的。
3）人才
传统toC的互联网企业，汇聚了一批顶尖的技术人才。因为传统toC的业务一般规模上得快，轻资产运营，赚钱相对“容易”。优秀的人才的发挥空间也比较大，做一些技术上的改进，立马就能带来非常大的收益，所以互联网企业对优秀人才都很大方，久而久之聚集起来的人才密度相对较高。但一旦转到toB的业务后，决定项目成败的，往往不是技术，而是项目的运作（包括前期的招投标、商务、销售、客户关系、项目实施和项目管理等等），这种情况下，ToC的技术人员在ToB/ToG项目中的重要性就下降了。那么顶尖的技术人才没有施展的空间，就会选择离开。整体组织上就会慢慢从人才密度较高的互联网ToC企业，变成人才密度相对较低传统的ToB/ToG企业。
4）文化
在企业文化方面，互联网ToC行业特别推崇创新，对员工一般也不加什么约束，穿个圆领T恤、大裤衩、人字拖上班都可以。等级制度上也不那么严苛，大家直呼其名或用花名之类的，减少直接X总、Y总的叫法，目的都是形成相对自由和创新的文化。而传统toB企业更多像科层制，为了保障打单和成功交付，更多的是怎么把控流程、控制风险，并不鼓励创新。
甲方转乙方的身份落差
传统做C端互联网业务，与客户的接触界面通常是标准化的产品，C端产品并不是满足用户的所有要求，只要考虑到绝大部分用户的需求就够了，不被满足这部分客户，流失就流失了， 总体来说，还算是站着在赚钱 。项目制的B端客户，金主是甲方爸爸，需要想尽各种办法来满足客户的需求。甲方还经常拿竞争对手的价格和响应速度来压你，做乙方只能面对客户的各种需求和“刁难”，差不多算忍气吞声地 “跪着”赚钱 ，不光赚的是辛苦钱，还得接受身份上的转变。
三、结语
本文讨论了一个ToC互联网企业做ToB/ToG的战略转型过程中会碰到的一些问题和挑战。国外的发达市场，ToC和ToB的头部上市企业基本各占一半，但是中国，头部的上市公司ToB和ToC还有很大的差距。甲方头脑里的观念是一个慢变量，这就决定了中国的ToB市场发展会是一个相对较慢的过程。云计算到现在发展了十几年才慢慢地被接受，ToB市场也会需要时间来培育、成熟、完善。期望在未来的5-10年能成长起来一批有影响力的ToB公司，我们拭目以待。
本文非原创，转载之前老同事公众号，可以直接点击查看原文链接，关注公众号；