REQ-QPP-01 · 质量与项目计划（QPP）获批——建立生命周期治理框架

已满足 GAMP5 项目全流程

需求概述首次提出 2026-02-20 · 更新 2026-02-20（v1 已批准）

定义项目生命周期模型（URS→FS→CS/DS→FAT→SAT→IQ/OQ）与四项质量流程（变更控制/文档管理/配置管理/风险评估）各自的 SOP 归口，是整个治理框架的总纲——后续每一份治理类文件都从这里派生立项。

全流程依赖关系有的存在先后——这里是"彼此咬合"的地方

← 前置（本条依赖谁先完成）

REQ-URS-01 用户需求规范（URS）获批——全流程的源头

本条解锁了谁 →

REQ-DM-01 文档管理规范（DM SOP）——版本控制与文档编号规则 REQ-CM-01 配置管理规范（CM SOP）——软硬件基线记录机制 REQ-CC-01 变更控制规范（CC SOP）——约束 FAT 至 OQ 阶段的一切变更

验收标准 URS 式 · 可测量 · 挂证据文件，不是全绿

合格生命周期模型（URS→FS→CS/DS→FAT→SAT→IQ/OQ支持）在 QPP 中明确定义 QPP 双方评审签署 · PHM-QPP-EMS-001 · 2026-02-20

合格质量流程（变更控制/文档管理/配置管理/风险评估）SOP 归口全部列明责任文件编号 QPP 双方评审签署 · PHM-QPP-EMS-001 · 2026-02-20

变更 / 偏差记录（1 条 · 0 条未闭环）

现场每发生一次变更或偏差，就在这里追加一条——需求台账靠这条流持续生长

PCR-2026-04 变更请求 PCR 已闭环 2026-02-18 · 王磊

QPP 生命周期图新增 IQ/OQ 阶段负责人分工细化

双方评审时发现 QPP 生命周期图对 IQ/OQ 阶段的责任划分（谁准备协议/谁执行/谁批准）不够细，要求补充分工表。

纠正措施：在 QPP 生命周期章节补充 IQ/OQ 阶段责任分工表，随 v1 一并批准发布。

影响文件 PHM-QPP-EMS-001

受控文件register （1 份）

版本升级必须挂一条变更/偏差编号，不能凭空跳版

文件编号	类型	版本	状态	生效日期	起草 / 审批	触发变更
PHM-QPP-EMS-001	QPP 质量与项目计划	v1	已批准	2026-02-20	李强 / 王磊	—

代际时间轴

设备会死，需求不死——每一代是需求当前的一次物理实现

本次实施 2026 年 v1 已批准

关联工单（0 张）

查看全部工单 →

暂无关联工单。

下一代触发条件环的闭环点：报废决策喂回下一代需求

↻ 文档管理/配置管理/变更控制三份 SOP 依据本计划分别立项

真实交互 · 仅写入本次浏览会话，不接入后端

需求台账是"环的顶层锚点"——当前 asset-archive 的 record.schema.json 还没有"需求""文件""变更"实体，本页是概念层管理界面，不改变真实数据模型。文件register/变更事件流的字段设计参照真实制药工厂 BMS 项目文件体系（URS/HDS/SDS/FAT/SAT/偏差/变更请求）。要把需求实体化，需要另立 schema 设计（跨项目核心引擎变更），另行决策。下面四个按钮是真实可交互的表单——填了会立刻出现在页面上，但只存在于这次浏览会话里（刷新即重置）：这是公开零登录墙站点，真的接一个能持久化的后端意味着任何人都能篡改演示数据，所以刻意不做持久化，不是没做完。