利益相关者创始人（影响力高·立场坚定）：技术出身，对AI理解远超团队。运营VP（影响力中·立场观望）：多次失败后持谨慎态度，需要可见成果。产品经理（影响力低·立场积极）：希望借助AI提升产品力，是内部推动力量。
触发事件新任技术VP（来自某互联网大厂）提交了完整的AI转型方案，预算3837万元，预计10个月实现投资回报。董事会在评估后批准了该项目。
风险矩阵技术风险（可能性高·影响中）：模型效果不达预期、系统集成困难、数据质量不达标。组织风险（可能性高·影响高）：关键利益相关者抵制、变革中途失去动力、核心团队流失。进度风险（可能性中·影响中）：项目延期、速赢效果不显著、反复返工。
行业背景公共服务领域正经历从经验驱动到数据驱动的范式转移。约76%的头部企业已完成第一阶段的AI部署，行业平均效率提升约8%。
blue痛点二：信任透支。过去4次数字化项目均以失败告终，员工对新概念的接受度降至冰点。「数字化」这个词在内部已经成为一个负面标签。新项目需要花费额外精力重建信任。
gold痛点四：范围失控。管理层期望一次性建成「企业级AI平台」解决所有问题，而非小步快跑分阶段实施。这种大而全的思路增加了项目失败的风险和实施周期。
顾问诊断诊断发现三个核心不匹配：目标与资源不匹配（预算3837万元但期望覆盖全部业务线）、期望与现状不匹配（期待3个月见效但数据准备需要10个月）、问题与方法不匹配（用技术方案解决管理问题）。
purple痛点三：数据基础薄弱。核心业务数据分散在6套系统中，数据口径不统一，关键参数缺失率高达12%。根因是操作流程不规范，而非技术问题。
※ 案例信息已脱敏处理。仅供教学参考。以下展示本案例将应用的层面。Step2展开。
掌握在公共服务场景中运用结构化方法论诊断企业AI准备度的能力，学会区分表象问题与根因问题。
核心挑战：本案例最大的难点在于客户对AI的认知偏差与组织变革疲劳的双重叠加——这不是技术问题，而是管理问题。
理论概述：企业基本面、业务运营、IT成熟度、组织文化、AI准备度——五维评估。
理论概述：连续追问为什么，但不是机械地问五次，而是在不同深度层面对症下药。
理论概述：从业务（Business）、数据（Data）、组织（Organization）、技术（Technology）四个维度系统性评估企业AI准备度。
理论概述：组织拥有对变革的内在防御机制。识别并化解这些防御，比推动变革方案更重要。
理论概述：通过结构化的工作坊形式，将顾问的方法论转移给客户内部团队，实现能力固化。
理论概述：高质量的访谈通过精心设计的提问顺序，引导客户自己发现问题的真实面貌。
区分客户说的问题和真实的问题——症状往往不是根因
| 层 | 参考问题 | 意图 | 追问 |
|---|---|---|---|
| S1 | 如果这个项目不做，3个月后会发生什么？ | 建立紧迫感 | 帮助客户认识到不做的风险 |
| T2 | 您认为最重要的成功标准是什么？ | 了解客户价值观和优先级 | 注意客户是否过度关注技术指标 |
| A3 | 您对这个项目的最高预算和资源投入是什么？ | 了解资源约束和真实投入意愿 | 追问"如果预算不够，您愿意调整范围吗？" |
| R4 | 根据行业数据，类似规模企业通常7个月实现8%提升，您觉得这个范围合理吗？ | 管理期望，建立参考基准 | 追问"如果实际效果低于范围，您的底线是什么？" |
| S5 | 您希望用什么机制来定期评估项目进展？ | 建立持续沟通机制 | 建议每月正式review+每周非正式同步 |
| T6 | 您对这个项目的成功是如何定义的？ | 了解客户的顶层期望 | 注意是否存在多个不同的成功标准 |
| A7 | 您过去在效率提升方面做过哪些尝试？效果如何？ | 了解历史经验和组织惯性 | 追问"如果效果不理想，主要原因是什么？" |
| R8 | 你觉得团队对新技术的接受度如何？有没有预见到什么阻力？ | 评估组织变革准备度 | 注意客户是否回避或粉饰这个问题 |
• 客户问"你做过我们行业吗？"——回应"我们团队做过多个类似场景"
• 客户坚持"先说说方案"——引导"好方案源自深入了解，给我30分钟"
• 客户期望不切实际——用行业数据校准"通常需要X到X个月"
推荐：《系统思考》丹尼斯·舍伍德
自我检查：建立了足够信任？识别了真正根因？给了客户有价值的洞察？客户愿意继续合作？