全文核心内容:

1. To B 企业范式转换是数字化转型时代的必然趋势

2. 客户需求变化是范式切换的根本原因

3. 市场决定经营范式

4. IBM、Adobe、神策、51 社保的案例解析

转型与创新:To B 企业为什么需要范式转换？

1. 数字化转型的时代背景

互联网技术革命进入下半场，从 PC 互联网、移动互联网的爆发阶段和狂热阶段，过渡、深入到各个行业的数字化转型阶段。

图源：《技术革命与金融资本》

2. 科学革命的过程，就是范式转换的过程

范式的核心包含两部分，一部分是理论，一种范式可能包含若干条理论；另一部分是范式案例，这就像课后练习，我们经过系统理论学习后掌握了一种范式，但真要讲清楚范式的边界在哪里，其实并不容易，这就是库恩讲的范式概念。实际上，科学革命的过程就是范式切换的过程，范式的转变就是世界观的转变。

科学革命的结构如下，常规科学在一个基本概念的框架或者范式中解决问题，有些解决不了的反常现象会积累起来，挑战现有的概念，从而引发危机，最终由于新范式的诞生让危机得以平息。也就是说，范式切换包括反常、危机、革命三阶段。

3. 产品型范式 VS 客户经营型范式

To B 企业包括产品型范式和客户经营型范式，但这两种范式在理念和方法上完全不一样：

从提供服务看，产品型范式就是单纯卖产品，但客户经营型卖的是解决方案和人力外包服务；从价值目标看，产品型范式更偏向 To B 产品，偏向赋能，比如使用数据库后拥有更大的能力，至于能力如何使用，还是要因人而异；但客户经营型范式不偏重于赋能，而是在真正场景中运用，跑通业务流程。

从杠杆性看，产品型范式的杠杆比较高，毛利率一般在 70% 以上，但客户经营型范式，也就是重服务，毛利率一般在 40-60%，无杠杆的人力外包毛利率只能做到 30%-40%；从售卖方式看，产品型范式包括 license、维保和订阅制，客户经营型范式包括项目制和订阅制。

产品型范式与客户经营型范式的对比

至于哪种范式更好，没有固定答案，对于 To B 企业的范式切换，很多时候切换并不意味着 A 比 B 好，而是 A 比 B 更适合这种场景，产品型范式与客户经营型范式互相切换，都是有可能的。

4. To B 企业范式转换的原因与示例

Salesforce、SAP、埃森哲都是 To B 领域范式切换的经典案例。比如 Salesforce，它的经营方式一方面有 SaaS 化产品，另外还有生态伙伴帮忙做实施；SAP 既有卓越的产品，又有经营卓越大客户的能力，也有生态伙伴实施。对 SAP 来说，它的很多重要客户都是自己经营，而不是像 Salesforce 一样，和生态伙伴一起经营。（延伸阅读：从一个想法到千亿美元帝国：Salesforce 对中国 SaaS 企业的启示）

Salesforce、SAP、埃森哲三种范式

埃森哲是做咨询服务的，拥有最佳实践知识库、行业 Know-how、成功案例。埃森哲坚持中立性原则，只用第三方产品，所以可以和像 SAP、Oracle 等企业保持非常好的合作关系。

(1) 客户需求变化是范式切换的根本原因

对于 To B 企业，我认为范式切换发生的根本原因是客户需求发生了根本性变化，导致客户需求发生根本性变化的原因我们可以用 PEST 模式分析（P：Political ，政策性变化；E：Economic，经济环境变化；S：Social，社会环境变化；T：Technological，技术革命变化），这些变化的出现带来客户需求变化，从而导致范式切换的发生。

PEST 模式

其次，我们也要不断问自己，你的客户是谁，客户群体有哪些，哪些规模的客户是你的目标客户，客户需求是什么，客户追求个性化需求还是定制化需求，比如客户想要产品化的奶瓶服务还是个性化的保姆服务。

从 《跨越鸿沟》书中的理论看，由于市场成熟度不同，客户想要的东西也不一样，就像神策服务的客户群体，他们想要的东西随时会发生改变。正是由于客户需求发生了根本性改变，导致之前的范式不灵，需要换一种方式，这个时候就需要进行范式切换。

(2) IBM：业务转型带来的范式切换

业务转型也会带来范式切换。这部分有一个很典型案例就是 IBM。IBM 在 1993 年经历过一次范式切换，1993 年，在 PC 时代，企业内出现软件整合需求，以前软件大多是打包卖，相当于附属品，后来客户解决应用场景需要软件，但软件需要打通硬件结合做，解决实际业务问题。

这种环境下，IBM 亏损严重，营收连年下滑，郭士纳临危受命带领 IBM 从软件公司转化为咨询服务企业，IBM 并购了莲花公司做解决方案和集成商，从卖硬件产品转变到卖软件和解决方案。以前 IBM 只卖自己的软硬件产品，现在不仅卖自己的产品，同时卖其他家的产品，从以产品为核心到以客户为核心，这就是 IBM 当时做的切换。

从 1993 年开始，到 2000 年左右，IBM 股价涨了 10 倍，所以说 IBM 的转型还是非常成功的。

IBM 股价走势图

(3) Adobe：产品化+客户管理+生态伙伴实施三管齐下

Adobe 在 2008 年也出现了范式切换，当时正值金融危机，许多客户为了节约开支不升级新版本，导致 Adobe 的营收下滑了 18%，相当于少了五分之一收入；从技术上来说，移动和云的大趋势下，让提供新功能价值有了可行性，Adobe 开始从理念上转向 SaaS 化，一是提供云端服务，二是订阅制。2009 年，Adobe 收购了 Omniture，主要是看中其在订阅方面的实际操作。

在业务上，2018 年 Adobe 并购了全球最大的营销自动化 SaaS Marketo 和全球最大的电商 SaaS 系统之一的 Magento，加上整合现有产品， 提供全营销解决方案。

后来 Adobe 的服务越做越强，产品迭代方式也在发生改变，以前是 18 个月-24 个月发布新版本，到市场售卖，迭代以后变为按月更新，这样可以持续不断地提供最新功能和价值。

Adobe 范式切换分析

Adobe 在营销、文化等方面都发生了很多变化。在营销方面，从之前关注合同额到现在关注订阅客户数；在文化方面，Adobe 追求持续不断创新，不管是整合其他公司的创新想法，还是自己的创新想法，总之 Adobe 的创新文化非常强。

在客户经营上，Adobe 坚持自己的产品，大家可以看到 Adobe 的财报，毛利率高达 84%，实际上， Adobe 产品化率也是非常高的；在客户管理上，虽然很多客户会交给生态伙伴去做，但 Adobe 一定要保证和客户之间的联系，所以产品化的方式加上客户管理再和生态伙伴的实施，三管齐下，我觉得 Adobe 还是非常成功的。

Adobe 从 2012 年左右开始转型，高的时候市值达 3000 亿美元，Salesforce 的市值虽然也有 2400 亿美元，比 Adobe 还差了 20% 左右，不难看出，Adobe 的发展势头还是很猛的。

产品加大客户经营:神策的范式转换

再来讲下神策的案例，神策的发展经历了如下几个阶段。

1. 确定产品的优先级

2015 年到 2017 年，我们做的是 SaaS 范式，虽然提供私有化部署方式，实际还是订阅制收费，当时的产品理念是单品极致，把产品做到 90 分，争取做到行业头部。

2017 年到 2018 年，从互联网客户扩展到 “互联网+”客户，我们当时做的 “互联网+” 其实是一些传统企业开了互联网新业务，归根结底，还是可以理解为互联网公司，所以并没有牵扯到范式切换。

到了 2018 年、2019 年，神策开始扩充品类，从一个产品变成多个产品，和 Salesforce、Adobe、Oracle、SAP 一样做产品矩阵，我当时提了一个口号，神策要做中国的 “数据便利店”，但这不意味着我们要掌握数据，而是提供各种各样的数据能力。

三个季度下来，拆东墙补西墙，现在回头看，这个策略是不对的。因为资源不够，所以走到后来还是觉得要聚焦，不能到处发挥。在资源有限的情况下，单靠产品是没有办法解决所有问题的，必须将产品按照优先级分类。

神策数据范式切换分析

不管是扩张到互联网+企业，还是做产品矩阵，我们始终都是产品型打法，在这个过程中，虽然存在焦虑，但更多的是忙不过来，不至于对信仰（认知）产生冲击，但 2020 年疫情的发生对我的信仰产生了冲击，同时让我清楚认识到 APP 战争已经结束了，市场也确实在发生变化。

2. 基于市场需求打造爆品

在产品型范式阶段，神策有遇到过一个危机，我们曾经非常希望借助互联网力量打造爆品，虽然我们是 To B 公司，但一直想要打造下游爆品。

后来，我们也尝试做了些产品，但是不够规模化。比如我们在 2019 年做神策智能运营产品，2019 年 8 月完成了 PMF，认为自己已经达到了规模化，从 10 月份到 12 月份卖了几十个客户，一度认为 2020 年就可以达到第二次传奇，结果到了 2020 年，做完分析后发现没有想象中那么容易，我们发现智能运营产品的打造主要针对 APP 场景，但目标客户并没有想象中那么多，因此给我们带来非常多压力。

另一方面，随着服务的客户越来越深入，有时候客户对交付不满意，导致大家不知道如何去做服务，尤其是做一些大客户的时候，我们的内部出现了很多不一样的声音。

作为 CEO ，很多时候我对自己的认知是很自信的，但发现招数不灵的时候，内心是很痛苦（危机感）的，痛苦其实是范式转换的一个阶段。遇到危机时，如果有替代品，危机感就不会很强烈，如果没有替代品，危机感就会很强烈。

3. 明确产品、大客户经营双驱动范式

当时我们也有在内部讨论做项目制，也就是大客户经营，通过这个方式重新走到重视产品阶段，我的感受就是不得不这么做，从当时的情况看，我内心对这件事的接受度还是不够的，但现实迫使我不得不这样去做，直到去年下半年快到年底，我逐步才从心底里面接受这件事，这其实要回归到一家公司的信念到底是什么？神策的信念有三点：

第一，追求卓越。我们宁可死在卓越的路上，也不愿平凡的活着，如果用平凡的方式和视角做项目制服务，那我宁可不做。

第二，用科学的方法提升效率。我们用科学的方法做产品与服务，同时我们的交付方式、做事方式也是科学方法。

第三，给客户带来价值。如果我们做的东西对客户没有价值，那这事就不要做了，所以这也是我们的底层信念，这些信念会催生我们去思考。

我们接受不了用平凡的方式做大客户经营，还有没有更卓越的方式做大客户经营，这个时候我又重新看到了 SAP。SAP 既有卓越的产品又有卓越的大客户经营。对神策而言，我们曾犹豫做产品还是项目，最终决定了做产品加大客户驱动的双驱动范式。实际上，真正把思路转换过来后，内心反而淡定了很多。

4. 范式切换带来的三大变化

神策从 SaaS 范式切换到以产品，大客户经营双驱动范式，切换过程中牵扯到很多变化，有些变化和范式切换有关，但有些是自身迭代发展带来的变化，但确实因为加速切换带来了很多痛苦。

(1) 理念与业务的变化

理念上，卖的到底是产品还是解决方案，提供的是单点还是闭环，轻服务还是重客户理念，这些都发生了很大变化。比如神策也在做经营战略调整，开始重视考察毛利，一些理念发生了变化。

业务上，我们从数据分析到营销科技，从以互联网为中心到以数字化为核心；价值主张上，从提供大数据分析能力，拓展到营销科技，围绕数据加营销提供闭环，整个业务也在不断发生变化。

(2) 组织与文化的变化

组织机制上，机制越来越精细化。我们现在就是在经营单元，每一个经营单元都要考核毛利，不能亏损，对考核力度精细化程度要求比较高。

文化上，也就是我们前面讲到的信念，其实真正转型变革时，如果连企业信念也发生改变，那变革也没有太大意义，但实际上每一个创业者需要有信念感，这个信念指的不是利润，而是认知改变。

所以，我们既要不断迭代又要学习榜样，我一度对迭代非常有信念，我认为没有迭代解决不了的问题，如果解决不了就再迭代一次，至于学习榜样，像 SAP、华为、埃森哲都是值得我们学习的榜样，学习榜样不是说看几页 PPT，了解一点就够了，还是要对这些伟大公司要有敬畏之心。

另外，我们之前强调的产品化后来也发现认知远远不够，我们追求的核心是高杠杆，牵扯到文化上的东西，像 PMF (Product Market Fit，产品市场匹配模型），还有 GTM (GO-TO Market Strategy，进入市场战略）在确定产品成功之前，我们就是锤子逻辑，拿一个产品到处碰。

(3)  产品与市场的变化

神策在创业路上还是比较顺利的，不管从融资还是自身业务的发展都比较深，但要说这里面完全凭实力肯定不对，或多或少都有运气的成分在。比如我们早期分析产品 PMF 的过程都非常顺利，这也跟我们之前在百度的积累有关，所以才能顺利的迈过那个阶段，但即使把问题解决了，也不能意味着对问题有个很好的思考。神策本身对如何做 To B 的 PMF 还是比较有方法的，即便这样，过去两年我们对 PMF 的认识也发生了非常大的变化。

我前两天还看到一篇由国外 intercom 公司 CPO 写的一篇文章，讲的是我们应该花更多时间在发现市场需求和定义需求上，而不是花太多时间在打造解决方案上，过去半年我们比较看好的是华为的五看三定，还有 BOM 业务领先模型，其实就是说要看宏观市场，关注行业客户、竞争、自己，做详细分析。

并且，我们真的要清楚自己的客户是谁，他们的需求是什么，在这个基础上做 PMF，就是针对标杆客户把它打造成 PMF 的过程。以前我们面向的客户是几百万个 APP，如何盘点，触达，靠扫荡模式肯定不行，这个时候我们会把行业细分，比如证券行业的目标客户一共就 100 多个，每一个都是精准的，谁在做竞争内容，客户的需求是怎样的，通过不断深入了解，清晰度就非常高了。

5. 市场决定经营范式

从一种范式切换到另一种范式，中间牵扯到多方面改变，我觉得很大程度上还是认知方式、做事方式的改变，但这些改变很多时候大家不一定能够适应，真正的切换一定是需要过程的，但在这个过程中我们需要尊重事实，用开放心态不断升级认知，知行合一，这也是范式的基本原则。

 简单总结说，什么样的市场决定了什么样的经营范式，也就是要明确目标客户到底需要什么；另外就是不要闭门造车，不仅要自己领悟还要学习榜样，毕竟迭代还要追求效率，追求效率的基础上加速迭代，这才是我们应该要做的事。

SaaS 软件 VS 服务产品:To B 业务的两种不同范式

以下为 51 社保副总裁方兴的分享：

我对产品的理解是满足客户需求的一切解决方案。这里的解决方案涵义很广，不管是服务、软件、硬件，金融等，只要能满足客户需求，都可以称之为产品。一个好业务本质就是解决客户需求并将产品规模化复制，最后在市场上获得绝对优势。

对于 To B 业务，我有一个坐标轴，纵坐标是客户需求，从标准化到定制化；横坐标是对应客户需求的解决方案，也就是产品，从人工化（用人来解决问题）到软件化（用机器人来解决问题）。

To B 业务整体划分

把坐标轴划分一下，我们会发现第一象限是高度标准化和软件化的产品，比如石墨、神策、销售易、北森其实都在这个象限，我们把它称之为 SaaS 软件，SaaS 软件是杠杆很高的业务模式，所以受到了投资人的热捧；第二象限，用人工化方式来满足标准化需求，这是人力外包，这个业务模式没有太多杠杆，主要追求的是效率和规模效应。

第三象限和第四象限分别是针对定制化需求的人工解决方案和软件解决方案，我们分别称它们为专家咨询和项目软件，这里面对客户定制化需求有足够高的 Know-how，所以一般客单价比较高。

那么横坐标上下之间的区别是什么呢？

上面的产品客户可以自己做，不管卖 SaaS 软件还是卖人力外包，客户都可以自己做，他之所以付费给你，是因为你的效率比他高，你已经打磨出来一套相对更成熟的产品，或者说，他只需要付出相对小的成本，就可以实现自己的需求以及得到更好的增值服务。

但是下面这部分的客户会更依赖我们，比如人力资源行业里做咨询的美世，在自己的领域有了很深的 Know-how，而这种 Know-how 在企业内部一般很难长出来，所以企业就愿意给足够高的预算，请这样的公司用他们的 Know-how 来解决自己的定制化需求。

当然，SaaS 软件和人力外包做到一定程度后也具备了自己的 Know-how，甚至也发展出了专家咨询和定制软件这样的业务模块。Know-how 很浅的 SaaS 软件和人力外包容易在竞争中被更高维度的产品降维打击，比如协作文档和任务协作就很容易就被企业 IM 降维打击。

以上是我对 To B 业务的整体划分。

1. 以软件为主，服务为辅的 SaaS 软件

对 SaaS 软件来讲，其实是以软件为主，服务为辅。从早期的标准化 SaaS 产品到产品矩阵，到今天项目软件的定制化，慢慢地从软件走向软件+服务的融合模式。在这个领域，一般来讲，欧美市场大概九成收益都是从 SaaS 软件获取的，剩下的不管人力外包、咨询以及项目软件所占的份额相对较少，但目前在中国来讲，项目软件所占的份额较大。

 软件为主，服务为辅的 SaaS 软件

因为我之前是做协作软件的，我觉得软件基本上是效率最高的一种解决方案，但当我进入人力资源服务领域后，发现逻辑完全不同。

2. 以服务为主，软件为辅的人力资源服务产品

人力资源服务领域的业务其实是以服务为主，软件为辅。拿中国的人力资源市场来讲，比如中智、FESCO 这样的人力外包大概占了 70% 左右的市场，还有大家熟知的北森、易路、Moka，这类人力资源 SaaS 占得市场蛋糕其实并不多。而在欧美，人力资源 SaaS 其实占的份额很高。

服务为主，软件为辅的人力资源服务产品

做 To B，大家会发现你进入的领域直接决定了你的未来。创业者做公司，不管是被大公司并购，或者自己独立 IPO，都希望有个很好的估值，但不同领域的公司切入不同的细分行业估值模型肯定是不一样的。比如人力外包，它的估值主要来源于规模而不是 PS，但 SaaS 领域的估值则来自 PS 或 PE，我觉得大家可以用坐标轴把自己从事的领域画一下看看，你在哪个位置，核心优势是什么，未来的天花板在哪里。

客群、产品、业务、组织:51 社保范式转换的 4 个变化

我会分四部分给大家分享 51 社保的实战经验，第一是客户群体的变化，从小客户走向大客户；第二是产品形态的变化，从卖一个产品到卖多个产品；第三是业务形态的变化，从卖服务到卖服务 SaaS；最后是组织形态的变化，从单一组织到融合组织。

 我自己本身是非常注重组织的管理者，所以不管前面三个点如何变化，本质都是组织变化后的结果。

1. 客户群体的变化：从小客户到大客户

做 To B 大家会比较清楚两个指标，CAC 和 LTV，我会把客户分成两种类型，小微客户，我一般会说他是 CAC 客户，因为小微客户的付费能力相对有限，我们也做过分析，小微客户的生命周期一般在一年左右，它的 LTV 只有那么多，LTV 被限定后，小微客户的限制点会在 CAC 上，也就是说怎么做能把它的客户获取成本降到最低。

国外大数据公司 Palantir、云计算公司 Snowflake 做的都是大客户，他们一些比较大的客户最早一年只能给到几十万美金，最后能成长到一年给一千万美金以上，所以我觉得大客户要注意的是 LTV ，前期可以投入很多，但我们要花非常多的精力去让这类客户长期成长。

从小客户到大客户，我自己的定义是从 CAC 客户到 LTV 客户，而这其中客户范式的变化，意味着整体底层组织也需要有非常大的升级。

2019 年，我们推动了销售组织的升级，升级后，从原本单一的销售团队升级为覆盖小微客户的网签、覆盖中型客户的顾问、覆盖行业大客户的 KA、覆盖同行和代理商的渠道。

2020 年，我们把整个客服团队做了升级，首先是客户分级，把客户分成了“头”，“腰”，“尾”，针对不同层级的客户，配置不同的客户成功团队。

在这个过程中，我们会发现整个市场的获客模型发生了变化，包括我们的品牌，最早做小客户的话，做很多流量获取的事情，往大客户走的时候，我们做了很多线下活动和品牌宣传，甚至还投放了专门的分众品牌广告。当然，在疫情的这几年里，线下活动也很大部分的转移到了线上。

疫情时，我们只做小微的网签团队，一年大概签了七八千单客户，这在缓解我们业务焦虑的同时，更是让覆盖中型客户的顾问和行业大客户的 KA 可以释放精力聚焦的去拓展大客户。经过两三年的实战，KA 包括各地大客户顾问给我们贡献了很多行业灯塔客户，所以升级还是比较成功。

但在实施过程中是存在着很多挑战的，比如从小客户到大客户，销售模型也发生了变化，升级过程中如何做到不影响原有的体系，我们当时是把网签团队和原有体系的销售团队物理隔离开，网签团队放在重庆从 0 开始搭建。

在小微转大客户更重要的一点是在范式升级过程中，管理者能不能跟上。因为以前的管理者是做小微客户，升级到管理 KA 或者全国顾问其实是有难度的，因为不同规模和体量的客户本身的需求复杂度不同，决策链条不同，能让客户决定付费的因素也是多元的，不再是单纯的需求匹配就能够签单，所以在这个过程中，管理者需要不断破圈，成长并赋能团队。

2. 产品形态的变化：单服务产品到多服务产品

产品形态上，从单品到产品矩阵的转变。2018 年开始，我们从社保、薪酬到残保金，最后又到业务外包和商业保险，产品越来越多，和 SaaS 软件不同的是，我们底层的产品团队内部叫软服一体产品团队，我们的产品其实是由底层服务交付和产品研发团队混合在一起的。

比如做一个软件产品，其实只需要在原有的产研团队再划分出一个团队，或者直接组建一个新的产研团队，但我们不一样，因为我们是软服一体团队，产品是由整个底层的服务交付团队和产研团队结合在一起的（以前做人力资源服务时，用邮件交流，但现在我们有一整套 SaaS 系统，客户可以在系统中提服务单，包括我们和官方或者税务沟通，也从线下转到了线上，我们还用了 RPA 机器人，所以其实这不是单纯提供服务产品，还包括产研）

在这个过程中，我们的挑战也挺多的，比如我们的社保业务，这其实相对来说是要把一个非常官方的业务结合我们提供的服务落地成一个 SaaS 系统形态的产品，Know-how 是不是需要服务交付的同学给产研的同学做培训，不同业务之间要如何进行协调、打通，都挺困难。

比如我们签了一个客户，员工的劳动关系、发薪、社保、商保要怎么处理，这是个长流程，在这个流程中，不同的业务之间如何协同，我们需要一套体系把信息流、服务流、资金流等串在一起，为了解决这个问题，我们首创了业内的服务产品经理团队，这其实也是一种范式变化。

从去年开始，我们把服务交付团队从整体的单技能变成了多技能，建立重庆 SSC+全国分中心的大服务体系，你可以简单理解为，麦当劳原本只需要炸薯条的员工现在也会做汉堡，可以解决不同时期业务波峰波谷带来的资源协调问题。同时，产研团队也升级为底层 PaaS 平台+多业务 SaaS 的大产品体系，这个也是我们正在实践中的范式，目前来看，进展比较顺利。

3. 业务形态的变化：业务从服务流进入管理流

这部分是我们今年开始做的，还没有完全做成，业务形态这部分我们做的大家可以理解为用工管理。用工管理有很多模块，我们在做的过程中慢慢切入了客户的管理流程，以前客户只需要把很多事务性工作丢给我们就行了，但随着做的业务越来越深入，产品越来越多，我们发现客户在用工管理上其实更需要我们。

针对业务形态的复杂程度提高，去年上半年，我们做了品牌升级：集团品牌+三个服务品牌+一个 SaaS 品牌。目前，我们有三个服务品牌，51 社保专门做全职员工的专业雇主服务，海握科技专门做灵活用工，还有一个新的事业部叫时在保险，主要针对 To B 企业做员工商业保险，我们还做了一个软件品牌 101 HR，其实也是为了未来能够更好的进入管理流程，整体来讲，这也是我们今年做的一些范式变化。

4. 组织形态的变化：单一组织到融合组织

第一，人才模型。对创业公司来讲，挑战传统公司靠的是创新，在创新过程中，需要有开放性，高能力人才进来。到一定阶段后，就会发现当下的人才梯队已经不能满足我们的进化升级了，可能还需要招一些人把他的资源分享给我们。比如 KA ，我认为 KA 很难从组织内部长出来，虽然可以培养不过周期会长一点，所以最好还是从外面挖，对于创业型企业来讲，时间=生命，因为 KA 核心就是他的资源。随着范式的不断升级，对人才的需求也不一样，最开始可能是高能力人才，慢慢变成经验型人才，再变成一种资源型人才。

第二，组织挑战，最核心的一点是高层不能成为瓶颈。对创业公司早期来讲，有一批比较厉害的高层，加上基层的执行力又很强，所以做起来了；但如果想要做成世界级公司，会面临一个很大的问题是，企业腰部力量可能支撑不起来，因为以前的腰部可能大量做的是执行，创新力和决断力可能会有所欠缺，所以这个时候身为高层的你，要持续地给腰部同学予以养分使其成长并给到机会，让他可以独当一面，同时自己也要不断破圈去持续成长。

第三，文化的融合。不管是科层制管理还是扁平化管理，如果想要做一些比较创新的事，让大家的潜能都能够释放出来，如何将两类组织融合在一起，一起为整个战略做事情，整体的价值观很和文化融合还是比较重要的。

最后，给大家讲一下感受。在范式不断升级的过程中，第一，确实很痛苦，因为你要不断突破自己，学习新的东西，以前的同事跟不上现在的节奏，新进来的同事如何融合，这些都是痛苦的过程；第二，做调整的过程中，不管是中层高层都会有点痛苦，因为我们需要不同的人，不同的视角，最好的办法就是把他放到新的岗位上。

比如去年我们把负责整体后端的服务交付高管放到了销售高管的岗位上，这就让他很痛苦，因为他之前没有过销售相关工作经验，但一年下来，他会有一些很明显的成长和变化，我觉得这些都是非常好的经验，一开始肯定会混乱，但不要因为混乱就不去做，最后肯定是可以在混乱中不断进步。

互动问答

1. 什么是范式？和模式有什么不同？

桑文锋：范式只是借用了《科学革命的结构》一书的用法，并不算精准的定义，和模式的意思是重合的。

2. 不同的企业软件服务公司，如何把握范式切换的时机和方式？

桑文锋：我觉得首先是之前的范式切换遇到了很大挑战，或者说现在的范式不适用于已有的场景，这个时候可以做范式切换，但尽量能不转就不转，不得不转的时候，我觉得就是要干脆。

方兴：范式切换来源于增长受阻，比如有些企业服务领域是有网络效应和双边效应的（比如电子签、协作平台和招聘平台），短期之内，不太需要做范式切换，因为它本身的增长就足够强劲。

但大部分走规模效应的公司就需要去把握范式转换的时机了，具体什么时候要做范式切换，第一，增长放缓；第二，出现趋势变化。要和最优秀的投资人或者是不同行业的优秀的 CEO 一起去交流，其实能看到很多趋势会在产生变化，这时候你可能会有一些提前的应对策略。

3. 企业突破瓶颈，完成范式切换，有没有可借鉴的方法？

桑文锋：我觉得就是开放共创，外部向优秀的公司比如 SAP、Salesforce 系统学习，内部引入合适的人。

方兴：我认为保持组织活力也很重要，做到后面的话还是要考虑如何给到年轻人一些机会，借助年轻人视角看待问题，让组织有更多的活力，让他们自己来做决策，做一些尝试的话会更好。

4. 对于初创型 SaaS 企业，选择产品驱动还是客户经营驱动？

桑文锋：客观上，产品更容易规模化，如果两者一定要做选择，我的建议肯定是选择产品型，毕竟产品型它的规模化肯定更强，还是要注重效率杠杆，但这个最终还是取决于你面对的市场。

方兴：我认为大家做 To B 时，并不是上来就是说我做产品还是大客户，而是要看到客户的需求空白是什么，我觉得空白对创业公司意味着机会，找到空白以后，问题就迎刃而解了，因为空白决定了你到底是做产品还是做其他。而且我个人觉得创业公司一上来就做大客户可能会死得比较惨，你的产品和服务都没有齐全，很难把大客户服务好。

5. 如何完成中小客户到大客户的转变？

桑文锋：其实就是怎么说服客户，说服自己，怎么去跟你给客户带来的价值观做平衡。

方兴：第一，相对来讲，大客户会提出很多比较高的需求，对服务的期待值也比较高，所以我觉得从中小客户到大客户肯定不是一蹴而就的；第二，要敢于换人，对于创业者来说，其实就是要打破路径依赖，可以用创新的思路去做这个事，而且做大客户的话，一定要去在外面引进人，而且是毫不犹豫坚决地去引进人，即使失败，也要毫不犹豫的去引入新人，在这过程中，和内部融合起来，整体来看，才有可能把大客户做起来。

6. To B 企业追求爆款，是想打破 To B 的线性增长瓶颈吗？

桑文锋：是的，是希望用 To C 的方式做 To B。

方兴：本质是希望走 PLG 的路线，但是一般适用于决策者和使用者是同一个人以及产品使用场景可以 C 端化（比如全员都需要使用文档），大量的 B 端产品还是要扎扎实实的一个一个客户去做。

7. 软件企业要 SaaS 化，通常会遇到哪些困难和挑战，如何完成范式转换？

桑文锋：可参考前面讲到的 Adobe 转型的内容。

方兴：最大的挑战是组织，可以学习链家，做贝壳的时候独立团队和独立物理空间。范式转换包括产研的敏捷迭代、销售客群以及收费模式的转变以及由此带来的销售管理体系的变化。

8. 比较适合国内市场的 To B 企业的增长范式有哪些？

方兴：扩产品版本：freemiun (免费增值模式)、professional (专业版)、enterprise (企业版)等；扩产品线: sales、marketing、service 等；扩客户群体：小微企业、中小企业、大型集团等；扩行业：零售、金融、互联网、制造等；扩区域：北美、欧洲、亚太等；扩生态：代理商、行业合作伙伴、应用商店等；以及 “买买买” 式的并购。

作者简介

桑文锋，神策数据创始人、CEO，浙江大学计算机系硕士，湖畔五期学员。曾在百度任职 8 年，从无到有构建了百度用户日志大数据平台，任大数据部技术经理。2015 年 4 月从百度离职，创建神策数据，提供大数据分析和营销科技相关产品与服务，致力帮助中国企业实现数字化经营。著有《数据驱动：从方法到实践》《企业服务从零到一》。

方兴，众合云科（51 社保）副总裁，To B 客户运营专家，曾担任金山办公运营总监。拥有多年协作管理和人力资源管理 SaaS 从业经验，擅长 SaaS 产品设计与客户运营。