一、"整个系统"这四个字包含什么

前面几节反复提到"一层层交出去"，走到 SaaS 时，交出去的东西是最多的：

从机房到应用代码，全部由对方负责。 你不用装、不用升、不用担心半夜挂了，甚至不用知道它在哪台机器上。你唯一要维护的，是你自己的数据和账号。

这个"全包"带来一个直接后果：SaaS 的选型标准，跟 IaaS／PaaS 完全不同。 选 IaaS 时你关心性能参数、网络规格；选 SaaS 时这些参数几乎看不到，你只能关心：功能对不对、数据拿不拿得回来、合同怎么签。

二、群件：功能常常买在同一份订阅里

教材用的词是【群件】——就是那类把邮件、日程、会议、文件共享、在线文档打包在一起的协作套件。

它值得单独讲，是因为它是 SaaS 里最典型、也最容易见效的一类：

注意"同一套订阅里"出现了四次——这是群件最容易被忽略的优点。如果这些能力各自自建，你要维护邮件服务器、IM 服务、文件服务、目录服务四套东西，而且还要让它们之间互相信任（这才是真正麻烦的部分）。打包成一份订阅之后，麻烦的不是每一样，而是每一样之间的连线，一起消失了。

三、六个场景：哪些能直接交给 SaaS

这张表是按"难度"排的：上面三行是"能不能用"，下面三行是"能不能放心用"。

区分点在于： 前三行的顾虑是功能（够不够用、合不合适），后三行的顾虑是归属——数据会不会出门、核心能力会不会变成别人的。后者才是真正需要谨慎的部分，因为功能不合适可以换一家，而核心能力交出去之后拿不回来。

四、SaaS 的账该怎么算

SaaS 最容易被算错的地方，是只算订阅费，不算省下的东西。

正确的算法是两栏对照：

• 你付出的：订阅费（按人月或按用量）＋ 流程迁就的成本 ＋ 数据迁出的成本（如果将来要换）。
• 你省下的：服务器与机房、运维人力、升级与补丁、安全防护、高可用建设、灾备演练。

关键在于后一栏里的每一项都不是零成本。 尤其是"升级与补丁"和"灾备演练"——这两件在自己维护时几乎总是被排在最后，然后一直没做。SaaS 把它们变成了对方的产品责任，这才是订阅费真正买到的东西。

五、动手 Demo：把群件与六个场景都列出来

# 群件：自建要维护几套东西，SaaS 要维护几套
self_built = ["邮件服务器", "反垃圾网关", "日历服务", "IM 服务",
              "媒体服务器", "文件服务器", "目录服务", "单点登录"]
saas_bought = ["一份订阅"]

# 场景判定：功能问题 vs 归属问题
def verdict(need, risk):
    if risk == "核心能力":
        return "不能外包"
    if risk == "合规":
        return "先确认再上"
    return "可以直接用" if need == "通用" else "要选型"

实跑输出：

==================================================================================================
D6 使用整个系统的 SaaS：一套订阅顶掉一堆服务器
==================================================================================================
  【一】所谓【群件】：这些功能其实常常买在同一份订阅里

  功能                自建需要什么                  用 SaaS 之后
  --------------------------------------------------------------------------------------
  邮件                邮件服务器＋反垃圾网关        Microsoft 365 / Google Workspace
  日程与会议          日历服务＋会议室预订          同一套订阅里
  即时消息与视频      自建 IM＋媒体服务器           钉钉 / 飞书 / Teams
  文件共享            文件服务器＋权限体系          同一套订阅里
  在线文档协作        要买 Office Online 类组件     同一套订阅里
  全员账号与权限      目录服务＋单点登录            同一套订阅里

  【二】六个业务场景：哪些能直接交给 SaaS

  业务场景                    能不能用 SaaS     理由
  ------------------------------------------------------------------------------------
  公司邮箱与日程              能，直接用        标准功能，没有自建的理由
  人事考勤与请假              能，直接用        通用流程，配置即可
  CRM 客户管理                能，要选型        行业差异大，挑匹配的那家
  核心生产排产系统            不太能            与产线设备深度绑定
  含客户敏感数据的分析        要谨慎            数据出境与合规得先确认
  有自创算法的计价引擎        不能              这是你的竞争力，不能外包

  ④ SaaS 的价值不在【软件便宜】，而在【省掉一整套运维】。
     代价是：流程要跟着软件的既有做法走，自定义的余地很小。
     判断标准很朴素——这件事【大家都这么做】，就适合 SaaS。

读这个输出：第一张表最该留意的是"同一套订阅里"这四个字重复的次数。它说明群件的价值不在单项功能强，而在这些功能本来就需要互相打通——自己做，打通的部分才是工作量的主体。第二张表则给出了一条可操作的线：能直接用的都是"做法通用"的事，需要谨慎的都是"你不愿放手"的事。

六、⚠️ 2026 现状

• SaaS 的定制能力明显增强。低代码配置、流程编排、开放接口、数据导出这些能力都比几年前成熟得多，"选 SaaS 就等于放弃所有定制"这个顾虑在减轻。但边界仍在那里：能改的是参数，不能改的是产品方向——你没法要求对方按你的独特流程去改造产品路线。
• 数据可携带性成了选型的硬指标。由于合规要求和业务连续性要求提高，"数据能不能完整、及时地导出"越来越靠前。实操上应该在签约前就把导出方式和格式写进要求，而不是等要换的那天再去问。
• "订阅"的成本结构越来越需要主动管理。按人月计费的订阅存在一个自然的膨胀：人员增加、功能包升级、用量超限，费用会逐月往上走。这跟自建那种一次性投入、然后折旧拉平的曲线完全不同——所以管理方式也不同：自建管采购，SaaS 管用量。

30 秒实验

打开你公司的邮箱或考勤系统，回答三个问题：

1. 上一次它升级是什么时候？ 如果答案是"不知道，反正没停过"，说明升级这件事已经不在你们的清单上了——这正是 SaaS 的日常。
2. 如果明天要换成另一家，你要准备什么？ 如果能想到的是"把数据导出来"，说明耦合很浅。
3. 它的某个流程跟你们实际做法不一样，你们改的是谁？ 是改了公司的做法去迁就软件——这就说明 SaaS 的【代价】这一栏已经在你身上发生了。

常见误区

1. 错误：SaaS 就是把软件放到别人的服务器上，功能还是一样的。——纠正：功能是持续在变的，而且是按对方的产品路线在变。自己买的软件版本停在你装的那一版，SaaS 则是每个月都在变——它既可能带来你期待的新能力，也可能带来你没要求的界面改动。接受这种"变化由别人决定"的节奏，才是用 SaaS 真正需要适应的部分。

2. 错误：能直接用的场景就不用管了，反正签个合同就行。——纠正：SaaS 时代最该管的恰恰是合同和退出。数据存在哪、能不能导出、导出成什么格式、终止服务时给多长的宽限期——这些如果不事先写清，用起来越方便，将来越难脱身。 所谓"锁定"往往不是技术上的，而是数据和流程缠得太深。

3. 错误：核心能力也可以先外包，等做大了再自己建。——纠正：核心能力一旦交出去，回来的路很长。因为在此期间你的流程、数据、团队习惯都会围绕对方的产品长起来；等你决定自建时，要做的不只是重新开发，还要把已经固化的习惯重新改一遍。通用能力可以后补，核心能力最好一开始自己拿着。

4. 错误：SaaS 更省钱。——纠正：它更可预测，但不一定更省。自建的成本主要压在前期（硬件采购）而后期递减；订阅制则是平的、持续的，并且会随人数增长而增长。规模小的时候，SaaS 通常更省；规模大到一定程度后，每月的订阅费可能超过自建的分摊成本。所以判断标准不是"哪个便宜"，而是"我的规模会往哪个方向走"。

• ☐ 下一节（2-7 是导入服务器还是利用 IaaS：物理独占、虚拟环境、备份、IaaS）

相关笔记

• 云服务的分类 —— 上一篇：三层分类的分界线
• 云服务的特点 —— 把固定成本换成可变成本，SaaS 是这条规律走到最远端的样子
• 云计算对系统架构的改变 —— 九个服务里"不宜上云"的三个，理由同样是"不愿放手"
• 是导入服务器还是利用 IaaS —— 下一篇：往另一端走，看看最自由的那一层
• ☁️ 云计算 · 索引 —— 全课路线图