需求详情
← 返回
演示
← 返回需求台账

REQ-CC-01 · 变更控制规范(CC SOP)——约束 FAT 至 OQ 阶段的一切变更

监测中 GAMP5 项目全流程
需求概述 首次提出 2026-03-15 · 更新 2026-03-15(SOP v1 已批准,生效窗口未打开)

定义 CR(变更请求)→CREI(请求/执行总索引台账)→CER(执行记录+证据)三表联动的变更控制流程,区分参数变更(简化流程)与非参数变更(完整流程)。SOP 本身在项目早期建立,但实际生效窗口从 FAT 阶段开始,到 OQ 报告签署后结束——建立时间和生效时间是两回事,这个错位本身就是"先后咬合"的一个例子。

全流程依赖关系 有的存在先后——这里是"彼此咬合"的地方
本条解锁了谁 →

无下游需求依赖本条——目前是全流程的终点。

验收标准 URS 式 · 可测量 · 挂证据文件,不是全绿
合格 CR/CREI/CER 三张表单与工作流在 SOP 中定义完整 CC SOP 内部评审 · PHM-CC-EMS-001 · 2026-03-15
待验证 变更控制生效窗口(FAT 开始至 OQ 报告签署结束)触发条件明确 项目里程碑对照 · — · —(FAT 尚未开始,窗口未打开)

变更 / 偏差记录 (0 条 · 0 条未闭环)

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

暂无变更/偏差记录。

受控文件register (1 份)

版本升级必须挂一条变更/偏差编号,不能凭空跳版
文件编号 类型 版本 状态 生效日期 起草 / 审批 触发变更
PHM-CC-EMS-001 CC 变更控制 v1 已批准 2026-03-15 李强 / 王磊

代际时间轴

设备会死,需求不死——每一代是需求当前的一次物理实现
  1. 本次实施 2026 年 SOP 已批准,等待 FAT 触发生效窗口

关联工单 (0 张)

查看全部工单 →

暂无关联工单。

下一代触发条件 环的闭环点:报废决策喂回下一代需求
↻ FAT 启动后变更控制窗口正式生效,直至 OQ 报告签署关闭
真实交互 · 仅写入本次浏览会话,不接入后端

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