IPD流程图和实际执行对不上，排查时先别急着归因。把“不一致”拆成可观察的症状，选一条产品线或一个已结束项目作样本，用实际发生的活动、责任人、评审结论和变更记录回填流程图，逐节点比对，再判断是图缺失、机制不清还是执行绕行。排查过程需要保留比对记录和修正清单，ONES可在其中承载节点比对与差异跟踪。
要点总览（TL;DR）
- 排查前先把“不一致”拆成五类可观察症状：图上节点实际没做、实际活动图上没有、顺序不同、角色不符、决策结论无记录，并选一条产品线或一个已结束项目作为比对样本。
- 原因假设分四条线索：流程图完整性、角色交接、决策节点、执行侧；每条假设配可取得的证据，证据到手才升级为结论，未验证的只列为待验证方向。
- 节点比对按“取受控版本流程图—回填实际执行路径—标记缺失/多余/顺序/角色四类差异—追溯原因—形成修正清单”推进，涉及流程文件变更先备份原版本。
- 修正后要在下一项目或下一阶段按同一方法复查，确认差异项关闭；若差异源于流程设计本身不合理，应先调整流程再要求执行对齐。
先确认不一致的具体表现和范围
“流程图和实际执行不一致”是一句笼统的判断，直接拿去讨论原因，很容易变成各部门各说各话。第一步是把这句话拆成能指认、能记录的症状，并确定拿哪个项目、哪个版本的流程图来比对。
常见症状可以归为五类，排查时逐条对照，有就记，没有就空着：
- 图上有的节点实际没做，比如某个技术评审在项目里被跳过或合并；
- 实际做了的活动图上没有，比如临时增加的方案讨论、客户确认或专项测试；
- 节点顺序不同，比如决策评审在技术评审结论出来之前就开了；
- 责任人或评审角色与图不符，比如图上是某部门负责人评审，实际由接口人代签；
- 决策结论没有记录，节点开了会，但通过与否、附带条件、后续动作找不到书面依据。
范围界定决定排查工作量。建议选一条产品线或一个已经结束的项目作为比对样本，明确三件事：使用的是哪一版受控流程图、覆盖哪些阶段、涉及哪些角色。样本选已结束项目，是因为活动、交付物和评审记录都已沉淀，回填时不容易遗漏；选进行中的项目，则适合观察执行侧是否存在绕行。
界定范围后，还要判断脱节的程度。如果多数阶段都存在节点缺失或顺序错位，属于整体脱节，问题更可能出在流程图本身或流程宣贯；如果只有个别节点对不上，属于局部偏差，优先查该节点的角色交接和记录。把初始差异条目列成清单，标注发现位置和见证人，这份清单就是后续比对的底稿。
逐类核对原因假设与排除证据
症状清单出来后，可以按四条线索提出原因假设：流程图完整性、角色交接、决策节点、执行侧。每条假设都要配一份能取得的具体证据，证据到手才升级为结论，拿不到证据的只作为待验证方向，不写进整改要求。
| 原因假设 | 典型表现 | 验证证据 | 状态记录 |
|---|---|---|---|
| 流程图完整性不足 | 阶段划分过粗，活动缺失，输入输出未定义 | 受控流程图版本、流程模板与实际活动清单逐项比对 | 待验证／已确认／已排除 |
| 角色交接不清 | 交接责任人不明确，跨部门接口无定义，角色兼任导致节点被跳过 | 交接记录、任务分派记录、角色职责表 | 待验证／已确认／已排除 |
| 决策节点设置或权限问题 | 评审点位置不合理，决策权限不清，评审结论未留痕 | 评审纪要、决策记录与图上决策点逐一对照 | 待验证／已确认／已排除 |
| 执行侧绕行或缺少模板 | 项目压力下简化流程，流程未宣贯，没有可填写的执行模板 | 变更记录、例外审批、当事人访谈 | 待验证／已确认／已排除 |
核对流程图是否完整，重点看三处：阶段之间的输入输出是否闭合，每个活动的责任角色是否唯一可指认，每个决策点是否写明了决策依据和结论形式。如果图上只写了“完成评审”，没写评审什么、谁拍板、结论记在哪里，这个节点在实际执行中几乎必然走样。
角色交接的排查要落到具体接口。跨部门交接最容易出问题的地方，是图上画了一条箭头，但箭头两端没有明确交付物和接收标准。验证时取任务分派记录和交接记录，看实际交接是否有人签收、是否附了交付物；如果角色兼任普遍存在，还要确认兼任是否经过授权，还是默认由同一人顺带完成。
决策节点的排查，把图上每个决策点与评审纪要一一对照。重点看三件事：评审是否在正确的时点召开、参会角色是否具备决策权限、结论是否形成书面记录并传达到下游。以IPD中常见的计划阶段为例，技术评审对整体技术方案和各子系统设计进行验证，阶段决策评审基于评审结果批准基线版本的业务计划书；如果实际项目里决策评审先于技术评审结论，或者结论只停留在会议口头，就属于决策节点与图不符。
执行侧的假设需要谨慎对待。项目压力下绕行、流程未宣贯、缺少可执行模板，这三种情况在访谈中常被混在一起说。区分方法是看变更记录和例外审批：有正式例外审批的，属于流程允许的偏离，应回写流程图或补充说明；没有任何记录的简化，才属于绕行，需要纠正执行。
按节点比对的排查步骤
原因假设建立后，用一次完整的节点比对把差异定位到具体位置。比对顺序从流程图本身开始，再到实际路径，最后追溯原因，避免一上来就讨论“谁没按流程做”。
- 取受控版本流程图。确认使用的是当前生效版本，在图上标注阶段、活动、责任角色、输入输出和决策点。若存在多个版本，先确认哪个是受控版本，其余版本封存备查。
- 回填实际执行路径。以选定项目为样本，按时间顺序把实际发生的活动、交付物、责任人和评审结论填进对照表，形成一条可追溯的实际路径。交付物以实际文档为准，不以计划清单为准。
- 逐节点比对。把实际路径与流程图并排，标记四类差异：图上缺失（实际做了图上没有）、图上多余（图上有实际没做）、顺序差异、角色不符。每条差异注明节点名称、发生时间和证据位置。
- 追溯原因。对每条差异回到上一节的原因假设表，判断属于图的问题还是执行的问题。同一节点出现多条差异时，优先查该节点的输入输出定义和角色交接。
- 形成修正清单。按“补图、补机制、纠正执行”三类给出动作，每条明确责任人和完成时限。补图指修订流程图和模板；补机制指明确交接标准、决策权限和记录要求；纠正执行指对绕行行为进行宣贯和纠正。
比对过程中涉及流程文件变更时，先备份原版本并保留变更记录。流程图的修订往往牵动多个项目的执行口径，没有备份就无法回溯比对基准，也无法判断差异是修订前遗留还是修订后新产生。
比对表建议保留以下字段：节点编号、图上活动、实际活动、责任角色、输入输出、差异类型、证据来源、原因判断、修正动作、责任人、时限。这张表既是排查记录，也是后续验证的对照依据。
修正后的验证与复发预防
修正清单关闭不等于问题解决，还要验证流程图与执行重新一致。验证方式是在下一个项目或下一阶段，按同一套比对方法复查：取同一版流程图，回填实际路径，确认原差异条目是否关闭、是否出现新的差异。复查记录与首轮比对表放在一起，形成可追溯的闭环。
防止再次脱节，需要把几件事固定下来：
- 流程图纳入变更管理。流程调整与项目实际做法同步更新，避免图上一版、执行一版长期并存。
- 关键决策节点保留评审结论与例外记录。结论写清通过与否、附带条件和后续动作，例外走正式审批，作为一致性证据。
- 定期抽查节点执行证据。按项目或阶段抽取样本，核对活动、角色和记录，把发现的差异条目纳入流程改进跟踪。
- 明确停止点。如果差异源于流程设计本身不合理，比如评审点设置过密导致项目无法承受，应先调整流程再要求执行对齐；在流程未调整前强行要求执行，只会把差异推到记录之外。
这套排查要持续运转，比对表、差异清单和修正记录需要有稳定的承载位置。ONES研发项目管理平台遵循IPD的理念和方法，覆盖概念、计划、开发、验证、发布等阶段，支持从需求挖掘、收集、结构化到开发决策、研发落地的全流程管理；团队可在同一平台中协同管理项目事项、过程信息和关键节点，减少市场、产品、研发等角色之间的信息断层。排查中形成的节点比对表、差异条目和修正清单，可以作为项目事项和文档留痕，供下一轮复查时对照。企业可结合自身产品研发流程、组织分工和管理要求进行方案规划，逐步形成适合自身的IPD管理体系。
常见问题
流程图和实际执行只有个别节点对不上，还需要做完整比对吗？
可以缩小比对范围，但方法不变。先确认偏差集中在哪个阶段或哪类节点，再只对该节点及其上下游做回填比对。局部偏差更可能出在角色交接和记录环节，重点查该节点的输入输出定义、交接签收和评审结论是否留痕。若同一节点反复出现差异，再扩大到整条流程复查。
项目里确实有正式例外审批，这种偏离算不算流程图与执行不一致？
有正式例外审批的偏离属于流程允许的调整，排查时应把它单独标记，与无记录的绕行区分开。处理方式是把例外审批的内容回写到流程图或补充说明中，让图与实际做法保持一致；如果例外频繁出现在同一节点，说明该节点的设计需要重新评估，而不是继续逐次审批。
流程图上只写了“完成评审”，没写评审什么、谁拍板，该怎么补？
这类节点是排查中优先修订的对象。补图时至少写清三件事：评审对象与输入交付物、具备决策权限的角色、结论的记录形式与传达对象。可以参照IPD中技术评审与决策评审的分工来设计，例如计划阶段技术评审验证整体技术方案和各子系统设计，阶段决策评审基于评审结果批准基线版本的业务计划书，两类评审的职责和结论形式分开定义。
差异确认是流程设计本身不合理，还要先纠正执行吗？
不建议。若证据显示评审点设置过密、节点顺序与业务实际冲突，或角色定义无法落地，应先调整流程再要求执行对齐。在流程未调整前强行要求执行，差异往往被推到记录之外，后续更难排查。调整流程时保留原版本和变更记录，调整后按同一比对方法复查，确认新版本能被实际执行承接。
排查记录和修正清单放在哪里，才能支撑下一轮复查？
关键是让比对表、差异条目和修正清单有稳定的承载位置，并与项目事项关联，避免散落在个人文档里。ONES研发项目管理平台遵循IPD的理念和方法，覆盖概念、计划、开发、验证、发布等阶段，团队可在同一平台中协同管理项目事项、过程信息和关键节点，减少市场、产品、研发等角色之间的信息断层；排查形成的记录可作为项目事项和文档留痕，供下一轮复查时对照。
