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

逸创云客服这个项目是从2011年就开始做的，那时就在国内听到过企业应用服务生态的概念，当然在国外是早就看到了。当时的企业SaaS服务还在萌芽发展，也遇到过许多厂商要么就是覆盖相关所有业务越做越臃肿，导致越来越不好用，然后变得没那么多企业用。要么就是孤立的，没有任何开放性。 做SaaS之前我曾经深入学习过很多国外的SaaS产品。国外一些现在上市的SaaS企业，我在他们只有不到1000家企业用户的时候就开始学习和关注，也深受熏陶，那个时候我认识到以后的发展方向是做小而美，不做大而全，专注核心业务，然后用互补集成形成企业级服务生态。（SaaS的方向确实四面八方。） 后来我想和CRM厂商进行合作，方便客服在服务客户的时候，能获取第三方CRM的数据，同时便利企业使用。结果找了一大圈，发现在当时（2012年）比较知名的CRM厂商，发现不要说集成了，连开放接口都没有。 在经历过一系列诸如此类的寻求集成失败后，我一度开始重新思考国内SaaS集成的定义和状况，也许是因为在早期还不够强，也许大家还没意识到1+1〉2，也许大家都想各自为阵的思路。 其实我一直是倡导开放思想的，甚至竞品之间也可以集成互补；所以在这里引出第一个议题：企业SAAS应用服务集成和生态是不是个伪命题？开放集成OR自己覆盖相关业务？ 其实竞合是必然，现在已不是英雄时代，是联盟时代，谁要封闭保守不开放，谁就会被时代抛弃。对于这样的现状，究竟应当开放集成，还是自己把周边的业务都覆盖了做成巨无霸，功能变得复杂、臃肿？ 首先，需要思考：SaaS生态正逐步在国内形成，是否需要将企业级应用互相的集成打通？又该如何去做？ 在国内，两个流派都有拥护者。有的人现在做垂直行业，而且是原本没有系统的行业，CRM＋BPM，但开放接口。而有的人基本只干专一行业的活。现在大家的心态是矛盾的，一方面知道开放是必然之路，另一方面又害怕开放。（也可能是贪婪） 在早期 SaaS发展的时候可能缺乏共享的意识或者担心被copy。现在发展成熟，各自SaaS都能成熟的往前走，都不再为生存考虑的时候，SaaS集成生态是否是一条可以考虑的路子？还是都去做，涵盖周边所有业务？ 事实上，国内竞争很激烈，连竞品都可以互补集成估计要被大家诟病。但 国内2B业务形态复杂，在国内出现BAT可能性不大，SaaS集成一定是大势所趋，而且有先天优势，都在云上。BAT就是一个非常好的例子。首先要做得够专，有一定规模，才适合做生态。而生态不是哪一家做的，是全体厂家共同努力的结果，大家都开放，自然就形成生态了，最终结果是让用户价值最大化。 然而，集成是大势所趋，但标准的制定和集成基于什么方式比较适合是两大难题。 这样的集成不是拷贝，是协调运作，联盟合作为企业提供全方位服务。但在这个过程中，客户会担心数据安全。 那么接下来，我们需要思考——集成的初衷！ 很多在初期发展的早期小型SaaS企业可能有会这样的思想经历：想集成，想拓展，大佬都不鸟你；也遇到过要集成就找流量大户集成，快速增长，流量来了才是第一，没流量谁都不想和你集成，哪怕有刚需场景。 比如说我在2013年早期想和一家类似竞品的SaaS产品进行集成，结果后面不了了之。到了2014年小道消息才知道是觉得我流量还不够大，没什么意义，因为那块业务是我发展方向必须涵盖的，本想通过集成互惠互利的方式解决，结果后面是我们研发团队剥离一部分人去做这块业务的研发，而事实上是我根本不想亲自做的。 当时的集成方式对方就是导流的思想，没有太多考虑企业用户的感受；比如说企业想要数据互通，你只把用户打通了，企业需要集成用户你放个链接做跳转等等。而事实上，导流是阶段性的，只是一方面。留存、购买和活跃才是主要的。如何在产品和业务层面留住企业才是比较关键的，通过集成来丰富企业的场景化需求，丰富企业的多元化需求，提高企业的迁移成本才是比较重要的。 如果是这样，每个SaaS企业需要如何思考，如何去做？ 所以引出第二个议题：

2、企业SaaS应用集成是以导流为主还是为了方便企业场景化使用为主？

互联网在互联一切，我们每一种应用的客户群，都是“小流量”，但如果我们有一种胸怀，敢于开发与协同，我们加起来，就可能是大流量。 关键字：粘性，迁移成本，满意度。核心还是满足客户的需求，这也是产品的价值所在。 目前看到的集成，多多少少带有导流性质的情形，但是导流最终必将会损害企业用户的利益。有可能场景根本就用不上，这时候必须要思考：到底是在为把企业做大而做大还是为了客户企业着想的问题。 导流涉及了利益，这种连接往往是互相制约而不是互相开放。因此导流从根本上来说是错误的，是本末倒置。 我们做SaaS，应该是一种部署在云端的服务，我们应该脱离产品竞争的时代，真正做好服务。实际上，应该竞争的不是产品，而是粉丝——这是互联网时代的气息。或者说 2B 是要稳扎稳打、方便企业客户，还是为了冲数据和流量？当然结合在一起并不冲突，在满足后者的前提下增强自己是最好了。 服务好客户是目标，导流是结果，一旦涉及利益就不好谈了。 下面我们来看看标准的SaaS服务所应该具备的标准共性：

（国外标准SAAS模型）

可扩展性其实也就是针对企业用户场景的集成，企业需要什么，刚需什么，就怎么集成扩展。

对于基于企业场景化的集成大致有如下几点：

应用内获取外部数据在系统内操作、呈现以及传递；

外部获取应用内数据在外部操作、呈现及传递；

用户系统的正向打通；

用户系统的反向打通；

消息信息对外推送；

消息的拉取/对内推送等

3、如何看待企业级产品extensibility可扩展性的呢？

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

4、集成是不是必须的？对SaaS应用服务发展的推动力和价值？

相信做企业SaaS服务的兄弟们听到比较头疼的是各个客户各种奇葩的需求，要这里改一下那里挪一下位置，要定制化需求，要二次开发，要部署私有云等等。我们是做客户服务产品的，属于深度切入企业业务场景的SAAS应用，企业对产品的定制化需求非常多，也是给我们一些挑战和小压力。 举个真实的匿名例子：有客户提到他们在某个场景用的时候想看到某个用户或某个组的他们自己系统里的信息，他们自己又用的是某个第三方的企业SAAS服务（我称之为A），由于两个SAAS服务没有基于类似公共用户场景的集成，那么对于我们来说，这个客户的需求就是多出来的定制化需求；对于A来说，这个客户也可能会因为要使用我们的服务来PUSH A来进行二次开发。 为了某一个企业的需求，要推动两家SaaS企业联合，使用额外的人力来满足，完全是费力不讨好的事情，而且最重要的一点是没有可复制性。其实如果两家SaaS企业对于某个刚需应用场景进行总结，形成插件或者集成，完全可以满足类似的需求，从而大大降低成本提升可复制性，同时提升两家企业的业务竞争力，同时也能鼓励更多的企业使用SaaS服务。 我相信做SaaS的企业谁也不愿意去给某个客户的单独需求做繁琐的定制化，当各个SaaS厂商都联合起来形成集成网，那么使用自行开发软件的企业也会越来越少，因为你使用的不是标准化的产品，你就需要自己来开发集成。这样一来，SaaS会更被认同，SaaS会更好卖，SaaS行业会更好更快地发展。那么问题就从雇第三方线下IT服务团队做定制化转变为一批开发者来为厂商思考、挖掘和开发集成插件的事。随着客户的需求越来越多，然后各自形成应用集成网。前提是各个厂商需要有满足客户需求的集成的意识，不仅利他同时也利己，也利整个行业。

小鲜肉创业者和“老人”们的PK是从这里开始的 ： 从当下来看，厂商联合起来形成集成网，那只是明日的一场梦而已，这个太大，也许只是个美好的愿望。小领域几个公司先实现这个倒是有可能的，增加客户的迁移成本。 那么，集成的价值是否能减少定制化开发、二次开发的工作量呢？ 从老一辈的眼光来看——SaaS，都是不同厂家开发的独立应用，从系统角度，只能是信息孤岛，应该没有直接整合的机会。但当80后这种小鲜肉主导的企业级服务公司越来越多后，一定会走向集成。 当然，其实集成也是要看行业SaaS产品的，有的却是找不到任何刚需场景。

SaaS解决客户个性化不是问题，在一个应用环境很多开发商协同完成任务也不是问题，但要把不同的SaaS整合到一起，似乎没有思路。事实上，即使没有竞争关系的公司互相参股，有可能形成几个阵营，但也不一定有效。因为到一定规模都已经有资本介入，互相换股不一定容易实现。 我们考虑集成云客服，就是为了提升客户满意度。因为在培训行业，对于培训管理员来说，一线人员的支持和满意度是他工作的核心指标之一，所以有价值；考虑集成视频会议系统，是为了便于客户开远程培训班和开会（延伸应用），都是为了加强我们的价值和加大客户的替换成本。

5、企业SaaS应用集成一定要有固定标准么？集成一定要大佬（微信，钉钉，云之家等）来PUSH还是照搬国外模式还是各自为阵？

最近阿里钉钉和微信企业号很火，思维走向了好像集成只有大佬才能玩的事，只有流量和用户帝、资源帝才能搞集成的定势。按照企业号的标准是，集成必须打通用户系统或者同步用户系统，包括我也看过有应用市场的SaaS服务，都有固定标准，比如如果要集成，必须要集成什么什么。但我觉得集成的标准是基于企业用户场景的，2B和2C毕竟不同，C是人嘛，有共性，但是企业就不一样了，流程不一样，规则不一样，制度不一样，场景也不一样，要以企业为本，不一定有硬性标准，不一定非要打通用户。 例如：我们做客户服务想让企业利用好客户信息来做EDM营销，那我们和SENDCLOUD（邮件发送SaaS服务厂商）集成就是数据互通性的集成，在应用内拉取SENDCLOUD的发送邮件接口，获取应用内用户列表，然后批量发送，然后返回发送结果分析。满足了客户想要的需求，但没有遵循硬性标准。 有什么简单的方法，不用统一标准，实现集成呢？ 那么，SaaS集成是否一定要有一个标准化的集成方案？ 一定要遵循这个方案？一定要集成用户？ 一定要集成消息系统？或者一定要某个平台作为总的,诸如应用市场、应用平台等。 实际上，应该没有标准——客户需要什么，那什么就是标准。从广义上讲，集成标准应该是非常复杂的体系。同时，集成不是saas厂商完成的，厂商完成的是开放，第三方来集成。 对于很多企业来说，自己去开发新的客户，获取用户体验信息，至少需要投入10个人干一年，所得的数据才勉强能用，这不是我们核心价值。 为什么要自己做？在有利润的条件下，整合是思路。对于各类应用，我们作为增值服务让客户选购，但整合好在一个系统里面。甚至还碰到客户要求我们整合他们的客服系统的，这就是“整合”的价值体现。 当然，这只是SaaS的整合集成，是小范围的讨论。对于其他很多领域来说，恐怕并不适用。全世界的大公司，没有1千万美元的预算，免谈跨系统集成，集成可能对客户并无什么了不起的价值。

6、为什么国内无法形成像SLACK的公司，如何认知类似SLACK这种集成式的厂商以及对国内企业SaaS服务带来的启示？

国外的SaaS发展如此迅猛，除了主要因素外，国外的厂商也在SaaS生态构建上做了很多功夫，基本上每个牛逼的SaaS企业都有各自的应用市场，而且是可扩展的。那么，为什么国内无法形成像SLACK的公司，如何认知类似SLACK这种集成式的厂商以及对国内企业SaaS服务带来的启示？ 从反集成派的角度来看，理想很丰满，现实很骨感，企业内部系统的整合非常困难。这个界面是崔牛会某企业所做的整合，各种API，各种代码，各种厂商，折腾起来，非常痛苦。或者说整合太难，不仅是技术问题，有时候哪怕客户给钱希望做整合，许多厂商也不敢做，认为这是一个无底洞。毕竟这个问题不是讲情怀，是现实如此。大家都会想：谁都想当入口，怎么会有slack？为什么这么多相当入口的都没有一个做起来？ 而看好集成的企业家们认为：定好对接标准，集成ecc和ebs并不可怕，但需要多方配合，成本是比较高。这也并不是天方夜谭，现在SaaS的细分化，碎片化，走向开放，走向集成是必然的。不会太久，也许等到年轻一辈2B人成长起来，就能实现。哪怕是今天，很多大企业，如果不考虑集成，你的产品就卖不进去。不管传统系统还是SaaS，集成是企业刚需，躲不过。例如逸创云客服的系统对接外部客户，所以集成是必要的。事实上，用友金蝶也是可以集成的，用友甚至专门有个接口平台。 做一次二次开发的集成是方便一家客户，做一次集成／插件是方便千百个客户，而且最多1-2天就能搞定（此处讨论的是指轻集成，或者叫假集成，SAP ORACLE的集成不在本讨论范畴）。这样一来，就能打通一个数据，满足一个场景，就能利好千百家客户，增强企业竞争力，何乐而不为？ 传统大企业IT环境因为封闭和定制化以及各家利益问题，集成确实是个坑。相对来说产品化和标准化的新SaaS厂商集成是有机会的，也会是部分厂家的共赢。也许总有一天会出个大平台，把大部分saas都集成了或者变成插件了。客户用户不会也不愿意用N个APP，或者会出现垂直行业的垄断型SaaS厂商，在一领域横行霸道。