第 2 章 · 预计阅读 20 分钟
诊断、提案与范围签约
为什么一份听起来很完整的提案，仍可能在执行时不断失控？
把问题、方法、交付物、客户输入、计划、验收、价格和排除项放进可执行工作说明书。
先放回整门生意
先知道这一章为什么存在
先把“诊断、提案与范围签约”理解成一段有触发、有负责人、有记录、也有完成标准的业务，而不是一组部门名词。
上一章“线索、问题与合作资格”应先形成：确认问题重要性、专业适配、决策人、预算、时间和可获得证据，再决定是否投入提案。
本章把“把问题、方法、交付物、客户输入、计划、验收、价格和排除项放进可执行工作说明书。”从一句目标变成可执行、可交接、可核验的工作。
结果将交给下一章“专家组队与项目执行”：围绕工作包配置专家与客户角色，用证据、评审和变更控制推进分析，而不是堆叠个人观点。
- 收入怎么受影响
- 澄策咨询通过诊断项目费、顾问工时费、专项数据分析费和后续落地辅导费收费。本章形成的“范围围绕可完成的专业判断”要和“本步核对线索：项目交付物在处理前后的状态变化”、“本步核对线索：工作说明书在处理前后的状态变化”、“本步核对线索：可计费利用率在处理前后的状态变化”和“本步核对线索：项目责任矩阵在处理前后的状态变化”一起核对，才能继续判断验收、结算或后续经营；现金时点按以下规则判断：启动收 40%，中期诊断评审后收 40%，最终成果验收后收 20%；范围外工作先签变更再执行。
- 风险在哪里出现
- 全程要警惕“范围不清、证据不足、专业责任和回款延期”。本章至少要用“本步核对线索：项目交付物在处理前后的状态变化”、“本步核对线索：工作说明书在处理前后的状态变化”、“本步核对线索：可计费利用率在处理前后的状态变化”和“本步核对线索：项目责任矩阵在处理前后的状态变化”留下可追溯证据。
读完这一章，你应该能自己解释
- 能用自己的话解释“为什么一份听起来很完整的提案，仍可能在执行时不断失控？”，并说出它为什么会影响客户价值或经营结果。
- 能按依赖顺序还原4个业务步骤，并指出每一步的负责人、记录和交接物。
- 能区分业务流、钱流、信息流和责任流，不把“做过动作”误当成“完成交付”。
- 遇到相似情境时，能用“产出是否形成、证据能否核对、风险是否受控”作出判断。
先建立业务直觉
为什么一份听起来很完整的提案，仍可能在执行时不断失控？
诊断发现库存、采购和仓网都有关联。客户希望项目覆盖所有问题，但预算和六周周期只够深挖三座仓库。团队必须让优先级和不做什么同样清楚。
把它放进澄策咨询的经营现场：本章只聚焦“诊断、提案与范围签约”这一环，追踪它怎样承接已有输入，并把“把问题、方法、交付物、客户输入、计划、验收、价格和排除项放进可执行工作说明书”变成可以执行和复核的工作。
本章从“定义问题”开始，依次经过“定义问题”、“设计方法”、“列明交付”和“签署范围”，最后得到“范围围绕可完成的专业判断”。判断是否完成，要把动作、产出、业务记录和下一位接手者放在一起核对。
至少同时满足三件事：产出“范围围绕可完成的专业判断”；关键记录“本步核对线索：项目交付物在处理前后的状态变化”、“本步核对线索：工作说明书在处理前后的状态变化”、“本步核对线索：可计费利用率在处理前后的状态变化”和“本步核对线索：项目责任矩阵在处理前后的状态变化”可以相互核对；相关负责人清楚下一步由谁接手。
完整案例推演
跟着澄策咨询，把“诊断、提案与范围签约”完整跑一遍
现在把镜头放到澄策咨询的“诊断、提案与范围签约”：为什么一份听起来很完整的提案，仍可能在执行时不断失控？ 先读下面的经营底账，后续每一步都会复用这些数字与约束。
贯穿全课的虚构案例
澄策咨询
一家 14 人的管理咨询公司受食品加工厂委托，诊断采购缺货和库存积压同时发生的原因，并在十周内交付可执行的补货与供应商管理方案。
- 项目金额
- ¥280,000费用购买的是约定范围内的诊断、方案和辅导，不是对降本结果作无条件保证。
- 项目周期
- 10 周、6 场关键访谈工作坊每一阶段都要取得客户数据和决策人反馈，否则后续建议缺少事实基础。
- 分析样本
- 18 个月、2,640 个物料 SKU数据清洗口径会决定缺货率和库存天数是否可比，不能直接拿原始表格下结论。
- 最终交付
- 1 份诊断报告、3 套流程方案、1 次管理层评审交付物必须通过评审并形成采纳决定，发送文件不等于项目验收。
客户为什么付钱
诊断项目费、顾问工时费、专项数据分析费、后续落地辅导费
钱在什么时候进来
启动收 40%，中期诊断评审后收 40%，最终成果验收后收 20%；范围外工作先签变更再执行。
利润最容易被什么吃掉
顾问和专家工时、数据采购与分析工具、访谈差旅、高级合伙人复核
这笔业务怎样一步一步形成可交付结果
- 01定义问题可供“设计方法”使用的可评审的解决方案
- 02设计方法可供“列明交付”使用的可复核的业务证据
- 03列明交付可供“签署范围”使用的已确认的目录或产品信息
- 04签署范围范围围绕可完成的专业判断
定义问题
在澄策咨询，团队先面对一条共同事实：“项目金额”为¥280,000。费用购买的是约定范围内的诊断、方案和辅导，不是对降本结果作无条件保证。
把宽泛诉求转成可回答的问题和成功标准。
这一步真正要判断：确认目标、边界和成功标准；协调专家与客户输入
如果本步没有形成“可供“设计方法”使用的可评审的解决方案”，下一步“设计方法”就没有可靠输入。
- 谁在参与
- 客户发起人与决策者、项目经理
- 关键记录
- 本步核对线索：项目交付物在处理前后的状态变化
- 形成产出
- 可供“设计方法”使用的可评审的解决方案
- 交给下一步
- 把“可供“设计方法”使用的可评审的解决方案”交给项目专家和客户业务团队，继续处理“设计方法”。
如果没做好：风险观察：交付物具有使用目的——诊断、优先级、路线图和模板各自回答明确问题。
设计方法
上一步已经形成“可供“设计方法”使用的可评审的解决方案”。与此同时，案例里的“项目周期”为10 周、6 场关键访谈工作坊，每一阶段都要取得客户数据和决策人反馈，否则后续建议缺少事实基础。
选择数据、访谈、分析和验证路径。
这一步真正要判断：主导分析框架和关键判断；按计划提供数据、流程与反馈
如果本步没有形成“可供“列明交付”使用的可复核的业务证据”，下一步“列明交付”就没有可靠输入。
- 谁在参与
- 项目专家、客户业务团队
- 关键记录
- 本步核对线索：工作说明书在处理前后的状态变化
- 形成产出
- 可供“列明交付”使用的可复核的业务证据
- 交给下一步
- 把“可供“列明交付”使用的可复核的业务证据”交给项目经理、客户发起人与决策者和项目商务经理，继续处理“列明交付”。
如果没做好：风险观察：SOW 同时写清做与不做——对象、输入、排除项、评审和扩展路径均可执行。
列明交付
上一步已经形成“可供“列明交付”使用的可复核的业务证据”。与此同时，案例里的“分析样本”为18 个月、2,640 个物料 SKU，数据清洗口径会决定缺货率和库存天数是否可比，不能直接拿原始表格下结论。
明确内容、格式、里程碑、评审和验收。
这一步真正要判断：协调专家与客户输入；确认目标、边界和成功标准；维护范围与费用变化
如果本步没有形成“可供“签署范围”使用的已确认的目录或产品信息”，下一步“签署范围”就没有可靠输入。
- 谁在参与
- 项目经理、客户发起人与决策者、项目商务经理
- 关键记录
- 本步核对线索：可计费利用率在处理前后的状态变化
- 形成产出
- 可供“签署范围”使用的已确认的目录或产品信息
- 交给下一步
- 把“可供“签署范围”使用的已确认的目录或产品信息”交给项目经理、客户发起人与决策者和客户业务团队，继续处理“签署范围”。
如果没做好：风险观察：价格匹配专家工作量——预算覆盖约定深度，并为新增对象保留单独估算。
签署范围
上一步已经形成“可供“签署范围”使用的已确认的目录或产品信息”。与此同时，案例里的“最终交付”为1 份诊断报告、3 套流程方案、1 次管理层评审，交付物必须通过评审并形成采纳决定，发送文件不等于项目验收。
确认客户输入、价格、计划、排除项和变更机制。
这一步真正要判断：协调专家与客户输入；确认目标、边界和成功标准；按计划提供数据、流程与反馈
这是本章最后一项可核验产出，用来判断团队是否真的完成了“诊断、提案与范围签约”。
- 谁在参与
- 项目经理、客户发起人与决策者、客户业务团队
- 关键记录
- 本步核对线索：项目责任矩阵在处理前后的状态变化
- 形成产出
- 范围围绕可完成的专业判断
- 交给下一步
- 把结果带入“范围围绕可完成的专业判断”，并回答：签约以后，怎样让专家团队与客户输入按同一节奏执行？
如果没做好：风险观察：客户输入责任被明确——数据提供、事实确认和里程碑批准有具体负责人。
案例结束时，不是因为所有人都完成了自己的动作就算成功，而是因为“范围围绕可完成的专业判断”已经形成、证据可以追溯，并且项目经理、客户发起人与决策者和客户业务团队能够解释结果怎样产生、风险怎样被控制。SOW 锁定三座代表性仓库、四项交付物、客户数据责任和新增仓库的变更机制。
章末经营结果
范围围绕可完成的专业判断
SOW 锁定三座代表性仓库、四项交付物、客户数据责任和新增仓库的变更机制。
- 项目周期
- 6 周
- 分析对象
- 3 座仓库
换一个视角再看
同一笔业务，同时跑着四条线
业务流说明事情怎样发生，钱流解释收入、成本与现金，信息流留下共同事实，责任流决定谁执行、谁确认、谁承担后果。点击切换，观察同一章节怎样变化。
围绕“为什么一份听起来很完整的提案，仍可能在执行时不断失控？”，业务必须按依赖关系推进，不能把一串并行任务误当成已经交付。
- 01
定义问题 → 可供“设计方法”使用的可评审的解决方案
- 02
设计方法 → 可供“列明交付”使用的可复核的业务证据
- 03
列明交付 → 可供“签署范围”使用的已确认的目录或产品信息
- 04
签署范围 → 范围围绕可完成的专业判断
出现这个信号要警惕：风险观察：交付物具有使用目的——诊断、优先级、路线图和模板各自回答明确问题。
岗位、记录与业务语言
一家公司靠什么把多人协作变成同一个结果
岗位不是孤立的名称，记录也不是多余的表格。前者分配判断与责任，后者让不同人能够核对同一件事是否真的发生。
谁负责什么，结果交给谁
| 角色 | 本章负责 | 最关心 | 交给谁 |
|---|---|---|---|
| 业务职能市场与客户开发 | 提供本章所需的约束、输入或审批 | 识别适合的问题与客户，建立可信的合作机会；重点关注：筛选线索、关系和采购路径 | 下一章节或业务结果的接收方 |
| 业务职能专业研究与解决方案 | 提供本章所需的约束、输入或审批 | 使用专业方法分析问题，形成结论、设计与可实施建议；重点关注：选择方法并验证证据 | 下一章节或业务结果的接收方 |
| 业务职能项目管理 | 提供本章所需的约束、输入或审批 | 把范围、计划、人员、输入、风险和客户决策组织成可交付项目；重点关注：建立计划、责任和沟通节奏 | 下一章节或业务结果的接收方 |
| 业务职能项目商务与财务 | 提供本章所需的约束、输入或审批 | 维护项目预算、工时、开票条件、应收和合同变更；重点关注：跟踪预算、工时与分包成本 | 下一章节或业务结果的接收方 |
| 外部参与者客户发起人与决策者 | 定义问题、列明交付、签署范围 | 定义项目价值，调动客户资源并作出关键取舍；重点关注：确认目标、边界和成功标准 | 项目专家、客户业务团队、项目经理 |
| 外部参与者客户业务团队 | 设计方法、签署范围 | 提供资料、访谈、业务判断，并承接成果使用；重点关注：按计划提供数据、流程与反馈 | 项目经理、客户发起人与决策者、项目商务经理 |
| 代表岗位项目经理 | 定义问题、列明交付、签署范围 | 把范围、计划、人员、输入、风险和客户决策组织成可交付项目；重点关注：协调专家与客户输入 | 项目专家、客户业务团队、客户发起人与决策者 |
| 代表岗位项目专家 | 设计方法 | 使用专业方法分析问题，形成结论、设计与可实施建议；重点关注：主导分析框架和关键判断 | 项目经理、客户发起人与决策者、项目商务经理 |
| 代表岗位项目商务经理 | 列明交付 | 维护项目预算、工时、开票条件、应收和合同变更；重点关注：维护范围与费用变化 | 项目经理、客户发起人与决策者、客户业务团队 |
哪些记录能证明业务真的发生了
| 业务记录 | 在哪产生 | 谁形成 | 证明什么 | 下一步怎么用 |
|---|---|---|---|---|
| 本步核对线索：项目交付物在处理前后的状态变化 | 定义问题 | 客户发起人与决策者和项目经理 | 可供“设计方法”使用的可评审的解决方案 | 设计方法 |
| 本步核对线索：工作说明书在处理前后的状态变化 | 设计方法 | 项目专家和客户业务团队 | 可供“列明交付”使用的可复核的业务证据 | 列明交付 |
| 本步核对线索：可计费利用率在处理前后的状态变化 | 列明交付 | 项目经理、客户发起人与决策者和项目商务经理 | 可供“签署范围”使用的已确认的目录或产品信息 | 签署范围 |
| 本步核对线索：项目责任矩阵在处理前后的状态变化 | 签署范围 | 项目经理、客户发起人与决策者和客户业务团队 | 范围围绕可完成的专业判断 | 范围围绕可完成的专业判断 |
本章术语：先用白话理解，再回到正式定义
- Project Deliverable项目交付物
- 白话：在约定里程碑提交、具有明确内容、格式、质量和使用目的的专业成果。
- 正式定义：在约定里程碑提交、具有明确内容、格式、质量和使用目的的专业成果。
- 放进业务里：供应链诊断不只交一份演示稿，还包括问题证据、优先级、改进路线和可编辑数据附表。
- SOW工作说明书
- 白话：描述项目目标、范围、交付物、方法、计划、客户输入、验收与排除项的执行文件。
- 正式定义：描述项目目标、范围、交付物、方法、计划、客户输入、验收与排除项的执行文件。
- 放进业务里：SOW 明确分析三座仓库，不包含运输招标实施，并列出客户必须提供的数据字段和时间。
- Billable Utilization可计费利用率
- 白话：专业人员在一定周期内投入可向客户项目计费工作的时间，占其可用工作时间的比例。
- 正式定义：专业人员在一定周期内投入可向客户项目计费工作的时间，占其可用工作时间的比例。
- 放进业务里：利用率过低会闲置专家能力，过高则可能挤压研究、培训、销售支持和质量评审。
- Project Responsibility Matrix项目责任矩阵
- 白话：明确每项工作由谁负责、批准、协作和知会的项目组织约定。
- 正式定义：明确每项工作由谁负责、批准、协作和知会的项目组织约定。
- 放进业务里：库存数据由客户团队提供，项目专家分析，客户发起人批准口径，质量评审人独立检查结论。
新手最容易误解的地方
承诺六周覆盖全部
为什么不对：若提案仍暗示深度诊断，实际扫描会造成交付预期落差和返工。
应该继续追问：如果改成“深挖三座并设计扩展方法”，需要谁确认、留下什么证据？
“定义问题”只要动作做完，就可以直接进入下一步。
为什么不对：风险观察：交付物具有使用目的——诊断、优先级、路线图和模板各自回答明确问题。
应该继续追问：是否已经形成“可供“设计方法”使用的可评审的解决方案”，并留下“本步核对线索：项目交付物在处理前后的状态变化”供下一步核对？
“设计方法”只要动作做完，就可以直接进入下一步。
为什么不对：风险观察：SOW 同时写清做与不做——对象、输入、排除项、评审和扩展路径均可执行。
应该继续追问：是否已经形成“可供“列明交付”使用的可复核的业务证据”，并留下“本步核对线索：工作说明书在处理前后的状态变化”供下一步核对？
先复盘，再做判断
现在，试着不用页面原话把这一章讲出来
- 为什么本章必须先做“定义问题”，如果跳过会影响哪一步？
- 在“设计方法”中，谁执行、谁提供约束，应该留下什么记录？
- 本章怎样影响诊断项目费、顾问工时费、专项数据分析费和后续落地辅导费？结合“启动收 40%，中期诊断评审后收 40%，最终成果验收后收 20%；范围外工作先签变更再执行。”判断它何时才会形成收入或现金。
- 如果只看到“范围围绕可完成的专业判断”的口头结论，你还会要求核对哪些业务记录？
六周项目应该覆盖多少分析对象？
客户希望一次看完八座仓库，团队判断深度分析三座代表性仓库才有可靠证据。