第一章：明确分析目标与范围
可行性分析的第一阶段，也是最重要的阶段，是将模糊的业务诉求转化为清晰、可执行的AI项目锚点。任何AI解决方案的失败，根源大多不在于技术，而在于目标和范围的失焦。
核心原则： 不要问“AI能做什么”，而要问“业务需要解决什么”。本阶段的目标是用最小的成本，锁定最正确的起点。
适用场景
- 企业首次提出“用AI优化XX流程”的初步构想时。
- 已有传统系统，希望评估引入AI替换旧方案的可行性。
- 多个业务部门都想上AI，需要做资源排期决策和优先级排序时。
- 项目立项前，需要向投资委员会或管理层提交可行性调研申请。
前置条件
- 明确的业务痛点： 至少有一个量化的业务指标偏离预期（如客服响应时效降低30%、生产良品率波动增大）。
- 初步的项目发起人： 已找到愿意投入时间、预算和跨部门协调权力的业务方负责人。
- 数据初步可触达： 确认与痛点相关的原始数据至少存在于某个系统中，且具备导出或查询权限。
操作步骤
本阶段通过三个核心步骤，从模糊走向清晰。每一步都强调对抗“需求蔓延”。
步骤一：定义业务问题
使用 5W1H 法 将业务方的原始诉求结构化。不要使用AI术语，强制用业务语言描述现状与期望的差距。
| 维度 | 引导问题 | 示例（客服场景） |
|---|---|---|
| What | 现状与期望的差距是什么？ | 客户重复提问占比35%，但人工客服无法实时识别。 |
| Why | 为什么这个问题必须现在解决？ | 导致NPS评分持续下滑，且人力成本已无法增长。 |
| Who | 谁受此问题影响最大？ | 一线客服人员、售后服务部门主管。 |
| Where | 问题主要发生在哪个环节？ | 用户接入后的前30秒，常见FAQ重复解释。 |
| When | 期望多久看到改善效果？ | 未来6个月内，实现首轮回复自动化解锁。 |
| How | 当前是如何处理这一问题的？ | 靠人工熟手记忆，或依靠笨重的目录树检索。 |
步骤二：确定AI解决方案边界
划定该AI项目的“作战半径”。明确哪些属于当前阶段必须解决的问题，哪些故意放在范围之外。这是对抗“范围蔓延”的唯一武器。
- 功能边界： AI模型仅做分类推荐，还是需要直接执行操作？是否保留人工干预接口？
- 数据边界： 仅使用30天的对话记录，还是需要全量历史数据？是否需要融合CRM系统、工单系统的字段？
- 系统边界： AI模块以何种方式嵌入现有系统架构（如API Gateway、消息队列、独立微服务）？
- 非功能边界： 对响应延迟的容忍度（秒级/毫秒级）、数据隐私合规要求（是否允许数据出域）。
实践技巧： 画出“包含/不包含”清单。例如：
包含： 实时FAQ自动回复、相似问题聚类。
不包含： 情绪识别、多轮复杂意图推理、与ERP系统对接。
包含： 实时FAQ自动回复、相似问题聚类。
不包含： 情绪识别、多轮复杂意图推理、与ERP系统对接。
步骤三：识别关键利益相关者
确定谁拥有决策权、谁提供业务知识、谁最终使用系统。缺少任何一位关键角色的参与，都会导致方案后续推进受挫。
- 决策者（发起人）： 提供预算和资源，否决不合理的需求。
- 业务专家（Subject Matter Expert, SME）： 定义正确的业务规则和评估标准。
- 技术交付负责人： 评估数据可获得性和技术可行性。
- 最终使用者（终端用户）： 为AI流程提供真实验证，反馈优化方向。
输入输出物
| 输入（材料） | 输出（交付物） |
|---|---|
| 业务反馈邮件、会议纪要、投诉报表 | 问题陈述单页： 包含量化指标、影响范围、期望时间窗口。 |
| 现有系统架构图、数据字典 | 范围界定文档： 包含功能、数据、系统、非功能四大边界清单。 |
| 组织架构图、项目相关方名单 | 利益相关者地图： 按决策、执行和使用进行分层，并标注参与点。 |
责任边界
| 角色 | 职责 |
|---|---|
| 项目发起人 (Business Sponsor) | 确认问题优先级、批准资源投入、消除跨部门协作障碍。 |
| AI解决方案架构师 (本章负责角色) | 主持目标研讨会、梳理5W1H、输出范围初稿、识别关键技术约束。 |
| 业务专家 (SME) | 提供领域知识的准确性和评估标准的合理性。 |
| 合规/信息安全 | 确认数据边界是否触碰红线、是否需要脱敏或合法授权。 |
记录材料
- 《AI项目立项提案》模板： 用于沉淀问题陈述、对齐目标和预估投入。
- 《利益相关者访谈》记录表： 用于统一收集各方预期，避免口头理解偏差。
异常处理
| 异常场景 | 处理决策 |
|---|---|
| 业务方与算法团队对问题定义存在分歧 | 强制召开“问题排序工作坊”，用数据历史统计说话，投票决定最核心的子问题。 |
| 多个部门都想把需求纳入项目范围 | 严格执行MoSCoW原则（Must have / Should have / Could have / Won't have），超出当前边界的放入“二期规划”。 |
| 业务方无法提供量化指标 | 变通方法：定义感知指标（如减少手工操作步骤数、降低平均处理时长），并设定基线测量任务。 |
验收标准
- 业务问题已被量化： 形成至少3个可测量的KPIs，清晰描述现状与目标值。
- 范围边界具备排他性： 明确列出了“本项目不包含的内容”，并得到项目发起人签字确认。
- 利益相关者覆盖率100%： 所有在关键路径上存在的角色均已确认参与，且了解自己在项目中的责任点。
- 文档版本已归档： 目标章程、范围清单和干系人地图已纳入知识库，可供后续阶段引用。