测量阶段不陷入数据泥潭：只收集问题真正需要的
测量是 DMAIC 的第二个阶段，介于定义与分析之间。它的职责狭窄而重要：建立一条可靠的基线，反映流程今天的实际表现，这样日后的任何改进才能被证明，而不只是被声称。团队在这里最常见的自毁方式，就是把数据的数量误当成理解的质量。他们把能找到的每一份系统导出都拉出来，最后被一堆电子表格挡住了看清问题的视线。
2021 年初让这种诱惑更甚。仪表板越来越多，远程团队只能依靠在家里能访问到的任何数据，而一份内容繁杂的报表很容易被误认为一次清晰的测量。
一个好的测量阶段是什么样的
一个有纪律的测量阶段从定义阶段写下的问题陈述出发，提出一个收紧的问题：我们究竟需要观察什么，才能知道这个流程是否健康？
只测量与问题相关的少数指标。 选取能反映你所定义的缺陷或延误的输出指标，再加上少数几个可能驱动它们的流程输入。不要仅仅因为系统能报告某项指标就把它加进来。
对每个指标下操作性定义。 写清楚究竟什么算作一个缺陷、计时从何时开始与停止、所计的单位是什么，使两个人测量同一件事能得到相同的数字。
检验测量系统是否可信。 在相信数据之前，先确认它是可重复且可再现的。如果两位检验员对同一件物品判断不一致，你的数据就是披着信号外衣的噪声。
在一个有代表性的时间窗内采集基线。 采集足够的、覆盖正常波动的数据，诚实地描述当前表现，而不是精挑细选出来的一个好周。
一个好的测量阶段，产出其实很小：一条可信的基线、每个指标清晰的操作性定义，以及对流程波动幅度的把握。带着这些进入分析阶段，已经绰绰有余。
一个糟糕的测量阶段是什么样的
因为字段唾手可得就导出几十个，然后再想着以后决定哪些重要。
没有操作性定义，于是同一个事件因记录者不同而被计成不同的数。
跳过对测量系统的任何检验，然后在没人核实过的数据上得出结论。
抽取一段方便的时间，而它并不代表流程平时的表现。
在基线尚未达成一致之前就滑向猜测根本原因，而那属于分析阶段，不属于这里。
糟糕的版本感觉很高产，因为它产出了大量材料。但一份没人信任的厚厚数据包，比一份人人都信任的薄数据更糟，因为它促使团队去争论数字，而不是去修复流程。
远离泥潭
在拉出任何一份导出之前，先决定你要测量什么，并把每个指标都追溯回问题陈述。在操作性定义和一次快速的测量系统检验上花上实打实的时间；正是这一点点投入，区分了一条你能站得住脚的基线和一条经不起第一个问题的基线。把收集到的集合刻意保持精简。如果某个数字不会改变分析阶段的任何决定，那你现在多半还用不上它。
如果你的改进工作总是卡在一片没人信任的数据泥潭里，XNM 的战略咨询 可以帮你只测量那少数真正左右结果的事情。