mcpField
P
pdca-improvement

pdca-improvement

github.com/rbraga01测试与质量4239 次安装1 周前更新
代码仓库

关于 pdca-improvement

面向质量改进的技能,引导团队通过计划、执行、检查、处理开展主动改进和受控试点。重点包括可衡量的基线、明确的试点范围、基于数据的评审,以及变更标准化前的文档记录。

主要功能

  1. 01计划—执行—检查—处理流程
  2. 02根因与基线分析
  3. 03试点范围和成功标准
  4. 04基于数据的评审关卡
  5. 05标准化与文档记录

适用场景

  1. 01试点流程变更
  2. 02实现可衡量的质量目标
  3. 03根据经验教训开展改进

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/rbraga01/quality-engineering-skills --skill pdca-improvement

安装后在 Claude Code 中输入/pdca-improvement确认已加载。

附带文件references/pdca-examples.md

详细介绍

PDCA 改进循环

适用时机

在以下情况下使用 PDCA:

  • 持续改进计划(而非对问题作出反应——此时应使用 8D)
  • 实施结果不确定的流程优化
  • 在全面部署前试点变更
  • 根据经验教训或审核发现进行结构化改进
  • 需要采用新方法才能实现质量目标

**与 8D 的主要区别:**PDCA 用于主动改进或需要长期推进的改进;8D 用于应对特定缺陷或故障。两者都会使用根因分析,但 PDCA 的范围更广,并且在全面部署前包含试点步骤。

将 PDCA 用于纠正措施时(例如,响应审核发现或重复发生的不符合项):还必须发起 纠正措施请求(CAR),根据 ISO 9001 §10.2 记录根因、措施和 VOE。PDCA 是改进方法;CAR 是治理记录。

前提条件

  • 已定义改进目标(含目标指标)
  • 已获取基线数据(当前绩效)
  • 已指定负责人并分配资源

工作流

PLAN — 分析并定义方法
  1. 定义当前情况

    • 问题或改进机会是什么?
    • 当前测得的绩效如何?(基线)
    • 目标是什么?(SMART:具体、可衡量、可实现、相关、有时限)
  2. 分析根因

    • 使用 鱼骨图 和 5 Why 了解当前绩效低于目标的原因
    • 使用数据:帕累托图、运行图、过程能力研究
  3. 制定改进计划

    • 哪些具体措施可以缩小差距?
    • 每项措施由谁负责?
    • 时间安排是什么?
    • 需要哪些资源?
    • 变更会引入哪些风险?审查适用的 PFMEA——此变更是否会增加或消除失效模式?是否会影响任何现有的预防或探测控制?
  4. 定义试点范围

    • 将在哪个流程、生产线或区域试点变更?
    • 需要多大的产量或多长的时间才能验证有效性?开始试点前应先定义这一点——不要等看到结果后再决定。
    • 将测量什么,如何测量?

**试点产量指南:**至少,试点应产生足够的输出,以便在统计上区分信号与噪声。常见参考值:

  • 过程能力变化:在新条件下至少连续进行 30 个周期或处理 30 件产品
  • 缺陷率降低:产量至少应使按旧缺陷率预计发生 5 次事件(例如,若基线缺陷率 = 2%,则试点至少为 250 件)
  • 随时间变化的改进:至少 4 周的持续绩效数据

**计划关口:**是否已了解根因?是否已明确试点范围及具体的最低产量/时长?能否根据具体目标衡量成功与否?


DO — 实施(试点)
  1. 仅在试点范围内实施计划的变更
  2. 培训受影响的人员
  3. 在试点期间执行并收集数据
  4. 记录实际情况与计划情况的差异(偏差也是数据)

**此阶段不要大范围部署。**试点是为了学习,而不是承诺全面实施。


CHECK — 验证结果

将试点结果与计划目标进行比较:

指标基线目标试点结果是否缩小差距?
[KPI 1]
[KPI 2]

请思考:

  • 变更是否带来了预期的改进?
  • 是否出现了意外的负面影响?
  • 改进是否可持续(随时间保持稳定),还是仅为一次性效果?
  • 试点是否在具有代表性的条件下开展(与生产使用相同的操作人员、材料和环境)?

检查关口:

  • 若达到目标 → 进入 Act(标准化)
  • 若部分达到目标 → 修订 Plan,再进行一轮 Do-Check 循环
  • 若未达到目标 → 返回 Plan,重新分析根因

ACT — 标准化或修订

如果试点成功:

  1. 更新流程文件:作业指导书、控制计划、PFMEA——每份文件都必须修订,以反映新流程
  2. 如果 PFMEA 包含与改进后流程步骤相关的失效模式,请更新受影响的 S/O/D 评级和 AP
  3. 部署到所有适用区域(横向部署)——列出各个区域,并确认部署已完成
  4. 培训所有受影响人员——必须保留培训记录
  5. 建立持续监控机制,确认改进效果得以维持
  6. 分享经验教训——录入经验教训登记表

如果试点失败或结果不明确:

  1. 记录学到的经验
  2. 修订 Plan(提出新的根本原因假设或采用新方法)
  3. 重复此循环

不要将未经验证的变更标准化。 将失败的试点标准化会永久固化问题。


PDCA 必需文档(ISO 9001 §10.3)

为确保循环可供审核,结束时必须有以下记录:

  • 基线测量及其数据来源和日期
  • 根本原因分析(鱼骨图或 5-Why 分析结果)
  • 试点计划,明确最低数量/时长及成功标准
  • 试点执行数据(前后对比)
  • 检查关口决策(继续/修订/重新开始)及支持数据
  • 更新后的 PFMEA、控制计划和作业指导书(如适用),包含新的修订编号和批准日期
  • 所有受影响人员的培训记录
  • 横向部署日志(评估的区域、采取的措施)
  • 经验教训登记表条目

关口摘要

关口核心问题通过标准
Plan是否已了解根本原因并确定试点范围?已确认根本原因、目标可测量、已定义试点数量/时长
Do是否按计划开展试点?已实施措施,并按计划收集数据
Check变更是否达到目标?达到或超过目标指标;达到最低试点数量
Act文件是否已更新,部署是否已完成?已修订 PFMEA/CP/WI、已完成培训、已记录横向部署

常见错误

  • 跳过 Plan——尚未了解根本原因就直接进入 Do
  • 未定义试点数量——试点结束后才决定多少数据才算“足够”;开始前就应设定最低要求
  • 跳过 Check——未经数据验证就将试点推广到更大范围
  • 在 Check 之前将 Act 视为永久措施——试点结果尚未确认就进行标准化
  • 只进行一个循环——PDCA 是一个循环;如果第一个循环未能解决问题,就再进行一轮
  • 用 PDCA 处理紧急缺陷——对于客户投诉或安全问题,请改用 8D
  • 未更新 PFMEA——流程变更后未更新 PFMEA,会导致风险登记表不准确

输出格式

每次使用开始时,询问用户:

“您希望以哪种格式接收输出? A — 结构化 Markdown(包含格式化表格和章节,可直接复制) B — 纯表格(简化结构,适用于 Excel 或 Word) C — 叙述式报告(适用于正式文档或电子邮件的连贯文本)

默认:A。”

根据所选格式调整所有输出章节。如果平台或会话上下文已指定格式偏好,则跳过此问题。

更新日志

版本日期作者变更
1.02026-06-01@RBraga01首次发布
1.12026-06-04@migmcc优化 PDCA 循环工作流并集成 D6 验证

评论

支持 Markdown