亚马逊AWS官方博客
业务SaaS化中的五种误区
背景
随着软件即服务 (SaaS)近些年的兴起，传统的行业头部公司基于自己对行业的洞察理解以及解决方案转换能力，逐步有了能力服务化输出的诉求，使得SaaS模式在2B端兴起。根据外部调研机构对来自SaaS公司的 200 名决策者的调查，他们的首要答案（25%的受访者做出了回应）是他们会更快地进入SaaS以获得与这种交付相关的回报模型。但即使在SaaS方面拥有丰富经验的高管表示，回首过去，他们会采取不同的做法来改善公司的SaaS之旅。
业务SaaS化过程中既有对现有服务模式的转变也有对未知领域的探索，通过对成功驾驭这一转型的组织的关键经验案例总结，来探讨阻碍SaaS化成功的几种典型误区。在这里我们将专注于SaaS Journey Framework的业务规划阶段面临的常见挑战。
什么是SaaS
SaaS（software as a service），软件即服务，是一种全新的交付、交互、订阅模式的在线软件服务。SaaS的概念最早由Salesforce在1999年首次提出，历经Web1.0和2.0的迭代升级，在2011年SaaS迎来交互端的巨大变革——移动化。基于移动化，SaaS的连接属性愈发强化，同时业务场景指数级涌现，让SaaS的覆盖范围和服务边际远超传统套装软件。
既然SaaS定义为一种服务，从服务的可达性、服务的部署方式、服务的标准化、服务的付费模式，通常具有以下特征。
业务SaaS化旅程模型
通过亚马逊自身经验及在帮助客户转变其SaaS业务的过程中观察到的模式和策略，我们总结了SaaS化旅程的框架模型。该框架是一个动态的工作过程，不一定是线性的。例如，在制定产品策略时，您可能会重新审视您的业务案例并进行更新。一些活动可能同时进行。整个旅程包括以下4个阶段。
-
业务规划
在开始考虑SaaS化之前，需要制定一个清晰的愿景，以捕捉并传达战略的基本要素。愿景的抽象过程可以借鉴业务分析6步领域建模法的第一步——业务愿景对齐。此过程将用于验证战略的关键组成部分，并将它们连接到说明SaaS化如何满足业务需求的模型。对于一些公司来说，路径和战略可能相对简单。在这些情况下，收集的数据为塑造前进道路奠定了基础。对于其他情况来说，困难的部分不是学习新技术，而是克服旧的计划、流程和对行业变化缓慢的系统进行优化。但无论从哪里开始，采用的策略都将植根于良好的数据。
-
产品战略和路线图
虽然业务规划阶段使您能够评估整体机会，但它只定义了高阶产品战略和路线图。一旦决定继续前进，就需要开始更详细地了解产品将是什么样子，以及将如何有效地瞄准市场的特定细分市场。正如我们之前提到的，旅程框架是非线性的，在某些情况下，产品愿景可能会先于业务规划。在此阶段，我们将集中精力为产品建立更完整的愿景以及我们希望为客户提供的体验。产品战略和路线图将回答关键问题，例如我们的目标用户和买家角色，我们希望他们从系统中获得价值的地方，以及客户使用该解决方案的不同选项。这些数据对于开发团队落地执行完整的业务和技术愿景至关重要。
-
最小可行性服务（MVS）
一旦建立并验证了业务规划和产品战略，就需要开始考虑在SaaS产品的首次推出中将包含哪些内容。最小可行性服务 (MVS) 是产品的第一个版本，具有足够的功能来有效地部署产品并吸引早期使用者在产品中留下他们的足迹，然后再将其成功出售给大众市场。在获得理想的产品/市场契合度之前，这是一种为未来产品开发收集早期用户反馈的经济有效的方式。这种策略在SaaS模型中尤为重要，它提供了在客户的整个生命周期中反复与客户互动的机会。在这个阶段，业务和技术方面的交付团队正在确保生产和运营服务所需的部分。对于不同的公司，这项工作可能看起来完全不同。对于其中一些来说，这可能是为了开始SaaS化而奠定基础的变化范围。对于其他的来说，这将更多地代表向市场提供某些东西所需的最小功能集的特性。
-
发布上市
旅程的最后一步是推出SaaS产品。这是一个需要定义明确的上市 (GTM) 战略的领域。每个将新SaaS服务推向市场的计划都需要了解客户角色（购买者和用户）、销售策略以及吸引新客户的营销计划。然而，SaaS GTM战略不会随着新客户的获取而结束。它必须跨越整个客户生命周期，包括保留和增长阶段。
SaaS业务规划：阻碍成功的5个误区
基于多年的AWS经验以及数百名AWS合作伙伴的反馈，我们总结了阻碍SaaS成功的五个常见误区。虽然这些还不是应该考虑的全部，但却是最常见的几类。
-
误区1：将SaaS视为一种技术战略
在AWS re:Invent 2019 上，Andy Jassy 谈到了数字化转型、公司如何进行自我转型以及如何重塑业务和客户体验。 “转型的第一个要素”，他说，“不是技术，而是领导力。你需要让你的领导团队保持一致，并坚信你将做出这种改变。”
许多组织从技术开始讨论，启用SaaS并享受该模型带来的价值应该考虑哪些架构因素？实际上，如果要转向 SaaS，实际是在做出业务决策，因此需要从所有技术问题中退后一步，从业务的角度思考，以及成为SaaS业务意味着什么。这是业务模式转变之初应该考虑的地方：这种模式将如何帮助发展业务、加快创新、保持领先于竞争对手并提高客户忠诚度？
-
误区2：认为有很多时间
在业务SaaS化过程中组织面临的第二个挑战是他们有一个非常漫长的多年转型过程。他们认为他们有一个专属市场，拥有良好的客户基础和稳定的收入来源。然而，挑战在于他们无法在如此长的周期时间内获得良好的客户反馈。在一个长期的多年计划中，使得其他竞争对手有机会出现并开始获得行业市场，最终可能会发现自己处于了追赶对手的窘境下。
Cohesity曾在AWS上将他的数据管理即服务 (DMaaS) 作为SaaS发布，简化了数据管理。从Cohesity首次推出DMaaS服务的内容我们可以发现：他们当时专注于旨在为潜在客户创造价值并加快上市时间的初始用例。这种方法帮助 Cohesity 快速验证潜在机会并根据客户反馈调整产品路线图。
你需要尽快尝试获得最小可行性服务 (MVS) 以测试你的假设。使用MVS方法从早期使用者那里收集数据和反馈，了解是否构建了正确的功能，以及是否创建了正确的客户体验。在客户有机会接触产品之前，避免过度优化产品以使其“完美”。毕竟，客户反馈可能会引导走向完全不同的方向。
-
误区3：敏捷性投资不足
SaaS 交付模式的最大优势之一是敏捷性，能够缩短开发周期、加快创新并快速响应市场动态。要达成这一目标，需要从旅程的第一天就开始投资敏捷性；它应该是系统的核心价值。其实，这也正是由于SaaS业务模式的特性所决定的。区别于传统软件，SaaS化服务面向的订阅-租户模式，需要服务于众多客户——少则几十家，多则几万家。不同用户间既有共性需求，但也不乏个性化需求。在以最小化成本前提下实现快速、多元化业务适配，需要在敏捷性的各个方面有准备和投入。
业务敏捷性。业务敏捷从广义上来讲，要求企业/组织中的每个人都参与到价值交付过程中。包括：业务和技术领导者、开发、IT、法务、市场、销售、财务、合规、安全等角色和团队。在SaaS中的业务敏捷性，通常是谈论需求的抽象度和转化效率。这就要求在业务SaaS化之初进行基于用户旅程地图分析的业务领域建模，这种建模方式能很好的帮助我们进行业务抽象和聚类。
技术敏捷性。技术敏捷的核心要义就是能够支撑业务敏捷，通常包含完整的自动化构建和发布流水线、自动化测试能力、以微服务模式实现的技术架构和智能运维监控。在SaaS化的技术架构中，通常我们需要考虑以下几个方面。
-
误区4：缺少软件即服务中的“服务”
向“即服务”模式的转变是富有挑战的。一些公司停留在产品思维模式中，他们认为这是他们为客户打造的产品。在转向服务思维时，需要检视整体客户体验，包括对问题的响应速度、如何与客户互动以帮助他们使用功能并扩大其使用范围，以及提供的运营敏捷性，而不仅仅是交付产品本身。BMC Software就成功推出了他们的“应用程序工作流程编排即服务”平台。BMC成功背后的秘诀之一是接受即服务的理念。BMC深入了解用户旅程，专注于客户成果，并在市场推广(GTM)和客户成功模式上逆向工作，从而创造了出色的客户体验。
-
误区5：延迟业务转型的启动
正如在第一个误区中提到的，许多组织将转向SaaS视为一种技术战略。这种想法的一个副作用是他们一开始就开始致力于技术开发，然后才考虑它将如何影响组织的其他部分。这包括销售和营销将如何变化，以及需要进行哪些其他组织调整以适应新模式。很多时候，延迟业务战略最终会成为SaaS化运营组织的挑战。这就是为什么希望在开始开发的时候来对齐业务和 GTM计划的原因。
业务SaaS化的实践
正如上文所述，从传统软件产品模式到“服务”化模式，其实不仅仅是一个技术变革问题，其还涉及到思维认知、业务建模和敏捷能力等方面的问题。通过过往项目中的总结，对业务SaaS化过程中常见的几类问题的破题实践进行了总结。
-
业务领域建模
业务SaaS化旅程的关键核心和起点来自于业务愿景和规划设计，通过对用户旅程的深入理解形成产品能力的抽象和业务领域建模，以MVS的方式进行验证并对SaaS服务进行增量迭代。但难点在于怎么准确定义出SaaS业务的产品愿景并基于愿景产出业务领域建模和MVS的设计。这是一个从宏观到具象，从具象到抽象的过程。整个过程要充分运用如设计思维、干系人地图、用户画像、用户旅程等现代化的业务分析工具，同时结合领域驱动设计方法进行业务领域划分。从业务愿景出发到业务领域建模，并找到有价值的最小业务闭环进行模型验证，我们总结了一套6步分析建模法。
-
SaaS+PaaS
SaaS的好处显而易见——对于成熟产品可以快速而又简单的使用，帮助企业降低成本，增加利润，避免重复造轮子。但是，SaaS平台也有弊端，那就是SaaS多数只能满足共性需求。对于无法“在功能层进行标准化”的功能，我们就需求想办法在开发层进行标准化，即通常我们所说的PaaS。如果一家SaaS决意要做大，PaaS能力就不是可选题，而是必选题。所以在架构设计的初期就应该充分考虑PaaS能力的引入，可依托成熟的PaaS体系产品来架构自己的“低代码”能力。
-
AWS SaaS Factory
当然也有一些传统企业想在数字化浪潮当中积极拥抱SaaS，以便在自己的传统赛道当中对比竞争对手形成差异化优势。但是，SaaS化能力对于这些传统行业企业来说，是个新鲜却又遥不可及的事物，他们需要的是SaaS旅程模型下的全生命周期能力。对于这种情况，最佳的方式是依托完整的解决方案，AWS SaaS Factory正是其中一种好的实践方式。
AWS SaaS Factory计划可为任何企业在软件即服务 (SaaS) 之旅的任何阶段提供帮助。无论是希望构建新产品、迁移现有应用程序还是优化SaaS解决方案，AWS SaaS Factory计划都可以提供帮助。该计划提炼了不同行业、地区、细分市场和规模的企业的规范性业务和技术指导的最佳实践，汇集了SaaS内容、工具和嵌入式资源的最佳组合，可以提供指导、方向和专业知识，以加速和最大限度地发挥SaaS解决方案的潜力。AWS SaaS Factory计划提供的价值包括：
提升SaaS知识。富有SaaS实施经验的业务架构师和解决方案架构师可以利用这些成熟的经验来帮组开发业务和技术最佳实践，这些先进思想也将帮助客户提高有关SaaS的知识。其中，AWS SaaS Factory Insights Hub还涵盖了在规划、构建和优化 SaaS交付时要观注的独特业务和技术内容。
利用现成的资源。每个个案在SaaS之旅中所处的阶段都各不相同，这就是为什么需要充分利用现成可用的资源、工具，并且还要与网络生态系统的其他部分联系起来。例如AWS SaaS Boost，或AWS Quick Start和架构完善工具SaaS Lens。
参考文献
https://aws.amazon.com/cn/blogs/china/business-digital-analysis-and-business-domain-modeling-design/
https://pages.awscloud.com/NAMER-field-OE-SaaS-Behind-the-Scenes-Webinar-Series-2021-reg-event.html
https://aws.amazon.com/partners/programs/saas-factory/