腾讯数据平台 SaaS 化实践

腾讯灯塔小明

发布于 2023-03-30 11:10:23

1.2K0

发布于 2023-03-30 11:10:23

文章被收录于专栏：敏捷分析敏捷分析

丨导语丨

To B行业无法回避的客户定制化需求是否有更好的满足方式？本文将分享关于数据平台 SaaS 化和开放能力建设的一些思考和实践。

主要包括三大部分内容：

1. 数据平台 SaaS 化建设的机遇与挑战

2. 更好地满足定制化需求

3. 数据产品工作思考

作者｜李子坤腾讯产品经理

一

数据平台 SaaS 化建设的机遇与挑战

1、销售驱动 VS 产品驱动

最近在 SaaS 领域比较火热的一个名词是 PLG（Product-Led Growth），即产品驱动的增长。这和 2010 年之前的销售驱动模式的差别还是比较大的。

销售驱动模式具有如下特征：

第一个特征是主要面向大客户、做的是大项目，一个项目的成交金额可能会到千万级别，甚至有些非常大的集团公司能达上亿。

第二个特征是这样的项目客户来购买服务时的要求是不一样的，为他们提供 SaaS 服务的供应商通常会派出专门的售前、售后的销售团队来贴身服务。

最后一个特征是站在用户视角或者说站在产品经理视角，产品真正的使用者和真正决定购买这个产品的决策者之间是分离的。

我们来看一个具体例子，左图为 Garter 总结的以 B2B 销售为主体的销售模式的路径图，从准备立项到招投标，接标后开始分析甲方客户的需求清单以及业务问题，再到项目交付验收，整个过程非常复杂。其中涉及到的甲方用户也是来回转换的，首先是采购部门发起采购流程，在中途会引入一些业务专家或是真正的使用部门来评估和罗列需求清单，最后会由管理层来进行排版。在这个过程当中，需求转了两三道，在决策时考虑的因素就会融合很多其他的和最终使用者不太相关的因素。这是由行业特征所决定的，销售团队需要针对一个客户投入大量的资源和精力。

再看产品驱动的模式，这是外国的一个投资公司总结的 SaaS 化的市值规模（右图所示）。在 2020 年之后，SaaS 企业的市值和规模是突飞猛进的，其主要特征是：

基于公有云服务于中小型公司成为了可能，在中小型公司大量兴起之后，需求也越来越多，意味着 SaaS 化的服务模式以及服务需求场景也越来越多。在规模变大之后，一个企业或者说一个独立的开发者就可以针对单点问题来提供 SaaS 服务，所以整个的需求量级以及卷入的开发资源甚至共建者都会越来越多。

第二点是，中小企业成为了需求的主力，基于成本的考虑，原来的销售模式肯定无法提供贴身的服务。

第三点是，在做产品设计和打磨的时候，就真正的需要解决一个特定的场景问题并把它打磨透。当产品开始真正地解决用户问题了，用户就会主动地体验选择或者进行口碑传播。产品使用者这时候已经可以反向影响企业的订购决策流程了，比如说某一个专业岗位设计师，可能自己会尝试使用 Figma，然后反向督促企业的采购部门来采购 Figma（企业版）。这样的服务模式对于产品的要求更高，但是可能会压缩销售成本，让我们更集中精力打磨我们的产品，这也是行业发展的趋势。

2. 中外行业发展差距

我们来看一下中外行业的发展差距。18 年之前 ToC 领域是非常火热的，像美国的 Amazon、Google 和 Facebook，中国与之对标的阿里巴巴、百度和腾讯，至少量级上来说是旗鼓相当的。但是 ToB 领域，美国微软比较老牌，其他的新生力量像 salesforce 和 shopify 这种实质规模可达千亿级或百亿级，它们都是在美国已经站住脚的头部 SaaS 供应商。目前在中国这一部分还稍显空白，阿里云、腾讯或者字节也在开始搞这种平台化的云服务，但并不是非常纯粹的 SaaS 服务，可能是打包售卖云上的基础设施来捆绑 SaaS 软件。

3. ToB 行业差距影响因素

总结起来 ToB 领域中的差距还很明显，我们需要思考为什么会有这样的差距，大概有以下四方面的成本可能会影响企业的决策和 SaaS 从业者的选择：

第一项是合规成本。对于外国尤其是欧洲企业，合规要求会非常高。作为供应商是不能出错的，供应商需要把这个领域的合规要求吃透站稳脚跟之后再提供服务。例如美国企业有一个特征就是大企业的供应商链条就是一个大企业，像特斯拉或苹果，它的供应商上下游的链条可施加的影响力不管是硬性的还是软性的，都是非常强大的。比方说特斯拉或苹果的某个业务领域使用你的 SaaS 服务满足了其需求，可能它上下游的供应商会跟随来采购，使用你的产品，这样会有更快的交付。此外，监管处罚力度也是比较大的，如果没有合规到位，就无法生存。

第二项是宽带成本，可以对比 ToC 和 ToB，对于 ToC，前几年对于三大运营商一直在提一个“提速降费”，相当于是把 C 端用户的流量成本降到了非常低的价位。因此，用户上涨成本低了，线上化的使用场景成为了可能，由此催生了国内一大批 ToC 的企业。但是对于 ToB 来说，这部分宽带成本还是非常高的，比如我们内部在做 SaaS 服务的时候会调研技术方案，在调研技术方案的时候，就不得不评估到企业的流量带宽成本，即它的数据上报量。哪怕是做了一个 Demo 的活动也需要评估带宽会不会耗费太多的成本。转换一下，在面向真正的中小型企业采购者时，同样也需要考虑带宽成本，如果这个成本很高，下次服务可能就不会来了。

第三项成本是直接相关的人工成本，它是一个替代成本。中国的人力成本相对还是比较低的，虽然最近几年工资成本有所提高，但是整体相对美国还是比较低的。目前甲方老板默认的思考路径是对于新问题如果投入人力能解决就投入人力来解决，但是美国人工成本比较高，可能这个路径就堵死了。另外，我们真正在部署 SaaS 项目的时候，需要考虑到企业内使用这个 SaaS 产品的用户的磨合成本。这个磨合成本是指，可能需要转变之前的工作模式和之前使用工具的习惯，甚至整个工作流程都需要重构，磨合成本尤其在初期会非常高。这一部分可能也是无法避免的，但是在真正的提供这种服务的时候，如果考虑不到位，可能真正落地的时候就会无法往下走下去。尤其是对于现在，SaaS 化、PLG 是一种订阅式的服务，可能第一年能够靠品牌或者人脉让客户采购一年，但是后面的留存或者付费比就会下降，所以这个磨合成本在项目实施过程中需要考虑。

第四个就是实施成本，我们如果能够提供标准化的产品，对于供应商来说成本是最低的。但是对于采购方来说，他们在选购服务的时候，首先要考虑的是自己的需求，这个和企业的治理结构有关系。我们提供 SaaS 服务时就需要考虑到这些采购者的不同特征。另外，在国内，业务发展比较快、需求难以固化，为提供一个完全标准化的 SaaS 服务带来了困难。对于甲方来说，或多或少会需要有一些定制化或者需要适配改造的地方，所以这些因素会造成中国 ToB 行业的 SaaS 服务发展比较慢。

4. SaaS 行业的挑战与机遇

SaaS 行业既有挑战也有机遇。

首先看一下挑战，大客户和大项目定制化、快速能够实现收入是主要的商业特征。但是如果提供 SaaS 服务可以更好地满足中小企业的需求，而且能够沉淀标准化的产品解决方案，那么长期来说，收益肯定是高于私有化部署或者定制服务于某一个大客户的。要综合考量行业特征，判断到底是走什么样的产品建设路径。短期来说，可能会投入比较高、见效比较慢，那么是否能够有足够的资源和底气沿着这条路径走下去很关键。国内的大型和中型的 SaaS 服务商的决策逻辑都会有一些区别，所以需要理解行业的客户特征来做最终的决策判断。

除了挑战之外，行业也有一些机遇：

首先是疫情的影响，不管是纯粹的互联网公司也好，还是偏传统的企业也好，远程办公和在线协作的诉求都是越来越强的。

第二，平台生态的发展，很多企业已经购买了钉钉或者飞书，逐渐培养起了员工的使用习惯，并逐步接受基于公有云和 SaaS 化的方式来提供工作工具的服务。

最后，IM 平台为中小 SaaS 服务提供商提供了一个更快速变现的窗口。相对来说，如果没有这样的平台，中小 SaaS 服务商来做获客或口碑都是非常困难的，可能需要花费非常大的精力。如果融入 IM 平台，都有应用商店，相对来说起步会更容易。由于 IM 平台是一个开放性的模式，所以对于各个 SaaS 的服务商来说，他们的产品也是需要打磨到至少是有亮点的，即客户使用之后能让一部分用户留存下进行后续的付费转化，这是现在中国行业的一个特点。

最后说到 SaaS 产品的建设，目前阿里云和腾讯云这样的大平台，会包装非常多的套餐或套件，类似于全家桶的服务模式。在国外可能单品突破的会比较多一些。下图中的右图是一个例子：在做 PPT 或者官网页面的时候，一般会放企业的 Logo 墙，而这个产品就是只做这一件事，你只要输入企业的网址，它就能自动爬取并生成对应的企业 Logo 各个像素、各个规格的 Logo 图片，试用之后可以按照包年或包月的方式付费。

目前来看，这种服务模式在国外是能生存的，中外这两方面的差别还是挺大的。站在中国角度来说，可能未来的探索方向是以产品矩阵为基础，对于一个行业的客户来说，我们有相应的服务包或产品包来覆盖其各种各样的需求。但是对于不同的客户，希望能够达到一种可拆可合的状态。这样至少能够对接到客户，也能够更好地满足客户，这是可能的一个探索发展路径。

最后一个机遇就是用应用商店的模式，主要有三个特征：

第一个特征，像 salesforce 是一个非常典型的例子：它最开始是基于 CRM，后面扩展了非常多的服务能力。它的应用商店非常开放，客户也可以成为 SaaS 服务的开发者。这会让客户产生成就感，对客户来说是很好的驱动力。这不再是单纯的之前那种销售驱动的模式，客户生怕被坑蒙拐骗从而要来严格把控提供商提供的功能清单有多少功能，虽然某个功能客户可能不需要，但是如果缺少功能，客户就觉得自己吃亏了。而新的服务模式是客户自己进入到这样一个生态体系内，自己做一些插件或者服务，对于自己的成就感、自己企业的品牌传播以及解决方案的沉淀和分享都会有一定的促进作用。

第二点是选购的灵活性，这个是完全站在交易的视角或者说企业的采购视角来说的，客户来购买产品的时候肯定是希望以最低成本来买到最多的功能或者说能够更好地解决企业问题。如果能够加灵活的组装形式，那成本就不会非常高。

最后一个是，我们可以把整个行业的生态建设得更好一些，引入更多的独立开发者或者说第三方的中小 SaaS 服务商来贡献自己的力量。在整个生态搭建起来之后，比如在数据分析领域或者说数据平台领域，我们可以通过基础的产品服务包，加上各种各样的开发者贡献的能力集合，去更好地服务于企业的需求。对于 SaaS 的供应商、企业客户和独立开发者，都是三方共赢的。

5. 数据平台 SaaS 化的优势

回到数据平台本身 SaaS 化的优势：

首先，数据特征天然需要统一维护和上下拉齐，即数据治理，并不是为了治理而治理，而是我们要看到一个准确的数据，并且希望数据来指导业务。当老板看到一个数据发出了疑问，下面的执行层是不是能够首先定位到问题所在；其次，通过一些有效手段来改善这个问题，进而来反向影响最终的结果指标，这样整个企业的运转才会更加良好，这是天然的需求场景所在。

第二点就是数据平台服务的业务场景是比较明确的，它不像 CRM 或者财务系统是非常复杂的，有时候可能一些法务、法规的变更就会造成系统有重大的调整。数据平台专注的是业务的开展，而且是专注在数据分析、数据挖掘方面的。这些都有特定的工作模式，这个模式对工具能力的供给、使用方式以及使用规范来说相对更好、能够达成一致。

第三点，是我们开展数据工作流的时候，这样的解决方案有通用性和互相分享交流的价值。

二

更好地满足定制化需求

第二部分，来看一下我们内部的具体实践，如何更好地降本增效。

1. 定制化需求在中国市场无法避免

我们在做一个数据平台 SaaS 化的服务，不可避免的就是企业的定制化需求。可以看一下下面的两个图片：

左侧的图片是美国农场农田的规划，它的一个考量就是标准化而且高效。它是圆形的，这是因为它的低灌的机器结构，是以秒针的形式来运转的，所以圆形能够浇到最大的面积，通过这种标准化高效率的工具和解决方案，可以创造最大的收益，使得农作物种植以及收割的效率都会比较高。

右侧是一个非常典型的中国的梯田，在丘陵地带地少人稠，要抓住任何一块能够耕作的土地来争取最大的收成。但是想要引入大型机械进行提效来说，提出了非常高的挑战。

这个放在中国的这种商业市场里也有类似的特征：美国是一个合规规范比较明确、发展时间悠久的国家，商业认知、工业化的合作思维相对来说比较到位，能够信赖外部的第三方来帮助企业做这件事情，可以整合各方面的资源，只要满足最终的目标就可以。而在中国商业环境中，企业及企业主有各自特殊的发展环境或发展历程，对于引入外部工具来说，需要适配自身企业的发展需要，短期来看定制化需求在中国市场短期内是不可避免的。

2. 尝试的解法：平台化+服务组件化

基于以上的思考判断，我们在尝试的一个解法就是通过平台化和服务组件化的形态来对外提供服务。

这是粗粒度的一个概念：最底层是大数据平台，首先是基座服务，这个可以对接到企业或不同的平台、到它们的服务运营环境，相当于是底层服务器运行的环境，同时可以提供公共的基础服务，类似于一些租户管理、企业基本的人员管理、权限管理相关的，相当于是靠一个平台的基座串联起上面的各项服务能力。上面的各项服务能力会专注在可视化、数据分析建模、用户画像、营销触达、推送告警、权限管理等方面。

加号代表开放能力，站在一个团队的角度来说，不管这个团队或大或小，想要满足所有的数据分析场景的需求，都不太现实或者成本非常高、时间周期比较长。能不能把它抽象成一个服务组件，同时提供一个外部开发者能够方便使用的开发环境，从而贡献多种多样的服务能力很重要，所以这也相当于是留了一个想象空间。上层的数据应用就是最终面向企业客户真实的工作场景，比如数据大屏、面向管理者的驾驶舱，或者营销工具等等。这些我们不会把它全做，可能需要引入业务知识，需要业务开发者或者业务团队真正的理解业务的看数需求或分析数据的需求，然后来给予我们底座和服务能力提供接口、插件或者说服务化的能力来得到最终的数据应用，这是总体的建设思路。

3. 实操案例

下面是我们内部正在探索的一个实操案例。

腾讯希望将灯塔平台做成公司最完整、最高效的数据分析工具。在这个分析平台上有数据分析、用户画像、数据可视化，也有数据驱动中工作流等一系列的组件。基于这些组件可以为用户提供最基础的数据服务，但是对于客户来说，他们希望有一个强大好用的数据工具，希望可以按照企业、按照行业、或者按照业务场景进行灵活的定制，或者说希望有一些更高阶的增值服务，比如可以为他们提供数据治理的服务，或者指标体系的梳理搭建等等。用户的诉求和单纯站在平台建设者的视角来梳理这些功能之间是有 gap 的，我们需要将两者有机的结合起来，才能为客户提供真正有价值的产出或者交付物。需求输入和能力供给之间进行有机组合之后，发布到产品的应用市场或人力服务市场，在这里企业客户就可以选购自己想要的服务了。之前历史沉淀的包括正在做的公有云是基于腾讯云的分析套件，私有云像工业数字化，以及面向企业集成，就是 TME 集团的数据服务都是可以通过这种模式来搭建起来的。

此外不得不说到的就是合作伙伴，我们希望有更多的共建者能够把这套分析平台做得更好、更灵活、能够解决更多的问题。单靠一方或两方很难，我们想做一个开放性的设计。我们会沉淀包括基座、服务能力的 OpenApI 开发文档、开发的工作环境，同时可以引入第三方开发者进入到这样的平台中，来集成各方的能力满足相应的需求。

下图是开放平台的设计，基本思路和上面一样，只是会更多地关注细节：开发者怎么进入到我们这里开始开发，我们需要梳理 OpenApI、沉淀插件化的改造 SDK 和一些基础的视觉规范和视觉元素，做到线上的自动开发工作流的发布，真正的能够对接到刚才提到的这种黄色位置的服务能力和数据应用，使得它们都可以通过这种方式来进行线上化的开发和发布。

三

数据产品工作思考

数据产品的工作流程是发现问题、理解问题、产品建模和验证迭代。

首先，我们一定要永远站在客户的视角来思考我们做这件事情的价值或意义。C 端的产品经理感受会更直观一些，例如优化了视觉或者提供了全新的服务，作为用户能够立刻感知到价值。但是 B 端产品经理在和业务人员打交道，需要做身份的切换、站在业务方视角来思考产品的这种服务模式或价格设计，是不是能够更好的服务于这样的行业或客户。

另外，我们提供的工具和服务需要真正帮助用户解决问题，而不是简单的功能的罗列或堆砌。有文章曾提到，国外 PLG 这么成功，而中国一直在尝试却没有立竿见影的效果，这可能有两方面因素：一方面是甲方的采购者或老板的思维观念还停留在销售驱动阶段，担心缺少功能和吃亏、以为是一锤子买卖；第二方面，站在 SaaS 行业从业者自身角度来说可能也会存在问题，商务团队和后台的产研是分开的，商务和产研不能真正地站在客户的视角想问题。我们需要思考客户选购了这样的产品或 SaaS 服务是否能够解决当前企业存在的一些问题，能够降低成本或提高效率。

最后，希望引入更多的贡献者以达到价值增值的目标。如何把更多的人引进来，并且他们也愿意并能够贡献高质量的插件或服务也是比较有挑战的事情，还需要经过时间的验证，才能得到更充分的思考和实操的方法。

四

问答环节

Q1：对于 ToB 的产品，定制化和成本之间的平衡是怎么考量的？

A1：定制化的成本肯定会更高一些，站在我们的视角，接收到一个定制化需求，首先需要理解这个需求是不是具有通用性，或者至少某一个场景是有价值的。如果有价值的话，我们再思考它的实践方式，如果非常通用的话，我们会把它抽象为一个基础能力，或者说是封装成服务，如果是偏行业的，那我们会更多的让客户或者外部的合作者利用我们基础的开放能力来进行支持。

Q2：对于用户的留存，B 端用户和 C 端用户在产品的发展和角色上有什么样的区别呢？

A2：根据我的调研，C 端产品的用户最先考虑的是产品对我是不是有帮助，像抖音和快手，最开始消磨用户时间，之后让用户获得放松，这对于用户来说存在正向收益，用户感知会非常明显，C 端产品用户的留存和他自己的偏好直接相关。那么关于留存的影响因素会更容易定位或者说更好分析。比方说是不是我们产品的某次迭代伤害了某一部分核心用户、是不是有一些影响产品口碑的事、或者舆情的发生、或者也有一些行业或政策因素等等，这些都会影响一个用户的留存。C 端用户留存的手段也会比较多一些，或者说老客的召回都会好做一些。相比来说，差别就在于用户的感知和企业 SaaS 的选购周期的传导会稍微慢一些，另外可能在甲方企业内部的信息转换也会不太一样。

ToB 产品的留存，在行业内主要考量的是次年的付费收入/今年的付费收入，如果大于 1，证明是正向的，那么就是有更多的甲方企业，或者说更大范围的甲方部门来选购我们的 SaaS 服务，这是一个正向的考核指标。如果说想要施加一些手段提高留存，我们可能需要投入更多的精力。由于服务是比较复杂的，它不会像 C 端的一个单点功能就会有明显感知，而是可能整个链条都需要优化到一定地步，才能解决某一些客户的问题。

Q3：现在很多 SaaS 公司的盈利模式可能比较难，有没有比较好的建议和策略可以增加公司的变现能力？有没有体系化的一些想法？

A3：关于变现，我不太确定这个变现是说自己企业内部沉淀的之前的能力还是说把产品转换为一个面向外部真正开始赚钱的业务。如果是这个问题的话，我的理解是回归到商业化的本质，你提供的服务在市场上是有需求的，这个需求相当于是一个双边交易市场。我有这样的需求，有这样的供给，才能促成这样的一笔交易。

如果是站在基于企业内部沉淀的服务能力来思考的话，首先第一点需要判断我们要切入哪个市场、这个市场的特征和规模是怎么样的；第二点需要判断在这个市场下和这个细分领域下我们现在的产品有没有一些亮点，或者说我们整体的一个服务是不是至少能够和目前行业内已有的产品来做有利的竞争，相当于是先分析自身再看一下市场上的需求。如果市场的需求只靠人力就能解决，或者只是投入时间就能解决，但是不影响赚钱的业务场景或者切入领域的话，那么当前进入的时机是不太友好的。由于要创造收入，对于自身或者对于整个企业的决策来说，及时的正向激励才能促使我们更好地往下推进。

李子坤

腾讯产品经理

北邮本硕。曾就职于腾讯，贝壳，滴滴等多家互联网公司，具备多年大数据产品经验，专注于数据分析及应用、数据中台产品建设。目前就职于腾讯中台部门，探索大数据分析平台 SaaS 化建设及商业化路径。