夜雨聆风
|
⚠️ 重伤坑 ｜ 组织内耗 · 部门对立
先说损失。软件年费 18 万，实施集成 6 万，IT 三个人投进去大半年、加上两轮培训，内部成本折算约 4 万。合计 28 万。7 个月后，30 家门店里，日常还在打开这套系统的，最多的时候是 4 家。
（说明一下口径：本文的金额和使用数据来自多位经营者的访谈整理，已做区间化脱敏，是还原量级的近似值，不是某一家公司的精确账单。决策链路和关键对话保留原貌。）
坑不在工具。这套系统功能没出过大问题，验收也过了。坑在立项那天——「谁来定需求」这件事，从头到尾没人说清楚。
读完这篇，你能拿到 7 条红旗信号，在项目启动前判断出这个 AI 项目会不会烂在部门墙上。
|
|
|
完整链路还原
背景：一家连锁零售企业，30 多家门店，总人数 300 人上下。IT 是独立部门，有独立预算。
第 0 月 · 起因
老板去参加了一场行业会议，听同行讲他们门店用 AI 助手查商品参数和促销规则，店员响应快了不少。回来第二天，找 IT 总监：我们也搞一个。
这句话本身没问题。问题是这句话之后，需求链路就变成了「老板 → IT」。中间没有业务。
第 1 月 · 决策（踩坑点在这里）
IT 部门做了完整的调研。对比三家供应商，看 demo，试用，拉了功能对照表，选定一家报价 18 万一年的。流程规范，文档齐全，挑不出毛病。
运营部是什么时候知道的？签约前一周，一封邮件：下个月我们会上一套 AI 门店助手，届时安排培训。
被通知，不是被咨询。这两个词的差别，7 个月后会以 28 万的形式还回来。
第 2 月 · 签约与需求确认
IT 给运营部发了一份需求确认表。表格做得很专业——列了 23 项功能，每项后面是「需要 / 不需要 / 待定」三个勾选框。
运营部三天后回了：全部勾「需要」。备注栏两个字，没问题。
第 3–4 月 · 上线与培训
系统按期上线。IT 组织了两场线上培训，参加的是 30 位店长。培训反馈不错，店长们说功能挺全。
第 5 月 · 第一次预警
后台数据出来了。日活门店：4 家。剩下 26 家，一周打开不到一次。
IT 找运营部。运营部的回复是：店员太忙，接待客人的时候顾不上，我们再催催。
第 6 月 · 老板过问
季度会上老板问了一句，这个项目现在什么情况。运营总监说了一句话，会议室安静了几秒：
|
第 7 月 · 结果
项目实际停摆。合同还剩 5 个月，年费已付，不可退。IT 那三个人转回原岗，重新选型的事没人再提。
|
|
|
这三个节点里，没有坏人。IT 按规范流程做完了选型，最后三个人转回原岗，半年白干。运营部按理性逻辑填完了确认表，最后被追问为什么不用。店员根本没进过这个决策链，却成了「不配合」的那一方。
每个人在自己的位置上都做了合理的事，合起来却是 28 万的损失。这正是组织内耗最难办的地方——它不是谁的错，是这套权责结构在正常运转下的必然产物。所以骂人没用，改结构才有用。
|
红旗信号清单
以下 7 条，出现任意 3 条，这个 AI 项目大概率会卡在部门墙上。这些信号本身就是权责错配的外显。
01. 立项会议纪要里，业务部门的发言总字数不到 IT 部门的三分之一。
危险原因：说明需求不是从业务疼点长出来的，是从技术方案倒推出来的。
02. 需求确认用的是勾选式清单，不是场景描述。
危险原因：勾选不代表认同，只代表不反对。不反对和会用之间，隔着一整个部门。
03. 项目名字里带部门名——「IT 数字化项目」「技术中心 AI 试点」。
危险原因：名字决定归属感。名字里没有业务，业务就会一直觉得这是别人的事。
04. 预算全部走 IT 科目，使用部门一分钱不出。
危险原因：预算科目决定了问责路径。钱从哪个科目出，年底复盘时就找哪个部门要交代。使用部门不在这条链上，效果好坏跟它的经营指标没有任何勾稽关系——哪怕象征性分摊 20%，这条链就接上了。
05. 培训参加的是管理层，不是一线操作者。
危险原因：管理层的「好用」和操作者的「好用」，评价标准完全不同。
06. 上线一个月内，使用部门没有主动提过任何一个功能改进需求。
危险原因：沉默不是满意。真在用的人一周之内一定会有抱怨——没有抱怨说明没有打开。
07. 出现「等系统稳定了再全面推」这类没有具体日期的说法。
危险原因：所有没有日期的推进承诺，都是体面的搁置。
|
立项前自检清单（📸 建议截图保存）
□ 立项文件里有没有一段是使用部门自己写的「问题陈述」？（不是 IT 代写）
□ 验收标准里有没有一条是「使用率」，且写了具体数字和时间点？
□ 预算是否至少有一部分从使用部门的科目出？
□ 试点用户里，一线操作者占比是否超过一半？
□ 需求确认环节，是否问过「你愿意为此改掉哪个现有动作」？
□ 项目负责人是不是使用部门的人？（IT 当技术负责人，不当项目负责人）
□ 有没有约定「试点使用率不达标则不进入全量推广」的中止条款？
七条里对不上三条以上，建议把立项推迟两周，补齐再启动。两周的延期，比 7 个月的停摆便宜得多。
已经卡住的项目，3 步止损
|
|
|
说点可能有争议的
我知道有人会不同意上面的判断。常见的反驳是：这就是执行力问题。老板一句话压下去，谁不用就考核谁，自然就用起来了。
我不同意。压出来的使用率和真实使用率是两回事。前者三个月后一定会掉回去，而且掉得更难看——那时候连「再催催」的余地都没有了。
但我也知道，肯定有公司是强推跑通的。如果你手上有这样的真实案例，评论区说说你们具体怎么做的。那条线是怎么撑住的，我很想知道。
什么类型的经营者天然免疫这个坑
如果你公司总人数在 30 人以内，老板本人就是主要使用者之一——需求和使用之间没有传递损耗，想到什么就自己用什么，这个坑基本踩不到。
如果你们的 IT 不是独立部门，而是挂在业务线下面（比如运营部里有个技术岗），决策链只有一层，也不容易踩。
真正的高危区间，是同时满足下面三条的公司：
· 总人数 150 到 800 人
· IT 独立成部门，且有独立预算
· 业务部门有明确 KPI，但 KPI 里不含数字化指标
三条全中的，这个坑不是会不会踩的问题，是踩几次的问题。
|
|
|
|
|
