4. 建设工程启动与需求调研

产品数据管理（PDM/PLM）建设工程的失败，很少败在软件功能上，绝大多数败在启动阶段：痛点没找准、需求没写清、验收标准没定义、干系人没拉齐。本节把工程启动与需求调研拆成四件必须交付的事——痛点清单、需求规格说明书、验收标准、干系人矩阵，并给出可直接套用的做法与示例。

一、先识别痛点：从“现象”追到“根因”

痛点调研最忌讳收集一堆“希望系统能……”。正确做法是从业务现象出发，沿数据流追根因。以某装备制造企业为例，调研中记录到的现象是：同一型号的BOM在ERP、车间、售后三处数量不一致，工程变更平均要7天才能传到采购。继续追问会发现根因不是“没有系统”，而是：图纸版本靠文件名区分（如_v2_final_改），BOM在Excel中人工维护且无唯一数据源，变更单走邮件审批无状态跟踪。

建议按“现象—影响—根因—可量化指标”四列记录，形成痛点清单。判断一个痛点是否值得纳入工程范围，看三条：是否可量化（如变更传递周期、BOM准确率）、是否跨部门（单部门问题优先用管理手段解决）、是否与产品数据直接相关。

二、需求规格说明书：把痛点翻译成可验证的需求

需求规格说明书（SRS）不是功能罗列，而是“业务需求—功能需求—非功能需求—约束”的逐层分解。每条需求必须可追溯到至少一个痛点，并具备唯一编号，便于后续验收对照。

以“变更传递慢”这一痛点为例，其需求分解如下：业务需求 BR-01 为“工程变更在24小时内同步至采购与车间”；功能需求 FR-01-01 为“变更单审批通过后自动触发BOM版本升版并推送通知”；非功能需求 NFR-01 为“通知到达时间≤5分钟，支持≥200并发用户”；约束为“必须与现有ERP通过中间表对接，不改造ERP”。

编写时注意三点：一是需求要写“系统应……”，避免“最好能……”；二是每条需求标注优先级（必须/应该/可选），防止范围蔓延；三是明确排除项，例如“本期不包含工艺路线管理”，排除项写清楚比写清楚包含项更能控制预期。

三、验收标准：从“做完了”到“做对了”

验收标准必须与需求编号一一对应，且可测量。推荐采用“给定条件—执行操作—预期结果”的格式。例如对应 FR-01-01 的验收用例：给定一个已审批的变更单，执行“发布变更”操作，预期结果为BOM版本号自动加1、采购与车间用户在5分钟内收到通知、ERP中间表在10分钟内出现新版本记录。

验收标准要区分功能验收与数据验收。功能验收看流程是否走通；数据验收看迁移后的数据是否准确，例如“历史10万条物料主数据迁移后，必填字段完整率≥99.5%，与源系统抽样比对一致率100%”。没有数据验收标准，系统上线后往往出现“功能都能点，数据不能用”的尴尬。

四、关键干系人：谁拍板、谁使用、谁受阻

用“权力—利益”矩阵识别干系人：高权力高利益者（如研发副总、项目经理）必须深度参与并担任决策角色；高权力低利益者（如财务负责人）需保持知情、定期汇报；低权力高利益者（如一线设计员、采购员）是需求的主要来源和验收的最终裁判；低权力低利益者做常规通知即可。

每个关键干系人要明确三件事：在工程中的角色（发起人/决策者/需求提供者/验收人/使用者）、参与节点（启动会、需求评审、UAT测试、上线）、以及期望管理方式。特别要识别“隐性反对者”——往往是因数据透明化而利益受损的岗位，需在启动阶段就通过沟通或流程调整化解。

五、可直接使用的需求规格说明书片段示例

下面给出一份精简但结构完整的SRS片段，字段可直接扩展为正式文档。注意每条需求都带编号、优先级、来源痛点与验收方式。

需求编号：FR-01-01
需求名称：变更审批通过后自动升版并推送
业务需求：BR-01 工程变更24小时内同步至采购与车间
来源痛点：PAIN-01 BOM三处不一致、变更传递7天
优先级：必须
需求描述：系统应在变更单审批通过后，自动将受影响BOM版本号加1，
          并向采购、车间角色推送站内通知与邮件。
非功能要求：通知到达≤5分钟；支持≥200并发；与ERP通过中间表对接。
验收方式：给定已审批变更单，执行发布，检查版本号、通知时间、ERP中间表记录。
排除项：本期不包含工艺路线变更。

六、启动阶段的三个常见陷阱

• 把“上线”当“验收”：上线只是系统可用，验收要看业务指标是否改善，如变更周期是否真的降到24小时内。
• 需求只由IT编写：IT写出的需求往往偏向技术实现，缺少业务场景，必须由业务方确认签字。
• 干系人只列不管：矩阵列出来却不安排参与节点，等于没识别。每个关键角色都要有明确的评审、测试或签字任务。

完成本节四项交付物后，工程才算真正“启动”：痛点有据可查、需求有号可追、验收有例可测、干系人有责可担。这四份材料将贯穿后续的方案设计、系统配置与上线验收，是整项建设工程的基准线。