近期，以“SaaS生态与共创的路径思考”为主题的崔牛会SaaS小会第36期直播成功举办，本期SaaS小会由牛透社资深记者张保文对话衡石科技创始人&CEO刘诚忠，共同探讨SaaS企业如何选择适合的生态合作模式、如何通过生态协同共创数字生产力、又要如何走出“研发成本”的坑、什么类型的功能适合集成“等SaaS生态关注的核心问题。刘诚忠为大家分享衡石科技的生态合作经验，及其“AI+BI+指标”的全新架构能够为生态伙伴带来的价值。

刘诚忠：合作基于双方在各自领域的专业化分工优势。每个企业完成擅长的任务时，成本显然比其他厂商更低。一旦在业务或功能上实现协同，合作就是合乎逻辑的。

前几年的SaaS生态协作，是双方的交叉销售、市场活动、PR站台等。而疫情两三年，尽管整个行业承压较大，但发展速度依然很快，最明显是产品层面协同合作越来越多，如产品之间的集成、打通、相互配合等。

刘诚忠：生态协作中最关键的是要明确边界，边界越明确、越专注的公司越容易合作。衡石专注于数据分析和BI可视化。衡石的边界构建有个前置的问题，这涉及到数据产业的一个重要特点，即是在行业无关的工具层面研发产品，还是在行业属性层面研发完整产品解决方案？衡石从创立之初便选择从行业无关的工具层面研发通用型产品，与垂直行业服务划分开，这就是衡石的边界。通过和专注于行业的厂商伙伴合作，衡石可以专注于提供数据分析的能力，帮助行业伙伴减少研发成本，而行业伙伴则发挥其行业know-how、场景落地经验等优势，双方共同为终端企业客户提供场景化的分析应用和不跳出业务视角的报表原地分析。

在SaaS生态中，有横向与纵向的区别。横向基本都是业务型的SaaS，主要看在用户场景上是否存在上下游协同关系。例如，卫瓴科技能将能力embedded到其他行业SaaS中，是因为它的MA/SCRM能力能在营销场景中被复用，这是一个典型的业务能力协同。而衡石与伙伴的合作是下层数据分析功能向上服务业务场景，是纵向协同。

当下企业服务都在快速完成数字化转型，每个业务场景都有相应的SaaS服务支撑，很多业务之间需要协同，例如业财税一体化、销售市场漏斗管理、财务运营风险预警等，都是当下的主流协作场景。我们需要注意到的是，所谓的业务协同归根到底是数据协同，通过数据接口传递信息，业务通过数据来拉平信息。

衡石目前已经与数百家SaaS和软件厂商合作，这些厂商之所以会选择与衡石合作，是因为数据分析、BI可视化报表、数据服务API接口、指标统一管理等功能已经成为业务升级明确需要加强的方向。但是数据分析和报表能力的构建需要耗费巨大的研发资源，涉及到长时间的功能排期，与构建业务APP等横向功能不同的是，构建数据能力需要的数据清洗、建模分析、可视化渲染性能等功能比较垂直，导致许多SaaS和软件厂商的伙伴在投入研发时大大低估了需要投入的研发资源。幸运的是，这个能力又是标准化的，因为业务和行业差异化被封装在数据库表的schema设计中，表格设计本身已包含业务含义，针对表格的后续需求则是连结创建表对象、管理表关联模型、构建指标体系，最后落实到看板中。衡石以标准能力对接所有业务场景，通过与生态伙伴的协作实现1+1＞2，目前这种与生态伙伴之间的产品高度集成协作已经是衡石的核心策略——powered by hengshi.

刘诚忠；这个问题没有标准答案，这与产品类型及市场周边生态进化的阶段有关。如北森云的平台层能力非常完整，能够应对各种功能上的需求，并且以大而全的方式提供PaaS服务，从我个人看来是因为当时并没有一个可以被生态协作的优质开放的产品环境供它选择，这是历史原因。

关注自己的客户群体从中小客户到大客户的变化过程中，复杂需求是否越来越难以通过标准化功能满足，以及市场上是否有在某一个细分方向上功能足够成熟的厂商以供合作，是确定合作的典型决策过程。例如几年前在面对KA客户的复杂需求时，SaaS厂商们实际上并没有太多的选择，因为整个产品生态尚不成熟。而在当前发展阶段，各种SaaS企业百花齐放，业务支撑已经有较为充分的覆盖，企业也要转为稳健经营，守住自己的基本盘，发挥差异化优势，这个时候生态协作就必然将成为趋势。

刘诚忠：合作和竞争关系同时存在非常正常，关键在于是否认可并承认对方的专业性。例如虽然都是BI领域，但是在表格控件领域葡萄城做得很专精，那很多BI厂商都直接使用葡萄城的控件来应对复杂表格的一些问题。所以即使存在竞争，只要有差异化，都可以合作，关键在于找到明确的合作边界和各自位置。

如何找到合适的生态伙伴，有几次关键因素。首先在于边界明确。明确的边界是指企业对外呈现的形象定位要非常清晰，明确做什么以及不做什么，并且清晰的传达企业遵循这个策略的商业逻辑。在相互选择生态合作伙伴的过程中，彼此的roadmap以及未来规划都要足够清晰。以我们自己为例，衡石明确专注于数据分析和BI可视化的标准工具平台，没有行业解决方案，我们的解决方案实际上都是伙伴的，业务场景中的行业know-how是伙伴赋予的场景价值；其次，在to B领域生态合作中长久专注非常重要，长期专注某个领域是衡量一个伙伴是否具备安全感的重要标准。衡石长期专注于数据分析和BI细分领域，团队拥有长时间的深入研究，有足够成熟和完备的产品能力，这能够给予伙伴合作的稳定性；最后一个关键因素是产品架构需要足够开放，功能尽量做到微服务的模块化，具备API对接能力和SDK二次开发能力，双方产品能够互相深度集成整合，组装式的对接。衡石的产品架构是完全开放的Open API架构，伙伴可以根据自身的功能需求，灵活嵌入集成到自有的业务系统中，产品形态保持无缝一致的体验。

刘诚忠：这两个问题实际是一体的。

以数据分析产业变化为例，比如我们看海外的情况，早期当客户需要上一套完整的数据产品，需要购买一套Oracle的数仓平台、购买Informatica来做数据清洗、购买BI工具来做报表分析，这些成本在百万美金以上很正常，而这样一个完整的项目落地的建设周期基本需要12-18个月。随着业务逐渐转向云端，各项数字化转型业务能够在云上实现，数据也积累沉淀在云端，Snowflake的出现极大降低了数据存储及计算成本，在流行起来后带动有配套的产品厂商与Snowflake打配合，有专业的数据同步工具Fivetran来降低数据搬运成本，有dbt降低数据加工转换的成本。这几家企业的协作将数据在云端产生后的搬运、存储、转换和分析成本都降低了，彻底改变了整个数据分析产业的成本结构，同时又大大提升了分析的灵活性，反过来促使数据工具市场更繁荣，激发更多企业挖掘数据价值，这就是典型的通过产品生态协作的方式降低产业链整体TCO成本的典型例子。

在国内，衡石的战略合作伙伴云器科技近期发布了以“Single-Engine”为核心理念的云端湖仓一体平台，衡石的分析PaaS产品已经与云器的 lakehouse 产品完成产品深度整合，形成了云端一体化的数据分析解决方案，为用户提供高性能、低成本、业务灵活的数据分析体验。

衡石提供的完全开放的成熟产品架构，可以帮助生态合作伙伴在2-3周内上线完整的数据分析能力，成为在垂直领域内具备专业BI能力的行业厂商，减少了产研团队在自研BI项目中投入巨大成本。这样的合作价值是低成本的扩展产品能力边界，提升面向大客户的个性化服务能力，给伙伴在客户端带来新的收益。

刘诚忠：通常会有两个问题：一是以产品化为目标的研发投入成本容易被低估，二是复杂功能的设计和研发在时间维度上很难加速。

在过去两年里，我常与同行讨论是否应该加强PaaS层的能力。一开始，我们认为这是为了更好应对个性化需求，所以去抽象出PaaS层的自定义能力。然而，PaaS涉及到软件层面的概念抽象和设计重构，其能力要求非常高和投入也非常大。因此，对于SaaS厂商是否应该投入加强PaaS层的能力是否会得不偿失大家持有争论意见。仅从数据分析这个细分能力的场景来看，我们的实践经验是产品合作明显优于团队自研。

数据分析和BI能力是既可以标准化组装，又可以有很重的API层发布和面向服务提供的需求的，对于行业SaaS来说可以按照PaaS进行产品设计。整合BI的目的是为了应对自定义报表需求，即当大家关注某个业务场景的数据运营时，指标口径以及接下来想要追问挖掘的内容都是动态的，通过开发的方式实现过于僵化，无法满足灵活性需求。最佳方案是将部分主导权交给客户侧，给他们一定的自由探索空间。

无论是BI还是其它能力PaaS，在研发资源消耗方面，它与一般业务SaaS或构建应用软件都非常不同，具备几个特点。首先是处于底层位置，对成熟度要求很高，这决定了PaaS投入资源可能在SaaS的几倍到几十倍的量级，这个研发资源容易被低估。其次，面向各种SaaS的需求的差异性，PaaS必须有高级的抽象设计要求，且抽象过程是逐级开展的，这个层面的研发投入不能被资源加速，国外就算顶尖软件厂商比如谷歌、Salesforce等巨头在需要BI能力的组合时，通常都是对BI厂商发起收购，而不会选择自研。

以衡石的合作伙伴经历为例。衡石的伙伴中有约1/4的伙伴曾经尝试自研，期间投入了相当大的成本，投入了5-10个工程师的团队开发，在十几个月的时间内耗费数百甚至上千万的研发成本，最终不能达到预期的设想，无法满足业务端或客户端的需求，最后还是选择了衡石这样长期专注于BI的嵌入式分析平台，但让人遗憾的是，前期投入也就成为了沉没成本，是很昂贵的试错。

所以如果SaaS厂商足够专注，生态合作一定会比自己投入研发来重复造轮子好得多。在当下环境下SaaS企业要实现盈利，成本结构必须优化，不能随便冒险分配研发资源，尤其在长期看不到ROI的情况下，更要专注于自身垂直业务本身。

刘诚忠：越靠近行业konw-how和客户场景的通常是集成方，越偏向标准能力的则是被集成方。衡石在和生态伙伴的产品合作关系中，是属于被集成方。

稳定性、安全感和明确边界对于合作来说非常重要。被集成的一方就像乐高积木一样，每个模块必须明确且通用，在任何场景下都可以实现即插即用，需要具有很高的产品完成度和成熟度，能够让集成方灵活组装嵌入到业务产品或方案中，好的被集成形态的产品合作的摩擦力是很低的。

集成方通常面临的是在某些服务挑战，如需求升级后的服务成本挑战。以BI为例，在服务客户时，由于Marketing或用户增长对运营要求较高，导致报表、分析和指标方面的需求难以满足，这对于提供CDP、用户增长和营销平台的产品厂商来说压力很大，因为客户的分析需求很难做到标准化的固定报表体系。这类厂商会有很充分的理由嵌入集成衡石来控制住成本的爆炸。因为产品上自研BI或者通过定制化开发来满足报表需求成本都太高了。

刘诚忠：痛点是当业务侧或者运营侧真正开始使用数据分析进行探索时，会感到不灵活。

主要原因是，业务分析是一个偏运营的动态过程，统计报表和分析口径会随着业务快速变更和业务人员的思路变化而发生变化，但业务人员往往无法进行真正的自由探索，需要数据团队先处理数据，导致分析过程中断和长时间的等待，这是BI行业几十年来都致力于解决优化的问题。指标中台在很大程度上解决了分析灵活性问题。当业务有新需求或探索想法时，可以通过指标构建和更改的方式来满足，在不启动数据工作的情况下重新构建分析报表，大大节省了反馈周期。

刘诚忠：是的。衡石的架构实际可以分为两部分：数据能力和分析能力。数据能力类似一个完整的data factory，重点帮助IT/数据团队的专业工程师，内置湖仓的设计可以与各种湖仓厂商合作。而分析方面，目前采用BI、指标中台和AI增强的方式进行构建。

通过AI助手和衡石的指标中台结合方式，当用户发出提问时，通过自然语言处理能力，可以将问题分解为指标体系上的操作，而这些动作是自然完成的。对于业务场景的智能化，衡石的BI、指标和AI三件套正在数家生态伙伴中尝试落地。这个能力的底层是数据，上面是BI、指标和AI增强，这样的完整架构是我们目前看到的最优体验，也与衡石“empower”的核心策略继续保持一致。

刘诚忠：目前，所有厂商都在寻找最优方案，尚未找到大家公认的最好方案。大家认为，最终可能会走向垂直行业的小模型。模型的构建成本会降低，在每个垂直行业中，可以私有部署或在云端安全部署自己的行业模型。整个过程中，数据不会泄露，而是会Feed自己的模型。同时，所有操作都能有完善的管控和审计过程，这是未来的趋势。当然，目前开源方案下私有模型的构建成本和成熟度都无法达到Open AI团队的高度。在整个分析体验的设计方面，衡石也进行了很多尝试，目前的最优体验仍然是Copilot。

分析师在Copilot场景下的能力会得到非常大的增强，整个BI的受众群体会快速普及。首先是有自然语言的交流接口，其次是交互上会给出相关问题的提示，引导用户如何正确发问。任何对业务有认知的人，都可以轻松掌握这套工具，在AI Copilot的推动下，数据分析和BI的门槛极大降低，体验得到明显提升，这项技术才能走到普及阶段，这就是我们讲的“跨越鸿沟”。