产品经理，请摘下你的“客服耳朵”，戴上“医师听诊器”

guozi

B端ERP产品经理如何从用户反馈中挖掘系统真正问题？本文通过真实案例分析，揭示从「症状」到「病因」的诊断过程，教你像系统医师一样开出「治本药方」。掌握需求分析三要素与系统流程思维，避免成为需求传声筒，真正解决企业级系统的复杂难题。



最近在带产品新人发现一个共性问题：新人特别容易陷入“客服思维”——用户说什么，就记什么；用户要什么，就转什么需求。

这让我想起那句经典的话：用户要的是一匹更快的马，而福特给了一辆车。

但在B端ERP这种复杂系统里，情况远比“马和车”更复杂。用户要的可能不是“更快”，而是根本不知道自己要去哪儿；也可能他知道要去哪儿，但路上堵的不是马，是整个交通系统。

今天这篇文章想用B端ERP的真实案例，聊聊产品经理如何从“症状”中找到“病因”，从“用户处方”中开出“系统药方”。
一、产品经理 = 系统的医师
先说一个基础认知：好产品经理不是需求的“传声筒”，而是系统的“医师”。

医师的职责是：诊断病因 + 开出药方 + 跟踪疗效。产品经理在B端系统里，做的正是同样的事。

如果把企业使用的ERP系统比作一个需要维护的生命体：

• 症状 = 用户反馈的操作痛点（“对账太慢”“改单太难”）
• 病因 = 系统设计或业务流程的缺陷
• 处方 = 用户自己提出的解决方案（“加个按钮”“给个权限”）
• 治疗方案 = 你作为系统医师的专业诊断与系统优化方案


系统医师的特殊之处在于：治疗一个模块，要考虑整个系统的关联影响。采购模块改个流程，可能影响财务结账；销售模块要个权限，可能打乱生产计划。

一个合格的ERP产品经理，不能只盯着“用户要什么”，而要思考“系统出了什么问题”。
二、需求分析三要素
在深入案例之前，先建立一个分析框架：

• 用户描述 → 症状（哪里不舒服）
• 真实问题 → 病因（系统为什么出问题）
• 用户建议 → 处方（患者自己想吃的药）
• 产品方案 → 你的诊断与治疗方案（系统的优化方案）


记住：用户描述的往往是“症状”，用户建议的往往是“治标的偏方”。你的价值，是找到“病因”，开出“治本的药方”。
三、案例一：采购到付款流程的“对账之痛”
【症状】

用户原话（采购部）：“供应商对账太麻烦了，每个月财务都要找我们核三次数据。”

用户处方：“在采购单页面加个‘快速对账’按钮，让我们自己先核一遍。”

【初步分析】

听到这个需求，很多新人可能会直接记下来：“采购部需要快速对账功能。”

但你要追问：为什么对账麻烦？麻烦在哪里？为什么是采购来核？

【病因诊断：四层深度挖掘】

这是系统医师特有的分析维度——不能只看操作层，要往下挖：

第一层：操作层面

• 对账需要跨系统导出Excel
• 数据格式不统一，要手工调整
• 采购员看不到付款状态，只能问财务


第二层：系统流程层面

• 信息流断层：采购系统有订单、仓储系统有入库、财务系统有付款——三个系统数据不同步
• 权责不清晰：对账到底是谁的责任？异常处理流程是什么？
• 时间节点混乱：没有明确的对账周期和截止时间


第三层：数据层面

• 供应商主数据不准确（名称、账户信息不一致）
• 物料编码不统一
• 税率信息缺失
• 历史变更无记录


第四层：组织层面

• 部门墙导致协作困难
• KPI考核导向不一致（采购看交付率，财务看资金安全）
• 缺乏端到端的流程owner


【诊断结论】

表面问题：对账操作繁琐

根本问题：采购、仓储、财务三个系统的数据没有打通，系统流程缺少一体化支撑，加上部门间职责不清，导致每个月的对账变成一场“跨部门追查游戏”。

【治疗方案】

简单处方（治标）：

• 加“快速对账”按钮
• 给采购查看付款状态的权限
• 优化导出模板


问题：只是把问题从财务转移到采购，没解决根本问题

系统方案（治本）：

1. 三单匹配自动化



核心功能：

• 系统自动匹配三单，无需人工核对
• 支持容差配置（数量、金额容差配置）
• 差异自动分类（价格差异、数量差异、无订单入库等）
• 差异处理流程化，责任到人（不同差异可设置不同流程）


2. 协同工作流

• 采购发起对账 → 仓储确认入库 → 财务审核付款
• 每个环节系统自动提醒
• 超时未处理自动升级


3. 供应商门户

• 供应商自助查看对账进度
• 在线确认差异
• 电子发票直接对接，减少录入错误


4. 数据治理先行

• 统一供应商主数据管理
• 物料编码标准化
• 价格有效期管理，避免过期价格混用

四、案例二：销售订单变更的“部门博弈”
【症状】

用户原话（销售部）：“客户改个订单要折腾三四个部门，一两天才能确认，客户都等急了。”

用户原话（生产部）：“销售老是改订单，我们生产计划全乱了。”

用户处方：

销售部：“给我们个紧急修改权限，不用走那么长流程。”

生产部：“锁定订单后销售不能再改。”

【病因诊断】

问题的本质不是“流程太长”，而是系统信息不透明。

销售在系统里看不到改一个交货期会影响几个在产订单、增加多少成本；生产在系统里看不到客户为什么要改、改的是否紧急。信息不透明导致只能靠层层审批来传递和确认，流程自然就长了。

【治疗方案】

不采用：



系统方案：智能变更预评估

当销售尝试修改订单时，系统实时显示：



销售在提交变更前就知道影响有多大，有些变更可能直接就取消了。需要审批的，审批人也能看到同样的数据，决策更快。

这个方案不是“给权限”或“锁订单”，而是用透明信息替代盲目审批，让每个环节的人基于数据做决策。
五、B端ERP系统的特殊考量
通过上面两个案例，你会发现B端产品和C端产品的分析逻辑有很大不同。

经常被问到：市面上那么多需求分析方法论，B端到底有什么不同？

有时C端产品可以“加个按钮”解决问题，但ERP不行。ERP的每个功能都嵌入在业务流程里，改一个点，可能影响上下游多个环节。

错误做法：用户抱怨 → 加功能 → 新问题 → 再加功能

正确做法：业务痛点 → 系统流程分析 → 系统优化 → 组织适配

1. 系统流程优先于功能点

不要只想着“加个按钮”，要思考“优化整个系统流程”。系统功能要支持业务流程，而不是破坏它。

2. 数据一致性是生命线

ERP的核心是“一个数据源头”。任何功能设计都不能破坏数据一致性。

案例一里，如果只是加“快速对账”按钮，采购改了数据，财务不知道，最后账还是对不上。必须保证采购、仓储、财务看到的是同一套数据。

3. 组织变革伴随系统变革

B端产品经理经常会发现：问题不在系统，在组织。

案例二里，销售和生产的冲突，本质上是因为KPI不一致——销售考核销售额，生产考核交付率。这种情况下，光改系统没用，还要考虑组织层面的调整。
六、系统需求分析五步法
结合上面的案例，总结了一套B端系统需求分析的实操框架。这套方法的核心差异在于“系统流程思维”而非“单点功能思维”。

第一步：症状定位（5W2H）

Who：哪个部门/角色反映问题？

What：具体是什么操作卡住了？

When：在什么时间点发生？

Where：在哪个系统环节？

Why：用户觉得为什么会这样？

How：现在是怎么解决的（手工Excel/找人问）？

How Much：问题发生的频率、影响范围、耗时、成本等量化数据（例如：每月发生几次？每次耽误多少人天？造成多少金额损失？）

第二步：系统流程诊断（画泳道图）

画出问题涉及的所有部门和系统节点，标注每个节点的输入、输出、耗时、卡点。

第三步：根因分析（5 Why法）

以案例一为例：

1. 为什么对账麻烦？→ 因为要跨系统导Excel

2. 为什么要导Excel？→ 因为三个系统数据不打通

3. 为什么数据不打通？→ 因为当初系统是按模块独立建设的

4. 为什么模块独立？→ 因为不同阶段上了不同系统

5. 那根本问题是什么？→ 缺乏统一的系统架构和流程设计

第四步：方案设计（三个层级）

临时方案：1周内可实施，快速缓解症状（比如优化导出模板）

优化方案：1个月内可实施，改进现有流程（比如打通接口，做半自动对账）

重构方案：需要资源投入，系统流程再造（比如三单匹配自动化）

第五步：价值评估

用数据说话，估算每个方案的价值。这里的“How Much”思维贯穿始终：

现在每月对账耗时：采购3人×3天 + 财务2人×2天 = 13人天

优化后：系统自动匹配，人工只处理异常 → 效率提升77%，原来需要13人天的工作，现在只需3人天即可完成

这意味着：团队成员可以把每月多出来的10人天时间，投入到供应商谈判、成本优化等高价值工作中，而不是消耗在重复的手工对账上。
七、写在最后
思维转变是起点

做B端产品经理，最难的不是写PRD，不是画原型，而是思维的转变：

从“用户要什么 → 做什么”

到“系统出了什么问题 → 为什么出问题 → 如何系统化解决”

三个需要警惕的陷阱：

• 直接实现用户建议
• 只解决表面症状
• 不考虑系统上下游影响


三个应该追求的目标：

• 挖掘真实需求
• 解决根本问题
• 创造系统整体价值


记住：用户告诉你的是“我觉得我该吃什么药”，而你要诊断出“系统到底得了什么病”。

好产品经理不是需求的“传声筒”，而是系统的“医师”。

本文由 @雨柒 原创发布于人人都是产品经理。未经作者许可，禁止转载

题图来自Unsplash，基于CC0协议

--------------------------------------------------
本文转载自：https://www.woshipm.com/pd/6376505.html