在职场上，如果有一些工具能让我们顺手使用，工作效率会高很多。本文作者汇总整理了一份B端产品的工具包，并以案例穿插其中，可以帮助大家更好掌握文中列举的这些工具。

初阶B端产品经理工具包将分为三个部分分享，这一篇分享第一部分，涵盖总览、售前、需求分析阶段的工具。

一、B端产品交付流程

在进入具体的工具介绍前，让我们先了解下B端产品交付（售前除外）的完整流程。

图片 1 B端产品交付流程

在这个流程中，以仓储物流场景为例，产品经理可能需要接触哪些人，做哪些工作呢？

注：在不同的公司及产品，下述任务可能会被拆分到不同的岗位职能，但是产品经理需要从需求到落地的所有流程步骤。

表格 1各环节工作事宜

在上面的注意事项里，我频繁地写到“顶住压力”，在B端物流产品交付的过程中，产品经理确实扮演着双面人的角色，承载着两侧的压力。

一面面向业务，产品经理是需要挡在用户面前，为开发测试承压的，无论是收集需求、还是落地实施阶段，都需要顶住业务侧的压力，做好沟通，控制需求范围，在盘通流程的基础上保障交付。

一面面向开发，产品经理也需要顶住开发测试侧的压力，有效梳理并传递业务需求，时刻关注开发测试进展，避免需求落地变形。

那么，已知上述交付流程，在B端产品经理精进的路上，我们可以学习哪些工具呢？

我简单整理了下面的工具清单：

图片 2 以系统工程展开，B端产品经理工作流程

表格 2工具清单及建议掌握程度

本书将依循上述清单逻辑展开各环节的工具介绍。

二、售前-立项阶段工具

2.1. 售前调研工具：业务问题清单

为什么需要提前准备业务调研问题清单呢？

因为我们和业务沟通的时间是有限的，需要在最短的时间内，尽可能地提高会议有效信息的密度，减少需求的遗漏，降低立项决策的失误风险。

此外，提前准备问题清单，能够帮助产品经理在前期与业务侧的接触中树立靠谱专业人设，产生信任感。信任是团队协作的基础，这一点在B端产品的落地过程中尤为重要。

最后，业务问题清单在收集足够多了之后，可以帮助我们把握行业核心诉求，能够有效的帮助我们思考产品如何设计。

那么，如何列出系统调研问题清单呢？

我们以一个WMS系统调研清单为例，展开讲如何梳理系统调研问题清单。

表格 3某WMS系统调研问题清单

我们在梳理问题清单的时候，需要有三个方面的内容需要考虑到，即项目基础背景、项目业务所需流程、项目商务信息。

例如在上面的WMS系统调研问题清单中，我们以仓库基础情况类目的问题，确认了项目的基础背景，即项目的利益攸关者有哪些、系统的接触者和相关者是谁、系统的目的是什么。

接着，我们用仓库业务需求类目的问题，串联起了从入库到出库关键节点的关键问题，这有助于帮助我们明确系统的功能和目标。

最后，我们用商务基础信息，确认了这个项目的外部投入情况，为项目立项阶段计算投资回报比（ROI）打下基础。

不局限于物流产品，所有B端产品都可以用上述的思路梳理调研问题清单，随着项目的积累，这张清单会日趋完善，并最终反哺系统设计。

2.2 决策工具：投资回报率（ROI）

B 端产品经理为什么需要熟悉投资回报率（ROI）呢？

因为它大致确定了一个项目在企业内的受重视情况。相对来说，投资回报率高的项目，在后期落地的过程中，更容易调配到资源。因此，为了后续落地的开发测试顺利，产品经理一定要在前期就了解项目的投资回报率。

当然，这里不是说投资回报率低的项目不受企业重视。某些标杆项目在企业内部很受重视，但是它的ROI不够好看，甚至有可能是赔钱赚吆喝的。

那么怎么计算投资回报率呢？

我们可以简单遵循如下公式（在粗估时，可以忽略机会成本）：

例1.在一个面向外部客户的软件项目A中，在计算投资回报率时，首先需要了解项目的总成本，即软硬件投入成本、员工成本、实施成本、差旅成本、x年期运维成本等，此外还要了解项目的总收益，即一次性软件许可收入、实施和定制收入、培训收入、x年期运维收入等。

我们假设某项目的总成本与总收益如下：

成本项：

• 软硬件投入成本：1w
• 员工成本：30w
• 实施成本：5w
• 差旅成本：3w
• 一年期运维成本：3w

收益项：

• 一次性软件许可收入：10w
• 实施和定制收入：30w
• 培训收入：5w
• 一年期运维收入：5w

那么计算A项目的ROI如下：

例2.在一个面向内部业务的软件项目B中，投资回报率的收益项略有不同，以一个仓储系统优化项目为例，项目的总成本维持不变，仍是软硬件投入成本、员工成本、实施成本、差旅成本、运维成本，预期收益可能包含应用系统后的生产效率提升、库存优化、人员利用率提升、订单赔付率降低等。

我们假设某项目的总成本与总收益如下：

成本项：

• 软硬件投入成本：1w
• 员工成本：20w
• 实施成本：5w
• 差旅成本：3w
• 一年期运维成本：1w

收益项：

• 生产效率提升量化收益：11w
• 库存优化量化收益：15w
• 人员利用率提升量化收益：9w
• 订单赔付率降低量化收益：5w

那么计算B项目的ROI如下：

上述简略的ROI公式忽略了机会成本，仅是粗略估计的投资回报率。在实际的应用中，需要注意项目中成本项和收益项选择。

此外，为了ROI的准确度，我们需要确保成本和收益是被合理量化的。

2.3. 项目规划工具：甘特图（Gantt Chart）

B端产品经理为什么需要熟练使用甘特图呢？

因为产品经理需要把控系统交付的时间、资源、进展，这是甘特图可以提供的。

甘特图里包含了哪些内容呢？

甘特图包含了项目的关键时间点和里程碑，展示了多任务之间的前后依赖关系，并且展示了在同一时间并发的任务。

甘特图在系统项目交付过程中有什么作用呢？

通过甘特图可以让项目组成员清晰地感知项目规划，能够帮助管理者提前进行资源的部署，避免资源冲突。并且，甘特图中的里程碑，能够帮助项目分散交付风险，将风险分散到一个个关键节点，通过关键节点的验收，能有效避免将风险延迟到交付截止日。

那我们怎么进行甘特图的绘制呢？

这里以一个为期三个月的系统项目C为例：

图片 3某项目甘特图

STEP1：我们要设计横轴与纵轴。

横轴建议放日期，长度覆盖整个项目周期，重点标记关键节点，标记每个任务的起始和结束时间。纵轴建议将项目交付中的关键任务进行拆分。

图片 4横轴时间初始绘制内容

图片 5纵轴任务节点初始绘制内容

STEP2：汇合横轴与纵轴的信息。

通过横轴与纵轴的信息汇合，我们就能清晰地看到项目的任务排期情况，完成甘特图的绘制。

图片 6汇合横轴和纵轴

STEP3：分割色块。

为了使甘特图更加清晰，我们将时间按照大的交付阶段分割，按照不同的颜色标识；同时，按照交付阶段分割纵轴，标识不同的颜色，就能清晰地看到不同阶段不同任务的规划时间。

图片 7成品甘特图

可以通过什么软件绘制甘特图呢？

目前的工作沟通软件如钉钉、飞书，均内置了画甘特图工具，如果你想和项目计划书关联度更高，可以尝试套用excel、project中的甘特图模版。

2.4. 项目沟通工具：沟通计划

B端产品经理为什么需要熟悉沟通计划呢？

因为产品经理在系统项目交付中的很多场合，扮演者会议组织者、会议主要参与者的角色，我们需要知道这个项目应该在何时、何地、和什么人确认什么样的事宜。

沟通计划里包含着什么样的关键信息呢？

首先是组织架构图，这框定了在一个项目中由谁担任什么样的角色，向谁汇报，在常规的组织架构图里要从实际出发，明确到每个人的角色。

这里以某项目C的组织架构信息举例：

图片 8某项目C组织架构图

在梳理组织架构图的时候，要注意不要产生一人向多人汇报的情况。

上面的组织架构图示只简单展示了组织分工，为了细化职责，还需要根据实际情况，列明每个组（部门）的分工及成员，这样才能使每个职责都有专门的组或部门承接，不会产生三不管或者多头管理地带。

以上面的某项目C的职责分工表为例：

表格 4某项目C职责分工表格

通过组织架构图和职责分工表，我们已经知道了在一个项目中，由哪些人负责什么样的职责，在具体的会议组织上，可以告知部门（组）的负责人会议目的，让他们自行指派专人跟进。那在什么时间、什么地点进行会议呢？

项目沟通计划，会帮助我们更直观地展示在什么时间、什么地点进行什么样的会议。

我们继续以某项目C的项目沟通计划为例：

表格 5某项目C项目沟通计划

通过项目沟通计划，我们以表格的形式直观的知道会议会在什么时间、什么地点与什么人进行什么事项的讨论，在具体会议的预定上，将由项目经理负责。

在列明了项目沟通计划后，为了保证在项目推进中的沟通基本质量，我们需要就与会情况进行考勤，考勤的记录同样由项目经理负责。

我们继续以项目C的考勤记录表为例：

表格 6某项目C会议考勤记录

从上图，我们可以看到在7月的考勤记录表中，仅有两人在产品部组织的局部会议上请假，那么我们仅需要确认上述两人知悉此次会议事宜即可。

2.5. 决策汇总工具：立项报告（Feasibility Study Report）

B端产品经理为什么需要熟悉立项报告？

管理层进行项目是否开展的决策前，会让项目组出具立项报告，立项报告明确了项目目标、阐明了项目背景、划分了项目范围、描述了资源分配情况、进行了项目风险评估、完善了项目可行性分析、指明了项目落实时间规划。

参与制定或查看立项报告，可以帮助产品经理全面地把握项目基础情况，确保项目推进的信息透明。

那么如何编写立项报告呢？

STEP1：阐明项目背景

• 阐述项目提出的背景和必要性。
• 分析项目实施的外部环境和内部条件。

STEP2：明确项目的具体目标

明确项目的具体目标和预期成果。这里可以应用SMART法则。

图片 9 SMART法则在立项报告中的应用

• 具体（Specific）：立项报告中的目标应该是明确和具体的。例如，不是模糊地提出“要通过系统降低包材的仓储成本”，应具体到“要在包材管理系统，在明年一季度将包材的仓储成本降低30%”。
• 可衡量（Measurable）：报告中应包含可以量化的指标，以便于跟踪进度和评估结果。例如，可以设定“通过供应商满意度调查，将仓库预约系统满意度从85%提升至90%”。
• 可实现（Achievable）：目标应该是现实的，可以在现有资源和条件下实现。在立项报告中，需要评估资源、时间和能力，确保目标的可实现性。例如，如果当前拣货错误率是万分之九，那么设定降低到万分之六以内的目标是可达成的。
• 相关（Relevant）：目标应该与组织的整体战略和使命相关联。在立项报告中，需要说明项目如何与组织的长期目标和战略规划相一致。例如，如果组织的目标是降本，那么项目目标应该是降低仓储成本。
• 时限（Time-bound）：目标应该有明确的完成期限。在立项报告中，需要设定具体的开始和结束日期，以便于监督和评估目标的实现进度。例如，“在接下来的6个月内完成新系统的研发”。

STEP3：划分项目范围

明确项目的范围和边界，明确项目包含和不包含的内容。

STEP4：梳理组织结构

• 描述项目的组织架构和部门分工，梳理方式见2.4
• 明确各方参与者的职责和协作方式，梳理方式见2.4

STEP5：列明项目预算分配

提供项目的预算明细，包含软硬件预算、员工预算、实施预算、差旅预算、x年期运维预算等

STEP6：进行项目风险评估与应对措施

识别项目可能面临的风险，并提出相应的预防和应对措施，这里可以使用吉德林法则（Jidelim Law）帮我们梳理思路。

图片 10 吉德林法则（Jidelim Law）在立项报告中的应用

1）明确识别问题：

吉德林法则强调，只有先认清问题，才能很好地解决问题。在项目风险评估中，首先要识别所有可能的风险因素。

系统项目的风险，包括技术风险、市场风险、财务风险、法律和合规风险等。

识别风险的过程可以通过头脑风暴、专家访谈等方法进行。

2）清晰地描述问题：

将识别出的风险清晰地描述出来，这是吉德林法则的核心。

在立项报告中，应详细列出每个风险，并对其可能性和潜在影响进行描述。这种清晰的描述有助于更好地理解风险的本质，为后续的分析和应对措施提供基础。

3）分析风险的可能性和影响：

对每个已识别的风险，评估其发生的可能性和对项目目标的潜在影响。这一步骤可以通过定性和定量分析来完成。

定性分析可以使用风险概率影响矩阵，而定量分析可以计算风险的预期值。

4）制定应对策略：

根据风险分析的结果，为每个风险制定应对策略。策略可以是规避、降低、接受或转移风险。

5）实施和监控：

将应对策略转化为具体的行动计划，并在项目实施过程中进行监控。监控的目的是确保风险应对措施得到有效执行，并在必要时进行调整。

6）沟通和报告：

在项目全生命周期中，持续进行风险沟通和报告（举手）。

这包括与项目团队成员、利益相关者和管理层的沟通，确保他们对项目风险有清晰的认识，并参与风险管理过程。

STEP7：进行项目效益分析

• 计算项目的投资回报率（ROI），计算方式见2.2
• 量化项目的机会收益

STEP8：指明项目的进度计划表

梳理项目的甘特图，包括各阶段的起止时间和关键节点，梳理方式见2.3

三、需求沟通分析工具

图片 11 需求分析与加工（工具清单）

在这个章节中，我们将介绍需求识别、需求定义、需求分类、需求分级、需求装换的工具；需求关联工具（图）在产品设计环节也需要用到，我们放在下个章节介绍。

3.1 需求沟通工具：需求清单

B端产品经理为什么需要熟练使用需求清单呢？

因为产品经理需要有效的管理产品从概念到落地的整个生命周期，需求清单作为和业务方的沟通记录，能够帮助产品经理把握业务需求。

那么怎么进行需求清单的梳理呢？

STEP1：根据业务调研，罗列需求

业务调研的流程和售前调研类似（详见2.1），在问题清单的指引下，围绕着业务背景与流程面向正确的人提问，调研汇总的信息，即为需求清单。

表格 7 需求清单表格初稿

STEP2：组织产品评审后，更新需求清单表格

在产品评审之后，可以更新需求清单的字段如下：

表格 8 需求清单表格更新稿1

STEP3：迭代发布之后，再次更新需求清单

在迭代发版之后，可以更新的清单字段如下：

表格 9 需求清单表格更新稿2

通过上述三个环节的更新，一个贯穿需求到落地流程的需求清单就完成了。

图片 12 需求清单全览

由于需求清单非常重要，补充一个案例帮助详细阐释这个工具：

案例：张飞和他的审单平台（1）

角色介绍：

Lily：上海一家报关行E的业务主管，24年四月，因为薪资待遇、工作发展等问题，她手下的员工出现了1/3的流失，从15人锐减到10人。

张飞：深圳六臂物流科技公司的中级产品经理。

前情概要：

报关行E的老板联系到的六臂物流科技公司业务拓展人员，希望为其定制化开发一套报关单校验平台，由业务人员Lily对接。

六臂物流科技公司的业务拓展人员协调产品团队，产品部门主管指派张飞对接此客户需求。

张飞在线上与Lily完成了1次1h的需求调研，汇总了如下会议纪要，并且与Lily约定在2天后澄清需求清单中的业务问题。

需求调研会议纪要：

表格 10 张飞与Lily的初次会议纪要

会上，除了记录会议纪要，张飞还见缝插针地记录了客户初步需求：

图片 13 张飞记录的初稿需求清单

会后，张飞立刻梳理了会议纪要，并通过思维导图帮助自己整理思路：

图片 14根据会议纪要梳理的思维导图

为了进一步明确需要校验的内容，张飞向Lily申请了20套报关单据（发票、合同、箱单、报关单），开始整理需要比对的具体字段。

表格 11一套基础的报关材料

在上次的会议结束一天后，张飞认真查看了客户提供的20套报关材料，此时，他发现这个需求似乎并没有Lily描述的那么简单，于是他和Lily约了第二天进行部分业务需求的澄清。

未完待续。

3.2 需求定义工具：根本原因分析（Root Cause Analysis）

B端产品经理为什么需要熟练掌握根本原因分析？

根本原因分析（Root Cause Analysis, RCA）是一种系统性的方法，旨在透过浅显的表象找出问题的根本原因。B端产品经理的工作，同样需要透过表层业务，提纯核心需求，所以需要熟练掌握根本原因分析。

B端产品经理怎样应用根本原因分析？

根本原因分析是B端产品经理工作中的基础内功心法，它包含的方法有很多，例如5W（Five Whys Method）法、鱼骨法（Cause and effect Fishbone diagram），结合实际项目经验，对于B端产品经理来说，适用于我们的根本原因分析方法，需要在5W的基础上做延展，增补1H和1V[2]。

图片 15 5W+1H+1V需求分析

具体应用的步骤如下：

STEP1：确认WHO

明确这个项目的客户是谁、这个系统的实际使用者（用户）是谁。

STEP2：确认WHEN

明确用户何时会有需求。

STEP3：确认WHERE

明确在什么业务中会产生需求？在哪里可以满足用户的此项需求?在不同场景中的需求是否一致?

STEP4：确认WHAT

明确在什么业务中会产生需求？在哪里可以满足用户的此项需求?在不同场景中的需求是否一致?

STEP5：确认WHY

为什么产生这样的需求？什么原因导致的？

STEP6：确认HOW

怎样才能满足这个需求？如何决策？如何实施？

STEP7：确认VALUE

需求是否有价值？有什么价值？如何做才能产生价值？

根本原因分析对于B端产品经理非常地重要，这里补充一个案例：

案例：张飞和他的审单平台（2）

角色介绍：

Lily：上海一家报关行E的业务主管，24年四月，因为薪资待遇、工作发展等问题，她手下的员工出现了1/3的流失，从15人锐减到10人。

张飞：深圳六臂物流科技公司的中级产品经理。

前情概要：

书接上回（4.1案例），距离和Lily的业务需求澄清会还有1天，张飞看了眼屏幕上的会议纪要及需求清单，又看了下那一叠令人头晕眼花的报关单据，陷入沉思。

本次情节：

张飞在电脑上创建了一个EXCEL表格，敲了如下根本原因分析表格：

表格 12 张飞对审单需求进行的根本原因分析

接着，为了进一步确定这个需求的价值，张飞通过价值流分析（VSM）和方法时间测量（MTM），对制单员动作进行对比分析，量化了改善效果。

表格 13 制单动作的VSM 价值流分析

表格 14 制单动作的MTM

写完之后，张飞觉得自己对这个需求的理解加深了，满意地松开鼠标。

3.3 需求分类工具：Kano模型

B端产品经理为什么要了解Kano模型？

B端产品经理需要处理复杂的业务需求，这涉及跨部门的多利益相关者，Kano模型能够帮助我们识别，优先处理哪些需求，能最大化提升用户满意度。

如何在B端产品需求中应用Kano模型？

Kano模型是由日本学者狩野纪昭（Noriaki Kano）在1984年提出的一个用于分析和分类用户需求的模型。该模型将用户需求分为五类：

1）基本需求（Must-be Quality）：

这些是用户认为产品或服务必须具备的特性。如果这些需求没有得到满足，用户会非常不满意。但即使满足了这些需求，也不会显著提高用户的满意度，因为它们被视为理所当然的。

仓库管理系统（WMS）中的基本需求举例：

1. 库存管理：跟踪库存水平，确保数据准确，这是仓库管理的核心功能。
2. 订单处理：接收、处理和履行订单的能力，包括订单的创建、修改和取消
3. 货物入库和出库：管理货物的入库和出库流程，记录收、发报表。

2）性能需求（One-dimensional Quality）：

这些需求与用户的满意度成正比。产品或服务在这些方面的表现越好，用户的满意度就越高。这些需求是可量化的，用户可以清晰地表达他们对这些需求的期望。

仓库管理系统（WMS）中的性能需求举例：

1. 灵活的波次释放和拣选策略：根据订单的优先级和特性，灵活地安排波次释放和拣选策略，提高拣选效率。
2. 集成自动化设备：集成自动化立体仓库（AS/RS）、存取小车（AGV）、分拣墙等，能有效提升拣选效率。

3）兴奋需求（Attractive Quality）：

这些是超出用户期望的特性，能够给用户带来惊喜和愉悦。如果产品或服务能够满足这些需求，用户的满意度会显著提高。

这些需求往往是创新性的，用户可能没有意识到他们需要这些特性，直到企业提供了这些特性。

仓库管理系统（WMS）中的兴奋需求举例：

1. 增强现实（AR）拣选：通过增强现实技术辅助拣选过程，比如通过AR眼镜直接在操作员的视野中显示拣选指令和路径。
2. 智能装车推荐：系统能够根据货物的特性和运输要求，自动推荐最合适的装车堆码垛方案。

4）无差异需求（Indifferent Quality）：

这些需求对用户的满意度影响不大，无论是否满足这些需求，用户的满意度都不会有显著变化。这些需求可能是用户不关心的，或者是超出了用户的期望范围。

仓库管理系统（WMS）中的无差异需求举例：

1. 过度的视觉设计：WMS用户界面（UI）的设计如果过于复杂或花哨，不会给大多数用户带来额外的价值。
2. 仓库系统实现实时聊天功能：在仓库系统内实现实时聊天，并不会对业务提升有帮助。

5）反向需求（Reverse Quality）：

这些需求是用户不期望或不希望出现的。满足这些需求可能会导致用户满意度降低，因为它们可能是不必要的或用户认为不值得的。

1. 过多的强制性步骤：在操作流程中设置过多的强制性步骤，可能会导致用户感到不适，并且带不来相应的价值。
2. 不必要的数据强制输入要求：要求用户输入大量非关键性数据，这会增加用户的工作量，并且带不来相应的价值。

3.4 需求分级工具：评价打分

B端产品经理为什么要了解评价打分？

在我们进行需求分析的过程中，存在着大量的定性信息，评价打分能够将定性的数据量化，帮助我们的决策更加客观。

评价打分的方法有很多，例如层次分析法等，本文选用的是李克特量表。

如何在B端产品需求中应用评价打分？

STEP1：收集用户需求

利用4.1中提到需求清单，进行需求的收集

STEP2：将用户的需求进行简单的分类

将需求分为功能需求、性能需求、用户体验需求等

STEP3：制定评价标准

制定评价标准，例如重要性、紧迫性、可行性、成本效益等，不同分类的需求，在不同的评价标准上可以采用不同的权重。

STEP4：设计评价量表

设计一个量表，让用户对每个需求的不同标准进行打分。量表可以是1到5分：

表格 15 量表赋值

用户都打完分后，就把每用户对每个需求的分数加起来，得到一个总分。这个总分就代表了用户对这些需求的整体态度。

接下来，根据总分把用户分成两组：一组是总分高的“高分组”；另一组是总分低的“低分组”。

然后，找出那些在“高分组”里得分高，在“低分组”里得分低的需求。这些就是大家特别看重的需求，可以用这些问题来组成李克特量表。

通过评价打分，能清楚地知道，哪些功能是用户真正关心的，哪些是不重要的。这样，我们可以优先开发用户都想要的功能，用最少的资源让用户更满意。

3.5 需求关联工具：N^2图

B端产品经理为什么要了解N^2图？

在刚才介绍的功能树中，我们只能了解到独立的功能与父级的关系。但是，B端产品经理要看到功能间的关系，图给我们一个很好的视角，去了解功能之间的关系。此外，深入了解图，可以帮助我们掌握解耦和模块化设计。

那我们怎么进行N^2图的绘制呢？

以某复合仓储系统为例：

STEP1：我们要梳理这个系统中包含什么功能（组件）？

• 订单管理：处理客户订单需求。
• 入库管理：处理客户卸货、收货、上架等需求。
• 出库管理：处理客户拣货。
• 库存管理： 记录库存流水、更新库位库存。
• 设备调度：调度库内硬件设备（AS/RS、AGV、机械臂、换标机、称重量方设备、分拣墙）。
• 库内硬件设备： 库内硬件设备（AS/RS、AGV、机械臂、换标机、称重量方设备、分拣墙）。
• 库内管理：处理客户移位、库存调整、品质变更、库存锁定、库存盘点等需求。
• 结算管理：处理订单的财务结算。
• 报告与分析：基于WMS作业数据生成报告和分析数据。

STEP2：我们要梳理出功能（组件）间的关系。

• A 到 B: 订单管理向入库管理发送订单信息。
• A 到 C: 订单管理向出库管理发送订单信息。
• B 到 D:入库管理向库存管理发送库存变化信息。
• C 到 D:出库管理向库存管理发送库存变化信息。
• B 到 E：入库管理向设备调度发送作业信息。
• C 到 E：出库管理向设备调度发送作业信息。
• E 到 F：设备调度向库内硬件设备下发调度指令。
• G 到 D：库内管理向库存管理发送库存变化信息。
• A 到 H：订单管理向结算管理下发订单信息。
• B 到 H：入库管理向结算管理下发入库作业信息。
• C 到 H: 出库管理向结算管理下发出库作业信息。
• A 到 I：订单管理与报告与分析共享订单信息。
• B 到 I：入库管理向报告与分析共享入库作业信息。
• C 到 I: 出库管理向报告与分析共享出库作业信息。
• E 到 I：设备调度向报告与分析共享调度作业信息。

STEP3：我们要明确每一种交互归属于什么类型的连接。

• 电气连接（E）：用于表示系统之间通过电子信号或数据交换进行通信。
• 机械连接（M）：表示物理上的机械交互，如传送带或自动化设备。
• 供应服务（SS）：表示一个系统为另一个系统提供必要的服务或资源。
• 数据服务（DS）：在WMS中，数据服务可能用于表示功能之间共享信息和数据。
• 控制服务（CS）：表示一个系统对另一个系统的操作进行控制。
• 接口（I）：表示系统之间的交互点，可以是软件接口或硬件接口。

STEP4：最后，我们可以通过绘图软件（这里用的是Process On），完成我们的图片绘制

图片 17 N^2图，以某复合仓储物流系统为例

以上，我们就完成了图的绘制，接着我们怎么进一步思考解耦呢？

STEP1：首先我们需要了解什么是紧耦合的典型状态：

面向一个系统集合进行图的绘制，如果可以简化为下面的形态，我们就可以判断其处于低内聚、紧耦合的状态。

图片 18 低内聚、紧耦合示例

面向一个系统集合进行图的绘制，如果可以简化为下面的形态，我们就可以判断其处于高内聚、松耦合的状态。

图片 18高内聚、松耦合示例

STEP2:我们将高耦合的系统，重新梳理功能，将其转化为高内聚、松耦合状态的过程，就称为解耦。

图片 19 解耦示意图

思考：为什么要解耦？

• 降低系统间的复杂性：减少各个系统之间的依赖，使结构更清晰。
• 提高系统可维护性：当系统组件之间的耦合度低时，对系统的一个部分进行修改或更新时，不会影响到其他部分。
• 增强可拓展性：对于松耦合的系统，新的功能可以被添加到系统中，而不需要对现有的代码进行大规模的修改。

3.6 业务需求整合工具：业务需求文档 （BRD）模板

B端产品经理为什么要熟练掌握业务需求文档（BRD）？

BRD定义了产品交付的范围，有助于避免需求的蔓延，并且能有效的控制客户预期，确保产品交付符合客户预期。

那么怎么引导关键用户或自行编写业务需求文档呢？

我们以“某项目仓储物流系统入库业务需求文档”为例：

注：如果是产品经理代为编写的业务需求文档，一定要保存好业务侧的确认信息（签字或邮件），避免后续阶段扯皮。

以上，就是B端产品经理工具包的第一部分，由于单篇文字限制，后续将持续更新第二部分-产品设计工具及开发测试阶段工具，欢迎收藏、评论或转发给有需求的小伙伴~