流程需求分析是系统化工程，需立足业务目标与痛点，通过明确边界、拆解流程、识别场景、梳理规格四步法，导出清晰的需求规格，为流程解决方案设计筑牢基础，让流程设计有章可循。

经过前面一系列的流程专题的介绍，大家也能够清晰了解到，流程架构的设计是一个系统化的工程。

如果只是站在流程本身去看待流程设计这个问题，你会发现无从下手。

但如果你是站在一个项目、一个产品的维度来看待这件事，就会变得非常简单，至少也是有了落脚点。

因为讲产品、讲项目的太普遍了，这就进入了大家的舒适区。

典型的IPD开发流程就可以用来设计流程。

当然，在流程设计之前，需要先做好对业务的分析，包含：业务目标、业务痛点、现有流程(AS-IS)、用户访谈记录、系统现状、关键绩效指标等等内容。

接下来就可以做流程的需求分析了。

需求分析阶段的核心目标是要：

• 系统化、结构化地导出清晰的流程需求规格；
• 为设计满足业务期望（解决痛点）的流程解决方案奠定坚实基础。

需求分析四步法分别是：第一步：定边界第二步：拆解流程第三步：识别场景 第四步：梳理规格

接下来讲解一下这四个步骤。

第一步，定边界

这个步骤的目标是明确分析的范围，避免范围蔓延，聚焦核心价值流。

这个阶段的关键交付物：顶层价值链、边界说明文档。

具体怎么做呢？

首先是要确定本次分析涉及的核心业务领域，比如：订单到现金、采购到付款、研发到上市。

接下来绘制顶层泡泡图：

其中每个“泡泡”代表一个端到端的高阶业务能力或核心价值流阶段 ，比如商机管理、售后服务；

用箭头清晰展示泡泡间的主要流程流向和价值传递。

明确标注起点和终点。

接下来继续定义边界：

范围内In-Scope：清晰列出本次分析包含的具体业务环节、组织范围、系统范围、地理范围。

范围外Out-of-Scope：明确排除哪些相关但不在本次分析范围内的环节、组织、系统、地域；

边界假设：记录任何影响边界的假设条件。

再往下就是识别关键干系人：

明确该边界范围内涉及的主要业务部门、关键用户角色、IT系统负责人。

最后是评审与确认：

与核心干系人（业务负责人、产品负责人、架构师）评审边界定义并获得正式签署。

第二步：拆解流程

第二步的目标是将顶层业务能力逐层分解为可管理、可分析的子流程和活动，并理解整个业务过程。

这个阶段的关键交付物包括，分层级泡泡图 (L1-Ln) 、泡泡图详细说明文档。

具体怎么做呢？

首先是选择分解的起点：从顶层泡泡图中的一个泡泡开始。

接下来构建下层泡泡图 (L2)：

将选定的高阶能力 (L1泡泡) 分解为5-9个关键子流程 (L2泡泡)；

明确子流程间的逻辑顺序 (串行、并行、选择分支) 和交互点；

标注关键输入/输出物 (如：申请单、审批结果、发货通知)。

再往下是描述业务过程：

为每个L2泡泡撰写简明描述：说明该子流程的目的、主要活动概览、触发事件、结束状态；

识别该层级涉及的主要角色/岗位。

接下来判断是否继续分解 (应用退出标准)：

退出标准：

• 粒度达标：当前层级的泡泡已代表一个单一、明确的业务目标，通常对应一个用户故事或一个可独立执行的流程步骤；
• 规则清晰： 该层级的业务规则和决策点能够被相对清晰地识别和描述。
• 责任明确： 该层级的活动能明确归属到一个主要角色或岗位。
• 痛点可定位： 能够在该层级有效关联和定位已知的业务痛点。

如果不符合退出标准，则重复步骤2.2-2.4。

继续对L2泡泡进行L3分解，依此类推 (L3, L4… )。

最后是文档化：

维护清晰的层级关系图 (表明L1->L2->L3…的归属)。

泡泡图说明文档包含：

各层级泡泡定义、目的、输入输出、主要角色、简要活动描述、已知痛点初步映射。

第三步：识别场景

第三步的目标是识别影响流程执行路径的各种业务场景，确保流程解决方案能覆盖所有业务过程。

这个阶段的关键交付物包括：

业务场景清单、活动/场景关系矩阵、业务场景图 (流程图/状态图)。

详细环节与操作：

一是识别业务要素 (驱动场景的因素)： 针对当前分解层级 (如L3/L4) 的每个活动/决策点，识别：

• 业务对象状态，比如订单状态=待审核、已批准、已拒绝；
• 业务规则/条件，比如金额>10万需上级审批；
• 异常/变体，比如客户信息不全、库存不足；
• 外部事件，比如法规更新通知；
• 用户角色差异，比如内部员工 vs 合作伙伴。

接下来生成场景清单：

• 基于识别的要素，组合出该活动/决策点下的所有典型场景和边缘场景。
• 使用 Given-When-Then 格式描述场景。
• 清晰定义前置条件、触发事件、预期结果/流转。

简单示例：

场景ID： SC_OrderApproval_HighRisk

• Given： 客户信用等级为C级 (高风险)
• And： 订单金额 > 50,000 RMB
• When： 销售代表提交订单审批
• Then： 系统自动路由至区域总监审批
• And： 触发高风险客户审核流程

接下来是做场景与流程匹配：

将识别出的场景映射到对应的泡泡图层级 (L2/L3/L4) 和具体活动/决策点。

建立 活动/场景关系矩阵 (行：活动/决策点， 列：场景， 单元格：关联性)。

之后是场景建模：

绘制包含分支、合并、事件的详细业务场景流程图，清晰展示不同场景下的路径。

或使用状态图展示关键业务对象 (如订单、合同) 在不同场景下的状态变迁。

最后是循环：

对每个需要详细分析的层级 (通常是L3/L4及更细粒度) 执行步骤3.1-3.4。

第四步：梳理规格

第四步的目标是基于细化的流程分解和场景分析，详细定义流程需求规格，为设计解决方案和识别Gaps提供精确输入。

这个阶段的关键交付物： 流程需求规格说明书 (PRS)。

详细环节与操作：

详细描述业务步骤： 针对达到退出标准的最底层活动 (通常是L4/L5)：

步骤编号与名称： 清晰唯一标识；

角色/执行者： 明确负责执行的角色或岗位；

详细操作描述： 具体说明用户/系统在该步骤做什么；

输入： 所需的文档、数据、信息、触发事件；

输出： 产生的文档、数据、信息、状态变更、触发事件；

所用系统/工具： 明确支持该步骤的IT系统或工具。

定义业务规则与管控要求 (原子化)：

业务规则：

清晰、无歧义地描述控制流程逻辑的条件、计算、决策逻辑；

类型： 验证规则、计算规则、路由规则、授权规则、合规规则。

管控要求：

KPI指标： 该步骤/流程需满足的效率、质量、成本等指标；

控制点： 必要的审批、复核、审计点；

合规要求： 必须遵循的内外部政策、法规、标准；

风险控制要求： 针对识别的风险点的控制措施。

关联痛点与Gaps：

明确指出当前步骤/规则在AS-IS流程中是如何导致业务痛点的 (建立因果关系)；

清晰描述该步骤/规则在AS-IS状态与需求期望之间的具体差距 (Gap)。

最后，整理需求规格说明书 (PRS)。