一句话理解
要件定義（ようけんていぎ）是日本 SAP 项目的第一个正式阶段，目标是把客户的业务需求书面化、结构化、可评审——输出的《要件定義書》是整个项目的需求基线，后续所有设计、开发、测试都要回溯到它。
实战提示
实战提示：要件定義阶段最值钱的一句话是"这个需求，请在要件定義書里明确"。口头说的都不算数，白纸黑字写进文档并让客户签字，才是需求。
要件定義阶段的目标
- 明确业务范围 —— 哪些业务流程在 SAP 范围内，哪些在范围外。
- 定义业务需求 —— 每个流程"现在怎么做（As-Is）"、"将来怎么做（To-Be）"。
- 识别 Fit & Gap —— SAP 标准功能能覆盖的（Fit）和需要开发/变通的（Gap）。
- 确定非功能需求 —— 权限、报表、接口、数据量、性能等。
- 形成需求基线 —— 客户签字确认，后续变更走変更管理流程。
核心产出物
| 产出物 | 日语 | 说明 |
|---|---|---|
| 要件定義書 | ようけんていぎしょ | 核心文档：业务需求、范围、流程一览 |
| 業務フロー図 | ぎょうむフローず | As-Is / To-Be 业务流程图 |
| 機能要件一覧 | きのうようけんいちらん | 功能需求清单（对应后续 Fit & Gap） |
| 非機能要件書 | ひきのうようけんしょ | 权限、性能、接口、运维等要求 |
| スケジュール | - | 项目整体计划（マスタースケジュール） |
1
ヒアリング向业务部门访谈，收集 As-Is 业务
2
As-Is 整理画出现状流程图，确认业务痛点
3
To-Be 设计结合 SAP 标准功能设计未来流程
4
要件定義書作成写成文档
5
レビュー客户评审，多轮修改
6
承認客户签字，需求冻结
访谈（ヒアリング）的 5 个技巧
- 带着流程图去 —— 先画你理解的 As-Is，让业务部门纠正，比空口问高效得多。
- 问"例外"不问"正常" —— 正常流程大家都清楚，例外处理（返品、取消、紧急采购）才是需求的坑。
- 问数字 —— 单据量、并发用户数、数据量，这些决定后续设计和测试。
- 确认决策人 —— 业务部门经办说的不算，要确认"谁能拍板"。
- 当天出议事录 —— 访谈结论 24 小时内书面发给对方确认，避免"我没说过"。
常见坑
- 需求口头化 —— 没写进要件定義書的需求，开发阶段一定会扯皮。
- 范围蔓延 —— "顺便把这个也做了吧"是日本项目的经典陷阱，一律走変更管理。
- To-Be 照搬 As-Is —— SAP 项目的价值在于流程优化（Fit to Standard），把旧流程原样搬进 SAP 是失败的开始。
- 非功能需求遗漏 —— 权限、接口、报表现在不谈，上线前会集中爆发。
常见问题
Q：要件定義和国内项目的蓝图（Blueprint）有什么区别？
A：思路接近，但日本项目的要件定義更偏"需求"、基本設計更偏"方案"。国内蓝图往往把两者合在一起。日本项目分阶段评审更细。
Q：要件定義一般要多久？
A：中型项目通常 1-3 个月。时间取决于业务复杂度、客户配合度，以及是否已有现行系统的资料。
Q：客户不配合访谈怎么办？
A：通过 PM 升级（エスカレーション），把"客户访谈延迟"作为課題（Issue）正式记录，关联到项目进度风险。日本项目里，书面记录是最好的自我保护。