📚 课程目录第4章故障排查方法论

4. 故障排查方法论

结算审核流程中的“故障”通常表现为：审减率异常波动、反复退回修改、争议久拖不决、签证资料缺失等。要系统性地排查并根治这些故障，不能仅凭经验“拍脑袋”，必须引入成熟的质量管理工具。本节将重点讲解四种在结算审核场景中经过验证的故障排查方法论。

PDCA循环（Plan-Do-Check-Act）是质量管理的基本逻辑，同样适用于结算审核流程的调优。它不是一次性解决问题，而是通过螺旋上升的循环，持续降低审核故障率。

阶段	审核场景应用	关键输出物
P（计划）	分析历史审核数据，识别高频争议项（如土方工程量、材料调差），设定本次审核的“审减率目标”与“一次通过率目标”。	审核计划书、风险清单
D（执行）	按照计划执行审核，使用标准化检查清单（Checklist）逐项核对，对争议项进行标记并记录初步意见。	审核工作底稿、问题标记
C（检查）	复核审核结果，对比计划目标。检查是否存在漏项、计算错误或标准应用不一致。对退回修改的结算书进行二次审查。	复核记录、偏差分析表
A（处理）	将成功的经验（如某类争议的标准化处理方式）固化为新的审核细则；将失败的教训（如某类资料缺失的预防措施）纳入下一轮计划。	流程优化建议、更新后的模板

    案例提示： 某项目在P阶段发现“隐蔽工程签证”是争议重灾区。在D阶段，审核员重点核查影像资料与签证单的对应关系。C阶段发现影像资料日期与签证日期不符。A阶段将此问题纳入“签证审核前置条件清单”，并在下一轮循环中要求承包商在提交签证时必须附带时间戳照片。

当审核流程出现异常（如某类签证审核时间超期3倍），使用5W1H（What, Why, Where, When, Who, How）可以快速将模糊的问题具象化，避免在表面现象上浪费精力。

应用技巧： 在结算审核中，建议将5W1H制作成一张“故障排查卡”，贴在审核看板上。每次遇到争议或延误，先填卡，再讨论。

维度	中文对应	审核故障排查示例
What	发生了什么故障？	某标段土方工程量审核结果与送审量偏差超过20%。
Why	为什么发生？	送审方采用“平均断面法”，审核方要求采用“方格网法”，计算方法不一致。
Where	在哪个环节发生？	发生在“工程量核对”环节，具体为“土方工程”子项。
When	何时发现/发生？	在审核流程的第5个工作日，进行第一次数据比对时发现。
Who	涉及哪些角色？	承包商预算员（送审方）、咨询公司土建审核师（审核方）、监理工程师（原始数据提供方）。
How	如何解决/预防？	在合同或技术规范中明确土方量计算方法；建立“计算方法确认函”作为审核前置条件。

鱼骨图（因果图）和故障树分析（FTA）是两种互补的结构化分析工具。鱼骨图适合头脑风暴，快速罗列可能原因；故障树适合逻辑推演，定量计算故障概率。

鱼骨图将“结算审核争议”作为鱼头，从“人、机、料、法、环、测”六个维度（5M1E）展开，系统梳理潜在原因。

故障树分析使用“与门”和“或门”将顶层故障事件逐层分解为基本事件。在结算审核中，可用于分析“结算审核严重超期”或“重大审减争议”等复杂故障。

注意： FTA需要一定的逻辑符号基础。在工程项目成本管理中，建议先从简单的“定性FTA”开始，即只画逻辑关系，不计算概率，待数据积累充分后再进行“定量FTA”。

故障树分析在审核中的应用步骤：

定义顶事件： 如“某项目结算审核失败（退回重做）”。
构建逻辑树： 分析导致顶事件的直接原因。例如，可能是“资料不齐全”或“计算逻辑错误”。
使用逻辑门：
- 或门： 任一子事件发生，顶事件就发生。例如，“资料不齐全”或“计算错误”任一发生，都可能导致审核失败。
- 与门： 所有子事件同时发生，顶事件才发生。例如，“审核员判断失误”且“复核机制失效”同时发生，才导致重大漏项。
最小割集分析： 找出导致顶事件发生的最少基本事件组合，优先解决这些关键路径。

工具	适用场景	输出形式	在审核中的典型应用
鱼骨图	定性分析，头脑风暴阶段	图形化因果清单	分析“签证审核慢”的潜在原因
故障树（FTA）	定性+定量，逻辑推演阶段	树状逻辑图	分析“结算审减率异常高”的根本原因链

    专家建议： 在实际项目中，建议将PDCA作为流程改进的“大框架”，将5W1H作为日常排查的“快速工具”，将鱼骨图和FTA作为深度分析的“专项武器”。四者结合使用，可以覆盖从日常问题到系统性故障的全场景排查需求。