构建 CTQ 树：把含糊的“做得更好”变成可以衡量的东西
客户很少用数字告诉你他们想要什么。他们会说“我希望订单准时送达”或“报告应该易于阅读”。关键质量特性（CTQ）树正是精益六西格玛中那件工具，它把这些宽泛的需求翻译成具体、可衡量的要求，让你据此设计、据此检验。它出现在 DMAIC 定义阶段的早期，紧接在收集客户之声之后，能防止团队去优化客户根本不在乎的东西。
当需求与供应动荡不定时，这件工具尤其物有所值——正如许多运营部门在过去两年的扰动中所体会到的。当你无法面面俱到时，CTQ 树会在你花钱去追求之前，先逼出一个清晰的答案：“准时究竟是什么意思，我们又怎么知道做到了？”
树的三个层级
CTQ 树自左向右展开，每一步都更加具体。可以把它看作一次从语言到数字的受控下行，每一层都必须由上一层来支撑。如果某个 CTQ 无法经由某个驱动因素干净地追溯回最初的需求，它就不该出现在这棵树上：
需求。 客户用自己的话表达的宽泛、往往带情绪的诉求。“我想要可靠的配送。”通常一棵树只有一个需求。
驱动因素。 在客户心目中使该需求成真的少数几个要素。对于可靠配送，可能是准时性、订单准确性以及到货时的状态。
CTQ（要求）。 针对每个驱动因素，给出具体、可衡量的特性，并附上目标值与容差。“98% 的情况下在承诺的时间窗内送达”，或“破损商品少于 0.5%”。
如何构建一棵 CTQ 树
确定客户与需求。 明确你服务的对象是谁——内部客户也算在内。用对方的语言、而非你的语言记录需求。
把客户之声翻译成驱动因素。 问一句“要让他觉得这个需求被满足，必须做到哪些事？”对原始反馈做亲和分组，直到归纳出一小组驱动因素，通常是两到五个。
把每个驱动因素转化为可衡量的 CTQ。 写明指标、目标值和可接受范围。如果无法附上一个数字，就继续追问“我们具体要衡量什么？”
目标值要来自数据和客户，而非凭感觉。 结合客户表达的期望和你的基线表现，选定一个现实且站得住脚的目标。
向客户验证这棵树。 把它再讲回给客户听。如果对方在你的 CTQ 里认不出自己的需求，说明翻译在某处出了岔子——现在就改，别等项目结束后才发现。
团队容易出错的地方
最常见的失误，是直接跳到那些容易采集的指标，而非真正反映需求的指标——衡量系统已经在记录的东西，而不是客户的感受。另一个失误是任由单个驱动因素膨胀成十五条 CTQ；若样样都关键，便等于没有关键，所以要抓住为数不多的要害。第三个失误是写出没有容差的 CTQ，使其无法干脆地判定通过或失败。第四个则更为隐蔽：把内部目标误当成客户要求——你运营团队自定的服务水平协议，未必就是客户真正会接受的标准，而究竟是哪一种，只有客户能告诉你。
一棵构建得当的 CTQ 树会成为项目其余部分的骨干：它告诉你在测量阶段该测什么、在分析阶段到哪里去找根本原因，以及到了控制阶段“好”应当是什么样子。它同时还是一件沟通工具——用一页纸向发起人清楚地说明你为何恰恰衡量这些指标。把它做对，整个改进工作就会对准客户真正会注意到的东西，而不是某个在仪表盘上看着光鲜、却丝毫没有改变客户在乎之事的数字。
如果你们的改进工作总是因为没人能就“更好”达成一致而停滞不前，XNM 的战略咨询可以帮助你把客户需求翻译成可衡量的目标，并让努力始终对准要害。