3. 定义阶段工具精讲

定义阶段的核心任务，是把“客户觉得不满意”这种模糊感受，变成“项目要改进哪个可测量的指标”这种清晰命题。VOC、Kano、CTQ树、范围界定与利益相关者分析，正是完成这一转化的五件套工具。它们不是并列的五个步骤，而是一条从声音到指标的收敛链：VOC提供原始素材，Kano判断需求属性，CTQ树把需求翻译成可测量特性，范围界定锁定改进边界，利益相关者分析保证项目落地有人支持。

一、VOC收集：先拿到“客户原话”，再谈转化

VOC（Voice of Customer）是客户对产品、服务或流程的真实表达，包括抱怨、期望、称赞和隐含要求。收集VOC时最忌讳只拿二手结论，比如“客户说响应慢”，而应尽量保留原始语境：“我上周三提交的报修单，到今天还没人联系我。”原话里包含时间、对象、事件和情绪，这些信息在后续转化中非常关键。

常用收集渠道包括：客户投诉记录、客服通话录音、满意度调查开放题、退货原因、社交媒体评论、销售与售后访谈、现场观察以及客户拜访。实操中建议按“来源—原话—场景—频率—影响”五列整理VOC清单。例如某设备制造企业收集到一条VOC：“机器报警后，操作工要翻三页手册才知道怎么处理。”来源是售后访谈，场景是产线换型，频率为每月约12次，影响是平均停机18分钟。这条VOC已经隐含了“报警信息可读性”和“故障处理指引”两个改进方向。

收集时要注意样本代表性：只访谈大客户会忽略中小客户；只统计投诉会漏掉沉默流失者。建议至少覆盖三类对象：直接使用产品的终端客户、决定采购的决策客户、影响使用的间接客户。每类客户的VOC要分开记录，避免混在一起后无法判断优先级。

二、Kano模型：判断需求是“必须”还是“惊喜”

Kano模型把客户需求分为五类：基本型需求、期望型需求、兴奋型需求、无差异需求和反向需求。基本型需求是“没有会强烈不满，有了也不会加分”，比如手机能打电话；期望型需求是“越好越满意，越差越不满”，比如电池续航；兴奋型需求是“没有不抱怨，有了会惊喜”，比如早期手机的指纹解锁。定义阶段用Kano，是为了避免把资源投在客户根本不在意的功能上。

实操中可用Kano问卷：对同一特性问正反两题。正向题：“如果设备能自动推送故障处理步骤，您感觉如何？”反向题：“如果设备不能自动推送故障处理步骤，您感觉如何？”选项为“喜欢、理应如此、无所谓、能忍受、不喜欢”。根据正反回答组合查Kano评价表，得出该特性属于哪一类。例如正向选“喜欢”、反向选“不喜欢”，通常归为期望型；正向选“喜欢”、反向选“无所谓”，则偏向兴奋型。

Kano结果不是永久标签。三年前属于兴奋型的“扫码支付”，今天已变成基本型。因此定义阶段要结合当前市场阶段和客户群体判断，不能照搬历史结论。

三、CTQ树展开：把需求翻译成可测量特性

CTQ（Critical to Quality）是关键质量特性，即对客户满意度有直接影响、且可以被测量的产品或流程参数。CTQ树的作用，是把一句模糊的VOC逐层拆解为可采集数据的指标。典型展开路径是：VOC → 需求 → 质量驱动 → CTQ → 测量方式。

以“报修后没人联系我”为例。VOC是“报修后没人联系我”；需求是“报修后能及时获得响应”；质量驱动是“响应速度”和“信息透明”；CTQ可定义为“从报修提交到工程师首次电话联系的时间间隔”，单位分钟；测量方式为客服系统时间戳差值。再往下还可拆出“首次联系及时率”“一次解决率”等CTQ。每个CTQ必须满足三个条件：客户关心、可测量、项目可控。如果某个指标客户不关心，或者现有系统根本取不到数，就不适合作为定义阶段的CTQ。

CTQ树展开时建议控制层级在四层以内，末端指标不超过8个。太多会导致项目失焦，太少则可能遗漏关键特性。每个末端CTQ要标注数据来源、采集频率和当前基线值。没有基线值，后续改善就无法判断是否真的有效。

四、项目范围界定：明确“改什么”和“不改什么”

范围界定是定义阶段最容易失控的环节。客户一句“响应太慢”，可能牵扯到客服排班、工单系统、备件库存、工程师技能、甚至组织架构。如果不加约束，项目会越做越大，最后无法收口。范围界定要用三句话写清楚：起点是什么、终点是什么、边界外是什么。

以报修响应项目为例。起点：客户通过客服热线或在线系统提交报修工单。终点：工程师完成首次电话联系并确认故障信息。边界外：备件采购、现场维修、费用结算、客户回访。这样定义后，项目组就知道数据采集只覆盖“提交到首次联系”这一段，改善措施也集中在这一段。边界外的问题可以记录，但不纳入本项目。

范围界定还要配合SIPOC图使用：供应商、输入、过程、输出、客户。SIPOC能帮助团队看清项目在更大流程中的位置，避免把上游问题当成下游问题解决。例如“首次联系慢”可能不是客服不努力，而是工单系统没有自动派单规则。SIPOC一画，问题归属就清楚了。

五、利益相关者分析：让项目有人推、有人接

定义阶段不仅要定义问题，还要定义“谁会影响项目、谁会被项目影响”。利益相关者分析常用“权力—利益”矩阵：高权力高利益者要重点管理，高权力低利益者要争取支持，低权力高利益者要随时告知，低权力低利益者要最小化打扰。

以报修响应项目为例。客服总监权力高、利益高，是核心决策者，必须每周同步进展；IT经理权力高、利益中，负责工单系统改造，需要早期介入；一线客服权力低、利益高，是流程执行者，要邀请参与方案设计；财务部权力低、利益低，只需在费用审批时知会。分析完成后，要针对每类人制定沟通策略：谁需要签字、谁需要培训、谁需要提前吹风、谁只需要邮件抄送。

利益相关者分析不是一次性的。项目进入测量阶段后，可能发现IT部门的态度从支持变为观望，这时要重新评估并调整沟通方式。定义阶段至少完成一轮完整分析，并明确第一周内要沟通的关键人物。

六、可直接使用的定义阶段检查表

定义阶段结束时，项目组应能回答四个问题：客户最在意什么？我们改哪个指标？项目边界在哪里？谁支持谁反对？如果这四个问题还有模糊，说明定义阶段尚未完成，不应匆忙进入测量阶段。定义阶段的输出质量，直接决定后续DMAIC是有的放矢还是盲目试错。