- 长臂猿-企业应用及系统软件平台
旧文重温 | 《总算有人把 PaaS 讲明白了》 2022 年，崔牛会在《洗牌无声：HR SaaS 窗口关闭前的微妙时刻》一文中，谈到国内 HR SaaS 的一体化。与此同时，一体化背后的 PaaS 平台也再度闯入大家的视野。在客户需求依然很难标准化的现状下，对于一体化的壁垒和鸿沟，PaaS 成为大家的普遍共识。事实上，国内关于“SaaS 产品 PaaS 化”的争论，从未停止过。
李令辉：2017 年，iPhoneX 发布之后，苹果首席设计师 Jony Ive 接受《纽约客》主编采访时说了一段话，我很认同。里面谈到了 iPhone 为什么会诞生这个重要的问题。Ive 说是因为苹果受不了当时使用的那些手机，认为它们都枯燥无味并且粗制滥造。
想想在诺基亚、摩托罗拉、阿尔卡特、西门子等繁盛一时的功能机时代，相当长的一段时间内，诺基亚每年的研发费用都数倍于苹果。为什么苹果这个毫无手机行业经验的外来人，把手机行业带入了一个新的篇章？因为只有苹果看到了未来，没有被现有成果所限制，直接去追求代表未来的更先进产品。
今天，大家看到 Salesforce 市值 700 亿美金，SAP 1400 亿，Oracle 2000 亿，数字之下，不明觉厉，也带动了中国 SaaS 的创业热潮。这里隐藏着一个巨大而又被忽略的风险是，这些公司会不会是上一个时代的诺基亚？这个行业里会不会诞生苹果一样的公司？
有些国内公司对 SOS (Salesforce、Oracle、SAP) 是在复制追赶；而事实上，这个市场需要的是“受不了它们的枯燥无味并且粗制滥造”的公司。当然，在产品技术上要做出比 SOS 强一个时代的 PaaS 及 SaaS 体验，成本上达到一个数量级的降低，在中国乃至全球市场取代 SOS ，这很难。但事实上，之前大家觉得去 IOE (IBM、Oracle、EMC) 也很难，阿里还是做到了，之前大家觉得去思科、爱立信很难，华为还是做到了。我们相信在这个新时代，在应用软件领域，也一定会有中国公司脱颖而出，引领世界。
SOS 具体有哪些不够先进的地方？
李令辉：SAP 的生产型 ERP 和 Oracle 的数据库不在我说的范围内，我指的是 SaaS 及应用软件部分。
你能看到 Oracle 的 SaaS 大部分是收购而来的，产品的迭代速度极慢，另外各收购产品之间不是原生就打通的，要分别集成，数据整合，产品一致性和灵活性都有一定问题，云产品的服务器不在国内，访问速度比较慢。
SAP 的云化刚开始，但 SAP 的思路并不是很现代，东西越做越贵，HANA 是一个完全基于强大硬件的内存解决方案。在大流量下，单位成本的高昂几乎是不可接受的，中国互联网企业都在去 IOE，SAP 比 IOE 合起来还贵，效率明显低下。互联网的技术方向是用廉价的硬件+全新的分布式技术来解决这类问题，数据量越大，技术成本就摊得越薄，效率就越高。
其实这三家里面，产品体验最好的当属 Salesforce，但是由于所处时代的限制，在今天看来，它有很多地方也无法忍受。比如依赖于昂贵的 Oracle 数据库，因为数据库底层的限制，OLAP 方面的能力不是很强，因为使用的技术都不是互联网时代出现的针对大流量大数据的技术，所以遇到 To C 的使用场景，单位成本非常高昂。因为限制只能使用 Apex 语言做二次开发，导致对开发者限制很多，无论是学习还是开发门槛都相对较高，并且 Salesforce 坚持不提供私有化服务，导致在一些领域无法推广。Salesforce 的服务器也不在中国，访问速度也较慢。
另外，中国市场有自己的特殊性。例如世界领先的电商渗透率，移动设备渗透率，未来的物联网渗透率，4G/5G，移动支付的普及率，小程序等连接线上线下的平台强大性，企业对人工智能的开放程度，互联网转型的急切心态，等等。
SOS 等国外大厂调整产品，满足国内客户需求的速度也是难以忍受的，这方面我们会做得更好。微软现任 CEO 萨提亚·纳德拉 (Satya Nadella) 上任时就对全体员工说“我们这个行业不尊重传统，只尊重创新。”
21 世纪的科技巨头和繁荣的开源社区创造了很多先进优雅的技术，我们的起点在 2016 年，世界已经和 20 世纪大不同，社会的每一个环节都被改变，这么多年里，快速发展的互联网行业从根本上改变了 IT 行业的基础和格局，我们依托于这些伟大的创新，站在巨人的肩膀上，当然有机会做出一个新的 PaaS 平台，比 SOS 更先进，成本更低。
PaaS 是 Platform as a service，通俗地说是 Platform 的云化。所以我想先谈谈 Platform，再来谈谈 PaaS，这是一脉相承，但并不相同的两个概念。
可以看到，很多大名鼎鼎的软件都支持充分的自定义，微软 Office 系列支持 VBA，PeopleSoft 支持 PeopleCode，Unix 上每个著名软件的配置文件语法都可以写本书来讲。你可以把它们的这个能力抽象成 code execution platform/computing platform。来到了云计算时代，计算能力在云端而不是本地，就有了 PaaS，将 Platform 的能力，以 Service 的形式提供在云端。
其实从工业化时代开始，各行业都开始通过做一个靠谱的 Platform 来降低创新和迭代的成本，将不变的东西自动化，将不断变化的东西抽象成编程语言来提供灵活性，以此降低创新的成本和风险，这就是规模生产的工业化 Platform 的概念。
上世纪 90 年代，国外企业级软件里就能看到强大的 API 和可编程性，每个强大的软件都带着一个强大的 Platform，例如当时的 PeopleSoft、 Siebel CRM 都发明了自己的编程语言，在二三十年前就很强大了。Salesforce 和 Workday 的 PaaS 不是凭空而生的，是一路沿袭过来的。而中国直到现在，并没有足够好的 PaaS 供应方出现。为什么呢？因为做 Platform 难度很大，PaaS 就更难了。
再说说 as a service，它就相当于从买车到租车或者滴滴打车的变化。如果自己买车，首先要付一大笔钱，还要自己负责年检，保养，保险，考票，交罚单，加油，洗车等等事情，但 as a service，租车或滴滴打车，就不用那么复杂，并同样能达到从 A 点到 B 点的目的。
当然作为服务提供方，租车公司或者滴滴打车做了很多工作把业务复杂度给消化了，直接呈现给客户一个简单易用的服务。所以不管 IaaS、PaaS、SaaS 相比传统的基础设施，platform，软件，都是消化了特别多的复杂工作，提供一个简单易用的服务给客户。这种商业模式，无疑是正确的方向。
具体到 PaaS，这件事对企业信息化至关重要。它能从根本上降低试错成本，任何行业创新都源自大量的试错，如果成本很高，就会减少可能成功的机会，而 PaaS 是提高试错效率的有效手段。如果没有 PaaS，企业信息化这个行业的井喷发展期就很难到来。
用个通俗的比喻来说，在没有 PaaS 的世界里，客户想吃个西红柿炒蛋，就要自己去造燃气灶和油烟机。大部分企业客户需要的仅仅是实现业务需求 (就像想吃西红柿炒蛋)，而不是如何管理资源，如何处理身份认证，如何管理倒排索引等等 (就像造燃气灶和油烟机)。
由于通用编程语言过于基础，程序员需要把大量的精力花在对计算机资源的控制，去解决大量重复出现的问题，把至少 80% 的精力花在了原本要解决的核心问题之外，而一个合适 PaaS 的价值就在于，将解决方案提供者的视野限定在了业务需求范围内，把此领域中反复出现的问题事先解决好，不去浪费当事人的精力。
SaaS 公司想做大客户，PaaS 是必须要有的吗？
你去看 SAP、Oracle、Microsoft Dynamic 365、Salesforce、 Workday、ServiceNow 都具有 PaaS 能力。中国市场里，满足大客户高度复杂定制化需求的最常见方法是外包，这种商业模式价高、质低且不可持续，其次是找标准软件商提供定制服务。因为这种服务是非标准的，所以无法保证质量，成本也极高。而第三条路，就是提供 PaaS，依靠后续的实施和开发来满足需求和应对变化。
这里可以谈一下 ToC 和 ToB 的本质差别。To C 产品解决的是一个确定的问题域，是一个比较具象、比较聚焦的需求场景。但是这一套逻辑在 To B 领域里完全不适用。在企业信息化中，最终使用者由企业中各层级的不同角色、职能，在不同的业务场景下管理需求，即使是一个行业，也分为大中小型规模，即使是同一个公司，也分为早中晚不同时期的管理模式。
可以说，永远不可能凭借想象来穷举所有遇到的需求，需求是无穷无尽的。一套好的系统，必须能够跟随企业的发展和变化，充分灵活和可塑，所以才有了 PaaS 的概念，我们需要把提供的服务拆解到更底层的维度，才能经得住时间的考验。
大家都知道 IaaS，PaaS，SaaS 这三层的关系，理论上一个强大的 PaaS 层，是能支撑各种 SaaS 需求的。在我看来，一个强大通用的 PaaS，从技术上可以拆分成三个维度：高性能 PaaS，复杂度 PaaS，开发者 PaaS。
论技术难度，做好一个高性能 PaaS，相当于一个大型互联网公司的基础架构部或中间件团队的工作内容，需要丰富的经验和大量的研发投入。做好一个复杂度 PaaS，相当于创造一套数据库+一套编程语言+若干个强大好用的中间件。上一个时代里，IBM、Microsoft、Oracle 三家公司都做过类似的，艰难繁复的工作。而一个开发者 PaaS，要解决的是开发者工具支持的完整度，开发、调试、部署、安全、文档、数据隔离的问题。这需要提供一个基于云的开发、调试、部署工具，大致相当于一套 App Engine 的工作，可以类比 GAE、Heroku，或者 BAE。
我们做 PaaS 的公司，要同时去挑战这三件事的难度，更可怕的是还要同时挑战这三件事的完整度，这意味着巨大的工作量。要知道 Salesforce 做 PaaS 平台的有近 4000 位工程师，每年的人力成本就接近 10 亿美金。
三种 PaaS 的技术挑战何在？
我们内部评判 PaaS 总共有 50 多条标准，按照高性能、复杂度、开发者三个维度来拆开分析。
先说高性能 PaaS，这块的难度相当于：百亿美金互联网公司的基础架构。这是互联网 To C 公司的强项，FLAG，BAT 都是其中的佼佼者。主要挑战在于如何最大程度的发掘机器的潜能，如何利用分布式集群的能力，如何保证系统的 SLA 承诺，如何水平扩展，如何控制单位成本，如何实现集群的自愈和监控，如何有效的控制平摊下来的人力维护成本，又如何不断优化架构，提升检索，读写 IO 的能力。
以美洽的做法举例：我们通过分布式系统和集群管理工具来管理容量，并至少保障 99.95% 的 SLA 可用性，运维和部署一并解决。通过分布式系统，我们规避了昂贵的硬件，我们甚至也不使用的单机数据库，而是使用分布式数据库 TiDB，具有在不牺牲业务特性和强一致性的事务保障的前提下的水平的扩展能力。并且，我们整个架构还尽量使用多租户设计，更进一步节省了计算资源和存储成本。
这里要明确一点，大部分互联网公司的水平扩展技术是以牺牲某些技术特性或需要使用者做很多「work around」的工作来解决水平扩展性问题，而美洽的 PaaS 是提供不打折扣的类似于单机基础设施能力的。
我们使用的所有基础设施都是分布式的，比如分布式关系型数据库 TiDB，比如分布式的缓存系统 Memcached，比如分布式队列系统 Kafka，分布式配置管理系统 etcd，再通过将微服务化的无状态微服务容器化，通过 Kubernetes 和 istio 的能力，将所有的服务能力分布式化。
美洽提供了结合了传统单机系统一样的灵活性以及互联网公司常见的分布式高可用的基础技术平台。我们的多租户技术依赖于集群和数据库的能力。通过集群编排系统，智能地做容量管理，自动升级，部署管理，部署隔离。
我认为高性能 PaaS 是一个基本能力，无论做哪个领域的SaaS，大的，小的，垂直的，客户对你的要求，在这方面都是一样的，系统稳定性，数据安全性，数据量的水平扩展能力，处理较大流量的并发能力等，这件事情是避免不了的，一个收入天花板太低的 SaaS 公司，根本无力覆盖这块技术投入的成本。
这一点被很多创业者和投资人忽视或者低估了。就好像银行再有资源也无法做一个像 iPhone 一样出色的硬件设备，一个再大的企业也无法为内部开发一个强大的操作系统一样。这是个成本问题，一定要覆盖更多的人和领域，高昂的成本才能平摊到可以接受的程度。
再说说复杂度 PaaS，其难度相当于设计一套数据抽象系统，以及领域专用编程语言。这块是企业软件公司的强项，之前世界上最强的是 Salesforce 和SAP。主要挑战是如何最大程度地提高解决复杂问题的能力，如何高效的应对业务变化，而且必须是不能阉割的解决方案，要能解决所有问题。一般业务人员讲给不懂技术的客户，总说类似乐高积木的系统，任意需求都可以拼搭出来，说的其实就是复杂度部分。
我讲讲复杂度 PaaS 这块我们是怎么做的。首先，美洽 PaaS 中一切都是以服务形式提供的，这样的好处是将某件事情的复杂度控制在服务内部，服务之间隔离数据和逻辑，只以 API 形式协作，这样的好处是把问题域限制在一个较小的范围内，对人类脆弱的大脑比较友好，可以更好的完成每一个具体的服务。
并且大部分服务本身都是元数据驱动的多租户服务，它们都可以通过定义元数据的方式改变行为，特别是PaaS的核心，也就是存储服务，可以通过元数据定义出数据和数据之间的关系，数据以及数据间的映射还有级联关系。
企业级服务的核心就是数据的增删改查，以及级联操作。通过一个高度定制，可以元数据定义的分布式数据服务，来满足复杂的数据业务场景。我们把OLTP，OLAP，搜索引擎合三为一，用户可以一键式开启这些能力，无需开发。企业级开发的权限需求也非常复杂，像我们的权限系统兼容 RBAC 和 ABAC，权限控制可以精确到数据库的表级，列级，行级，甚至字段级。
对于复杂的业务场景，直接封装成可高度定制化的服务来单独提供，比如审批，工作流，报表等服务，全部可以通过元信息定义出期望的行为。为了提高交付速度，连 Web，iOS，Android 三端也可以通过元信息生成界面，而无需开发。为了满足个性化展示需求，三端也可以全部抛弃，客户完全可以基于API或者基础UI组件，来独立开发。
对于一些特别的需求，客户可以基于 PaaS 提供的 API，基于自己擅长的编程语言，开发适合于自己需要的程序，以 Plugin 的方式部署，这样既提供了足够的灵活性 (任意语言，任意行为)，又保证了数据安全和资源隔离。
从本质上来说，Salesforce 的 force.com 和 Heroku，它们分别代表了不同的思路和世界观，虽然后续 Salesforce 收购了 Heroku，将其变成了给自己扩展功能的底层设施，但毕竟是两个独立的平台。我们的思路是一开始就将这两者合二为一，更加一致和强大。
最后说说开发者 PaaS，难度相当于开发 App Engine 的大致难度 (比如GAE)。这是技术型平台公司的强项，最强的是微软，谷歌。这部分的挑战是：要建立清晰明确的世界观，要服务好里面的所有玩家，要有完整的工具链条和文档建设，要从架构上支持开发者，要做好社区建设。要保证对开发者友好，易用，强大，而且不断进步，尽量降低门槛，让大家容易上手，还可以不断精进，快速解决问题，提高收入。
以美洽 PaaS 为例，我们会推出完整的编程工具，辅助完成元数据的编写和查看，提供调试工具、部署工具，以及沙盒环境，帮助开发者快速开发，提高效率，并且提供在线监控平台协助开发者了解自己程序的运行状况，把整个系统状态尽量和客户保持透明。我们会提供一个让开发者更高效的在线开发环境，也会尽量保持和普通虚拟机类似的开发体验来让开发者低成本的迁移自己的经验和知识。
高性能 PaaS，复杂度 PaaS 和开发者 PaaS，这三个 PaaS 不能割裂来看，用小米雷总的话说，铁人三项，少一项都会有问题。目前看要同时做好这三方面事情的难度和挑战还是很大的，需要很强的想象力和架构能力。
其中很多地方是反互联网技术常识的，互联网 To C 公司，因为业务发展和变化太快，大部分时候不会也无法做特别长久的设计，而 To B 业务，因为别人要依赖于这个 PaaS 而存在，所以一开始就要是个至少完整正确的设计。
架构也好，设计也好不是为了解决计算机的问题，而是为了解决使用者的问题，人类的脑容量不适合处理特别复杂，变量特别多的东西。所以，一个事先考虑的很清楚，强大优雅，简单清晰的世界观就非常重要。
按照难度，高性能 PaaS，复杂度 PaaS 和开发者 PaaS 如何排序？
这三方面，第一难的是高性能 PaaS，第二是开发者 PaaS，第三是复杂度 PaaS。但其实最难的，是如何将三者整合，同时呈现。
为什么这么说呢？说到复杂度，过去几十年的企业级玩家，用小型机，或者单机实现的功能都是非常复杂的。仅限于单机的技术，就不是特别有挑战的事情。将这些复杂度用某种易于理解和使用的方式呈现给开发者，就需要掌舵人很好的建立世界观，维护好这个思想世界里的一致和协调。
到了互联网时代的数据爆发期，单机解决不了问题了，就要考虑如何在分布式环境下同时解决存储和逻辑的问题，这也是过去二十年里，互联网巨头们一直在努力的领域。
这里面用到的技术和理论还是很新很难的，互联网公司往往为了使用这些能力，放弃了很多业务上的便捷，但在企业级这些又无法放弃，所以三者结合的难度又大大高于其中任何一种。
以美洽的做法举例：我们通过分布式系统和集群管理工具来管理容量，并至少保障 99.95% 的 SLA 可用性，运维和部署一并解决。通过分布式系统，我们规避了昂贵的硬件，我们甚至也不使用的单机数据库，而是使用分布式数据库 TiDB，具有在不牺牲业务特性和强一致性的事务保障的前提下的水平的扩展能力。
这里要明确一点，大部分互联网公司的水平扩展技术是以牺牲某些技术特性或需要使用者做很多「work around」的工作来解决水平扩展性问题，而美洽的 PaaS 是提供不打折扣的类似于单机基础设施能力的。美洽利用最新的技术手段提供了结合了传统单机系统一样的灵活性以及互联网公司常见的分布式高可用的基础技术平台。
要做出比 SOS 更先进的 PaaS 产品，应该要有什么样的用人策略？
就像攀登珠峰有南坡、北坡两条路，国内 PaaS 公司也有不同的路径。有的技术带头人软件行业背景强擅长复杂度 PaaS，有的技术带头人互联网行业背景强擅长高性能 PaaS，这就看哪个打入到对方领域，更容易了。我认为应该选择全互联网背景的人才，我们认为从高性能 PaaS 打到复杂度 PaaS 更容易。
软件行业和互联网行业两种人才的能力特点和认知都相差甚远，做产品、架构、写代码的方式也差异极大。大部分软件行业的人才，虽然应对复杂需求的能力 ok，但这只是必要能力，不足以破局，如何应用最新的互联网技术和思想，去突破性的解决问题才是关键。
互联网技术在过去二十年里获得了突飞猛进的发展，诞生了很多革命性的技术手段，这些技术合理地应用到 To B 领域，是可以带来突破性的功能/成本/体验优势的，这也是我们看到的巨大机会。其实从这个角度来看，SOS 的团队也是相对陈旧落后的，他们也在革新和换血。
对于做 PaaS 的厂商来说，应该有什么样的商业化策略？
从商业策略上来说，最重要的是发展生态伙伴。你去看 SOS 这种体量的公司，它们没有一家是单纯靠直销做大的。Salesforce 负责中国业务的员工应该不超过十个，每年就能做到两个亿的收入，销售效率极高。而国内厂商，现状都是靠大量的直销团队，来拉动销售收入，不管人均单产高低，毕竟短期可以让投资人看到增长的可能性。
现在国内厂商在生态伙伴这方面，基本没有真正开始，有也只是一些帮着走货的小批发商，很少有类似埃森哲，汉得信息这种体量的，能帮助客户做定制化解决方案的合作伙伴。
事实上，如果你去搜索 2016 中国方案商 500 强，会发现，中国最多的企业 IT 预算是在方案商这里的。那为什么国内现在的云厂商都没打入这些方案商市场？就是因为没有强大的 PaaS 及公司品牌，方案商的实施人员根本无法施展。做 PaaS，做生态，作为一个范式转换的新兴事物，被市场全面接受并普及是需要一个过程的，我们应该要有充分的耐心。
AWS 是 2006 年推向市场的，Netflix 是 2008 年才开始和 AWS 合作，7 年后的 2015 年才全部迁移到 AWS 上面。iPhone 诞生于 2007 年，但到了 2013 年，智能手机的出货量才超过功能机的出货量。
很多合作伙伴觉得不能依赖其他第三方平台，这种想法是可以理解的，其实这是一个行业成熟度的问题，想象一下全世界范围内为汽车生产变速箱，发动机的厂商寥寥无几，生产 CPU 的厂商也一只手就数得过来，大家选择公有云，其实也就那么几个大厂出品。
因为不同事情需要不同的人，不同的经营策略，不同的管理方式，一个企业什么都做的方式在现代工业文明里越来越少见。任何一个事情要做好都需要巨大的投入，如果没有一个足够大的规模去平摊掉成本，这个巨大投入就没有人负担的起。
疑问 1：如何鉴别 PaaS 的真伪，以及是否强大？
崔强：有人认为 PaaS 是需求累积到一定程度倒逼出来的，不可能凭空做出来一个 PaaS。还有人认为 PaaS 投入巨大，只有 Salesforce、Oracle、SAP 这种巨头才能玩得起，市场上又有很多小公司声称自己开发出来了 PaaS。这些到底如何鉴别，是真是假，是否强大？
李令辉：“PaaS 是需求累积到一定程度倒逼出来的”这个说法是相当经不起推敲的，需求是无限的，而人的生命是有限的，以有限追无限，是不可能成功的。PaaS 的设计是来自于对某一领域可能有的需求的总结和抽象，不需要穷举。在我看来，PaaS 更类似于编程语言和操作系统，在发明编程语言的时候，计算机科学家根本无法想象出今天的无数种应用场景。
如何判断一个编程语言的强大性？科学的方法是判断它是否图灵完备，这更像是一种数学证明方法，而不是穷举所有的编程需求。至于说“PaaS 只是巨头的游戏，小公司没法参与”，这个观点也站不住脚。在我看来这是典型的因果倒置，是做了 PaaS 的公司，才成了大公司。Salesforce 从创业开始就在做 PaaS，用他们的话说是要做商业的操作系统，那时候的 Salesforce 可是完完全全的小公司。
疑问 2：造成 PaaS 有不同侧重的内在原因是什么？
崔强：有一种说法是“PaaS 会有一个侧重，比如侧重 CRM 的，侧重 HR 的，很难有一个 PaaS 能各方面都很强大。”造成这种区别的内在原因是什么？
李令辉：这种说法有一定道理但是又有点似是而非，这里说的是复杂度 PaaS 的那一部分。我之前做了一个类比，这个领域类似于数据抽象系统+一门编程语言，数据库会对哪方面的业务有所侧重么？编程语言会明显倾向于解决某种业务么？
要知道从数据库的角度来看，都是 CRUD，编程语言的角度来看，都是读写 IO，参数处理，一点点计算而已。从这个角度来看，什么业务并没有太大差别。但是这种提法并不是一点道理也没有，因为 PaaS 都是在易用性和强大性之间做权衡，为了更快的交付，PaaS 一定会对具体要做的业务做很多接近的功能支撑，如果一个公司的在商业策略上倾斜于一个领域，当然在这个领域的功能支持上会增大投入，所以肯定会在交付上能力上有所区别。
但是这件事并不是必然的，而是和投入水平相关。通用的编程平台很多，根本不会有人质疑它们的通用性。
疑问 3：PaaS 那么重要，为什么 Salesforce 的 PaaS 收入还不到总收入的 10%？
李令辉：PaaS 直接售卖的不多，更多是打包成 SaaS 后去售卖的，但是透过现象看本质，你会发现，如果没有 PaaS 来平摊成本，效率是很低的。另外，对 Salesforce 而言，最重要的护城河是它的生态，单靠 Salesforce 一家公司直营，是不可能满足如此数量众多的客户需求的。而吸引如此众多的合作伙伴的前提，无疑是 PaaS。
就好像 QQ 其实长期都不是腾讯的盈利主力，网游才是，但是 QQ 的存在，现在是微信，是保证腾讯能够源源不断的获得网游用户的竞争力所在。你不能说这个不直接赚大钱，就不是公司的核心。
疑问 4：有一种观点说，凡是到一定规模的客户，难免会自己开发 CRM。你们怎么解决客户的这个问题？
李令辉：过去确实有不少中国企业倾向于什么事都自己干，这在以前技术人力成本较低的情况下还好。企业客户第一次做 CRM 开发时大多会低估难度，找个外包团队或在自己技术团队里找几个人就开始干了，做出一个能用的，就先凑合着用。
在今天还带着这个惯性来做的，肯定得不偿失。专业的人做专业的事情，一个公司不可能有精力把内部系统做的和外部系统一样好，现代社会肯定是用分工去提高效率的。
刚才提到的例子，过去大多数公司都自己买车，但是现在大家都改成租车了，因为自己养车成本高，效率低，就算每个公司都有车的时代，也没有哪个公司非要自己造车造发动机吧，你可以理解中国企业非要自己干内部信息系统的行为基本就等同于为了用车，非要自己造车。
随着时代发展，大家越来越在乎成本和效率，没有人会自己养车了，都会选择租车，在企业服务市场，大家都会选择租用 SaaS，而不是现在自己买机器，自己雇程序员，项目经理，产品经理，开发一个“用的人比做的人多不了多少”的系统。
算笔简单的帐，一个相对来说比较复杂的 CRM 系统 20 个人来做一点也不多，大约 4-6 个移动端，2-3 个前端，6-10 个后端，1 个项目经理，2-3 个测试，1-2 个产品经理，1-2 个 UE，这些人一年的所有成本大约 500-1000 万，如果一个团队经过多次迭代，三年才把 CRM 做到及格，就需要 1500-3000 万。
每家公司在自己的领域都要征服星辰大海，但肯定不是每家公司都征服同一片海嘛。任何行业的发展都会逐步走向更精密的分工及合作，企业信息化领域也不例外。美国的亚马逊、苹果、特斯拉、思科采购了 Salesforce，国内的金山软件、TalkingData、神策采购了 Salesforce。这些公司都有很强的软件研发能力，但在非核心的业务系统上，还是会采购专业的第三方服务。
国内现在是供应方产品技术能力比较弱，假以时日，这种现状肯定会改变的。
星标 牛透社 ，SaaS 洞察不错过~