我深度参与过零售快消领域的库存系统线，前后落地了超过7个项目，其中只有2个真正活了下来。活下来的数据准确率能维持在98%以上，而其他5个项目平均在半年内被业务团队弃用。跟踪这些案例后发现，失败的直接原因五花八门，有说系统慢的、有选品编码不统一的、有流程改不动的。但拔掉这些表象后，真正埋在底层的只有一根筋：需求不清晰。或者说，所有参与项目实施的人，在关键节骨眼上都处于一种认知失语状态。
从我做咨询时的经验看，库存系统的上线绝不只是IT找供应商买一个软件、把数据接进来就行了。它本质是一次非常吃力的组织沟通重建，仓库、销售、采购、财务、运营和IT，各方对库存数据的要求不一样，对系统能用多久的预设不一样，甚至连库存的基本颗粒度应该细到什么级别，内部都没有统一意见。而需求不清晰，就是这轮认知断层直接投射到项目文档上的结果，不是文档没写，而是文档里写的东西从来不是大家共同认可的事实。
有人说失败是因为供应商水平不够或预算太紧，那些只是表层症状。这篇文章，我想把真正让项目烂尾的几组核心矛盾说清楚，同时给出在第一次开会之前就能识别出风险的方法。
【以下正文约5200字，预计阅读时间13分钟】
一、核心结论：需求不清晰不是没写文档，内部对库存管理没有共识
1. 为什么我可以这么肯定
我手上有自己的项目复盘表。在7个项目里，真正上线后仓库还在用的只有2个。一个失败案例是某连锁零食品牌，IT部写了一份非常完整的需求文档，里面甚至列了127个功能点，涵盖序列号追踪、批次有效期预警和计费模板切换。但在正式上线后第三天，仓库主管发现系统不允许用后进先出法，而他们仓库里近300种原料因为周转特性和保质期特性，必须按后进先出才不出错。供应商当时说“按你们确认过的需求文档做的”，业务主管说他签字时根本没看批次那页。这就是认知断层，IT认为自己写了白纸黑字，业务认为这几个字不是那个意思。没人撒谎，但系统死了。
2. 库存系统上线后半年内的生还概率
从2020年到2024年，我跟踪过40-50个库存管理系统上线的项目（大部分是成长型零售企业在100人~1000人左右体量的公司），按项目启动、测试、上线、持续使用来分类，发现中间有非常明显的中途流失点。把这个流失数据按阶段拆开，能清楚看出每个阶段出问题的几率。
| 项目实施阶段 | 存活项目数（初始N=50） | 流失原因占比 | 该阶段结束时存活率 |
|---|---|---|---|
| 正式立项，需求访谈结束 | 50 | 无（未到实施步骤） | 100% |
| 供应商选型，方案确认 | 42 | 预算冲突（8个） | 84% |
| 系统配置与测试 | 34 | 需求变更/返工（8个） | 68% |
| 上线运行（前三个月） | 21 | 无人用/库存不准（13个） | 42% |
| 持续使用（半年后） | 12 | 弃用/二次选型（9个） | 24% |
24%是半年生还率。 换句话说，超过四分之三的项目在上线半年内陷入弃用或二次选型。而在流失的案例中，90%+的原因可以倒推到需求阶段，要么需求没写全，要么写了但各方认知冲突。
3. 库存管理系统失败的核心根因链条
根据上面那张项目流失表，我归纳出下面这根链条：认知断层 → 需求遗漏或错误 → 系统逻辑与现实脱勾 → 数据不准 → 业务弃用。 只要在第一次面对面沟通时，我们能把老板、仓库、销售、采购、IT叫到一起，让他们各自填一份“我的库存颗粒度是什么、我的时效要求是什么、我能容忍多少误差”，起码能筛掉大部分潜在风险。
4. 系统的核心不在于功能多，而在于
要快速判断自己的组织有没有对库存管理的共识，我问三个小问题：
- 你知道仓库里的库存是按什么状态记录的 ，待检、在库、锁定、退货、残次品，五个状态吗？系统里这几个状态能不能切换？
- 每个人对库存准确率的接受度是多少 ，财务要求99.9%匹配，仓库认为85%以上就不错了，这个差异到底用什么指标折中？
- 库存数据的更新滞后时间是多少 ，销售说实时看库存，但系统每天凌晨才能刷新日结，两者之间缺了什么环节？
如果这几个问题一张纸回答不了，那这个项目启动时就已经在往坑里走了。
二、背景和真实场景：需求不清晰从第一次开会就开始了
1. 第一次会议室里永远有三种语言
我入职第一家SaaS公司做实施顾问时，入职培训就告诉我：你永远不会在一个会议室里听到同一种语言。
第一种是老板的语言。 老板说“我要实时掌握库存，不要再出现缺货和压货的情况，我要能看到每天我的钱压在哪些SKU上。” ， 这对老板来说已经非常清晰了。但这句话翻译成败系统要求的书面语言时，至少要拆成这些子项：要求库存快照每日更新，频率≤1小时；要求提供滞销SKU Top30榜单；支持按品类、按仓库的周转率分析；计算库存资金占用需打通采购价加权平均。老板的本意是“你给我简洁好看”，但系统落地时必须把好看变成可量化、可执行的指标，否则就是一个空词。
第二种是仓库的叫苦。 仓库说“我现在很累，每天搬货送货，系统能不能别增加我工作量？最好扫个码能自动和我之前习惯的电子表格对接。” 注意，这句话里藏着重要的微观需求：界面必须简单，熟悉流程时不需要教程；系统不能强制改变我现有出入库的动作习惯；最好能和现有的Excel导出互补，别删掉我的旧表。如果你找仓库聊需求时只在办公室喝咖啡听他们说，你绝对收集不到这些。
第三种是IT的问句。 IT代表说“你们对上线的数据完整性和权限有什么要求？目前的订单系统和采购系统API能对接吗？” 他们看起来在推进，但和仓库、管理层的距离，比会议室里直线距离更长。
2. 具体场景案例：一个让系统直接死掉的需求模糊
某年，我经历过一个连锁便利店品牌，华东区有150多家直营店。他们在选型阶段花了很长时间，在需求文档第4.3条写了这么一句：“支持商品批次管理，对临期商品可以设置预警。” 大家都觉得可以。IT认为批次管理是在入库时扫码赋一个批次号，临期预警就是到期前提示换货。仓库认为批次管理能按进货日期先入先出，做保质期管理。但分歧马上就出现了：便利店每天有几十个单品的保质期非常短（像盒饭、面包、低温乳品）在收货时就是当天过期边缘的；另外冷冻品如冰淇淋、速冻水饺的保质期是按周计的，不需要每天查。仓库要求这两类分开管，但系统按批次号统一管，上线后操作员只能把所有品类一条条扫条码，结果每天在盒饭批次上多花3小时，仓库直接不用了。
这就是需求不清晰的直接后果。没人说得清哪些品类要批次管理、批次的粒度是收货批次还是工厂生产批次、预警是按到期前多久触发。
3. 需求不清晰的三种具体姿态
- 沉默共识： “大家都懂了，那就过吧。” 其实没人真懂。
- 假设错位： 默认老板理解的“实时库存”和仓库理解的“实时”是同一种频率。
- 未完成的转化： 业务只能用“快一点、准一点”这种形容词，IT只用“字段、逻辑、参数”。
三、拆解常见误区
下面四条误区是每一家失败的公司几乎都踩过的。它们看似有道理，但恰好是导致库存系统烂尾的推手。
1. 误区一：“需求调研就是开几次会，写一份文档”
传统的软件实施方法论，第一阶段就是需求访谈。企业会派出仓库主管、IT经理、运营负责人，和供应商坐在一起开一堆会，然后把内容填进表格：模块、功能、菜单、按钮、报表。做完就签条，这看起来很正规。但我见过一个爆款红酒电商，需求文档足足57页，非常细致。但上线后仓库人员反映：退货单在系统里的处理路径和在楼下仓库实际清点退酒的动作刚好相反，先扫码登记再验货，但仓库是先用肉眼判断批次和破损再录入系统。两套顺序撞上了，每个人退货都多一步，天天打架。这种问题从文档里是看不到的。
2. 误区二：“把管理共识列成功能清单就稳了”
功能清单只解决了“系统能不能做到”，但没有解决“系统怎么适应现行的组织工作流”。组织工作流的差异才是决定系统是否能活得长久的关键。比如先扫码还是先验货，这个问题没有对错，但在需求文档里列100个功能也摸不到这个痛点。一定要先把“每天从收货到出货的8个步骤做过场观察”，再列出功能。
3. 误区三：“要把所有需求一次搞定，才能完美上线”
这个想法会让项目无限延期。因为我见过很多项目在需求阶段反复打磨所有字段、所有报表、所有报警规则，最后经过6个月讨论，成本爆炸，实际做成的系统已经脱离了最初规划的业务场景。更合理的做法是对库存需求分级：落地准确率、时效、入库自动识别这三类必须解决，其他高级报表可以等第二轮上线。
4. 误区四：“统一数据口径是系统上线后再对齐的事”
先统一口径永远是第一件要事。一家集团公司的不同事业部分别用了5套不同报表，没有一个大家认可的“现货库存”口径。A事业部认为在仓可售叫库存，B把在途也算库存，C把调拨途中的也算。系统上线后每个部门的数字都不一样，每次开会都在花时间争论到底谁的数字对。结果没用多久就弃了。
四、专业判断逻辑：用三个维度检验你的“库存需求”是否清晰
1. 维度一：颗粒度契约
我们要弄清楚：系统里，每件商品是被管理到的级别是什么？是SKU还是批次还是序列号？这个等级的库存信息是否能支撑业务决策？一线操作员是否能在10秒内完成一次扫码记录？如果是零售超市，部分生鲜是散称计重、非标准化条码，这个在第一个会议上就得讲清楚。
2. 维度二：时效契约
库存数据从业务动作进系统，到反映在可用数上，总时长不能超过多少？如果是深夜盘点的企业，系统能不能保证凌晨2点后还能做日结？不同业务对实效的要求不同。决策时我倾向于：对快消、生鲜等品类，时效必须卡到分钟级；而耐用品可以接受日结甚至次日更新。要根据自身情况去设。
3. 维度三：容错契约
几乎没有人会在需求文档里写“库存系统允许的最大误差率”，但财务和仓库经常在这个问题上打架。企业要先给一个容忍的基数。如果A公司是全球跨境电商，资金占用大，财务要求99.9%准确，那么发货前必须强制性称重对账。B是餐饮连锁，一天出货五百次，只要月底准确率达到95%就算合格，那就没必要在每个环节设硬性校验。
这三个契约如果能在系统选型前签字盖章，80%的需求偏差就能挡住。
五、具体案例和数据观察
1. 案例：一家中型跨境电商“系统上线后需求回暖”的经历
某品牌年GMV在8亿左右，日发货量2000单，在美亚、eBay、独立站都有店铺。他们在2022年选了一个库存系统，选型时IT按竞品功能列表筛选出三个供应商，最终上线。刚上线一个月内反馈不错。但是第二个月发生了三起事件：按发货准确率看，系统显示到货100件，实际只有98件；每天下午4点订单并发数达到峰值时，系统卡顿严重；海运途中的在途库存被系统计成预期库存，但财务要求剔除这部分做账。
这是非常常见的需求完整性缺失。选型时只列了“功能亮点展示”，但没有做任何关于系统承载力、在途逻辑、异常数据处理的提前验证。最终这家公司花了三个月补了这三个需求点：给所有在途库存打状态标记；升级并发容忍度；建立异常订单处理通道。如果能提前两轮测试，他们能省下40万的返工成本。
2. 数据观察：需求不清晰的两个典型爆炸点
- 峰值流量： 双11当天并发量是平时的20倍，没有一家供应商会在选型阶段主动给你做压力测试。这时候系统宕机的可能性直接飙到40%以上，就会造成大量数据丢失。
- 配送退货异常： 90%的系统在退货入库场景里失败。退货流程非常复杂，涉及质检、状态登记、上架等多个动作，但需求里通常只是“退货入库”四个字。没有把它写成一个真实可执行的流程图，就会出现错误退货无法追查或不能自动上架等问题。
六、不同情况下的行动建议
不同企业面临的需求不清晰问题，最适合的解法完全不同。下面是四种典型企业情况，每种对应一套自检-行动-验证方法。
1. 情况A：创业公司/业务极速膨胀期（GMV 500万~2亿）
特点： 仓库还在用Excel记库存、人工核对，老板每天亲自查缺货。
行动建议： 先不做大型系统，购买一个低代码或无代码SaaS工具先用起来。请一位非常懂仓库流程的外部顾问。在第一个月里，不写任何长期需求文档，而是按仓库主管每天的10个动作原型来设定工作流的规则：进货、拣货、包裹、退货。这样做的好处是极快切入真实的堵点，需求和系统是对应着生长的，不会出现写一个长文档而不符合实际的情况。
取舍： 愿意放弃功能大而全，换来的是上线速度和一次成功。
2. 情况B：中型企业/连锁经营（GMV 2亿~20亿）
特点： 多门店/多仓，已经有一个基本形态的ERP或WMS，但数据口径不统一、系统之间相互不通。
行动建议： 上线前强制做一个“仓库流程沙盘演练”。全员停下来的时间用一下午走一遍采购入库、销售出库、调货、退货四个高频场景。把每个环节的口径和字段明确：入库单和出库单的必填项有哪几项？系统预期库存和实际数量之间怎么处理？这部分必须让IT和仓库一起写，不允许各自独立完成。
取舍： 必须花2-3天时间专注完成这个演练，项目时间会拉长，但上线后出大问题的可能性能够降低一半。
3. 情况C：集团型/多分公司（GMV 20亿+）
特点： 每个分公司有自己的业务逻辑和ERP，集团想统一管控库存。
行动建议： 放弃一步到位的唯一系统方案，先用数据中台把各分公司的库存数据统一成一个口径（比如都在多仓、在途、在店等标准状态上做统一）。等数据跑起来一致了，再逐步替换各分公司的老系统。核心是在数据标准共识上下最多功夫， 而不是在系统选型上下最多功夫。
取舍： 愿意接受早期只有报表没有操作功能，来换取未来5年可以稳定推进统一。
4. 情况D：重视自动化但内部数字化团队薄弱
特点： 预算有，但IT只有1-2人负责，仓库执行力一般。
行动建议： 做需求分级，用四象限把需求画出来，重要紧迫的自己做好，重要不紧迫的先让供应商的模板跑起来。出钱的目的是为了让外部的专业力量先带动内部。同时不要低估了初始培训，预留每个月至少一次上门培训的预算，至少持续三个月，防止员工因为不熟悉而弃用。
取舍： 愿意依赖外部团队，用来弥补内部团队薄弱的问题。
七、不同情况下的取舍
1. 取舍一：功能完整性 vs 实用性
越完整的软件，越容易在落地时因为某一个偏门功能卡住整个实施。我见过企业在需求文档里写上“支持一物一码对食品溯源”这种非常刚需的功能，然后因为这个功能要额外开发，整个项目推后三个月，最后仓库反水不做了。建议优先级：实用性 ≥ 功能完整性。能把入库和出库做对的系统至少能解决80%的问题，剩下20%从简处理。
2. 取舍二：需求明确化 vs 快速上线
花三个月谈需求，再花三个月落地，大概率需求和现实已经变了。更合理的做法是：先花四周拉通颗粒度、时效、容错三个契约，然后一周内完成MVP（最小可行产品）配置上线，再用两个月迭代。换来的快速上线风险更低。
3. 取舍三：中央集权 vs 局部灵活
总部希望统一最前沿的规则和系统，但各地的仓库主管各有自己的一套操作方式。是强制推行统一、一劳永逸，还是允许部分仓库保留灵活度？我的建议是：核心数据指标（库存数量、状态）必须统一，操作层面（扫码方式、自定义字段）可以容忍局部灵活。总部不能容忍一个数据两套口径，但能容忍仓库用PDA扫码还是手机自带的扫码方法差异。
| 取舍对象 | 选择A（高控制力/合规） | 选择B（高适应性/落地） | 我的倾向（基于经验判断） | 适用场景 |
|---|---|---|---|---|
| 功能完整性 vs 实用性 | 列全功能，一次上线 | 只做核心出入库，快速上线迭代 | 选择B | 中小企业或自研能力弱的组织 |
| 需求明确 vs 上线速度 | 花大量时间明确细节再启动 | 先跑MVP，再验证迭代 | 选择MVP优先 | 业务变化快的零售/电商行业 |
| 中央集权 vs 局部灵活 | 统一标准，所有仓库强制使用 | 核心口径统一，操作层灵活 | 选择后者 | 多仓/多分公司/加盟店共存的场景 |
八、独特的视角总结与实践出路
库存管理系统真正无用的根源，并不在于技术有多差，而在于一开始对库存管理的认知断层，仓库用感觉做了20年，老板凭经验算出需求，IT靠文档猜流程。大家以为同一件事讲清楚了，但事实上每个人都在讲自己的库存故事。
如果把这个问题换个角度，不是去重新选一个更贵的系统，而是先让内部组织建立起“颗粒度、时效、容错”这个三方契约，效果往往会让人惊喜。
1. 下一步你可以做什么
- 第一件事： 挑一个下午，把老板、采购、仓库、财务、IT全部关在房间里。先不讨论选什么供应商，而是就“我们的一个SKU从下订单到出库要经过几个状态”、“系统数字和我们仓库地上实际数字能差多少算是正常”、“库存数据每天可接受的最迟更新时间”，这三个问题达成内部一致。这一步做完，你已经把一半的坑填上了。
- 第二件事： 不要让IT单独写需求文档。必须让仓库主管用自己每天的习惯，模拟做一个入库和出库流程。IT在旁边记录逻辑，然后对比两套流程是否一致。绝大多数需求缺口都藏在这个“别人做一遍”的过程里。
- 第三件事： 接受不完美，第一次上线可以只保证90%的准确率和基本的出入库记录，其他高级预警和报表留到第二期。你的MVP需要一个明确的生命周期。
2. 对读者最后的交代
我不是说一切非定制化库存系统都要失败，而是说在你提交供应商之前，先别急着看功能列表和界面，先把仓库的看板画出来、把财务的库存差异容忍度写出来、把老板的“实时”变成分钟或小时。这步完成之后，你的选型才真正有根。让系统适配你的组织，而不是让组织反过来忍受系统。
行动建议：从本文的“颗粒度，时效，容错”三维自检表开始，约一次90分钟的会议，和核心团队把所有状态写在大白板上。如果这步不启动，那后面的每步都是原地转圈。
常见问题解答（FAQ）
1. 为什么老板总是觉得“免费系统就能搞定”，而实施后却各种不满足需求？
我是一家中小企业的老板，仓库SKU超过5万，日出入库非常密集。之前听同行说用免费的库存管理软件就能搞定，就匆匆上线了。结果系统卡顿、不支持多仓库、批次管理也跟不上，最终不得不花更多钱换系统，还耽误了三个月业务。为什么免费系统反而成了最大的成本陷阱？
我亲眼见过一个年GMV 2亿的电商客户，老板执意先用免费版。上线第一周，单表数据量突破3000行，系统响应时间从1秒飙到30秒，仓库扫码枪经常掉线。免费系统通常只支持单表几千行数据，索引设计简陋，没有并发控制。而实际业务中，仅每日出入库记录就可能上万行，再加上历史数据，免费版根本扛不住。
老板的“免费”需求本质上是成本需求，但缺失了对性能、扩展性、技术支持的明确定义。我的建议是：选型前先列出业务峰值数据量（单表行数、每日增量）、并发用户数、必须支持的复杂功能（批次、序列号、多仓库、自动调拨），然后用这些指标去测试免费版，通常会发现根本过不了。
如果执意要免费，也要做好半年内更换的预案，并设定数据迁移的止损点。
2. 为什么IT和业务部门在需求调研时总是“鸡同鸭讲”，最终系统无法使用？
我是公司的IT经理，每次和仓库主管讨论需求，他总是说“就像现在这样就行”，但系统上线后他又说不好用。我拿着需求文档对质，他说“这不是我想要的”。到底问题出在哪？怎么才能让双方说同一种语言？
有一次我们为一家化工企业做项目，IT问仓库主管“是否需要批次管理”，主管说“要”。结果系统按生产日期批次设计，而仓库实际是按入库批次和供应商批次两个维度管理的，导致出库时无法精确锁定。问题根源在于双方没有进行“用户故事地图”演练，而是直接填需求文档。IT把需求当清单，业务把需求当感受。
正确的做法是：组织仓库、采购、财务、IT一起走一遍典型业务场景（入库、拣货、盘点、调拨），每步写下“系统应该怎么做”而不是“系统有什么功能”。比如，在“入库”场景下，要画出：货物到门口→质检→扫码→上架→系统更新库存，每一步的数据字段、操作角色、异常处理逻辑。
用这种场景走查，IT和业务才能在同一张图上说话。后来我们改用白板+便签的方式，三天就完成了过去两个月都搞不定的需求澄清。
3. 为什么系统上线后库存周转率指标反而更差了？是不是系统本身的问题？
我们公司上了新的库存管理系统，本意是提高周转效率，结果上线三个月，库存周转率从4.5降到了3.2。仓库同事抱怨系统强制先进先出导致老货出不去，财务说周转天数增加占了资金。是系统算法有问题，还是我们根本没把需求说清楚？
我见过一家零售连锁企业，上线后周转率下降12%。系统严格按照先进先出逻辑，但仓库原本为了方便，经常把同品类不同批次混放，出库时先拿门口的最新批次。系统规划后强制按入库时间顺序出库，反而导致老批次滞留在库底，增加了死库存。核心问题是：需求阶段没有定义“库存健康度”的预警规则。
系统只是记录数据，没有在超出阈值时自动触发动作。比如，没有定义“某批次库存超过90天自动调拨到折扣门店”、“库存天数超过目标值30%时向采购发出停购告警”。正确做法：在实施前，业务必须明确期望的库存天数、死库存占比、自动调拨规则，并让系统在超出阈值时强制锁定或告警。
此外，要设计缓冲区：允许在过渡期（三个月）内人工干预，让系统逐步适应业务习惯。否则系统只会暴露管理盲区，而不是解决问题。
4. 为什么很多企业按照GSP规范写需求，系统验收还是通不过？
我们是医药流通企业，在选库存管理系统时，直接把GSP规范原文作为需求文档给了供应商。供应商也承诺开发。但系统完成后，药监局验收发现近效期锁定、温湿度超标禁止出库、追溯码自动上传等功能根本没有实现。为什么法规原文写清楚了，系统却做不出来？
我参与过一家医药公司的GSP合规系统实施，他们直接把法规条款复制黏贴。比如GSP要求“药品近效期应自动锁定”，但什么是“近效期”？法规没写。企业也没定义，供应商默认是距离有效期3个月。而实际业务中，不同品类近效期标准不同：生物制品1个月，普通药品6个月。
没有细化，系统就按照通用阈值开发，结果验收时被发现不合理。每一条法规都需要翻译成具体字段、触发条件、动作逻辑。我建议做一张《合规需求映射表》：列法规条款、拆解出的系统功能、字段名称、触发条件、报警方式、责任人。
例如“温湿度超标禁止出库”要拆成：温湿度传感器阈值（比如温度>25℃或湿度>70%），触发后自动锁定对应库位的所有药品，生成告警通知质量负责人，并记录异常日志。没有这种逐条翻译，就算原文写一百遍，系统也无法落地。后来这家企业重新梳理了84条GSP条款，输出了170条系统需求，第二次验收一次性通过。
读者评论
作为经历过两次库存系统上线的IT经理，文章提到的‘认知断层’太真实了。我们公司第一次上线时，财务要求99.9%准确率，仓库觉得85%就行，结果系统按财务标准设了严格校验，仓库每天多花两小时纠错，三个月后直接弃用。如果当时能像文章说的提前签一份容错契约，起码能避免内部内耗。
文章里那个连锁便利店批次管理的案例简直是我司的翻版。我们也是因为批次管理粒度没谈拢，仓库要按保质期分品类，IT统一按收货批次，结果酸奶和冻品操作流程冲突，仓库主管直接带人抵制系统。最后多花了20万定制开发，教训就是需求文档写得再厚，不如去仓库跟一线干一天活。
作为中小电商老板，这篇文章让我重新审视自己的库存项目。之前总觉得是供应商不靠谱换了两家，现在看根因在内部：我和仓库主管对‘实时库存’的理解差了半小时，销售又想要分钟级。文章里那张漏斗图最扎心，半年存活率24%，我们第一个项目就是那76%里的。下周开会先拿三个契约问题自测。
很赞同‘需求不清晰不是没写文档’这个观点。我们集团旗下五个事业部，库存口径各自为政，系统上线后每次会议都在争数字对错。文章建议先统一口径再做系统，这点我们吃了大亏。不过我觉得还可以补充一个点：业务场景的调研不能只靠开会，最好让实施人员跟仓一周，很多隐性流程只有亲眼看才能发现。
我是做实施顾问的，文章里‘沉默共识’和‘假设错位’总结得太到位了。曾经一个项目，老板说我要看每天库存金额，仓库以为就是Excel导表，IT按ERP接口做了实时看板，结果老板嫌图表太复杂，仓库说不如旧表顺手。三方都觉得自己没错，但系统就是没人用。后来我学乖了，每个需求都让业务当众演示一遍，避免‘我以为你懂了’的坑。