B端项目上线即摆设？丰田精益生产思想或成解药。本文从产品经理视角，拆解如何用看板、5Why、异常暴露等原则，克制功能冲动，优化流程，让系统真正解决业务痛点，告别“伪上线”。

我们团队交付了一个ERP项目，客户却抱怨：“功能是上线了，但仓库该乱还是乱，料该找不到还是找不到。”

这不是个例。在做B端产品的几年里，我亲眼见证了许多项目陷入一个怪圈：我们太擅长给系统做“加法”，却极其不擅长让功能真正解决一个具体的业务问题。

最近重读《丰田生产方式》，大野耐一在几十年前提出的精益思想，几乎是为今天B端产品的落地困境量身定制的解药。这篇文章，我想从产品经理的视角，拆解如何用丰田的思维，治好B端项目“上线即摆设”的病。

原则一：不做“用户要的”功能，只做“业务痛”的功能

丰田启示： 后工序在需要的时候，去前工序领取正好需要的数量。没有“传票卡”（看板），就不生产、不领取。

B端产品的映射： B端产品最大的浪费，是做用户“想要”但并非“真正需要”的功能。

业务方说“我们想要一个XXX功能”，PM回来写PRD，研发吭哧开发，上线后无人问津。为什么？因为“想要”是解决方案，“需要”是背后的问题。

B端产品经理落地方法：

在需求评审前，强制用“三问”过滤每一个需求，确保进入开发队列的都是“真需求”：

案例对比：

• 伪需求： 库管员说“想要PDA扫码上架”。（直接做，可能因货位管理乱而失败）
• 真需求（用三问挖掘）：追问后发现，真实痛点是“手工记账常放错库位，导致拣货找不到料，订单延期”。“订单延期”是真实代价，因此核心功能应是“扫码自动匹配推荐货位”，而非简单的“扫码记录”。

原则二：连问五个“为什么”，挖出流程根因再动手

丰田启示： 著名的“5Why”法。机器停了，不问“怎么修机器”，而是连续追问，直到发现根本原因是“油泵轴磨损，没装过滤器”。解决方案是“装过滤器”，而非“换保险丝”。

B端产品的映射： B端PM最容易犯的错误，是把用户的“诉求”当“需求”。

案例：MES实施中的需求深挖

用户诉求： 车间主任说：“我要一个在工位上看SOP（作业指导书）的功能。”

5Why深挖：

1. 为什么要看SOP？ → 因为工人常做错工序。
2. 为什么做错？ → 因为新员工多，记不住。
3. 为什么记不住？ → 因为SOP变更频繁，培训跟不上。
4. 为什么变更频繁？ → 因为工艺部门改了BOM（物料清单），但SOP没同步。
5. 为什么不同步？ → 根因：ERP和MES的BOM数据是割裂的，SOP需人工维护。

真正的解决方案： 做一个“电子SOP查看器”是无效的（因为SOP本身是旧的）。有效方案是：打通ERP和MES的BOM数据，让SOP随BOM变更自动更新。这个案例深刻说明，不挖到根因，功能做得越多，错得越远。

原则三：让“异常”上线即暴露，而非月末靠报表发现

丰田启示： 丰田工厂的“指示盘”（Andon）让生产线状态（绿灯/黄灯/红灯）实时可见。大野耐一说：“不停产的生产线，不是没有问题，而是问题被掩盖了。”

B端产品的映射： 系统上线后最可怕的状态是“静默死亡”：

• 数据录错了，没人知道。
• 流程卡住了，没人知道。
• 某个核心功能已经三天没人用了，更没人知道。大家等周报、月报发现问题时，往往已造成实质性业务损失。

B端产品经理落地方法：

在产品设计阶段，强制规划“异常暴露”机制，而非仅依赖事后报表。这应作为产品功能的一部分。

原则四：克制“加功能”的冲动，避免过量生产式的开发浪费

丰田启示： “过量生产是最大的浪费，它会派生仓库、搬运、保管等一系列二次浪费。”

B端产品的映射： B端开发中最大的浪费，是开发“以后可能用得上”的功能。

• “这个配置项先做，虽然现在只有一种场景” → 结果配置太复杂，用户不会配，客服电话被打爆。
• “这个报表先留着，万一有人看” → 结果永远没人看，但每次发版都要回归测试。

B端产品经理落地方法：用“不做清单”代替“做更多”

判断一个功能是否属于“当前版本必做”，用这个标准过滤：

案例复盘： 一个MES项目中，业务方将“设备OEE（综合效率）分析看板”定为P0。但我们发现，当前设备数据采集都不完整。决定： P0改为“设备数据采集”，将“OEE分析”冷冻。三个月后数据稳定，再上线分析看板，上线首周就因数据准确产生了价值。

原则五：先优化流程，再开发系统。系统不背流程的锅

丰田启示： “先改进作业方式，再改进设备。一开始就改进设备，只能提高成本。”

B端产品的映射： B端项目中最致命的认知错误，是试图用系统解决流程问题。

• 流程是乱的 → “上个系统就顺了”（结果：系统里流程更乱）
• 职责是不清的 → “系统里设个权限就清楚了”（结果：权限乱设，业务混乱）

系统只能固化流程，不能创造流程。混乱的流程上线，只会被系统放大。

B端产品经理落地方法：需求阶段强制“流程梳理三步走”

在画任何原型、写任何PRD前，产品经理必须先输出流程梳理文档：

总结：B端产品落地能力的“丰田式体检表”

下次产品上线前，用这张表做一次自检，它能帮你区分是“真落地”还是“伪上线”：

最后，想对B端产品经理同行说一句：

大野耐一说：“能够在减少产量的条件下提高生产率的人，全世界恐怕为数不多。”

放在B端领域，这句话可以被改写为：

“能够在减少功能数量的前提下，提升产品交付价值的B端产品经理，少之又少。能做到这一点的PM多一个，我们的系统就离‘被吐槽’远一点，离‘被用好’近一点。”

做B端产品，不是做得多才算赢。做得少，但每一个功能都精准地解决了一个真实的业务痛点，才是真本事。