MEASURE 测量阶段

六西格玛数据收集:数据从哪来,口径谁说了算

一个改善项目最先烧掉的通常不是分析时间,是两三周的凑数据时间。而凑完之后最容易翻车的,是各部门对同一个指标的算法根本不一样。这一章讲清楚 Measure 阶段该确认哪些事,以及五个最常吵架的口径分别该怎么定。

阅读约 12 分钟 不依赖特定软件 含可打印检查清单
先说结论

Measure 阶段难的不是测量,是对齐

六西格玛培训里,Measure 阶段讲的是测量系统分析、过程能力基线这些方法。但在真实项目里,这一阶段的时间去哪了?

大部分花在两件事上:把数据从几个互不相通的系统里凑出来,以及说服相关部门接受同一套算法。前者是工程问题,后者是组织问题,两个都不在六西格玛教材的重点章节里,但两个都能拖垮项目进度。

这一章不讲统计方法,只讲这两件事该怎么做。六西格玛数据分析总览里提到的各阶段分工,从这里开始落地。

数据盘点

项目启动前,先确认这六类数据在哪

不同行业的系统名称不同,但缺口的位置高度一致。

数据类型常见来源最常见的问题
过程参数 生产执行系统、设备控制系统、班组记录表 关键参数只存在设备本地且无导出接口;或只有整点抽样,精度不够
质量检测结果 实验室信息系统、质检系统、Excel 台账 复检记录与首检混在一起,不知道该取哪一次
物料与批次 ERP、进货检验记录 批次号在不同系统里编码规则不同,关联不上
人员与班次 排班表、考勤系统 只有排班计划没有实际出勤,换班没记录
设备状态 维修保养记录、点检表 多为纸质或自由文本,无法直接参与计算
成本与损失 ERP、财务核算表 口径按会计期间切,与生产批次对不上

盘点的目的不是集齐所有数据,而是提前知道哪一类是缺口。缺口在第一周暴露,项目还能调整范围;缺口在第六周暴露,通常只能重来。

口径对齐

五个最常吵架的口径

这几条如果不在项目启动会上定下来,后面每次汇报都会重新吵一遍。

争议一

不良率的分母是投入数还是产出数

生产部倾向产出数分母小,不良率看起来低;而且产出数是他们的考核口径,现成就有。
质量部倾向投入数把中途报废的也算进去,反映真实的物料损失。
建议:两个都算,并列呈现,分别命名为「产出不良率」和「投入不良率」。改善项目关注的是趋势变化而不是绝对值,两个指标同向变动才说明改善真实发生。只报一个,后面一定会被质疑选了对自己有利的那个。
争议二

返修品算不算不良

它确实没有一次做对,隐含了额外工时和物料成本。
不算最终交付是合格的,客户端不良率里不体现。
建议:分开统计,不要合并成一个数。设「一次合格率」与「最终合格率」两个指标:前者含返修,反映过程能力;后者不含,反映交付质量。六西格玛改善的目标是前者,因为返修消耗的成本是实实在在的浪费。
争议三

时间窗口按什么切

按生产日期跟排产和班次对得上,便于追溯到人和设备。
按检验日期跟质检台账一致,但检验可能滞后几天甚至跨月。
建议:分析用生产日期,因为要把结果归因到当时的工艺条件。但要在流程里保留检验日期字段,用于核对为什么某个月的数据量异常——通常是检验积压或提前突击。跨月滞后超过一定天数的记录应单独标记,不要静默混入。
争议四

复检数据取哪一次

取最后一次那是放行依据,代表最终判定结果。
取第一次那才反映过程的真实输出,后续复检可能换了样品或换了人。
建议:分析过程能力时取第一次,这是过程真实产出的分布。取最后一次会系统性地低估变异,把 Cpk 算高,改善效果看起来比实际好。同时保留复检次数作为一个单独字段——复检频繁本身就是值得分析的信号。
争议五

批次的粒度定在哪一级

粗粒度按工单或投料批,数据量小、关联简单,但一个批次内可能跨了几个班次和几台设备。
细粒度按设备加班次拆,能定位到具体条件,但很多系统记不到这个层级。
建议:取你能稳定拿到的最细粒度,并把这个粒度写进项目章程。中途改粒度是最常见的返工原因,因为前面所有的汇总口径都要重算。如果只能拿到粗粒度,就在结论里明确写出这个限制,不要假装分析结果能定位到具体设备。
怎么落地

把口径写进流程,而不是写进会议纪要

口径定完之后,真正的问题是三个月后还能不能还原它。

01

让每个数据源各占一个入口节点

数据库取一条、Excel 台账取一条、导出文件取一条,各自独立。不要先在 Excel 里手工拼好再导入——那一步没有记录,也是最容易出错的一步。

对应处理:数据库查询 · 表格文件读取 · 文本文件读取 · 文件夹批量读取
02

关联键先清洗再关联

批次号在不同系统里常有前后空格、大小写差异、补零规则不同。关联之前先统一格式,并且把关联不上的记录单独输出一份,而不是让它们静默消失。关联失败的比例本身就是数据质量的指标。

对应处理:字符串处理 · 关联(保留未匹配行) · 行过滤 · 缺失值处理
03

口径定义写成规则节点,不写成公式串

「投入数怎么算」「哪些状态算不良」「哪些记录要排除」,每一条对应一个可读的规则。规则节点的好处是别人打开就能看到判定条件,不需要去解析一长串嵌套公式。

对应处理:规则引擎 · 公式节点 · 列重命名(用业务语言命名,不用系统字段名)
04

在节点注释里写下为什么

这一步最容易被省掉,也是三个月后价值最高的一步。不是写「过滤异常值」,而是写「排除 2026-03-15 停机调试期间的记录,依据是设备维修单 M2603-118」。工具能记录你做了什么,记录不了你为什么这么做。

对应处理:节点注释 · 流程分区注释框
05

把这段处理封装成组件

下个项目、下条产线,数据准备的逻辑八成是一样的。封装之后口径由一处维护,不会出现三个人三套算法的情况。这也是让第二个项目比第一个快的主要原因。

对应处理:组件封装 · 组件参数化
可行性判断

数据够不够做分析,用三个问题判断

这三条任何一条不过关,后面的统计分析都会得出误导性的结论。

  • 采样频率对得上吗。工艺参数每秒一条、质量检验每批一次,中间的对应关系怎么建立?常见做法是把参数按批次时间窗口聚合成均值、极差、最大最小值。但要注意:聚合本身会丢掉波动信息,而波动往往才是问题所在。如果怀疑问题出在过程波动上,聚合方式需要额外设计。
  • 关键参数有没有缺失。工程师凭经验认为最相关的那几个参数,如果恰好没有采集,分析只能在剩下的参数里找相关性,很可能得出一个看起来显著但实际是代理变量的结论。这种情况下诚实的做法是先补采集,而不是硬做。
  • 历史长度够不够覆盖变异。如果原料批次三个月换一次、季节温湿度有明显影响,那么只有一个月的数据就无法区分「工艺参数的影响」和「换了批原料的影响」。判断标准是:数据跨度要覆盖你已知的主要变异来源至少两个循环。
  • 有没有已知的中断和异常期。设备大修、工艺变更、换供应商、疫情停产,这些时间段的数据不能和常态期混在一起算。项目启动时就该向生产和设备部门要一份这样的时间清单。
  • 数据能不能持续拿到。Control 阶段要把监控固化成每天自动跑。如果这次的数据是靠某位同事手工导出的,那么改善成果就无法持续。这一条应该在 Measure 阶段就确认,不要等到最后。
常见陷阱

三个会让整个项目白做的坑

这三条都发生过,而且发现得都很晚。

用汇总数据反推明细结论

拿到的是按天汇总的合格率,却想分析设备之间的差异。汇总之后个体信息已经丢失,再怎么分析也还原不回来。需要明细就在取数阶段要明细。

默默丢掉关联不上的记录

两表关联后行数少了三成,没人注意。如果丢掉的恰好是某条产线或某个时间段,结论就系统性偏了。关联未匹配的记录必须单独输出并说明原因。

把检验合格的记录当成全部产出

质检系统里往往只有送检的样品,没送检的、现场直接报废的不在里面。用这份数据算出来的不良率会系统性偏低,而且偏多少无法估计。

先把口径清单发出去

这一章最值钱的动作不是搭流程,是把上面那五个口径争议整理成一页纸,在项目启动会上让相关部门当场确认。这件事花半天,能省掉后面几周的返工。

iModel 专属客服
在线留言或电话联系
在线留言

留下您的问题和联系方式,我们会在一个工作日内回复。

手机与邮箱至少填一项

4008568196 拨打此号码联系我们

微信扫码咨询

iModel 微信咨询二维码

使用微信扫描上方二维码