流程需求分析是系统化工程，需立足业务目标与痛点，通过明确边界、拆解流程、识别场景、梳理规格四步法，导出清晰的需求规格，为流程解决方案设计筑牢基础，让流程设计有章可循。经过前面一系列的流程专题的介绍，大家也能够清晰了解到，流程架构的设计是一个系统化的工程。如果只是站在流程本身去看待流程设计这个问题，你会发现无从下手。但如果你是站在一个项目、一个产品的维度来看待这件事，就会变得非常简单，至少也是有了落脚点。因为讲产品、讲项目的太普遍了，这就进入了大家的舒适区。典型的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_HighRiskGiven： 客户信用等级为C级 (高风险)And： 订单金额 > 50,000 RMBWhen： 销售代表提交订单审批Then： 系统自动路由至区域总监审批And： 触发高风险客户审核流程接下来是做场景与流程匹配：将识别出的场景映射到对应的泡泡图层级 (L2/L3/L4) 和具体活动/决策点。建立 活动/场景关系矩阵 (行：活动/决策点， 列：场景， 单元格：关联性)。之后是场景建模：绘制包含分支、合并、事件的详细业务场景流程图，清晰展示不同场景下的路径。或使用状态图展示关键业务对象 (如订单、合同) 在不同场景下的状态变迁。最后是循环： 对每个需要详细分析的层级 (通常是L3/L4及更细粒度) 执行步骤3.1-3.4。第四步：梳理规格第四步的目标是基于细化的流程分解和场景分析，详细定义流程需求规格，为设计解决方案和识别Gaps提供精确输入。这个阶段的关键交付物： 流程需求规格说明书 (PRS)。详细环节与操作：详细描述业务步骤： 针对达到退出标准的最底层活动 (通常是L4/L5)：步骤编号与名称： 清晰唯一标识；角色/执行者： 明确负责执行的角色或岗位；详细操作描述： 具体说明用户/系统在该步骤做什么；输入： 所需的文档、数据、信息、触发事件；输出： 产生的文档、数据、信息、状态变更、触发事件；所用系统/工具： 明确支持该步骤的IT系统或工具。定义业务规则与管控要求 (原子化)：业务规则：清晰、无歧义地描述控制流程逻辑的条件、计算、决策逻辑；类型： 验证规则、计算规则、路由规则、授权规则、合规规则。管控要求：KPI指标： 该步骤/流程需满足的效率、质量、成本等指标；控制点： 必要的审批、复核、审计点；合规要求： 必须遵循的内外部政策、法规、标准；风险控制要求： 针对识别的风险点的控制措施。关联痛点与Gaps：明确指出当前步骤/规则在AS-IS流程中是如何导致业务痛点的 (建立因果关系)；清晰描述该步骤/规则在AS-IS状态与需求期望之间的具体差距 (Gap)。最后，整理需求规格说明书 (PRS)。本文由人人都是产品经理作者【产品人卫朋】，微信公众号：【产品人卫朋】，原创/授权 发布于人人都是产品经理，未经许可，禁止转载。题图来自Unsplash，基于 CC0 协议。