市场团队工具泛滥的隐性成本

一个市场进入团队购买的每一个工具，都有两个价格。一个是 SaaS 账单上的那一行数字，另一个则是这个工具此后索取的一切：学习它所花的时间、连接它所付出的精力、被它单独切割出去的客户数据，以及它从销售工作中抢走的注意力。对大多数收入团队而言，第二个价格远远大于第一个，而它几乎从不会出现在预算评审中。

工具泛滥，就是这些隐性成本在几年之后呈现出的样子。没有人是刻意决定要让技术栈变得难以管理的，它是通过一个个看似合理的决定，一个团队接一个团队地悄然蔓延，直到整个组织在运行几十个功能重叠的应用，没人说得清一半工具究竟归谁负责，销售代表每天要花相当一部分时间在各种工具之间反复登录、退出。

泛滥是一种症状

把泛滥当作一个采购问题来处理，是很有诱惑力的：采购太多、监管不足。但泛滥其实是另一个问题的下游产物：市场进入工具市场本身，就是为了向各个独立团队销售狭窄、专业化的产品而搭建起来的。这与你的收入技术栈为何正在碎片化背后是同一股力量。

当每个团队都可以自行采购、每个厂商都只解决工作流中的一小片段时，泛滥就是事情自然而然会走向的结果。解决它，要从理解每个工具在订阅费之外真正的代价开始。

首先是认知负荷。每一个销售代表必须学习并记住的工具，都是对注意力的一种税，而上下文切换从来都不是免费的。一个要同时应付八个应用的销售者，绝不可能把一整天的时间都花在销售上，他们会把大量真实的时间损耗在重新进入状态上。

其次是新人上手的拖累。新员工既要学习你的产品、你的市场，还要学习你整套工具生态系统。技术栈越庞大，达到完全生产力所需的时间就越长。在碎片化的组织里，上手周期会从几周拉长到几个月，这直接推迟了你雇佣的每一位销售者能为公司带来收入的时间。

第三是数据碎片化。每个工具都各自保留着一份"这个客户是谁、做过什么"的版本。协调这些不同版本既昂贵又容易出错，而这些缝隙会变成一个收入问题，而不是 IT 问题。基于不完整数据做出的决策，就是糟糕的决策。

第四是集成开销。那些无法原生协同工作的工具，必须被拼接在一起，而这种拼接工作是一笔持续产生的账单，既消耗资金，也占用工程精力。这就是集成税，而且它是随着连接数量、而不是工具数量增长的，这使情况变得更糟。

以及许可证浪费。工具泛滥会滋生"僵尸订阅"：一个从未真正结束的试点项目、分配给已离职员工的席位、两款功能几乎重叠的产品。大多数组织都在为自己早已遗忘拥有的能力持续付费。

你不需要请一家咨询公司来做这件事，一个粗略的估算就足够了。

统计实际在使用的市场进入工具，包括那些 IT 部门并不知情的影子工具。估算每位销售代表每周花在导航、重复录入或跨工具核对数据上的小时数，乘以满载的销售人力成本和人员数量。再加上用于集成中间件的年度支出，以及维持其运转所需的工程时间。最后再加上新员工上手延迟所对应的配额达成延迟。

得出的数字通常令人吃惊。对不少团队来说，工具泛滥的隐性成本，甚至超过了整个可见的软件预算。销售代表在各工具之间来回切换的转椅式困境，往往是其中最大的一项。

购买一个工具会让人感觉自己做出了果断的决定：它填补了一个显而易见的空缺，还配有一场看起来很出色的演示。但每一个新工具，都是一个网络中的新节点，而这个网络的复杂度增长速度，往往超过其能力的增长速度。

一套技术栈的价值，取决于其各部分之间协作的质量，而不是部件的数量。一支拥有六款彼此协同工作的工具的团队，几乎总能胜过一支拥有十六款互不配合的工具的团队。表面积越大，接缝就越多，而价值恰恰是从接缝处流失的。

所以，应对泛滥的答案很少是"买一个更好的工具"，而是要改变你所保留的这些工具彼此协作的方式。这更多是一个编排问题，而不是一个采购问题。

如果泛滥已经在你身边悄然滋生，从小处、具体处入手。

如果你怀疑自己的市场进入技术栈正在悄悄地拖累团队，绘制出协作断裂的地方，是一个很好的第一步。而这正是收入编排存在的意义所在。