业务流程图评审要形成可执行的结论，通过标准应写成“指标+口径+证据+阈值+例外”的组合，而非一句“评审无异议”。本文面向流程文档交付前的质量评审，说明如何把完整性、一致性、可执行性、可读性转成可统计或可核验的指标，给出计算、取证与判定步骤，并用示例演示标准如何落地。
要点总览（TL;DR）
- 通过标准应写成“指标+口径+证据+阈值+例外”的组合，避免只写“评审无异议”这类无法复核的结论。
- 完整性、一致性、可执行性、可读性四类质量属性需分别落到可统计对象，如异常分支覆盖率、需求条目对应率、活动要素齐备率、命名规范符合率。
- 每个指标要定义统计对象、版本、计数规则与分母，分母为零时登记为不适用，证据缺失时记为未取证并列入待补事项。
- 判定按确定范围→逐指标取证→计算→对照阈值→记录例外→给出结论的顺序执行，阈值可按流程风险分级设定。
- 正式启用前用一张已完成的流程图做试评，校准阈值与证据要求；评审通过只代表流程图作为需求表示达到约定质量，不代表需求内容本身正确。
评审通过标准要解决什么问题
评审通过标准的核心任务，是在流程文档交付前确认流程图已经达到可作为需求表示基线的质量水平。它回答的是“这张图能不能作为后续设计、开发、测试共同参照的版本”，而不是“业务需求本身是否合理”。把这两件事分开，评审才能聚焦在流程图这一交付物上，结论也才可复核。
判定对象需要事先说清楚。单张流程图的评审关注该图自身的节点、连线、角色与分支是否自洽；一组关联流程图的评审还要看跨图衔接，例如上游流程的输出是否构成下游流程的输入、同一角色在不同图中的职责是否冲突、异常处理是否在关联图中闭环。两类对象的检查项和证据要求不同，标准中应分别列出。
边界同样要写明。需求内容的业务正确性归需求分析与澄清环节，由业务方确认；系统架构设计和UI绘制不属于本文讨论的流程图质量范围。评审通过标准只对流程图的表示质量负责，避免评审会把“图对不对”和“业务对不对”混在一起争论。
一套完整的通过标准由五个要素组成：指标说明评什么，口径说明怎么数，证据说明凭什么确认，阈值说明达到什么程度算通过，例外说明特殊情况如何处理。缺少任何一项，结论都容易退回主观判断。下表概括这五个要素的作用。
| 要素 | 回答的问题 | 缺失后的典型后果 |
|---|---|---|
| 指标 | 评哪一项质量属性 | 评审意见散乱，无法逐项对照 |
| 口径 | 统计对象、版本与计数规则 | 不同人算出不同结果 |
| 证据 | 用什么材料支撑结论 | 结论无法追溯和复核 |
| 阈值 | 达到什么水平算通过 | 评审靠印象拍板 |
| 例外 | 特殊情况如何记录与补正 | 问题被口头放过，无人跟进 |
质量指标与评估范围怎么划
四类质量属性需要各自落到可统计的对象上，指标才有意义。完整性看覆盖，一致性看对应关系，可执行性看活动能否被角色按图执行，可读性看命名、分层与图例是否统一。每类属性选两到四个指标即可，指标过多会让评审变成填表。
| 质量属性 | 指标示例 | 统计对象与单位 |
|---|---|---|
| 完整性 | 异常分支覆盖率 | 已标注异常分支数 ÷ 需求条目列出的异常场景数，按分支计 |
| 完整性 | 角色覆盖完整率 | 图中已出现的执行角色数 ÷ 需求条目涉及的角色数，按角色计 |
| 一致性 | 需求条目对应率 | 能在图中定位到对应活动的需求条目数 ÷ 纳入范围的需求条目数，按条目计 |
| 一致性 | 术语统一率 | 与术语表一致的节点名称数 ÷ 抽查节点名称总数，按节点计 |
| 可执行性 | 活动要素齐备率 | 同时具备执行角色、输入、输出与判定条件的活动数 ÷ 活动总数，按活动计 |
| 可执行性 | 判定条件明确率 | 标注了明确条件的网关数 ÷ 网关总数，按网关计 |
| 可读性 | 命名规范符合率 | 符合命名规则的节点与连线数 ÷ 抽查总数，按元素计 |
| 可读性 | 图例与分层一致性 | 定性核验：图例是否覆盖所用符号，分层是否在同一粒度 |
评估范围要在评审启动时固定下来，包括纳入评审的流程图清单、每张图的版本号、关联的需求文档与术语表版本。范围一旦确定，评审过程中新增的图或改动的版本应登记为下一轮评估对象，避免边评边改导致口径漂移。对于确实不适用或申请豁免的指标，例如某流程本身不涉及异常分支，应在范围表中登记豁免理由与确认人，而不是在计算时悄悄跳过。
数据口径与证据要求
口径的作用是让两个人按同一规则能算出同一结果。每个指标至少写明四项：统计对象（节点、连线、角色、分支或需求条目）、版本（以哪个流程图版本和需求文档版本为准）、计数规则（什么算一个、重复出现如何计）、时间窗（本次评审取哪个时间点的快照）。口径写在标准文档里，评审时直接引用，不在会上临时解释。
证据要求解决“凭什么确认”。可留存的形式包括：流程图版本链接或文件编号、评审记录（参与人、日期、逐项结论）、与需求条目的对照编号、术语表版本。定性指标的证据通常是评审人对具体条目的确认记录，例如“图例覆盖检查：已核对，符号说明完整，确认人某某”。证据与指标一一对应，结论才能被后续复核。
缺失值和无法取证的情况要预先规定处理方式。常见做法是：证据缺失的指标记为“未取证”，不计入通过项，也不直接判为不通过，由评审主持人在结论中列为待补事项并指定补正期限。分母为零的情形，例如流程图中没有网关因而无法计算判定条件明确率，应登记为“不适用”，并在结论中注明，不能按100%计入通过。
| 情形 | 处理规则 | 记录要求 |
|---|---|---|
| 证据缺失 | 记为未取证，列入待补事项 | 写明缺失项、责任人与补正期限 |
| 分母为零 | 登记为不适用，不参与通过判定 | 注明原因，如“本流程无异常分支” |
| 版本不一致 | 暂停该项计算，先统一版本 | 记录涉及的版本号与统一结果 |
| 范围外新增内容 | 转入下一轮评估 | 登记新增图或改动点 |
通过标准的计算与判定步骤
判定按固定顺序执行：确定范围→逐指标取证→计算→对照阈值→记录例外→给出结论。顺序固定可以减少争议，也便于把每一步的产物留存下来。计算时每个定量指标写成公式，明确分子、分母与单位，例如“活动要素齐备率 = 四要素齐备的活动数 ÷ 活动总数 × 100%，按活动计”。定性指标写成“证据类型 + 评审人确认”，例如“图例一致性：提交图例页与符号清单，由评审人逐项核对并签字确认”。
阈值按流程图等级或风险分级设定。高风险流程，例如涉及资金、合规或对外服务的流程，采用更严格的阈值，并要求关键分支全部有证据；低风险或内部辅助流程可以适当放宽，或与相邻流程合并评审。阈值应写成区间或明确数值，例如“活动要素齐备率不低于95%，且缺失项不得集中在关键路径活动上”，避免只写“基本齐备”。
例外和有条件通过需要记录理由、责任人与补正期限。有条件通过适用于主体质量达标、个别指标存在可限期修正的缺口的情形；结论中应写明缺口项、影响范围与复评时间。例外记录与评审记录放在一起，作为下一轮评估的输入。
- 确定范围：锁定流程图清单、版本与关联需求文档，登记豁免项。
- 逐指标取证：按口径收集版本链接、对照编号与评审确认记录。
- 计算：按公式算出每个定量指标，定性指标形成核验结论。
- 对照阈值：逐项标注达标、未达标、不适用或未取证。
- 记录例外：写明例外项、理由、责任人与补正期限。
- 给出结论：通过、有条件通过或不通过，并附证据清单。
评审记录、流程图版本与需求条目的关联如果分散在邮件和共享盘里，复核成本会很高。ONES 的文档与工作项管理可以把流程图文档、评审记录和对应需求条目放在同一工作项下关联，评审结论和待补事项以工作项状态流转，补正期限和责任人随记录留存，便于下一轮评估直接引用。这一衔接服务于证据留存和结论追溯，标准本身的指标与阈值仍由团队按上述方法确定。
一个完整的评估示例
以下为演示情景，指标取值按假设数据填写，实际使用时替换为团队真实范围与版本。示例对象为“订单退款审批”流程图 V2.3，关联需求文档 REQ-118 的 12 条需求条目，评审范围包含该图及其上游“退款申请提交”图 V1.7。
完整性方面，需求条目列出异常场景 8 个，图中已标注异常分支 6 个，异常分支覆盖率 = 6 ÷ 8 = 75%；需求涉及角色 5 个，图中出现 5 个，角色覆盖完整率 = 5 ÷ 5 = 100%。一致性方面，12 条需求条目中有 11 条能在图中定位到对应活动，需求条目对应率 = 11 ÷ 12 ≈ 91.7%；抽查节点名称 20 个，与术语表一致 19 个，术语统一率 = 19 ÷ 20 = 95%。可执行性方面，活动总数 14 个，四要素齐备 13 个，活动要素齐备率 = 13 ÷ 14 ≈ 92.9%；网关 4 个，条件明确 4 个，判定条件明确率 = 100%。可读性方面，抽查元素 30 个，命名规范符合 28 个，命名规范符合率 ≈ 93.3%；图例经评审人核对确认完整。
| 指标 | 计算 | 结果 | 阈值 | 判定 |
|---|---|---|---|---|
| 异常分支覆盖率 | 6 ÷ 8 | 75% | ≥90% | 未达标 |
| 角色覆盖完整率 | 5 ÷ 5 | 100% | 100% | 达标 |
| 需求条目对应率 | 11 ÷ 12 | 91.7% | ≥95% | 未达标 |
| 术语统一率 | 19 ÷ 20 | 95% | ≥95% | 达标 |
| 活动要素齐备率 | 13 ÷ 14 | 92.9% | ≥95% | 未达标 |
| 判定条件明确率 | 4 ÷ 4 | 100% | 100% | 达标 |
| 命名规范符合率 | 28 ÷ 30 | 93.3% | ≥90% | 达标 |
证据清单包括：流程图 V2.3 与上游图 V1.7 的版本链接、REQ-118 的条目对照表、术语表版本、评审记录与图例核对确认。例外记录两项：缺失的 2 个异常分支属于“支付超时重试”场景，需求条目已列出但图中未展开，责任人为流程负责人，补正期限为复评前；1 条未定位的需求条目为“退款到账通知”，需确认是否属于本流程范围。最终判定为有条件通过：主体质量接近阈值，缺口集中在异常分支覆盖和个别活动要素，补正后复评。
结果解读与标准维护
单项指标达标不能推出整体通过。示例中命名规范符合率和判定条件明确率均达标，但异常分支覆盖率未达标，若只看可读性指标就会漏掉关键缺口。综合判定应以关键指标优先：涉及异常处理和角色职责的指标未达标时，即使其他指标全部达标，也应给出有条件通过或不通过。
指标之间不可比的情形需要识别。范围不同（单图与关联图组）、版本不同（评审期间图被修改）、粒度不同（活动拆分粗细不一致）都会让同一指标的数值失去可比性。出现这些情况时，应先统一范围和版本再比较，或在结论中注明不可比，避免用历史数值直接下判断。
标准需要定期复核。触发调整的条件包括：连续多轮评审中某指标普遍达标但漏检问题频发，说明阈值偏松；某指标长期因取证困难被记为未取证，说明口径或证据要求需要简化；流程分级规则变化时，阈值应同步调整。复核由评审主持人或质量负责人发起，调整结果记录在标准文档的版本历史中。
最常见的误用是把评审通过当作需求正确性的保证。评审通过只说明流程图作为需求表示达到了约定质量，业务规则是否合理仍需需求分析与业务确认环节负责。把两者分开表述，评审结论才不会被过度引用，标准也才能在后续迭代中保持可信。
常见问题
流程图评审中，某个指标因为流程本身没有异常分支而无法计算，应该判为通过还是不通过？
这种情况应登记为“不适用”，不参与通过判定，并在结论中注明原因，例如“本流程无异常分支”。不能按100%计入通过，也不宜直接判为不通过。登记不适用时，建议同时记录确认人，避免后续复核时对豁免范围产生分歧。
评审时发现流程图版本在评审期间被修改了，已经算出的指标还能用吗？
版本不一致时，该项指标应暂停计算，先统一版本再重新取证。评审记录中要写明涉及的版本号与统一结果。如果修改发生在评审启动后，建议将改动后的版本登记为下一轮评估对象，避免边评边改导致口径漂移。
有条件通过和直接不通过之间怎么区分？补正期限一般怎么定？
有条件通过适用于主体质量达标、个别指标存在可限期修正的缺口的情形；不通过适用于关键指标未达标且缺口无法在短期内补正，或缺口影响范围较大的情形。补正期限由评审主持人与责任人根据缺口工作量协商确定，并在结论中写明缺口项、影响范围与复评时间。例外记录与评审记录放在一起，作为下一轮评估的输入。
阈值设定有没有通用参考值，还是每个团队必须自己试评确定？
阈值没有统一标准，需要结合流程图等级或风险分级来设定。高风险流程采用更严格的阈值，低风险流程可以适当放宽或合并评审。建议在正式启用前用一张已完成的流程图做试评，观察指标取值分布与漏检情况，再校准阈值。阈值应写成明确数值或区间，例如“活动要素齐备率不低于95%，且缺失项不得集中在关键路径活动上”，避免只写“基本齐备”。
评审通过后，业务方又提出需求理解有偏差，评审结论还有效吗？
评审通过只说明流程图作为需求表示达到了约定质量，业务规则是否合理仍需需求分析与业务确认环节负责。如果业务方提出需求理解偏差，应回到需求分析与澄清环节确认内容，流程图可能需要相应修订并重新评估。把“图的质量”和“业务内容的正确性”分开表述，评审结论才不会被过度引用。
