SaaS的本质是什么
引言
年初跟一位做SaaS的企业家朋友聊天，讨论到国内和国外SaaS业态差异，引出了一些深层思考。
他说，国内的决策机制和市场环境下，出现了大量非标需求，导致垂类SaaS倒向了定制开发、私有化交付，很难做到一个中心的云上系统，服务大多数客户。
那么，以这种形态交付的软件服务，还能称之为SaaS吗？
最后这位朋友的结论是：只要客户不是一次性买断，而是持续给软件付费，就算SaaS。
相比于典型的中心云SaaS，哪怕半私有化交付的边际成本和获客成本更高，只要能一直收到钱，公司就能活下去，交付形式没有那么重要。
SaaS的本质是订阅。
听了朋友的分析，我不禁感慨，实践派的观点总是简单而深刻，这篇文章我们从“SaaS的本质是订阅”的观点出发，从价值流角度，分析SaaS的本质是什么。
什么时候买SaaS？
既然SaaS最普遍的特征是“为软件服务持续付费”，首先要问一个问题：为什么客户会持续付费呢？
在六阶导数解构企业经营中提到了一个常识：财务结果是对用户价值的度量，也就是说，客户觉得值得买，企业才可能盈利。
继续追问：SaaS的客户到底购买的是哪些「价值」呢？
我访谈过十几位采购SaaS的决策者，问他们到底是哪些因素，让他们选择了SaaS，而不是自研系统、传统方法手工做、外包这些方式。
下面总结了3类答案，不同的角色排序不一样，但最终都因为这些原因选择了SaaS。
1. SaaS的综合成本更低
综合看SaaS的投入产出比，一定比“全域自研”和“土法炼钢”都要高，TCO（Total cost of ownership）也比其他方案低得多。
比如常见的ZOOM、Google GSuite、WPS这类协作办公类SaaS，许可证费用才每人每月十几块到几十块钱，相比于云化前的办公文件到处传、线下到处找工位，省下了巨量的沟通成本和管理成本。
另外，相比于自研或买断，SaaS的租赁模式对现金流压力更小，再综合考虑货币时间价值、买断后的利用率这些因素，显然SaaS是综合成本更低的选择。
一般老板拍板买SaaS时，最看重的是这一点。
2. SaaS的经验起点高、迭代快
成熟的SaaS，凝结了这个领域最核心的经验，包括：
- 以模板形式提供的可复用的资源
- 以功能模块形式提供的可复制的能力
SaaS相当于租赁了这个垂直领域最关键的资源和能力。还是拿在线办公举例，买了WPS VIP后，既可以参考各种优秀的Excel/Doc模板资源，又能用云同步、格式转换这些开箱即用的能力，简直是打工人的救星。
一些对新技术采纳比较激进的决策者，不仅看重SaaS带来的经验起点，还会看重经验增量。每次版本更新，能不能解决更多实际问题？那些中小型SaaS能瓜分到行业龙头的份额，靠的就是在细分领域精准、快速迭代产生的增量价值。
一般CIO或部门领导拍板买SaaS时，最看重的是这一点。
3. SaaS能转移经营风险
不管是自研还是买断，都意味着所有使用和维护的责任都是自己承担了。而购买SaaS，意味着系统的维护责任、数据的部分管理责任、功能的安全合规性，相当一部分由供应商承担了。
承担的责任变少了，风险自然就被分摊掉了。
这点不管是IaaS/PaaS/SaaS都是一样的，区别是越靠近业务侧，供应商分摊掉的的责任和风险越多，当然潜台词是订阅价格也越贵。
合规、法务、一些相对保守的部门，采购、采纳SaaS最看重的是这一点。
什么时候不买SaaS?
访谈也得出了另一个问题的答案：什么时候不该买SaaS？
下面三种场景中，SaaS的投入产出比是不够的，因此一般会选择自研、买断、收购、外包这些“非SaaS模式”获得服务：
- 与核心业务领域强相关。既然是在核心领域，企业自己有领域专家，一般选择自建而非购买。
- 业务发展到一定规模后的垂直整合。业务到达一定体量后，上游服务的垂直整合就会变成降低经营风险和成本的重要战略方向。但一般也只是整合业务上游中的高价值、高风险的部分，大而全的盲目整合、全域自研不可取。
- 市场上存在TCO更低、ROI更高的其他方案，比如基于开源或免费软件的方案、整个职能外包的方案等等。具体选择哪种模式呢？一般是越接近底层越有倾向采纳开源方案，比如Linux、Kubernetes；越处于价值链边缘越倾向于整个职能外包，比如企业内部IT服务、财务中的账务服务等等。
SaaS价值如何产生？
搞清楚了“客户为什么觉得SaaS值得买”，我们再从SaaS公司内部组织结构做价值流分析，就离SaaS的本质更进一步了。
我们把一个SaaS企业价值链的关键部门，按照关联程度做一个聚类分析，可以找到以下三类组织。
- 跟客户沟通的
- 提供服务的
- 设计和改善服务的
1. 跟客户沟通的
这类组织冲在前线，大多数工作都是沟通。常见的组织形态有：
- Sales：传递产品和服务的价值，促成客户的采购决策
- Solution Architect (SA)：根据客户的实际问题，提供定制化的完整售前方案
- Customer Success Manager (CSM)：全生命周期的客户体验管理
- Technical Account Manager (TAM)：协助用户管理数据、提升对技术的使用深度
他们站在客户的立场上，作为客户的“业务伙伴”，发现客户面临的挑战，对外推动客户的购买和使用，对内反馈新问题和新需求。
这类组织的关键词是Discover。
2. 提供服务的
SaaS用户购买产品后，并不是直接找上面这些角色提供服务。大多数情况下是软件自助服务和人工技术支持。常见的组织形态是：
- SaaS产品本体。在不同领域衍生出各种”X“aaS, 载体可以是GUI Portal，或是没有GUI的SDK、API，甚至是内置在硬件内的系统
- Support Specialist/Service Engineer (SS/SE)：技术支持/服务工程师
这些组织提供的服务，是用户拿在手里解决问题的“锤子”。不同于买个真锤子，SaaS是软件定义的、逻辑上的“虚拟锤子”，底层的物理资源实际上是共享的。因此，SaaS对计算资源、支持人员这些物理资源的调度效率越高，也就意味着服务共享程度越高、自助服务程度越高、交付服务的速度越快。
这类组织的关键词是Deliver。
3. 设计和改善服务的
有了第一类组织跟客户沟通，就有了源源不断的输入，这些输入汇集到一个领域专家组成的产品团队，不断升级和改善第二类组织所交付的服务。
这样，一个以客户为中心的飞轮模型就搭建完成了。在输入和输出之间，承担服务流程设计和改善责任的，就是第三类组织，常见形态是：
- Product Manager：接收各方输入，抽象出解决一类相似具象问题的产品模型，用自然语言表达产品模型。
- Software Engineer: 构建软件模型，用编程语言表达出产品模型。
- UX Design：作为前两者的桥梁，站在用户体验角度，用设计语言表达出*产品模型。
这三个角色都是在做模型设计，只是表达方式和视角不同。软件的设计等于生产，一个迭代周期结束，产出就是服务流程的改进结果。
这类组织上SaaS的决策中心、经验中心、变革中心，其综合水平，直接决定了产品水平。
因此，SaaS公司非常看重构建Engineering-Product-Design铁三角(EPD Triad)，把研发团队和产品团队视为核心资产。
这类组织的关键词是Design。
SaaS三支柱模型
跟客户沟通的、提供服务的、设计和改善服务的，这三类角色的协同工作流，构成了一个创造价值的动态过程，即价值流。
借鉴人力资源管理的三支柱理论，我总结了一个SaaS的三支柱模型。
- 上面的一环是共享服务中心 (Shared Service Center - SSC），以产品形式提供自助服务的入口和接口，聚焦Delivery。平台化做的比较成熟的也可以叫共享交付中心(Shared Delivery Center - SDC)。
- 下面左侧的一环是业务伙伴 (Business Partner - BP), 是连接客户与软件服务商的桥梁、信息沟通的渠道，让客户不仅能把软件用起来，还能用的好、用的深。
- 下面右侧的一环是专家中心 (Center of Expertise - CoE), 是SaaS冰山下的核心能力，不断吸收和抽象来自客户的、市场的、技术领域的输入，在团队中和软件中不断沉淀新的经验，不断提升软件服务的价值。
按这个定义方式，任何一个SaaS公司的岗位，都能划分到三支柱中，比如：
- 服务运维(DevOps)、Technical Writer团队属于SSC
- 发布管理、TPM、QA等团队属于CoE
- Marketing、PR等团队属于BP
比较特殊的是 HR，Finance & Accounting，Security、Legal 这些公司职能部门，他们本身就是一个具备完整三支柱的服务单元。其实三支柱模型理论就是先在人力资源、财务这些完整的服务部门发展应用起来的。
类比一个人，CoE是大脑、SSC是四肢、BP是五感。
类比一个细胞，CoE是控制整个细胞结构的细胞核，SSC是有各种功能的细胞质，BP是接受和释放调控信号分子的细胞膜。
SaaS三支柱模型能解决什么问题？
1. 诊断服务质量问题
这种对SaaS的理解方式，最直接的作用是帮助我们发现哪里薄弱了、哪个角色缺位了，是做咨询诊断的好工具。
如果一个SaaS的服务质量有问题，从“问题在哪里”这个开放性问题出发，做好访谈、问卷、调查，就能逐步收敛到三支柱中的一些非常具体的因素。比如：是CSM管理了太多客户沟通不够、还是没有在工作中建立和CoE中PM团队的定期会议反馈问题？是产品团队的工程师能力问题开发速度太慢，还是因为没有重视用户反馈在闭门造车？是支持团队没有对产品有足够的理解解决不了用户的Ticket，还是产品本身有太多隐藏逻辑导致了用户和支持人员都没法自助服务？
举个我经历的例子，公司内部有十几个内部平台和中间件服务，但这些“内部SaaS”的成熟度不够、用户满意度不高，导致业务交付速度慢，市场竞争力难以提升。我们从去年年中开始，想办法解决这个问题。
一圈问卷调查和访谈下来，定位到主要问题在于BP和SSC两个支柱很薄弱，当时，60%以上的人认为没办法找到服务的支持人员、文档质量太差无法自助上手使用、服务不稳定等等。
再深入一层细节，看到是文档写了但很散乱、过时的比较多；支持人员是有排班的，但对人工支持的SLA管理没有闭环，没办法端到端解决用户问题等等，不展开了。
诊断完了，解决方案就有了。我们在SSC这一侧，构建了新的结构化的、集中管理的、AI自动问答的内部用户文档中心；在BP这一侧，构建专门的运营小组，做真正的SaaS服务的CSM、Solution Architect的事情，以服务为本，用数据说话。
一年多后，用户满意度已经有比较明显的提升。
这段经历让我理解了解决服务管理问题的朴素思路：对照着理论模型，搞清楚现实挑战，再收窄到几个主要问题，把缺的地方补上，掉在地上的事情捡起来。
2. 构建高效的CoE
三支柱模型有个有意思的地方，在CoE的内部，竟然套娃了另一个三支柱模型。
上面我们提到组成软件产品研发团队最关键的三个岗位 Engineering-Product-Design，EPD-Triad 正好和SaaS服务整体三支柱相对应：
- Engineering，代表了沉淀在软件里的领域经验，关注如何用软件模型本身的结构，是CoE中的CoE视角，
- Product，代表了从客户反馈提炼的产品迭代方向和目标，关注如何用产品帮助客户解决问题，是CoE中的BP视角，
- Design，代表了服务的用户交互流程，关注如何让自助服务的体验最优，是CoE中的SSC视角。
世界是分形的。理解CoE内部的这种分形结构，对实际工作有什么意义呢？
我认为理解本身就是意义。
理解了各方的立场，就能够促进各方高效协作。
很多软件公司经常遇到PM和工程师冲突、UX Design在前端实际用不了、工程师产出和实际需求脱节，这些都是没有正确理解CoE中这EPD三个角色的思维模式和分工意义导致的。
举两个常见的例子：有些工程师等着产品完全设计好才开始思考，只做一次把需求翻译成编程语言的工作，完全不关心用户目标、场景、满意度；有些交互设计师对业务领域了解很少，甚至没有完整用过产品，只是拿着PM的需求文档转换成设计稿。。
这两种情况都说明领域专家缺位，Designer停留在UI设计而非UX，Engineer停留在码代码而非解决工程问题，这种模式下，团队很容易产生冲突，产品质量一定不好。因为他们都没有真正成为领域专家的一员，只做了翻译的工作，没有用设计语言、编程语言做创造的工作。只把技术当一门手艺的人，在职业发展上是走不远的。
反之，真正理解了自己处在一个服务组织的CoE价值链之中，持续沟通、通过构建模型不断解决领域问题的，成为领域专家的一员，往往能走得很远。
3. 设计有效的沟通架构
沟通架构可能是公司治理中最重要的一环，三支柱模型可以指导新的服务部门或SaaS公司的顶层设计，因为 Discover-Design-Deliver三支柱之间的信息流转方向，就是沟通架构设计的最优解。
在软件行业有一个“康威定律”，本质上就是沟通架构决定产品架构，一旦沟通结构错了，产品一定会变形。
大公司病也是从沟通病开始的。基层员工缺少战略地图引导和跨职能沟通，长此以往便看不到价值链的全貌，只关注自己做什么，不关注大目标是什么。这种微观问题在宏观上的表现，就是目标和任务颠倒、部门墙出现、内部协作成本剧增、公司整体发展停滞。
比如，如果CoE中的PM，和BP中的CSM、SSP中的Support 没有常态化的双向沟通，那么产品迭代一定会出问题。CoE中的Engineer和SSC中的DevOps如果没有常态化双向沟通，服务的可用性和交付速度一定会出问题。
因此，管理者在辅导团队成员制定OKR的时候，一定要把在沟通架构中与之协作的角色纳入考虑，将双方或多方共同达成的目标列入OKR，而不仅是自己所在职能的单一目标，再让目标来引导出正确的沟通架构。
三支柱模型本身就是顶层的沟通架构，能够指导局部的管理实践，让每个局部之间的沟通架构有效运转。每一层的沟通架构对了，就能防治“康威定律的诅咒”和“大公司病”。
总结
本文从SaaS的持续订阅这个关键特征出发，分析客户为什么买SaaS，再分析一个SaaS企业的组织结构，推导出三支柱模型，最后讲了怎么用三支柱模型解决实际问题。
回到对SaaS本质的理解，我认为下面三个说法都对，只是看待概念的视角不同。
SaaS的本质，是订阅。
SaaS的本质，是一种以软件为中心的、CoE, BP, SSC三支柱共同组成的 Discover-Design-Deliver 业务模式。
SaaS的本质，是一种由领域专家构建的、持续迭代的、能够让用户自助操作的软件系统所提供的服务。