SaaS（Software as a Service）模式作为云计算的代表，为企业提供了便捷的软件服务。然而，在实际应用中，SaaS 解决方案并不总是受到企业 IT 部门的欢迎。本文将探讨背后的原因，分析 SaaS 系统在企业中的实施挑战，以及如何平衡 IT 部门的利益和 SaaS 产品的优势。

这天，CEO 把我请到办公室，神情严肃的问我，要不要尽快停掉一个 SaaS 项目。

这个项目由他亲自发起，加上软件、实施和自身人力，已经投入了上百万。

但我的态度很坚决：马上停掉，及时止损。

原因很简单，这个 SaaS 系统不但没有实现预期的目标，反而对整体业务造成了很大困扰。

举个例子，我们自研 CRM 系统的订单模块与这个 SaaS 系统进行了集成，而 SaaS 系统需要对相关数据进行校验，校验成功后才能完成订单处理。

但是由于 SaaS 系统的校验逻辑很复杂，且无法自定义修改，结果本来 1 分钟就能完成处理的订单，硬生生拖成了 10 分钟。

对门店的工作效率、客户服务都造成了很大困扰。

这个接口问题只是冰山一角，实际上 SaaS 系统的很多功能和公司业务的适配度都只有 60 分，和自研系统相比差距明显。

另外， SaaS 系统 80% 的功能我们都用不到，但是我们却必须接受这 80% 功能所带来的复杂度和成本。

综合评估下，还不如采购一些简单的本地部署软件，再加上一部分自研，不但成本更低，还更匹配我们的业务需求。

这个案例不是个例，实际上，这也是很多 SaaS 公司所面临的困扰：那就是 IT 部门往往不喜欢 SaaS。

甚至很多 SaaS 公司的 CEO 也公开抱怨：我们不指望 IT 部门能支持 SaaS，他们能不反对就谢天谢天！

那为什么 IT 部门不喜欢 SaaS 呢？

这里面有一些表面上的原因，比如：SaaS 不安全。

但自研软件就安全了吗？除非不接入互联网环境，否则大部分公司自研软件的安全性，都不如 SaaS 产品。

这些表面上的原因，并不是 IT 部门反对 SaaS 的真正原因——特别是在大公司—— IT 部门最关心的还是他们自己的利益。

所以，他们反对 SaaS 的真正原因，其实是 SaaS 产品增加了他们的工作难度，甚至妨碍了他们的业绩达成。

具体来说，主要有以下几点原因：

1、SaaS 过于封闭

SaaS 产品应该是对 " 标准化 " 最有执念的企业软件形态，没有之一。

这本质上是源于 SaaS 产品研发的理念：极致体验，小步快跑。这就导致研发成本很高，如果不做标准化产品，很容易陷入亏损。

但是大企业的 IT 系统往往个性化需求很多。

首先，大企业的系统关系错综复杂，对集成提出了很高的要求。这种集成不是简单的开放 API 就能搞定的，而是需要多方系统协同、个性化适配。

另外，大企业的管理也充满个性化，重点是这种个性化会随着业务发展而变化，这就对标准化产品形成了巨大冲击。

而大部分 SaaS 产品满足个性化的能力都很弱，这就导致一个局面——当某个项目需要 SaaS 产品进行个性化适配时，SaaS 公司的回复往往是：这个需求我们考虑一下，如果确实是合理需求，会纳入迭代计划。

如果你要求 SaaS 公司给一个迭代的时间点，他们的回复往往是：可能 3 个月以后（实际可能需要半年）。

而对于 IT 部门来说，哪怕是 3 个月的拖延，也基本上宣告了项目的失败。

这种情况下，谁敢用 SaaS？

2、SaaS 服务效率太低

大部分 SaaS 产品的功能范围都比较狭窄。

打个比方，我们实施 ERP 往往只会从一家供应商采购，但是如果你购买 SaaS ——要覆盖同样大的业务范围——可能需要 5 家甚至更多的 SaaS 厂商。

功能的碎片化，最大的问题就在于客单价很低，而很低的客单价则只能支撑起远程服务，这就显著降低了服务效率和体验。

其实，对于大企业来说，愿意多花一些钱以获得更好的本地化服务。

特别是一些超大型企业，IT 部门在一定程度上是一个项目管理组织，他们的工作高度依赖供应商的配合，而 SaaS 厂商提供的有限服务显然满足不了他们的需求。

不过，不管是个性化需求还是本地化服务，只要企业愿意付费，SaaS 公司始终有办法解决。

毕竟，如今的 SaaS 公司越来越像传统软件公司，他们甚至开始提供本地化部署，以及全代码的二次开发服务。

那为什么一些 IT 部门仍然不喜欢 SaaS 呢？

这就涉及到一个本质的问题，那就是 SaaS 公司在一定程度上已经成为了 IT 部门的竞争对手。

3、SaaS 与 IT 部门形成竞争

在大企业负责 IT，其实是一份很焦虑的工作。

由于很难直接给企业创造经济价值，IT 部门始终承受着一种压力：证明团队（特别是大团队）存在的必要性。

而自研系统越多，这种必要性就越高——极端一些的说——如果没有任何自研的成分（包括外采系统的迭代性自研），IT 部门的职责大概就只剩下修电脑了。

而 SaaS 系统越多，自研系统就越少——对于很多 SaaS 系统来说，甚至后续的迭代都可以省掉。

而且，很多 SaaS 系统由于金额较低、应用范围局限于某个部门，往往都是由业务部门自行采购，所以就会发生以下场景：

IT 经理小 B：老大，X 部门采购了一个 XX SaaS 系统。

IT 总监老 A：唉，我还说明年把这个系统纳入整体 IT 规划呢，看来又没我们的事了。

所以，从本质上来说，为什么 IT 部门不喜欢 SaaS，还是因为很多 SaaS 公司的运营方式影响到了他们的切身利益。

但是，哪怕 SaaS 公司再痛恨 IT 部门，都不得不接受一个现实：IT 部门将长期存在，如果我们想要拿下公司级的大项目，就最好让 IT 部门成为我们的朋友。

那如何做到这一点呢？

我觉得首先要摆正心态：IT 部门不是故意刁难 SaaS 厂商，更不是不接受 SaaS 这种产品形态，而是他们的利益受到了伤害。

就以我自己为例，我算是中国最早的一批 SaaS 产品经理，但是在我去甲方负责 IT 工作以后，同样也排斥 SaaS。

因为在甲方，往往是屁股指挥脑袋，所以换谁坐这个位置都一样。

在摆正了心态以后，SaaS 公司还需要积极面对 IT 部门的诉求。

在这方面，很多 SaaS 公司已经有了积极的改变。

比如，建设独立的实施和二次开发团队，专门为大企业定制；

再比如，提供现场实施和支持服务。

当然也有很多 SaaS 公司坚持绝对的标准化产品和远程服务——这肯定也没错——只是这种坚持的代价，就是放弃掉一部分大企业客户。

利弊几何，这就见仁见智了。

还有一些公司做得更进一步，比如某 SaaS 公司就鼓励超大型企业的 IT 公司在他们的 PaaS 平台上研发产品，然后推广给集团子公司，SaaS 公司会主动帮助 IT 公司解决自研过程中的问题。

这种思路兼顾到了 IT 部门的利益，自然会受到 IT 部门的欢迎。

本文由人人都是产品经理作者【ToB 老人家】，微信公众号：【ToB 老人家】，原创 / 授权 发布于人人都是产品经理，未经许可，禁止转载。

题图来自 Unsplash，基于 CC0 协议。