SUP.9 问题解决管理，面向产品和过程当中识别出来的问题，包含产品缺陷、过程执行当中发现的各类问题。很多项目图方便，不管是代码 bug、评审发现的过程问题，还是 MAN.5 风险管理项下的风险条目，全部录入同一套问题跟踪表单。缺陷属于已经发生的现实问题，风险属于未来才有可能发生的潜在不利事件，二者的分析逻辑、处置策略、闭环判定条件并不一样。全部混杂在 SUP.9 台账，会出现风险没有按照 MAN.5 流程开展分析，产品缺陷没有做根源分析这类情况。

实际落地过程中经常出现几类误区。把尚未发生的潜在风险录入 SUP.9 问题台账，用缺陷闭环逻辑处理风险，缺少风险概率、后果、缓解预案的分析。把产品缺陷、流程问题不加区分，全部套用同一套处置模板，产品缺陷缺少根源分析，流程类问题缺少纠正预防措施。闭环判定标准模糊，风险还没有消除，仅记录一条计划就标记关闭；缺陷只修改表面现象，没有定位根因就完成闭环。问题台账和其他过程产物缺少关联，评估时无法把问题记录对应到需求、测试、评审证据。

需要分清标准里不同过程的分工：SUP.9 问题解决管理处理已经发生的问题，包括产品缺陷、过程执行暴露出来的现实问题；MAN.5 风险管理专门处理尚未发生的潜在风险，二者不能互相替代。

项目前期明确台账分类规则。产品缺陷，例如代码 bug、文档错误，归入 SUP.9 问题解决管理，执行问题上报、影响分析、根源分析、纠正、验证闭环。过程类现实问题，例如评审没有按时开展、变更流程跳步，同样录入 SUP.9，除纠正本次问题之外，评估是否需要增加预防措施，防止其他项目复现。

对于还没有实际发生，只是有可能出现的潜在风险，例如供应链延期风险、新技术不成熟风险，不录入 SUP.9，交由 MAN.5 风险管理流程，完成风险识别、可能性与后果分析、制定缓解或者应急预案，持续监控风险状态。当风险真正发生，成为已经出现的现实问题之后，再创建 SUP.9 问题记录，承接后续处置闭环。

每一条 SUP.9 的问题记录，写明问题来源，来自测试、评审、客户反馈还是现场售后。产品类缺陷要开展根源分析，区分是偶发失误，还是体系流程存在短板。闭环不能只看表面现象修复完成，需要确认纠正措施已经验证，涉及过程短板的要确认预防措施落地。问题记录和对应的测试报告、评审纪要、变更单建立关联。

内部预评估核查 SUP.9 台账时，重点区分条目类型，检查风险类事项是否错误放在问题台账，产品缺陷的根源分析、验证记录是否完整。

SUP.9 不是万能的全品类跟踪表单，有它明确的适用边界。分清缺陷、现实问题、潜在风险，分别归到对应的 ASPICE 过程进行管控，才能够保证每一类事项都用正确逻辑处置，规避评估时的弱项。