SaaS 工具蔓延: 50 个工具的难题与解法
SaaS 工具蔓延指的是一家中型公司最终为超过 IT 或财务部门任何人凭记忆能说出的软件工具数量付费,通常超过 40 到 50 个工具,其中多个工具在做同一件事,一些席位没人记得是分配给谁的,也没有任何一个人对完整清单负责。解决办法不是一次性清洗,而是用三个互相核对的来源清点工具、为每个工具指定一位负责人,并建立按季度更新清单的常规流程,而不是每年审计时才重新拼凑一次。
- SaaS 工具蔓延不只是工具数量问题;而是在不做审计的情况下就无法回答“我们在为什么付费”。
- 它源于自助注册、转为付费的免费试用、外包人员带来的工具以及部门级采购,而不是一次糟糕的决定。
- 真正的成本是重复支出和无人追踪的访问权限,而不是订阅总额本身。
- 找出真实清单需要三个互相核对的来源:单点登录日志、信用卡账单,以及直接询问各团队负责人。
- 在不引发抵触的情况下削减工具,意味着提前90天通知并提供迁移指南,而不是当天就取消访问权限。
SaaS 工具蔓延到底是什么?
SaaS 工具蔓延不只是工具数量多。它指的是公司里没有任何人,无论是IT、财务还是任何一位团队负责人,能在不做一次审计的情况下列出公司正在付费的全部订阅。两家公司可能都在用 40 个 SaaS 工具;如果一家公司已经有一份表格记录着这 40 个工具、每个都有负责人,它就没有蔓延问题。如果另一家公司必须靠信用卡账单和猜测才能重建这份清单,那就是蔓延。
具体数字不如责任缺失重要。蔓延的本质是没有一个唯一、最新、可信的答案能回答“我们在为什么付费”这个问题,而这个缺口通常在中型公司的工具数量超过 40 到 50 个之后出现,因为那大致是一个人的记忆力开始不够用的临界点。
中型团队是怎么用到 50 个甚至更多工具的?
蔓延很少来自一次糟糕的决定,而是由多个各自看似合理的选择累积而成。
- 用公司卡自助注册。任何持卡员工都能在几分钟内开通付费计划,而且没有任何采购环节把这笔支出记录在案。
- 免费试用转为付费。为测试某个功能开通的试用,在没人注意的情况下自动续费变成付费计划,没人记得自己批准过。
- 外包人员和被收购团队带来的工具。外包人员带来自己的项目管理工具,或者一次收购带来了整套软件栈,两者都会在早该被重新评估之后仍继续被使用。
- 部门层面的零散采购。市场部买了一个财务从没见过的工具,销售部又买了一个IT从未通过单点登录接入的工具,而每一次采购单独看都说得通。
- 采购时没有指定负责人。如果没有规定新工具在刷卡前必须挂一个具体负责人的名字,后续就没人负责复核它。
除了订阅费本身,SaaS 蔓延到底要付出什么代价?
订阅费总额是看得见的成本,通常也不是最大的那一项。
重复支出是第一项隐藏成本:两个设计工具、三个项目跟踪工具,或者一个没人真正使用却和主力工具并存的聊天软件,各自单独计费,因为没人按功能而不是按厂商名称把它们归到一起。
无人追踪的访问权限是第二项,也是更严重的一项。每一个工具都意味着多一个登录入口,而一个没人复核的登录往往比申请它的人在职时间还长。共享或被遗忘账号带来的合规风险会随工具数量增长,而不是随订阅费高低增长,而这恰恰是审计员最先发现的问题。
第三项成本是续约时的议价能力。如果供应商在和一家说不清究竟用了多少个席位的公司谈判,它没有任何理由给出更好的价格,因为公司自己都拿不出理由要求更少的席位。
怎样才能找出公司真正在付费的每一个工具?
没有任何单一来源能给出完整清单。三个来源互相核对,才能接近真相。
| 来源 | 能看到什么 | 会遗漏什么 |
|---|---|---|
| 身份提供商/单点登录的登录列表 | 所有人通过单点登录访问过的应用 | 用个人账号而非单点登录访问的工具 |
| 信用卡和报销账单 | 所有周期性扣款,包括IT从未批准过的 | 月账单上容易被忽略的年度扣款,以及通过发票而非信用卡支付的费用 |
| 直接询问各团队负责人 | 口头批准购买的工具,以及即将续约的工具 | 完全取决于对方是否记得、是否愿意说 |
在 InventorIA 的演示工作区里,登记册涵盖 6 家供应商的 24 个许可证,这个规模还小到一个人能把整份清单记在脑子里。蔓延通常在公司超过这个数字的两三倍时开始出现,到了 50 个工具,已经没有一个人的记忆能覆盖全部,这正是为什么三方来源核对必须取代记忆,而不只是补充记忆。打开实时演示,看看当每个许可证都挂着一个负责人和席位数时,这种规模的登记册是什么样子。
怎样在不引发抵触的情况下削减重复工具?
用错误的方式砍掉一个工具,引发的抵触会比蔓延本身更大。按以下五步顺序操作,能避免大部分冲突。
- 按功能而不是按厂商名称分组。列出每个工具实际在做什么,而不是它叫什么名字,并标出任何有三个或更多工具声称能覆盖的功能。
- 先问使用最频繁的人。在IT决定保留哪一个重复工具之前,先问用得最多的人会保留哪一个、为什么;他们的理由通常反映的是真实的工作流依赖,而不只是个人偏好。
- 给出90天和一份迁移指南。一夜之间断开访问最容易引发抵触。带有明确日期和替代工具使用说明的通知很少会。
- 把被淘汰的工具保留一个计费周期作为后备,而不是整整一年,这样如果有人发现被忽略的依赖关系,还有时间提出来,而不是让决定默认无法撤回。
- 取消许可证,而不只是移除席位,在使用量连续一个完整周期为零之后再取消;只移除席位仍会让订阅和续约日期保持有效。
怎样防止工具数量再次悄悄增长?
一次清理如果后面没有跟上例行流程,效果只是暂时的。三个习惯能防止问题复发。
第一,任何信用卡扣款都必须挂一个具名负责人。要求任何新增 SaaS 扣款都必须有明确姓名、并在当天完成复核的采购规则,能堵住当初让蔓延开始的那个漏洞;关于购买之后而非购买当下运行的这类检查,可参考影子IT检测指南。
第二,按季度复核,而不是按年度。许可证使用率指南介绍了每季度都值得核对的已购席位与实际使用席位对比;一个工具如果连续两个季度使用率接近零,就是明确的取消候选对象,而不是“再看看”。
第三,建立一份所有人在采购前都会查阅的登记册,让新购工具前的第一个问题变成“现有工具是否已经能完成这项工作”。创建你自己的登记册,赶在下个季度的续约到来之前完成,这样下次审计时这个数字是一个已知值,而不是一次临时估算。
Okta 每年发布的Businesses at Work行业趋势报告会追踪各类组织每年通过单点登录连接了多少云应用,是应用数量在各种规模公司中持续攀升这一趋势最清晰的外部信号之一。云安全联盟也针对同样增长趋势的安全一面发布了治理指南,等清单本身理清之后值得一读。
常见问题
SaaS 工具数量到多少算是蔓延?
没有固定数字,但一旦超过大约 40 到 50 个活跃订阅,大多数中型公司就会失去凭记忆说出每一个工具名称的能力,这才是蔓延的实际定义,而不是一个精确的数字。
SaaS 工具蔓延只是IT部门的问题吗?
不是。财务承担重复支出,安全部门承担每个工具带来的登录攻击面,合规部门承担审计线索;只让IT参与的解决方案会漏掉另外两个方面。
找出隐藏的 SaaS 工具最快的方法是什么?
把单点登录的登录列表和信用卡、报销账单交叉核对。一个出现在信用卡账单上却不在单点登录列表里的工具,要么没被纳管,要么正被人用个人账号访问,两种情况都值得进一步核查。
修复 SaaS 工具蔓延需要专门的软件吗?
不需要,用一张表格交叉核对上述三个来源就足以完成第一轮排查。当清单长到手工维护开始跟不上时,专门的登记册才真正值得投入,而这通常正是蔓延变成真实问题的那个节点。