4. 需求分析：利益相关者识别、评价目标确定、评价范围界定、需求文档编写
好，咱们进入正题。需求分析这一步，说白了就是搞清楚三件事：为谁评、评什么、怎么评。我见过太多评价体系做到一半推倒重来的案例，十有八九都是需求分析没做透。你想想看，连目标都没对齐，后面再努力也是白搭。
4.1 利益相关者识别——先找到「谁说了算」
我个人习惯，拿到一个评价需求，第一件事不是画框架，而是拉一张利益相关者清单。为什么？因为评价体系最终是要给人用的，不同的人关注点完全不同。
核心原则：利益相关者识别要「广撒网，再收网」。先列全，再筛选关键角色。
常见的利益相关者包括这几类：
- 决策者：比如公司高管、项目负责人。他们关心的是「这个评价能不能帮我做决策」。
- 执行者：比如一线员工、操作人员。他们关心的是「这个评价流程复不复杂，会不会增加我的工作量」。
- 被评价者：比如被考核的团队或个人。他们关心的是「评价是否公平、指标是否合理」。
- 外部监管方：比如行业协会、政府机构。他们关心的是「评价是否符合规范、数据是否可追溯」。
嗯，这里要注意：千万别漏掉「沉默的利益相关者」。比如系统运维人员、数据提供方，这些人虽然不直接参与评价，但他们的配合程度直接影响体系落地。
我的经验：有一次做供应商评价体系，我一开始只访谈了采购经理和质检主管。结果上线后，财务部门跳出来说「你们这个评价结果没法跟付款流程对接」。你看，财务就是被我漏掉的利益相关者。从那以后，我每次都会专门问一句：「还有谁会被这个评价结果影响？」
4.2 评价目标确定——别把「手段」当「目标」
很多团队在需求分析阶段就急着讨论「用什么指标」，这是个大坑。你想想看，目标都没定清楚，指标选得再漂亮也是空中楼阁。
我建议用SMART原则来框定评价目标：
| 维度 | 说明 | 反面案例 |
|---|---|---|
| S（具体） | 目标要明确，不能模棱两可 | 「提升产品质量」→ 太模糊 |
| M（可衡量） | 要有量化或可验证的标准 | 「让客户更满意」→ 怎么算满意？ |
| A（可达成） | 目标要切合实际，别定得太离谱 | 「一个月内零缺陷」→ 现有工艺根本做不到 |
| R（相关） | 目标要和业务战略挂钩 | 「降低研发成本」但公司当前重点是「加速上市」 |
| T（有时限） | 明确评价周期和里程碑 | 「持续改进」→ 没有截止时间等于没有目标 |
举个例子。我之前帮一家制造企业做产线评价体系。一开始他们提的目标是「提高生产效率」。我说这太宽泛了，咱们得拆。最后拆成了三个具体目标：
- 三个月内，将产线换型时间从平均45分钟降到30分钟以内。
- 半年内，将设备综合效率（OEE）从72%提升到85%。
- 全年，将因操作失误导致的停机次数减少50%。
你看，这样目标一明确，后面选指标、定权重就顺理成章了。
避坑指南：我曾经遇到一个项目，甲方说「我们的目标就是建立一套科学的评价体系」。这其实不是目标，是手段。评价体系本身不是目的，通过评价体系解决什么问题才是目的。一定要追问到业务层面。
4.3 评价范围界定——画好「圈」才能不跑偏
范围界定，说白了就是划边界。哪些评、哪些不评，要提前说清楚。我见过最惨的案例，是评价体系做到一半，业务方突然说「哎，这个模块也应该纳入评价」，结果整个指标体系都要重做。
范围界定通常从三个维度入手：
- 组织范围：评价覆盖哪些部门/团队/岗位？是全公司还是某个事业部？
- 业务范围：评价覆盖哪些流程/产品/服务？是研发环节还是全生命周期？
- 时间范围：评价周期是月度、季度还是年度？数据回溯多久？
我习惯用一张范围矩阵图来跟利益相关者对齐。比如这样：
| 维度 | 纳入范围 | 排除范围 | 备注 |
|---|---|---|---|
| 组织 | 生产部、质检部、仓储部 | 行政部、财务部（仅提供数据） | 财务部作为数据源，不参与评价 |
| 业务 | 来料检验、过程检验、成品检验 | 供应商审核、客户投诉处理 | 供应商审核由采购部单独负责 |
| 时间 | 2024年Q1起，按月评价 | 2023年及之前的历史数据 | 历史数据仅用于基线对比 |
一个小技巧：范围界定完成后，一定要让所有利益相关者签字确认。别嫌麻烦，这步省了，后面扯皮的成本更高。我习惯在需求文档里专门加一页「范围确认页」，让关键角色手写签名。
4.4 需求文档编写——把「共识」变成「证据」
需求文档，是需求分析阶段的最终交付物。它不只是一份记录，更是后续设计、开发、验收的唯一依据。
我写需求文档有个「三三制」原则：
- 三成篇幅写背景和目标：让任何一个新加入项目的人，看完前三页就知道「为什么要做这个评价体系」。
- 三成篇幅写范围和约束：明确边界、假设条件、已知限制。比如「本体系不覆盖海外工厂」「数据源依赖ERP系统，延迟不超过24小时」。
- 四成篇幅写详细需求：包括功能需求（系统要做什么）、非功能需求（性能、安全、可用性）、数据需求（数据来源、格式、更新频率）。
下面是一个简化的需求文档模板：
# 评价体系需求文档 v1.0
## 1. 项目背景
- 当前产线质量数据分散在3个系统中，无法统一评价
- 管理层需要每月一份「产线健康度」综合报告
## 2. 评价目标
- 目标1：实现产线质量数据的自动采集与聚合
- 目标2：按月生成产线健康度评分（0-100分）
- 目标3：支持钻取分析，定位低分产线的具体问题
## 3. 评价范围
- 组织：A厂区、B厂区所有产线（共12条）
- 业务：从投料到成品入库的全流程
- 时间：2024年4月起，每月5日前生成上月评价结果
## 4. 关键需求
- 4.1 数据接入：支持从MES、QMS、WMS系统自动拉取数据
- 4.2 指标计算：按预设权重加权计算，支持权重调整
- 4.3 可视化：仪表盘展示总分、分项得分、趋势图
- 4.4 权限管理：不同角色看到不同层级的数据
## 5. 约束条件
- 数据延迟不超过24小时
- 系统响应时间 < 3秒（查询场景）
- 支持并发用户数 > 50人
注意：需求文档不是写完了就完事了。我建议至少组织两轮评审：第一轮跟技术团队过可行性，第二轮跟业务团队过准确性。评审通过后，文档要版本化管理，任何变更都要走变更流程。
4.5 本章知识体系总览
下面这张图，把需求分析的四个核心步骤串起来了。你可以把它当作一个检查清单，做项目时对照着来：
好了，需求分析这部分就讲到这里。记住一句话：需求分析不是写文档，而是达成共识的过程。文档只是共识的载体。下一章咱们聊聊指标体系设计，那才是真正开始「搭骨架」的时候。
公众号:蓝海资料掘金营，微信deep3321