1. 一个具体问题
一个订单团队购买自动化工具后，平均处理时间下降，但差错没有减少。后来才发现他们最初想解决的是返工率，却把处理速度当作成功证据。没有清楚的问题定义和可靠基线，改进项目容易在中途悄悄换成更容易展示的成果。
2. 一句话解释
DMAIC 依次通过定义、测量、分析、改进、控制五个阶段，系统改善已有流程中的质量或表现差距。
3. 出处与原意
DMAIC 广泛用于六西格玛和持续改进实践，ASQ 将其解释为改善现有过程的结构化方法。它不是必须依次完成五份厚报告的行政程序，也不意味着每个问题都需要复杂统计。新产品或根本重新设计可能需要不同的方法，不能把所有工作都强行套进既有流程优化。
4. 原理与机制
定义阶段说明客户需要、问题范围与成功标准；测量阶段检查数据口径和测量可靠性；分析阶段验证影响机制；改进阶段选择并试验对策；控制阶段建立标准、监控和异常响应。阶段顺序防止跳到解决方案，但新证据可能要求回到前一步。控制的目标是让改善持续，而不是对成员增加无差别监督。
移交前还要确认谁有权响应异常，以及需要哪些资源。如果指标变差后唯一动作是发邮件提醒，却无人能暂停流程或修改规则，控制计划就难以发挥作用。监控频率也应匹配变化速度，避免等到月末才发现每天发生的问题。
5. 一个完整案例
以下是假设案例。一个服务中心每月办理一千份申请，其中一百二十份因资料缺失退回，返工率百分之十二。团队定义目标为三个月内降到百分之六以下，同时不增加错误通过。测量发现不同人员对“退回”统计不一，先统一口径。分析显示高频问题是一个材料名称含糊，用户误传相似文件。团队改写说明并加入样例，在一个渠道试行五百份，二十五份退回，比例百分之五，抽检质量保持原水平。扩大前检查是否存在用户结构差异；实施后按周观察退回率和错误通过率，指定连续异常时由谁调查。项目交接的不只是新页面，还包括维护样例和响应异常的责任。
6. 适用条件与反例
适合已有重复流程、差距明显且需要跨阶段验证的问题。小问题可以轻量处理，不必等待正式立项。反例是已确认某字段映射错误，只需修复并验证，却花两个月走完整培训与审批；方法应服务于问题规模，不能让改善成本超过问题本身。
7. 今天可以尝试的行动
为一项改进各写一句话：解决什么、如何测量、怀疑什么、准备试什么、如何维持。检查哪一句缺少证据，就从那一步开始补足。若尚未验证原因，暂缓大规模实施，把预算先用于一个能够区分不同解释的小试验。