SaaS 已经说不通了
软件即服务诞生于一个前提：开发软件的成本太高，唯一能让它变得负担得起的办法，就是只做一款产品，再卖给成千上万个组织。这些组织接受了这笔交易：用上便宜、即开即用的软件，代价是按照软件规定的方式工作。
二十年来，这笔交易一直划算。如今不再如此，原因有三。
成本
组织按用户、按模块、按套餐付费，月月如此，连没人用的功能也要买单。此外还要请顾问来配置，做集成来对接其他系统，升级或新增功能时还得额外付费。
僵化
它是为一般水平的客户设计的。各个组织只能让自己的工作方式去迁就软件，凡是对不上的部分，最后都落到电子表格和手工操作上。
人工智能
支撑 SaaS 的那个前提，即量身定制的软件造价太高，已经不再成立。如今，一个组织自己的系统几天或几周就能建成，几小时就能修改。
过去，SaaS 之外唯一的选择是委托定制开发：前期投入高，周期长，而且交付之日即告定型。夹在这两条路之间的，是大多数中小企业，只能凑合着用手头的工具：手动回复 WhatsApp，逐一确认预约，在彼此不通的系统之间来回复制数据，还要指望团队里有人把所有事情都记住。
核心论点
TMaaS 将取代 SaaS。
如果开发和修改软件的成本只剩过去的零头，所有组织就再也没有理由使用同一套软件。每个组织都可以拥有自己的系统，为自身运营而打造，并持续演进。
有了 TMaaS，组织不再购买一个封闭的产品，也不再委托一个有截止日期的项目。它拥有一套为自身运营打造的系统，运行在独立部署的环境中，随组织的变化而变化。它得到的是服务的连续性，与 SaaS 一样；但又按自身尺寸剪裁，如同在裁缝铺里定做衣服。
这个名字沿用了 Software as a Service 的结构，只换了一个词。以服务形式交付的，不再是人人相同的软件，而是为每个组织量身定制的软件。
取代什么，不取代什么
TMaaS 取代的是应用层的 SaaS：CRM、预约排期工具、客服收件箱，以及那些迫使组织按它们的方式工作的管理软件。基础设施类服务，如支付、消息、云服务乃至 AI 模型本身，仍然是共享的基础组件。TMaaS 系统正是构建在它们之上。
为什么是现在
定制开发的问题从来都在于成本，而不在于价值。昂贵的是人力：编程、测试、编写文档和维护。
AI 编程智能体改写了这笔账。一个借助 AI 工作的小团队，几天或几周就能完成过去需要几个月的工作，几小时就能完成过去需要另立项目的修改。
这带来三个后果：
- 拥有自己的系统不再是奢侈。过去只有大型组织才负担得起的东西，如今任何组织，无论规模多小，都触手可及。
- 变更不再是项目。修改系统的成本低到可以持续进行，随组织的变化随时调整。
- 瓶颈发生了转移。难点不再是写代码，而是深入理解每个组织，决定要构建什么，并为上线的一切负责。
这正是 SaaS 无法企及的优势。它的模式依赖于所有组织使用同一样东西。当为每个组织做出不同的东西只需很低的成本时，将就于通用方案就不再说得通。
在 TMaaS 中，人的工作集中于理解、决策和担责。其余的交给 AI。
原则
七条原则，将 TMaaS 与 SaaS 以及传统定制开发区分开来。
-
I
软件适应每个组织
每个组织的规则，比如如何接待、收费、确认或转介，都是出发点，而不是别人产品里的一个配置选项。
-
II
共同基础，定制层
每个系统都构建在一个经过验证、共享的基础之上；每个组织特有的部分则放在单独的一层中。没有共同基础，这种模式不过是换了名字的外包公司。没有定制层，它就只是又一个 SaaS。
-
III
每个客户，独立部署
每个组织都在自己的环境中运行，数据彼此隔离。为一个组织所做的改动不会影响另一个。
-
IV
系统随组织演进
TMaaS 系统不是交付之后就此定型。它持续变化，与所服务的运营保持同一节奏。
-
V
数据属于运营者
运营过程中产生的信息，属于产生它的组织，而不属于构建系统的一方。
-
VI
人来负责，AI 来构建
AI 负责编程、测试和编写文档。人负责理解每个组织、做出决策，并审批上线的内容。始终有人对结果负责。
-
VII
前后都要衡量
每个系统都从其意在改善的指标基线起步。这样就能检验，量身定制的系统是否胜过它所取代的通用软件。
对比
TMaaS 汲取了两条传统路径的长处：SaaS 的连续性，以及定制开发的贴合度。它也摒弃了两者的短处：前者的僵化，后者的过时。
| SaaS | TMaaS | 传统定制 | |
|---|---|---|---|
| 谁来适应 | 客户适应软件 | 软件适应客户 | 软件适应客户，仅此一次 |
| 代码 | 同一套代码，成千上万家共用 | 共同基础加专属层 | 从零开始构建 |
| 首个版本 | 即时可用 | 几天或几周 | 几个月 |
| 变更 | 由供应商决定 | 持续进行，由组织驱动 | 每次都是新项目 |
| 部署 | 所有客户共用 | 每个客户独立部署 | 每个客户独立部署 |
| AI 的角色 | 又一项产品功能 | 构建与维护的方式本身 | 加快项目，但不改变项目 |
循环
TMaaS 系统并不随交付而终结。只要组织还在使用，它的构建就会循环往复。
量体
观察组织如何运营：它服务的每一个人如何找上门来，预约、收款、确认和转介如何处理。记录它的规则，并测量基线。
裁剪缝制
在共同基础上构建，并与组织已在使用的工具对接。第一个版本在几天或几周内即可上线。
调整
组织的团队随着运营的变化提出修改需求。修改经过构建、测试和发布，然后重新衡量一切。
剖析
TMaaS 系统是分层的。层级越低，共享程度越高；层级越高，越贴合每个组织自身。
定制层
按客户规则、工作流程、专门集成、沟通语气和定制报表。
行业模块
按行业同一行业的组织所共有的部分。以医疗为例：预约排期、确认、提醒和预付款。
共同基础
所有客户共用消息渠道、共享收件箱、用户与权限、报表、变更日志和部署。
独立部署
按客户每个组织拥有独立的环境和数据。
让这个模式运转起来的规则是：为一个组织构建的东西，如果也能服务其他组织，就上移到行业模块或共同基础中。这样，每一套新系统都会比上一套建得更快。
适用对象
适合
- 拥有独特流程、SaaS 不打补丁就无法覆盖的组织。
- 目前依靠 WhatsApp、电子表格和手工操作维持的日常运营。
- 规则特殊的行业：医疗、教育、专业服务、自产自销的零售。
- 凡是同时使用多款彼此不互通的 SaaS 工具的组织。
不适合
- 一次性项目，且预期不会持续演进。
- 从第一天起就需要完全自行运营一切的组织。
- 需要特定资质认证、而构建方并不具备的受监管系统。
开放问题
这是一份论纲草稿。以下问题目前还没有定论。
- 各类组织会以多快的速度离开现有的 SaaS？阻碍转变的又是什么：合同、数据，还是习惯？
- SaaS 巨头将如何应对：是向定制开放自己的产品，还是在新系统面前节节失地？
- 量身定制的调整与一款新产品之间，界线在哪里？
- AI 能在多大程度上减少理解和维护每个系统所需的人力？
- 同一行业的一群组织，到什么时候实际上就变成了一个垂直 SaaS？