夜雨聆风
SaaS将死,未来的软件由业务专家开发
人 机 协 同 系 列
从3000亿市值蒸发说起
SaaS将死，未来的软件由业务专家开发
一个动销率指标，暴露了所有经营系统的致命缺陷
当AI把造软件的成本打到接近零，
决定系统好坏的，不再是代码能力，而是业务理解深度。
2026年2月3日，美国软件板块单日蒸发大约3000亿美元市值。LegalZoom暴跌近20%，Salesforce下跌7%，Adobe跌超5%。市场给这个事件起了个名字：SaaS-pocalypse，SaaS末日。
触发这场恐慌的直接原因是AI Agent的能力突破。Anthropic发布的Claude Cowork可以自动审合同、做销售线索挖掘、甚至自主写代码。投资者突然意识到一个问题：如果AI能直接完成工作，企业还需要买那么多SaaS账号吗？
贝恩公司2025年9月发布报告，标题就是《Agentic AI会颠覆SaaS吗》。IDC同年12月发文：《SaaS已死？》。CIO杂志2026年3月的结论更直白：”AI带来的不是SaaS的崩溃，而是范式转移——组织开发和获取软件能力的方式正在被根本性改变。”
但在我看来，这场讨论漏掉了一个关键视角。SaaS真正的问题不是AI抢了它的生意。而是SaaS从一开始就做错了一件事：它把企业经营系统当成了技术产品来卖。
于是需求交给产品经理翻译，指标交给数据团队定义，最后出来的东西——界面很漂亮，数据很齐全，但经营判断是错的。
我用一个具体的指标说清楚这件事。
01
动销率：一个看起来正确、实际会骗人的指标
动销率的定义很简单：过去30天有出货的SKU除以在售SKU。42%意味着你100个品里有42个在卖，听起来是个清晰的健康度信号。
大部分公司的BI系统里都有这个指标。如果你用的是市面上任何一款主流SaaS BI工具，它内置的分析模板里大概率也有。数据团队算得没错，前端展示也没问题。
但它在很多业务场景下，会系统地误导判断。
核心原因只有一个：真实销售不是平滑的。
电子元器件行业，一个大客户下单就是一个月的量；团购业务，一波促销顶半个月销量；ToB订单，审批通过那天集中发货。这些场景的共同特征是——平时几乎没动静，偶尔一天爆量。
如果你直接拿原始数据算30天动销率，会发生一件事：某个SKU在25号卖了一次大单，它就被计为”动销”。但实际上，它之前29天没动过，之后可能又沉默一个月。
关键判断它不是“在稳定地被需要”。它只是“碰巧被买了一次”。
系统告诉你动销率42%，你觉得还行。于是继续备货、继续压资源。库存越来越大，现金流越来越紧，但仪表盘上一片绿灯。
这不是数据算错了。是指标的”问法”本身就问错了。而SaaS产品的本质决定了它没法不问错——因为它是一个通用产品，它的指标逻辑是为”大多数客户”设计的，不是为你家的业务场景定制的。
02
正确的做法：先还原真实需求，再谈动销
解决思路不复杂，但需要做一个关键区分：
本质区分“有没有卖过”和“是不是在稳定被需要”，是两件事。前者看的是极值——只要有一次非零记录就算数。后者看的才是趋势——在时间维度上，需求是不是持续存在。
具体操作分两步：
► 第一步，7天滚动中位数平滑把每日销售量按7天窗口取中位数，得到一个平滑后的日销售序列。中位数的特性是它不会被偶尔的大单或促销尖峰拉偏，它反映的是”大多数时候卖多少”这个水平。
► 第二步，用平滑后的序列重新判定动销设定一个阈值——比如平滑后日均销量大于等于1件（或根据品类调整），才算”真正动销”。低于阈值的，哪怕某天有大单，也标记为”偶发性动销”或直接归入滞销。
做完这一步，你会经常看到一个现象：原始动销率和修正后动销率之间，差距可能达到15到25个百分点。这25个百分点的SKU，就是你一直在错误投入资源的对象。
操作上，这件事不需要多高深的算法。Excel就能跑，任何BI工具都支持窗口函数。关键是有没有人意识到需要做这一步。
而这一步，永远不会出现在SaaS产品的标准功能里。因为它不是一个技术问题，它是一个业务判断。
03
为什么SaaS很难主动做对这个问题
不是因为SaaS厂商能力不够。是因为这是一个商业模式层面的结构性矛盾。
SaaS的逻辑是：做一个标准化产品，卖给尽可能多的客户，用规模摊薄成本。这意味着它的指标体系必须是通用的、普适的、不需要太多定制就能用的。”30天动销率”之所以成为标配，恰恰是因为它最简单、最直观、最多人能接受——而不是因为它最准确。
但你家企业的真实业务场景，从来不是”大多数客户”的那个平均值。
工程师的任务是：把指标算准、把页面做好、把数据链路跑通。”30天动销率”的需求传过来，他按定义实现，没有任何差错。
但经营分析要回答的问题是另一个层面的：这个指标会不会误导决策？它捕捉到的是不是真实的业务状态？基于它做的动作会不会放大风险？
德鲁克的判断“你衡量什么，你就管理什么。反过来，你衡量的方式错了，你管理的方向也就错了。“
问题在于，传统模式下企业的指标定义流程是这样的：业务提需求→数据团队/SaaS产品定义口径→工程师开发上线。这个链条里，没有人坐在”经营判断”的位置上问一句：这个指标的口径，会不会骗我们自己？
结果就是一个结构性缺陷：系统能够精确地计算一个错误的答案。
而且这种错误特别隐蔽。因为系统看起来一切正常——数据准时更新、图表色彩丰富、下钻路径完整。SaaS产品的UI设计越来越精美，但背后的判断逻辑可能是错的。
04
从”展示数据”升级到”触发动作”
这也是我认为未来真正的经营软件不会来自SaaS厂商，而是由业务专家自己开发的原因。
业务专家不需要最漂亮的图表。他需要的是：指标口径是自己定义的、判断逻辑是嵌入了自家业务场景的、系统输出的是动作建议而不是数据展示。
真正有效的经营系统，不应该停留在”告诉你动销率是多少”。它应该做到三件事：
▪ 能识别问题不是简单地标红，而是区分”真动销”和”假动销”，自动标记那些被误判的健康SKU。
▪ 能提前预警当某个品类的修正动销率连续3周下降，或者偶发性动销SKU占比超过阈值时，主动推送预警，而不是等人去翻报表。
▪ 能推动动作预警之后直接生成任务清单——哪些SKU需要清理、哪些需要降库存、哪些停止推广、哪些资源转移到高周转品项。任务落实到人，有截止日期，有闭环检查。
这三层合在一起，才叫经营系统。缺了任何一层，都只是一个高级报表工具——无论它是自研的还是SaaS订阅的。
落地动作：指标健康度审计拉出你公司最核心的10个经营指标，逐个做一次审计。三个核心问题：① 这个指标的口径会不会被异常值干扰？② 它反映的是”事件”还是”趋势”？③ 基于它做的历史决策，有没有事后验证过准确性？
这三个问题，大部分企业从来没正式问过。大部分SaaS产品也不会帮你问——因为这超出了它的产品边界。
05
所以我在做「战略经营作战指挥系统」
前面说的这一切，不是我凭空想出来的。是我过去几年在企业一线做经营分析和战略落地时，一遍遍踩出来的坑。
我看到太多企业花了大价钱上系统，最后得到的都是一个漂亮但错误的东西。问题从来不在技术栈，而在谁在定义这套系统的”大脑”——也就是那些指标的判断逻辑。
这也是我做星锚战略经营作战指挥系统的出发点。
星锚不是一个BI工具，也不是一款SaaS产品。它的底层逻辑完全不同：
核心定位这套系统是从战略设计和经营实战中长出来的，不是从产品规划文档里设计出来的。
具体来说，它解决的是三件事：
▪ 战略怎么拆到业务动作不是停在PPT上的”今年要增长30%”，而是拆到每个部门、每个月、每个关键动作，并且每天能追踪执行进度。
▪ 经营问题能不能被及时感知就像前面说的动销率案例——系统不会机械地展示一个数字，而是内置了业务判断逻辑，能区分真信号和假信号，提前预警。
▪ 问题出现之后能不能自动闭环发现异常→推送预警→生成任务→跟踪执行→复盘结果。全链路跑通，而不是开完分析会就散了。
这三件事合在一起，才是一个真正的作战系统。
而这套系统能做到这些，根本原因只有一个：它是由懂战略、懂经营的人，借助AI工具开发出来的。每一个指标的定义、每一个预警的阈值、每一个任务推送的逻辑，背后都是真实的业务判断，不是工程师对需求文档的理解。
— * — * — * —
2026年这场关于”SaaS生死”的讨论，最终会收敛到一个结论上：稀缺的不再是造软件的能力，而是对业务的理解深度。
当AI可以把代码成本降到接近零的时候，决定一个经营系统好坏的，就不再是UI好不好看、功能全不全、架构优不优雅。而是：定义这套系统的人，到底懂不懂这门生意？
没有业务理解，指标会选错，口径会设计错，判断会被误导。最后出来的东西再漂亮，也只是在一个错误的认知基础上做了一个精致的呈现。
核心结论先想清楚怎么判断，再去想怎么计算。顺序不能反。
未来的经营软件，一定是懂业务的人用AI工具搭出来的。不是因为他们会写代码，而是因为他们知道该算什么。
不是看数据。是让数据推动经营。
锚在新宇宙与你一起，让AI为组织赋能
专注于战略设计与落地和经营体系优化：助你打通战略设计，目标拆解，组织优化，经营分析，考核激励全流程
