“使用者不需要在自己的计算机上装任何软件，只要连上网络，就可以通过浏览器，使用各类软件的功能。”这是传统软件产业的巨头Oracle公司曾经认知的颠覆性的软件模式。但现如今，为了寻求更加长远的发展，它们也开始逐渐培养SaaS（Software as a Service）的业务。本篇文章里，作者分别从四个方面为我们详细解释了到底什么是SaaS，一起来看看吧。

“使用者不需要在自己的计算机上装任何软件，只要连上网络，就可以通过浏览器，使用各类软件的功能。”

这是在1998年秋，甲骨文副总载马克·贝尼奥夫所认知的颠覆性的软件模式。这种模式让贝尼奥夫意识到：“投入这个模式，才有机会翻身做软件产业的老大”，于1999年宣布将“摧毁软件产业”（这里的软件产业意指传统软件产业），这一年，贝尼奥夫以3400万美元起家，在自己家旁边租了间公寓，成立了salesforce.com。

截止到笔者写这本书的2021年，22年的时间过去了，贝尼奥夫尚未完成这个宏大的愿望，但Salesforce公司的市值，已经超过了甲骨文公司（Oracle），第一次超过Oracle公司的市值是在2020年。目前Salesforce公司是SaaS行业的龙头公司，市值约为2660亿美元。Oracle公司仍然可以视为传统软件产业的巨头，但也在几年前开始培育SaaS业务，目前市值约2580亿美元。

一、全面了解SaaS

1.1 什么是SaaS

SaaS，是Software as a Service的简称，意为软件即服务，这一概念的最早提出者已经无法考证了。业界一般认为，Salesforce的创始人兼CEO马克·贝尼奥夫是SaaS商业模式最早的实践者。

从SaaS的英文全称中可以看出，SaaS是软件和服务合为一体的，本质上SaaS是一种服务，这是同传统的软件产品最大的区别。

SaaS，一般指面向企业端的软件产品服务，广义的SaaS也包含面向个人的软件产品服务。面向企业的SaaS产品现在已经很多，后续文章我们会继续介绍。面向个人的SaaS产品服务，国内如金山公司的WPS office , 国外如Adobe公司的一些产品等。

1.2 软件的发展阶段

为了更好的理解SaaS，我们简单回顾下软件的发展历程。

1.2.1 网络角度划分

从网络的角度划分，软件的发展大致经历了三个主要阶段：单机应用、局域网络应用、互联网络应用。

单机应用：在互联网或网络还没那么普及的时代，计算机上安装的一般为单机应用程序，在本地计算机运行，这类软件出现时间很早，在1960年以后已经开始出现。到现在还有一些产品在使用，如一些卖license（许可证）的软件，无需联网，使用单机就能解决软件使用的所有功能，但现在的软件复杂度和易用性相比上个世纪已经大幅提高。

局域网络应用：这个阶段的软件产品主要部署在局域网络内，局域网络应用以企业应用为主，我们所说的传统软件产品，主要是该类产品，部分SaaS产品在私有化部署的方式下，也可以归类为这类应用。

互联网络应用：随着网络的普及，用户基本上都可以直接访问互联网，大量的服务开始直接部署在云端，而不是在一个小的局域网络内，所有的用户可以共同访问一个服务。SaaS产品大多属于这类应用，部分传统的软件产品也属于互联网络应用。

1.2.2 软件架构划分

按照软件架构的形式划分，包含C/S架构（客户机/服务器结构）和B/S架构（浏览器/服务器结构），C/S架构需要在本机安装特定客户端程序，B/S架构无需安装特定客户端，使用电脑自带的浏览器打开链接地址，即可开始使用软件。这两种模式，目前仍有很多企业再使用，但逐渐向B/S架构迁移。

在电脑端，早期以C/S为主，现在B/S为主流架构模式。在手机端，随着移动互联网不断发展，越来越多的应用在支持手机端。为方便用户使用，大多数产品都需要在手机上安装应用软件，目前移动端产品基本为C/S架构的应用，少量为基于手机浏览器访问的H5应用（这属于B/S架构）。

我们分析大量的国内外SaaS产品，可以发现目前大多数SaaS产品是以在电脑端操作为主，B/S架构模式占比更高。

1.3 如何理解SaaS

SaaS的英文翻译过来就是“软件即服务”。在SaaS概念提出以前，软件一直是被当做“产品”来看待的。产品是什么?

产品是指作为商品提供给市场  ，被人们使用和消费，并能满足人们某种需求的任何东西，包括有形的物品、无形的服务、组织、观念或它们的组合（定义来源于百度百科）。

SaaS是不是一种产品？当然是，从产品的定义可以看出，产品是包含服务的。那我们为什么又要强调服务的概念？

我们以自行车举例。看看通俗意义上产品和服务的区别。

在共享单车出现以前，我们要想骑车，一般需要自己花钱买一辆自行车，车辆的所有权、控制权都属于自己，车辆如果损坏了，一旦超出质保期，一般也需要自己承担维修等费用。

在共享单车出现以后，我们要想骑车，直接在智能手机上下载一个APP，扫描单车上的二维码，即可解锁骑行，到达目的地后，再把自行车锁上，完成付款，整个过程就结束了。我们不需要去管理车辆，也不需要担心车辆是否丢失，是否被损毁，如果出问题，会有单车所属公司来进行管理处理。

第一种场景，我们骑的自行车对我们来说是一种“产品”，它的价格、功能、售后支持周期等都已经确定，并且车辆的所有权也属于我们自己。第二种场景，骑的自行车对我们来说是一种“服务”，我们并没有拥有这辆自行车，却可以享受到骑行服务，这实际上是一种租赁服务。

这里我们是以产品的所有权归属来区分“产品”（非广义的产品）和“服务”。

对于传统软件产品来说，在软件发布的时刻，软件的功能、适用范围、许可证、以及软件产品的支持周期和价格都是确定的。

比如用户购买了Office 2010软件，内中含有Word，Excel，PowerPoint等等，详尽功能一一列举，然后微软还给出了市场指导价并约定对这一款产品提供5年的保修(技术支持)服务。这种模式下，和用户买了一部自行车没什么区别。这个产品在工作和生活中帮助用户创建和分享各种文档和表格。这就是用户把软件当做产品来购买时的常规形态。当Office 2010 这一款产品的生命周期截止的时候，用户将无法得到厂商的维修保障，如果用户想使用更多的新功能，那么只能向厂商购买下一代的新产品。

用户购买了一辆自行车，根据厂商的质保和服务条款，自行车一年后脱保，用户再想维修和更换易损件就要自己花钱了。如果客户还想用上最新一代更轻便的自行车，那只好再买个新的自行车。

本质上软件产品和自行车等一类产品都是一样的。

服务是什么？服务是一种不将实物商品从卖方转移到买方的交易。服务提供者利用资源、技能、独创性和经验使服务的对象受益。

套用到软件即服务的概念上，软件此时由产品变为了厂商提供服务的工具和载体。还用Office 来举例子，Office 的SaaS 版本就是Office 365。此时，微软不是卖Office 给客户，而是给客户提供文档创建、文档分享、邮件服务、在线会议服务等功能服务。与之对应的软件Word，Exchange，Teams 和SharePoint Online 等都变成了微软向客户提供服务的工具。这些工具承载着服务让用户来使用。

在提供服务期间，软件的技术升级一直都是厂商必须要做且客户无需付费的（厂商的目的是提升产品的市场竞争力）。如果三年前用户采用了Office 365服务并一直使用至今，那么当时应该使用的是Office 2016系列客户端办公套件，而现在可以免费更换和升级到Office 2019 套件。客户无需为此产品的升级而付费。

这就是产品和服务的差别。除此之外，这里面还涉及到两者的定价策略问题。软件产品往往是一次性付费加运维费用，首次建设费用偏高；而SaaS产品往往是按照周期收费，比如按年收费，费用较低。

本书我们主要探讨的是SaaS产品，也就是上文提到的为客户提供服务所需要的工具和载体，我们主要讨论的是这些软件工具和载体的构建过程。所以下文中，我们会在大多数情况下继续使用SaaS产品的概念。

1.4 SaaS的特点

从客户角度来看，SaaS服务典型的特点，包括以下几个方面：

互联特性：

SaaS产品是基于云的产品服务，没有网络，意味着无法使用SaaS服务。现在的很多SaaS产品都提了PC端和移动端等访问方式，在任何地方只要有网络接入即可使用SaaS服务。SaaS服务天然在云端存在，不像传统的软件产品是部署在企业内部，系统之间互相孤立的。

云端服务对跨系统的数据交互大有好处，两个SaaS系统之间一次打通，理论上所有的客户均可使用打通后的产品能力，能够摊薄系统间打通的成本，边际成本降低非常明显。传统软件对接的方式会带来大量的研发、协调和实施工作，单客成本远高于SaaS模式。

我们已经看到现在很多SaaS都在做场景延伸产品和上下游协同产品的打通，SaaS公司更容易、也有更有动力构建SaaS产品的生态圈。SaaS生态的构建，有助于为企业客户带来更好的效率提升和体验提升，增加生态圈内的产品复购率。

无需关注基础设施：

不需要企业部署大量的硬件设备，使用云服务即可完成企业的业务管理；传统的软件产品，企业需要采购物理服务器、防火墙、建设或租用机房等，需要招聘专业的运维人员，制定运维规范，考虑系统灾备等问题，用户量大的情况下，还需要考虑动态扩容，提升并发能力。基本上一个售卖一套产品，都需要按照一个项目进行实施。

比如微软销售邮箱产品，想要使用微软技术的邮件服务，那么该用户不但要购买微软的Office和Exchange 等软件产品，还要购买服务器硬件等，请微软的分销商、合作伙伴协助搭建一个Exchange 服务器群集(为了高可用和扩充)，然后自己组织内的雇员才能用Outlook 连接Exchange服务器收发自己组织域名下的邮件。

这套流程下来，快的也要一个星期，对于几万人的大型公司，微软把Exchange 按照项目来做的，实施几个月也是常事。同样是这一个客户，如果直接购买的是Office 365这样一款SaaS服务，那么用户不需要购买软件和硬件，也不需请微软合作伙伴搭建Exchange 群集，只需要经过简单的培训和介绍，在http://portal.offce.com 网站上登录并给组织内的雇员每人创建一个账号即可，做到了拆箱即用。

如果有大批员工来入职，客户也无需操心硬件容量问题，这些都由服务提供商微软自己来解决。微软不但要为客户暴增的容量负责，还需要为客户服务的高可用负责，在构建Offce365这个SaaS平台时就从基础架构上考虑了高可用。

按需付费：

上一个特征中，我们已经提到，SaaS服务是可以根据客户需要灵活创建账户的，根据使用的资源多少进行付费，比如根据开通的用户数量、使用的资源空间、功能的多少等进行计费，可灵活扩容或升级。比如邮箱新员工入职就多创建一个，有人离职了就删除一个，按需付费，大大减少初始成本的投入，降低项目启动成本。

持续服务价值：

SaaS产品本身就是一种服务，SaaS产品普遍都需要持续迭代，用户无需额外服务，就可以享受到未来软件产品升级带来的体验或价值的提升。SaaS公司比较重视客户的续费率，在发展过程中，一般会更重视用户的使用和反馈情况，大多数公司会配备在线客服和客户成功团队，让用户可以享受到便捷的客服服务。

从SaaS平台的建设角度来看，SaaS服务典型的特点，包括以下几个方面：

可扩展：

SaaS产品基本都需要进行持续迭代，需要具备良好的可扩展性，能够满足未来发展的需要。SaaS产品需要设计优秀的产品架构、系统架构等，扩展性即体现在产品功能上的扩展，也体现在性能上的扩展，甚至包括系统级的扩展。

一个扩展性差的产品架构，能够满足的场景会相对有限，而SaaS产品的定制化是不易处理的问题，所以产品本身能够覆盖更多的使用场景，能够有效提升产品竞争力——扩展性差的架构设计是需要尽量避免的。

多租户：

SaaS产品很大魅力在于多租户设计，这种模式可以大幅度降低软件使用的边际成本。

多租户：是一种架构模式，是实现如何在多用户环境下共用相同的系统或程序组件，并且达到各用户间数据的“独立”的技术。

使用SaaS产品，不同租户访问的是同一个网络地址，使用的是同一套软件产品，但数据却可以实现不同租户间的“互相隔离”，每个租户都只能看见和管理自己的数据。

多租户设计意味着用户新增过程是非常简单的，我们只需要开通相应的账号，就可以实现新增用户的目的。

可配置：

SaaS产品是多个租户共同使用一套软件，而每个用户所处的行业不同、流程不同、使用场景不同，一套软件要满足不同用户的使用，自然而然就需要软件可配置，通过配置满足不同用户的需求。

我曾经看到过一些软件产品，灵活性非常高，任意一个字段、按钮、读写权限等都可以进行灵活配置，我们在使用过程中，如果不是相对专业的人员是很难学会这种配置的，这会大大提升用户的学习操作成本。

在SaaS产品的可配置特性上，我们需要在灵活和易用之间寻找一种平衡，尽量以易用性为第一目标，在易用的前提下再增强可配置特性。

SaaS产品有还有一些其他特点，这里就不一一介绍了，其实我们不难发现，SaaS产品的一些特点，传统软件产品大部分也需要具备或者可以做到的，只是这些特点在SaaS体系内，显得更为突出和重要。

二、SaaS产品VS传统软件产品

通过前文我们能够发现传统软件产品和SaaS产品的一些不同之处，接下来，我们详细对比下这两种产品的特点。请看下表：

但SaaS产品和传统软件产品都属于软件类的产品，在很多方面还是有共同点的，对于大多数人来说，认为SaaS就是软件，这些共同点基本上是大家已经形成的认知，我不打算在花费篇幅描述。如果做过传统软件行业，会发现后文介绍的一部分方法论，是从传统软件的方法论中继承延伸而来的。

三、SaaS和PaaS的关系

3.1 关于XaaS

XaaS的全称是X as a service，一切即服务，X代表所有而不是某个单词的缩写。这一缩写指越来越多地通过互联网提供的服务，而不仅仅指本地或现场服务。

比如我们通常所说的IaaS、PaaS、SaaS都属于XAAS的范畴。SaaS我们前文已经介绍了，IaaS和PaaS的含义如下：

基础设施即服务 (IaaS ： Infrastructure as a Service)：

把计算基础(服务器、网络技术、存储和数据中心空间)作为一项服务提供给客户。

它也包括提供操作系统和虚拟化技术来管理资源。消费者通过Internet可以从完善的计算机基础设施获得服务。

平台即服务(PaaS：Platform as a Service）：

PaaS实际上是指将软件研发的平台作为一种服务，供应商提供的服务不仅限于基础设施，而是将软件开发和运行环境集成为整套解决方案，以SaaS的模式提交给用户，所以有些观点认为PaaS也是SaaS模式的一种应用。但实际上两者用户对象有所不同，PaaS一般是面向软件开发人员，而SaaS面向软件客户。

他们的关系如下：

从名称定义和所处的层级可以看出，SaaS和PaaS的关联度是比较紧密的。接下来我们详细介绍下PaaS平台以及同SaaS平台的关系。

3.2 PaaS平台的发展

我们看一个典型的案例。

Salesforce在2007年就推出了自己的PaaS平台http://Force.com，已经有超过5万家企业使用了这个平台。该平台有如下主要作用：

Salesforce内部：基于PaaS开发自己的SaaS产品，可以大大提高开发效率。Salesforce的Sales Cloud，Service Cloud等主打产品，都是基于http://Force.com开发的。

平台客户：一些SaaS客户有一些个性化需求，需要基于PaaS做定制开发，满足定制化的需求。基于http://Force.com平台，客户不但可以定制开发新功能，而且还可以对Salesforce的标准功能进行定制改造。

平台ISV（平台上的服务商）：基于PaaS开发新产品，针对不同行业，提供专属解决方案。比如基于http://Force.com开发的医疗行业CRM产品Veeva。

近年Salesforce相继收购了MuleSoft和Tableau，大大增强了PaaS平台在系统集成和数据分析方面的能力。

Salesforce在PaaS平台的投入上，启动较早、投入较大，相对比较成熟，是业内顶尖水平。

而对于其他厂商，第一是进入SaaS行业比较晚，进而推出面向SaaS的Application PaaS就更晚了，第二是开发PaaS平台有很大的技术难度，目前也仅有Oracle等少数SaaS企业能够做到，国内仅有少量几家SaaS企业在推进建设PaaS平台的尝试。

另外有一些IaaS平台也在向PaaS平台延伸，比如AWS和阿里云，为开发者提供一些运行环境、中间件和操作系统等方面的服务，已经超出了IaaS平台的服务范畴。

3.3 SaaS与PaaS的关系

从前面的介绍，我们已经了解到PaaS平台比SaaS平台提供的服务更加基础。在SaaS平台的建设过程中，PaaS往往作为SaaS一个强有力的支撑，来解决行业或客户的个性化、定制化问题。

从用户对象来说，PaaS平台主要面向开发人员，SaaS平台主要面向使用的软件用户。

SaaS平台的构建大多数并不是基于PaaS平台，SaaS平台往往有自己独立的产研团队和运维团队，需要重视数据安全等问题，有能力直接搭建这些基础设施，SaaS平台的建设对PaaS平台并没有依赖关系。

SaaS平台用户量大，侧重点在于解决用户的使用场景需求，产品相对标准化。

PaaS平台的存在，主要是解决企业基础运行环境和中间件服务的建设问题，方便研发人员更快的搭建系统。而围绕SaaS平台搭建的PaaS平台，侧重点是解决SaaS平台无法更好满足定制化的问题，为客户或行业软件公司的开发人员在现有的SaaS产品基础上，提供定制开发能力，解决个性化需求。

PaaS平台的构建思路，并不是在SaaS平台基础上进行延伸，SaaS公司想要建设PaaS平台，需要重构基础架构，不是简单的在现有SaaS平台的基础上提供一些定制开发能力，这在以往的PaaS平台建设过程中，已经验证了基于SaaS构建PaaS平台的问题。

四、SaaS的优势VS局限性

SaaS平台近年这么火热，到底有什么样的魅力，让这么多公司投入SaaS赛道，接下来我们分析下SaaS平台的优点以及局限性。

4.1 SaaS平台的优势

（1）可重复使用

SaaS的最大优点之一就是“可重复使用”，这其实是SaaS其他所有优点的基础。如果你确信企业应该使用SaaS解决方案，实际上你就已决定不从事重复工作，而是单单利用现有的解决方案。至少，该解决方案实施起来速度更快、成本更低，虽然算不得最好，也会是“足够好”。

（2）成本较低的解决方案

企业如果采用SaaS解决方案，其成本一般只有自行实施、部署、运行、管理及支持这类解决方案所需成本的一小部分。

SaaS解决方案的一个最大优点是，它们在价格方面可以提供非常显著的规模经济。之所以如此，原因就在于大多数SaaS提供商可以非常轻松地利用其在特定行业领域“重复使用”的优点，能提供具有高度可复制的“标准化”的解决方案。最终结果是，它们通常可以将这种可重复使用的优点惠及客户，同时可以大大节省成本。

（3）可以更快地提供解决方案

SaaS的提供商早已对企业即将采用的针对特定领域的解决方案进行了规划、设计、实施、部署及测试。这意味着企业可以使用已有解决方案，而企业要自行实施这样的解决方案需要很长时间。以大多数SaaS解决方案为例，软件已经实时运行、随时可以使用。唯一的“瓶颈”就是支付服务费和如何把这个工具与自己的业务流程联系起来。

（4）灵活的定价模式

采用SaaS的解决方案时，企业通常会使用基于订购、可以确定的定价模式，这种模式让企业可以在需要时购买所需服务。这意味着企业可以根据发展模式购买相应软件。企业规模扩大时只要开启新的连接，用不着购置新的基础设施和资源。而一旦企业规模缩小只要关闭连接即可。

这样，企业可以避免被过多的基础设施和资源所累，而传统上，即使你再也用不着它们，也不得不继续需要管理及支持。

（5）更好的支持

使用SaaS解决方案时，企业很可能使用由专家提供、管理及支持的解决方案，他们24×7小时关注某一专门领域。该提供商相当于企业的实时延伸部分。实际上，连接到SaaS提供商对使用者而言是一种成本非常低的方式，只要连接上，SaaS提供的资源就始终在为你服务，这相当于扩增了企业的资源。

（6）为企业减少所需的IT资源

通常只要用浏览器就可以连接到SaaS提供商的平台，所以用户需要的全部基础设施就是用来运行浏览器的设备以及让该设备可以访问互联网的简易网络。这意味着企业不必提供、运行、管理及支持自己的内部基础设施。对那些规模非常小、不想自行管理IT部门这项复杂工作的企业而言，SaaS无疑是一种行之有效的方案，有助于加快实施企业的解决方案，同时尽量减少所需的IT资源。

4.2 SaaS平台的局限性

（1）供应商锁定

SaaS提供的服务，让客户开通、使用服务非常容易，但退出服务有可能会比较困难。例如，数据可能无法在技术上或成本效益上向其他供应商提供的SaaS服务进行移植。因为并非每个供应商都遵循标准的API、数据定义和工具，这会造成切换SaaS服务的困难。

随着市场竞争越来越充分，SaaS平台自身的服务水平也在提升，社会责任感也有所加强，会促进行业标准和规范的形成，逐步为客户提供全生命周期的管理过程。另外在一些受到监管的行业，政府会主导制定平台建设的标准规范，保障客户权益。

（2）缺乏集成支持

许多客户需要与本地其他系统、数据和服务进行深度集成。SaaS供应商可能在这些方面能够提供有限的支持，但无法全部支持，从而使得用户在设计和管理集成方面投入更多的其他资源。所以SaaS平台在设计产品架构的过程中，应提供更多通用的、标准的api和丰富接入场景，以减少和其他系统集成的困难，构建行业生态。

（3）数据安全顾虑

为了满足软件功能的使用，SaaS平台需要将数据传输到云端数据中心进行存储。将敏感的业务信息存储到基于云的SaaS服务，可能会导致安全性和合规性受到影响。额外提一个小故事，Salesforce创立之初，创始人马克·贝尼奥夫投身慈善事业，这让马克和他的企业在业界树立了楷模形象，有助于提升公司形象，减少了顾客在安全方面的顾虑，当然此后马克·贝尼奥夫也在持续投身慈善事业。

（4）不易定制化

由于不同行业、不同客户会有不同的需求，需要提供不同的解决方案，因此定制化问题可能会困扰用户选择SaaS服务。现在一些软件开发工具包(SDK)附带的本地解决方案提供了高度的定制选项。一些头部的SaaS平台企业也在同步构建PaaS平台，用以解决客户的个性化需求问题。

（5）缺乏控制

SaaS解决方案使用云平台，对于客户来说相当于将控制权移交给第三方服务提供商。这些控制权不仅限干软件，还包括软件版本、软件更新、软件界面以及数据和管理。因此，客户可能需要重新定义其数据安全性和治理模型，以适应SaaS服务的特性和功能。SaaS供应商也需要在构建SaaS平台过程中，将更多的控制权交还给客户，让客户更愿意使用SaaS服务。

（6）功能限制

由于SaaS应用程序通常以标准化形式出现，SaaS产品的发展会在安全性，成本，性能或其他策略之间进行权衡，这对于客户来说，功能使用上会受到一定的限制，比如在产品迭代过程中，产品的操作习惯可能会变更，产品的功能也会变化——可能会更好用，也可能会不如原有功能的体验。此外，供应商的不易变更、成本或安全性等问题可能意味着将来无法切换供应商或者选购其他服务，无法满足客户的需求。

（7）性能和停机时间

由于供应商控制和管理SaaS服务，因此客户需要依赖供应商来维护服务的安全性和性能。尽管有适当的服务级别协议(SLA)保护，但计划内和计划外的维护，网络攻击或网络问题仍可能影响SaaS应用程序的性能。

我们了解SaaS平台的这些优点和缺点，有助于我们在建设SaaS平台的过程中，解决和规避这些问题，逐步让SaaS平台脱离这些“问题”标签，让整个SaaS行业朝着更加积极的方向发展，客户的接受度才会越来越高，整个生态才会更加健康繁荣。

如果您需要深入了解SaaS，可以参考我写的书籍《SaaS产品方法论——入门、实战与进阶》一书，感谢大家支持！

本文由 @原始森林 原创发布于人人都是产品经理，未经许可，禁止转载

题图来自 Unsplash，基于 CC0 协议