从一句含糊的抱怨到可衡量的质量：CTQ 树的实战
一个区域服务中心立项时定了一个熟悉的目标：「把面向公众的受理流程做得更好。」更好在哪里？改进团队手里有问卷意见、有零散的轶事，还有一位坚信总有什么需要修的发起人——但没有任何可以衡量或瞄准的东西。这恰恰是关键质量特性（CTQ）树要弥合的鸿沟。下文中的名称已匿名化，但方法是标准的精益六西格玛。
CTQ 树的作用
CTQ 树把宽泛而模糊的客户需求，翻译成你的流程必须交付的、具体且可衡量的特性。它从左到右分三层运作。你从客户之声出发——人们实际说出口的话；再进到客户背后的需求——这条意见背后的驱动力；然后把这个需求拆解为若干 CTQ：带有目标值和容差的可衡量要求。其中的纪律，就是逼自己不到能用数字表达的地步绝不停下。
这个服务中心的团队是这样梳理其中一条分支的：
客户之声。 「我等了好久，也没人告诉我到底怎么回事。」原始、带情绪，尚不可衡量。
需求。 这一句话里藏着两个不同的需求：及时的服务，以及关于进度的清晰沟通。把它们拆开很重要——它们的衡量方式不同。
及时性 CTQ。 到达后 10 分钟内给出首次响应；标准请求的总处理时间不超过 30 分钟。
沟通 CTQ。 每一位等候者至少每 15 分钟收到一次进度更新；预计等待时间在到达时即公示。
为什么拆分很重要
团队最初的本能，是把整件事当成速度问题，往队列里多堆人手。CTQ 树却揭示出：一半的不满源于沉默，而非缓慢——这是一条沟通 CTQ，修复成本远低于增加人头。若不把需求拆解开，他们就会把预算花在错误的 CTQ 上。一棵好的树常常揭示出：一句抱怨里其实含有数条需要不同解决方案的要求。
构建 CTQ 树的实用规则
从真实的客户之声数据出发，而不是凭你自己对人们想要什么的假设。
不断追问「要让客户觉得这个需求被满足，必须做到什么？」，直到答案可以衡量为止。
每一个末端 CTQ 都需要一个度量、一个目标值和一个容差——「快」和「友好」在没有数字之前都还不是 CTQ。
当一个需求里藏着不止一条要求时，就把它拆成不同的分支，就像这里的及时性与沟通。
在此基础上着手做改进之前，先用几位真实客户验证这棵树。
及早构建的 CTQ 树，为 DMAIC 项目的其余部分锚定了方向：这些 CTQ 既是你在「测量」阶段所衡量的对象，也是你在「控制」阶段所要证明已获改善的东西。在一个服务期望快速变化、许多团队都承受压力的时期，一棵树是一种低成本的方式，能确保你改进的是客户真正在意的东西，而不是最容易统计的东西。
如果你强烈感到某些地方需要改进，却没有清晰、可衡量的目标，XNM 的战略咨询 可以帮助你把客户需求转化为可以付诸行动的要求。