四、SaaS服务应用集成和生态该何去何从

叶翔 逸创云客服创始人

（一）企业SaaS应用服务集成和生态是不是个伪命题？集成OR覆盖业务

逸创云客服项目是从2011年开始做的，那时就在国内听到过企业应用服务生态的概念，当然在国外早就看到了。当时的企业SaaS服务还在萌芽发展阶段，也遇到过许多厂商要么是覆盖相关业务越做越臃肿，导致越来越不好用，然后变得没那么多企业用；要么就是孤立的，没有任何开放性。

做SaaS之前，我曾经深入学习过很多国外的SaaS产品。国外一些现在上市的SaaS企业，我在他们只有不到1000家企业用户的时候就开始学习和关注，深受熏陶，那时候我认识到以后的发展方向是做小而美，不做大而全，专注核心业务，然后用互补集成形成企业级服务生态。（SaaS的方向确实是四面八方）

后来，我想和CRM厂商合作，方便客服在服务客户的时候获取第三方CRM的数据，同时便于企业使用。结果，发现在当时（2012年）比较知名的CRM厂商，不要说集成了，连开放接口都没有。

在经历了一系列诸如此类的寻求集成失败后，我重新思考国内SaaS集成的定义和状况，也许是因为在早期还不够强，也许大家还没意识到1+1＞2，也许大家都想各自为政。

其实，我一直是倡导开放思想的，甚至竞品之间也可以集成互补。所以，在这里引出第一个议题：企业SaaS应用服务集成和生态是不是个伪命题？开放集成还是自己覆盖相关业务？

竞合是必然，现在已不是英雄时代，是联盟时代，谁要封闭、保守、不开放，谁就会被时代抛弃。对于这样的现状，究竟应当开放集成，还是自己把周边的业务都覆盖了做成巨无霸，功能变得复杂、臃肿？

首先，需要思考：SaaS生态正逐步在国内形成，是否需要将企业级应用互相集成打通？又该如何去做？

在国内，两个流派都有拥护者。有的人现在做垂直行业，而且是原本没有系统的行业，CRM+BPM，但开放接口。而有的人基本只干专一行业的活。现在大家的心态是矛盾的，一方面知道开放是必然之路；另一方面又害怕开放。

在早期SaaS发展的时候可能缺乏共享的意识，或者担心被复制。现在发展成熟，各自SaaS都能成熟地往前走，都不再为生存考虑的时候，SaaS集成生态是不是一条可以考虑的路子？还是都去做，涵盖周边所有业务？

事实上，国内竞争很激烈，连竞品都可以互补集成估计要被大家诟病。但国内To B业务形态复杂，在国内出现BAT的可能性不大，SaaS集成一定是大势所趋，而且有先天优势，都在云上。BAT就是一个非常好的例子。首先要做得够专，有一定的规模，才适合做生态。而生态不是哪一家做的，是全体厂家共同努力的结果，大家都开放，自然就形成生态了，最终结果是让用户价值最大化。

然而，集成是大势所趋，但标准的制定和集成基于什么方式比较适合是两大难题。

这样的集成不是拷贝，是协调运作，联盟合作为企业提供全方位服务。但在这个过程中，客户会担心数据安全。

那么接下来，我们需要思考——集成的初衷！

很多在初期发展的早期小型SaaS企业可能会有这样的思想经历：想集成，想拓展，有实力的人都不理你；也遇到过要集成就找流量大户集成，快速增长，流量来了才是第一，没流量谁都不想和你集成，哪怕有刚需场景。

例如我在2013年想和一家类似竞品的SaaS产品进行集成，结果不了了之。2014年才知道对方觉得我的流量还不够大、没意义。因为那块业务是我发展方向必须涵盖的，本想通过集成互惠互利的方式解决。结果后面是我们研发团队剥离一部分人去做这块业务的研发，事实上，我根本不想亲自做。

当时的集成方式对方就是导流的思想，没有太多地考虑企业用户的感受。例如企业想要数据互通，你只把用户打通了，企业需要集成用户放个链接做跳转等。事实上，导流是阶段性的，只是一方面，留存、购买和活跃才是主要的。如何在产品和业务层面留住企业才是比较关键的，通过集成来丰富企业的场景化需求，丰富企业的多元化需求，提高企业的迁移成本才是比较重要的。

如果是这样，每个SaaS企业需要如何思考、如何去做？所以，引出了第二个议题。

（二）企业SaaS应用集成是以导流为主，还是为了方便企业场景化使用为主

互联网在互联一切，我们每一种应用的客户群都是“小流量”，但如果我们有一种胸怀，敢于开发与协同，加起来就可能是大流量。关键字：黏性、迁移成本、满意度。核心还是满足客户的需求，这也是产品的价值所在。目前看到的集成，多多少少带有导流性质的情形，但是导流最终会损害企业用户的利益。有可能场景根本就用不上，这时候必须要思考：到底是在为把企业做大而做大还是为了客户企业着想的问题。

导流涉及利益，这种连接往往是互相制约而不是互相开放。因此，从根本上说导流是错误的、是本末倒置的。我们做SaaS，应该是一种部署在云端的服务，应该脱离产品竞争的时代，真正做好服务。实际上，应该竞争的不是产品，而是粉丝——这是互联网时代的气息。或者说To B是要稳扎稳打、方便企业客户，还是为了冲数据和流量？当然结合在一起并不冲突，在满足后者的前提下增强自己是最好了。服务好客户是目标，导流是结果，一旦涉及利益就不好谈了。

合作，要靠资本的力量，资本推动，背后有溢价，容易达成一致。但资本只是一方面，如果没有资本呢？基于当前利益的合作并不容易，要放下，要舍得，必须要思想心灵先解放。在这点上，国内外差异还是很大的。可以思考一下，过去15年，国内谁跟谁合作愉快了？

下面我们来看看标准的SaaS服务应该具备的标准共性，如图1-2所示。

在本次讨论中，其实我们就是针对这个图里面的extensibility可扩展性讨论。可扩展性其实就是针对企业用户场景的集成，企业需要什么、刚需什么、就怎么集成扩展。对于基于企业场景化的集成大致有几点：应用内获取外部数据在系统内操作、呈现以及传递；外部获取应用内数据在外部操作、呈现及传递；用户系统的正向打通；用户系统的反向打通；消息信息对外推送；消息的拉取、对内推送等。

（三）如何看待企业级产品extensibility可扩展性

扩展性指的是对外扩展延展性。现在管理软件就是一盘散沙，SaaS集成更是镜花水月，不是技术问题，而是地盘问题。软件服务这种信息产品，与物化产品属性不同，很多数据与流程的交互，是生命式的联系。

（四）集成是不是必需的？对SaaS应用服务发展的推动力和价值

相信做企业SaaS服务的人们听到比较头疼的是各个客户各种奇葩的需求，要这里改一下那里挪一下位置，要定制化需求、要二次开发、要部署私有云等。我们是做客户服务产品的，属于深度切入企业业务场景的SaaS应用，企业对产品的定制化需求非常多，也给我们带来挑战和压力。

有客户提到他们在某个场景用的时候想看到某个用户或某个组的系统里的信息，他们自己又用的是某个第三方的企业SaaS服务（我称之为A），由于两个SaaS服务没有基于类似公共用户场景的集成，那么对于我们来说，这个客户的需求就是多出来的定制化需求；对于A来说，这个客户也可能会因为要使用我们的服务来推动A进行二次开发。

为了某一个企业的需求，要推动两家SaaS企业联合，使用额外的人力来满足，完全是费力不讨好的事情，而且最重要的一点是没有可复制性。如果两家SaaS企业对于某个刚需应用场景进行总结，形成插件或者集成，完全可以满足类似的需求，从而大大降低成本、提升可复制性，同时提升两家企业的业务竞争力，也能鼓励更多的企业使用SaaS服务。

我相信做SaaS的企业谁也不愿意去给某个客户的单独需求做繁琐的定制化，当各个SaaS厂商都联合起来形成集成网，那么使用自行开发软件的企业也会越来越少，因为你使用的不是标准化的产品，你就需要自己来开发集成。这样一来，SaaS会被认同，SaaS会更好卖，SaaS行业会更好更快地发展。那么问题就从雇第三方线下IT服务团队做定制化转变为一批开发者来为厂商思考、挖掘和开发集成插件的事。随着客户的需求越来越多，然后各自形成应用集成网。前提是各个厂商需要有满足客户需求的集成意识，利他的同时也利己，也利于整个行业。

我们考虑集成云客服，就是为了提升客户满意度。因为在培训行业，对于培训管理员来说，一线人员的支持和满意度是他工作的核心指标之一，所以有价值。考虑集成视频会议系统，是为了便于客户开远程培训班和开会（延伸应用），都是为了加强我们的价值和加大客户的替换成本。

（五）企业SaaS应用集成一定要有固定标准吗

集成一定要领先者（微信、钉钉、云之家等）来推动吗，或者照搬国外模式，还是各自为政？

最近阿里钉钉和微信企业号很火，思维走向了好像集成只有领先者才能玩的事，只有流量和用户帝、资源帝才能搞集成的定势。按照企业号的标准，集成必须打通用户系统或者同步用户系统，我也看过有应用市场的SaaS服务，都有固定标准，例如如果要集成，必须要集成什么。但我觉得集成的标准是基于企业用户场景的，To B和To C毕竟不同。C是人，有共性。但是企业就不一样了，流程不一样，规则不一样，制度不一样，场景也不一样，要以企业为本，不一定有硬性标准，不一定非要打通用户。

例如我们做客户服务想让企业利用好客户信息来做EDM营销，那我们和SendCloud（邮件发送SaaS服务厂商）集成就是数据互通性的集成，在应用内拉取SendCloud的发送邮件接口，获取应用内用户列表，然后批量发送，返回发送结果分析。满足了客户想要的需求，但没有遵循硬性标准。

有什么简单的方法，不用统一标准，实现集成呢？

难度颇大。假设一下公司都用了3个SaaS公司的产品，公司里面还有4套业务系统，这些分散的业务数据如何融合？不仅仅是技术问题的考虑，更多是利益的考虑。

那么，SaaS集成是否一定要有一个标准化的集成方案？一定要遵循这个方案？一定要集成用户？一定要集成消息系统？或者一定要某个平台作为总的诸如应用市场、应用平台等？实际上，应该没有标准——客户需要什么，那什么就是标准。从广义上讲，集成标准应该是非常复杂的体系。同时，集成不是SaaS厂商完成的，厂商完成的是开放，第三方来集成。

无论是集成现在的各类异质管理软件，还是集成未来各厂商的SaaS应用，需求上看是个金矿，真正去干就是个大坑，最后爬上来才知是个粪坑。

对于很多企业来说，自己去开发新的客户，获取用户体验信息，至少需要投入10个人干一年，所得的数据才勉强能用，这不是我们的核心价值。

为什么要自己做？在有利润的条件下，整合是思路。对于各类应用，我们作为增值服务让客户选购，但整合在一个系统里面。甚至还碰到客户要求我们整合他们的客服系统，这就是“整合”的价值体现。

分析公司产品的定位、价值，围绕满足客户核心需求的几个周边需求去整合。同时，要将战略、预算、项目、组织、流程、检查、报告、KPI考核、IT工具、激励、人才配置，一盘棋通盘考虑，体系化规划、层层分解、环环相扣。必须集成，否则都是信息孤岛，不能形成整合力。

当然，这只是SaaS的整合集成，是小范围的讨论。对于其他很多领域来说，恐怕并不适用。全世界的大公司，没有1000万美元的预算，免谈跨系统集成，集成可能对客户并无了不起的价值。

（六）为什么国内无法形成像SLACK的公司

如何认知类似SLACK这种集成式的厂商及对国内企业SaaS服务带来的启示？

国外的SaaS发展如此迅猛，除了主要因素外，国外的厂商也在SaaS生态构建上下了很多功夫，基本上每个厉害的SaaS企业都有各自的应用市场，而且是可扩展的。那么，为什么国内无法形成像SLACK的公司，如何认知类似SLACK这种集成式的厂商，以及对国内企业SaaS服务带来的启示？

从反集成派的角度来看，理想很丰满，现实很骨感，企业内部系统的整合非常困难。这个界面是某企业所做的整合，各种API、各种代码、各种厂商，折腾起来，非常痛苦。或者说整合太难，不仅是技术问题，有时候哪怕客户给钱希望做整合，许多厂商也不敢做，认为这是一个无底洞。毕竟这个问题不是讲情怀，是现实如此。大家都会想：谁都想当入口，怎么会有SLACK？为什么这么多想当入口的都没有一个做起来？

而看好集成的企业家们认为，定好对接标准，集成ecc和ebs并不可怕，但需要多方配合，成本比较高。这不是天方夜谭，现在SaaS的细分化、碎片化，走向开放、走向集成是必然的。不会太久，也许等到年轻一辈To B成长起来就能实现。哪怕是今天，很多大企业如果不考虑集成，你的产品就卖不出去。不管传统系统还是SaaS，集成是企业刚需，躲不过。例如逸创云客服的系统对接外部客户，所以集成是必要的。事实上，用友、金蝶也是可以集成的，用友甚至专门有个接口平台。做一次两次开发的集成是方便一家客户，做一次集成/插件是方便千百个客户，而且最多1～2天就能搞定（此处讨论的是指轻集成，或者叫假集成，SAP、Oracle的集成不在本讨论范畴）。这样一来，就能打通一个数据、满足一个场景，就能利好千百家客户，增强企业竞争力，何乐而不为？传统大企业IT环境因为封闭和定制化及各家利益问题，集成确实是个坑。相对来说，产品化和标准化的新SaaS厂商集成是有机会的，也会是部分厂家的共赢。也许有一天会出现个大平台，把大部分SaaS都集成了或者变成插件了。客户用户不会也不愿意用N个APP，或者会出现垂直行业的垄断型SaaS厂商，在一个领域横行霸道。