第 5 章 · 业务、数据与价值
本章你会学到：怎么把客户的一句话变成可验证的问题，用访谈、流程地图、指标、数据地图、需求翻译和干系人地图把项目定义清楚，最后用一张评分卡决定该不该接。
一句话：项目不是在会议室里立项的，是在用户的工作流里被找出来的；价值不是被讲出来的，是被测出来的。
一个现场片段
以下是合成场景，用于说明典型情境，不对应任何真实客户。
第一次见面，客户的数字化负责人很直接：「我们想做一个客服 AI 助手，预算有，三个月要上线，能对话、能查订单、能安抚客户。」
你没有接方案，而是问了一句：「能不能让我去客服工位坐半天？」他有点意外，但还是安排了。
第二天上午，你坐在一位客服旁边，看她接电话。一个电话进来，她先切到 CRM 查订单，再切到工单系统建单，然后打开一个 Excel 记下「客户要求特殊处理」——三个系统、四次复制粘贴。她告诉你，每天新进大约 200 张工单，最烦的不是话术，而是「把客户说的内容归到对的类，再找到该找的人」：分类一错，工单就在组之间来回转，客户还要再打一次电话。
回到会议室，你说：「你们真正缺的可能不是一个能对话的助手，而是一个分类和分派工具，并且要能解释为什么这么分。」负责人沉默了几秒，说：「对，这件事我们内部吵了半年。」
后来的项目从「客服助手」缩成了「工单分流」：范围小了一半，但第一次有了可测的指标——分类准确率、误分率、平均处理时长。客户说的方案，通常是他能想象到的方案；你要找的，是他真正在付代价的问题。
现场五问：把「我要 AI」拆成可验证的问题
「现场五问」是我们贯穿全书的第一个判断工具。它不复杂，但能把大部分「伪需求」挡在立项之前：
谁痛？痛多大？现在怎么解？为什么是现在？谁为结果买单？
| 问题 | 你要拿到的证据 | 危险信号 | 一句追问 |
|---|---|---|---|
| 谁痛 | 具体岗位、具体人、多久发生一次 | 「大家都痛」；痛的是 IT 而不是业务 | 上次因为这个痛，你们损失了什么？ |
| 痛多大 | 时间、金额、错误率、合规风险，且已有基线 | 只有感受没有数字；数字来自供应商案例 | 现在每天发生多少次？一次损失多少？ |
| 现在怎么解 | 现有流程、Excel、人工补位、外包 | 说「没有流程」，通常意味着流程在个人脑子里 | 能不能现在演示一遍你怎么做？ |
| 为什么是现在 | 触发事件：新政策、新系统、旺季、换负责人 | 没有触发事件，项目就没有真实优先级 | 如果三个月不做，会怎样？ |
| 谁为结果买单 | 经济买家、预算、验收人、合同路径 | 只有用户热情，没有预算人 | 预算在谁手里？最后谁签字？ |
五问里最容易被跳过的是第五问。前面的痛再真，如果没人对结果负责、没人能批预算，项目会在试点结束那天突然死亡——用户说很好用，但没有人续费。
追问不够时，用这组问题补刀：第一问追「还有谁受影响」；第二问追「上个月最严重的一次损失是多少」；第三问追「哪个环节最容易卡住、卡住时找谁」；第四问追「如果下季度不做，会丢掉什么」；第五问追「预算从哪个科目出、谁签字、什么流程」。
一个反直觉的经验
「痛多大」这一问，问感受是问不出来的。要问具体事件：上个月最严重的一次出了什么事、谁被问责、赔了多少钱、加了多少班。能量化的痛，才配得上一个试点。
访谈方法：去现场，而不是发问卷
访谈的目标不是「收集需求」，而是还原工作现场。需求是用户对解决方案的想象，工作现场才是事实。四种方法按顺序用：
影子跟岗（shadowing）
坐在用户旁边看半天，不打断、不评价。记录三样东西：每一次系统切换、每一次复制粘贴、每一次找人帮忙。这三样往往就是自动化和 AI 的切入点。结束前问三个问题：今天最烦的是哪一步？哪一步最容易出错？如果只能去掉一步，去掉哪一步？
关键事件访谈（critical incident）
不要让用户泛泛描述「平时怎么做」，而是请他回忆最近一次最典型或最麻烦的事，按时间线讲：几点收到、先做什么、卡在哪、谁介入、最后怎么结束。一次具体事件的信息量，抵得上十次「我们的流程是……」。
5 Whys：连问五个为什么
从一个表层问题往下追，直到追到流程或数据问题。示例（合成）：
- 为什么报表出得慢？→ 要手工汇总。
- 为什么手工汇总？→ 系统导不出需要的字段。
- 为什么导不出？→ 录入时这个字段不是必填。
- 为什么不是必填？→ 当初上线时没这个需求。
- 为什么现在才提？→ 上季度开始按这个字段考核。
追到最后你会发现，问题可能不在「做一个 AI 报表」，而在「把字段变成必填 + 补历史数据」。
流程走查（walkthrough）
拿一个真实案例，让用户从头到尾走一遍，包括他实际会打开的系统、会问的人、会绕的路。注意：走实际流程，不走标准作业程序（SOP）。SOP 描述的是理想状态，实际流程才是你未来系统要嵌进去的地方。
访谈提纲清单
- [ ] 开场：说明用途、征得录音同意、强调没有对错
- [ ] 角色：你每天的主要任务是什么？向谁汇报？谁来评价你做得好？
- [ ] 最近一次：请讲一件最近发生的、最典型的事
- [ ] 时间线：从开始到结束，每一步做了什么、用了什么系统
- [ ] 例外：什么情况下流程会走不通？你找谁？
- [ ] 度量：你怎么知道自己今天干得好不好？有没有数字？
- [ ] 影响：做错一次会发生什么？对客户、对公司分别是什么后果？
- [ ] 愿望：如果有一个帮手，你最希望它接手哪一步？
- [ ] 收尾：还有谁我应该去聊？我可以把今天的记录发给你确认吗？
访谈记录当天整理，写成「事实 / 观察 / 判断」三栏，把猜测和事实分开——后面你会反复用到这份材料。
流程地图：把「实际怎么干」画出来
访谈之后，你要能把流程画在一页纸上。一张够用的流程地图包含六类信息：输入、输出、角色、系统、决策点、例外。画成泳道最直观：
客户 提交工单 ──────────────────────────────┐
│
客服 接单 ─▶ 分类判断 ─┬─ 分对了 ─▶ 处理 ─▶ 关闭
└─ 分错了 ─▶ 转组 ─▶ 退回重分
│
系统 CRM（查订单）/ 工单系统（建单）/ Excel（特殊备注）
│
例外 客户催单、信息不全、金额超限、系统打不开画的时候守着三条规则：
- **先画正常路径，再补例外。**例外往往是耗时和错误的主要来源。
- **标出耗时最长、最容易出错、最依赖个人的三步。**这三步就是候选的切入点。
- **一页纸画完。**画不下，说明你还没理解，或者流程本身就该拆。
画完拿给一线用户看，问一句：「哪里不对？」——他们会很乐意纠正你，而纠正的过程就是最好的验证。
指标与 ROI：先有基线，再谈目标
没有基线，就没有提升。项目定义阶段必须把三件事写清楚：基线的数值、目标值、测量口径。口径包括：统计周期、数据来源、算法、排除项（比如节假日、测试单）。
三类指标
| 类型 | 例子 | 特点 | 怎么用 |
|---|---|---|---|
| 业务结果指标 | 成本、收入、合规风险、客户满意度 | 滞后、受多因素影响 | 立项和续约时讲，必须能归因 |
| 运营指标 | 处理时长、准确率、升级率、一次解决率 | 领先、可周度观测 | 试点期间每周跟踪 |
| 交付质量指标 | 检索命中率、引用准确率、无答案率、时延、单次成本 | 受控、随改动波动 | 每次发版回归 |
**领先指标（leading）**先动，**滞后指标（lagging）**后动。试点阶段看领先指标，才能在没有业务结果之前判断方向对不对。
拿基线的三种方法
- 历史数据回算：用过去三个月的记录，按目标口径重新计算。最省事，但要先验证历史数据质量。
- 抽样观测：两周内抽样统计人工处理的时间和错误率。适合没有系统记录的场景。
- 对照或分阶段上线：先在一个组上线、另一个组不上线，或按时间窗对比。成本最高，归因最可信。
ROI（投资回报率）计算模板
价值通常落在四类账上。填模板时，每个数字都要能指向来源；来源不明的数字宁可空着。
| 类型 | 公式 | 合成示例（数字为演示，替换成你们的实际口径） |
|---|---|---|
| 时间 | 单次节省时间 × 年发生次数 | 每天 200 张 × 误分 18% × 每张修正 6 分钟 ≈ 每天 3.6 小时 |
| 人力 | 释放的工时 ÷ 人均年工时 × 全成本 | 每天 3.6 小时 × 250 个工作日 ≈ 900 小时/年 |
| 收入 | 转化率提升 × 客单价 × 年成交量 | 示例：转化率 +1 个百分点，按实际客单价测算 |
| 风险 | 减少的错误数 × 单次损失 | 示例：按历史事故的平均处理成本保守估算 |
时间账算出来之后，别急着把它写成「节省 X 个人力」。节省的时间可能只是变成了更从容的服务，不一定能减人。对外承诺要保守，内部测算可以激进。
引用真实案例时注意口径
BBVA 公开披露过 AI 助手「每周为员工节省 3 小时、周活 83%」这类使用指标（公司披露）；John Deere 的 See & Spray 公布过化学品用量减少约 70%、并按实际启用英亩订阅收费（公司披露）。这些数字可以帮你理解「什么样的指标值得追」，但不能当成你自己项目的基线——口径、业务、数据都不同。相关案例见案例库 · 大企业现场。
数据地图：能不能做，先看数据
业务问题清楚了，下一步是回答「数据够不够」。数据地图是一张表，把每个要用到的数据源写清楚：
| 数据项 | 源系统 / 表 | 含义 | Owner | 更新频率 | 质量与风险 | 权限 | 接入方式 |
|---|---|---|---|---|---|---|---|
| 工单文本 | 工单系统 · tickets | 客户原始诉求 | 客服运营 | 实时 | 含个人信息，需脱敏 | 业务只读 | 数据库 / API |
| 工单分类 | 工单系统 · tickets | 人工填写的类别 | 客服运营 | 实时 | 标签口径不统一 | 业务只读 | 同上 |
| 客户等级 | CRM · accounts | 客户分层 | 销售运营 | 每天 | 部分为空 | 需审批 | 数仓表 |
| 处理记录 | 工单系统 · logs | 流转与耗时 | IT | 实时 | 时间字段时区不一 | 需审批 | 导出 |
再给每个数据源打一个可用性评分（1-5 分），六项分别是：可得性、完整性、标签质量、时效性、权限合规、接入成本。一个简单的判断线是：
- 总分 24 分以上：可以考虑学习型方案（分类、抽取、生成）。
- 18-23 分：先用规则 + 人工复核跑通流程，边跑边补数据。
- 18 分以下：先解决数据问题，不要立项做模型。
数据地图还有一张「非结构化清单」：文档、合同、聊天记录、邮件。它们更容易被忽略，却常常是 RAG 类项目的地基。要写清楚：版本怎么管、权限怎么继承、更新后索引怎么重建。
需求翻译：把「我要 AI」翻译成四要素
在写方案之前，把需求翻译成四个要素：任务、数据、决策、反馈。
- 任务：输入是什么、输出是什么，用一个动词说清楚（分类、抽取、检索、生成、校验）。
- 数据：做这个任务需要什么数据，从哪来，够不够。
- 决策：谁在什么场景下使用这个输出，用它做什么决定。
- 反馈：错了怎么发现、谁来修、修正结果怎么回流。
| 客户原话 | 任务 | 数据 | 决策 | 反馈 |
|---|---|---|---|---|
| 「做个客服助手」 | 工单文本 → 类别 + 理由 | 历史工单与人工标签 | 客服确认后分派 | 客服改分类，修正回流 |
| 「帮我审合同」 | 合同文本 → 条款抽取 + 风险标记 | 合同库 + 审查清单 | 法务复核后出具意见 | 漏检与误报回流 |
| 「做个知识助手」 | 问题 → 答案 + 引用 | 手册、FAQ、制度文件 | 员工自助查询 | 无答案与差评记录 |
翻译完你会发现：大多数「AI 助手」其实是分类、抽取或检索任务。把它们说清楚，方案、数据要求和评测方法都会跟着清楚。
干系人地图：谁会帮你，谁会卡你
一个项目能不能推下去，往往不取决于技术，而取决于你有没有找到最小可行联盟。立项前把关键角色画出来：
| 角色 | 他要什么 | 他怕什么 | 你需要的动作 |
|---|---|---|---|
| 经济买家 | 可衡量的结果、可控的投入 | 钱花了没效果、被上级问责 | 用他的语言写目标和验收 |
| 一线用户 | 少干活、少背锅 | 被替代、被加活、被监控 | 让他参与设计，先解决他最烦的一步 |
| IT | 稳定、安全、可维护 | 背锅、被绕过、增加运维负担 | 提前对齐架构与权限，给回滚方案 |
| 安全与合规 | 数据不出域、可审计 | 违规、泄露、审计不过 | 数据分级、脱敏、日志留存方案 |
| 法务 | 责任边界清晰 | 错误输出带来法律责任 | 明确「辅助而非替代」，保留人工复核 |
| 采购 | 流程合规、价格合理 | 走不完流程、买贵了 | 尽早介入，按阶段验收设计合同 |
| 高层 Sponsor | 可见的成果与叙事 | 项目失控、内部阻力 | 关键节点汇报，给他可对外讲的结果 |
在每个人名后面标一个态度：支持 / 中立 / 阻断。然后回答三个问题：谁是真正的经济买家？谁有能力叫停项目？你缺的那一票，用什么证据去换？
只和 IT 聊，是新人最常犯的错
IT 会告诉你系统怎么接、权限怎么开，但不会告诉你用户实际怎么绕开系统干活。业务痛点在用户那里，技术约束在 IT 那里，两边都要聊；先聊用户，再聊 IT。
项目选择评分卡
不是每个项目都值得接。用五个维度，每个 1-5 分，加权后做决定：
| 维度 | 权重 | 1 分 | 3 分 | 5 分 |
|---|---|---|---|---|
| 价值 | 30% | 说不清痛，或痛很小 | 有痛，但只有定性描述 | 痛可量化，有明确基线 |
| 数据 | 20% | 拿不到，或质量极差 | 能拿到样本，需大量清洗 | 数据齐、口径清、可实时接入 |
| Owner | 20% | 没人负责，只有用户热情 | 有业务接口人，但无预算权 | 经济买家明确，愿意签验收 |
| 可验证性 | 15% | 无法在 8 周内测出变化 | 指标可测，但归因困难 | 指标可测且在试点期内能见效 |
| 复用性 | 15% | 纯一次性定制 | 可在同部门复制 | 能沉淀为平台能力，跨客户复用 |
加权总分（1-5 分制）的判断线：
- 4.0 分以上：优先投入，可以承诺试点目标。
- 3.5-4.0 分：可以立项，但先做 1-2 周的可行性验证。
- 3.0-3.5 分：只做小范围 PoC（概念验证），不承诺上线，边做边补条件。
- 3.0 分以下：不接。尤其注意两种情况：任何一项 ≤2 分且短期补不上，或者数据分低但对方要求直接上生产。
复用性低、价值高的项目可以接，但要提前说清楚：这是一次性交付，按项目收费、按阶段验收，不承诺产品化。反过来说，如果整个团队都在接一次性定制，人均产出会停在一个很难突破的水平——TCS 被反复引用的一个观察是：十年间营收和人数几乎同步翻倍，人均营收停留在约 4.9 万美元（BVP Atlas 2025，单一来源，用于说明结构性限制，不构成对任何公司的评价）。
一个常见的误判
「价值高」不等于「现在做」。如果数据分低、owner 不在场，正确的动作是先做数据可行性，而不是先接项目、后补条件。接项目的成本，往往是在交付中期才显现的。
常见误区
| 误区 | 表现 | 后果 | 正确做法 |
|---|---|---|---|
| 把功能清单当需求 | 「要能对话、能查订单、能总结」 | 做出来没人用，指标无法定义 | 翻译成任务-数据-决策-反馈四要素 |
| 只在会议室访谈 | 全程和 IT、管理层开会 | 拿到的是标准流程，不是实际流程 | 影子跟岗半天，看真实动作 |
| 用别人的案例数字当基线 | 「XX 公司省了 70%，我们也行」 | 目标不可信，试点结束无法验收 | 用自己的历史数据算基线 |
| 没有经济买家就开工 | 用户很热情，但没人签字 | 试点成功也无法转生产 | 五问的第五问必须先有答案 |
| 数据没拿到就承诺效果 | 先承诺准确率，再找数据 | 交付中途范围坍塌 | 数据可用性评分达标再承诺 |
本章小结
- 现场五问是所有项目的入口：谁痛、痛多大、现在怎么解、为什么是现在、谁为结果买单。
- 访谈要去现场：影子跟岗、关键事件、5 Whys、流程走查，四种方法互补，记录里把事实和判断分开。
- 指标要先有基线、再有目标，并写清口径；ROI 按时间、人力、收入、风险四类账分别算，对外承诺保守。
- 数据地图和可用性评分决定「能不能做」；需求翻译成任务-数据-决策-反馈四要素，决定「做的是什么」。
- 干系人地图找最小可行联盟；项目选择评分卡帮你拒绝不该接的项目。
练习
- **访谈一个真实岗位。**找一位你能接触到的真实工作者（家人、朋友、同事都行），用本章提纲做一次 40 分钟访谈，写一份「事实 / 观察 / 判断」三栏记录。判断标准：记录里有至少 3 个具体事件和 1 个反直觉发现。
- **画流程与数据地图。**基于上面的访谈，画一张一页纸泳道流程，并列出这项任务需要的数据源、owner 和可用性评分。判断标准：能让另一个没参与访谈的人看懂流程，并指出最值得切入的一步。
- **算一次 ROI。**为你选定的场景填完整的四类账模板，每个数字标注来源；再写一段 100 字的「保守承诺版」价值描述。判断标准：所有数字可追溯，承诺不超过基线可支撑的范围。
- **给自己的项目打分。**用项目选择评分卡给你手上的一个想法打分，写下分数和「接/不接」的判断理由。判断标准：五个维度都有证据，而不是感觉。
下一章：第 6 章 · 六阶段交付法：把发现、定义、原型、试点、生产、移交串成可执行的路径。
相关：附录 B · 模板工具箱（发现访谈、干系人地图、流程地图、ROI 模板） · 案例库 · 大企业现场 · 案例库 · 中国现场 · FDE 自评