| | |
| | | 事项来源 / 聊天要求 / 上游文档 |
| | | -> 写入项目事项总纲,说明背景、目标、边界、当前状态 |
| | | -> 拆分到项目事项计划,明确负责人、步骤、输入、输出、验收方式 |
| | | -> 项目事项计划审计,检查计划是否合理、是否对齐来源聊天和项目目标 |
| | | -> 判断事项风险与复杂度 |
| | | -> 普通、可逆、项目内事项直接执行;实质高风险或复杂事项才做计划审计 |
| | | -> 执行事项 |
| | | -> 在项目执行日志记录关键节点、关键输入、关键输出、偏离和当前状态 |
| | | -> 必要时写项目变更记录 |
| | | -> 项目事项执行审计,检查执行是否按计划完成、证据链是否闭合 |
| | | -> 普通事项由请求者或安排者验收;实质阶段门才做独立执行审计 |
| | | -> 如审计发现问题,主记录写项目事项审计报告;如非审计人员发现问题,主记录写项目问题记录 |
| | | -> 修复后复审 |
| | | -> 同一轮问题一次给全,合并修复后做一次必要复审 |
| | | -> 结论回写到项目事项总纲和项目事项计划 |
| | | -> 事项完成 / 暂停 / 取消 |
| | | ``` |
| | |
| | | |
| | | 1. 项目事项开始前,必须能在项目事项总纲中找到背景、目标和关键来源聊天记录或上游路径。 |
| | | 2. 项目事项执行前,必须能在项目事项计划中找到拆分步骤、输入输出、验收方式和来源聊天记录。 |
| | | 3. 项目事项计划必须先审计,审核员要判断计划是否合理,是否能满足事项目标,是否和来源聊天记录一致;计划审计未通过,不得进入执行。 |
| | | 3. 普通、可逆、项目内 L0/L1 事项不要求实施前独立计划审计;涉及权限扩张、不可逆外部写入、凭据、破坏性数据操作、正式发布、跨项目/跨控制面或重大结论的事项,才要求在执行前通过相应独立审核。 |
| | | 4. 项目事项执行中,关键节点必须写入项目执行日志。 |
| | | 5. 项目事项结束前,必须做执行审计;执行审计未通过,不得标记完成。 |
| | | 5. 普通事项完成后由请求者或安排者做功能/结果验收即可;需要独立审核的事项,审核应集中在实质阶段门,不做逐动作、逐文件或逐尝试复核。 |
| | | 6. 如果事项改变了项目目标、边界、角色、目录、体系启用状态或关键规范,必须同时进入项目变更流程。 |
| | | 7. 同一已登记事项内的普通修复和重跑不要求新建逐次 A001;确需授权时,优先使用项目级事项、时间窗或阶段范围合同。 |
| | | |
| | | ### 3.3 项目变更流程 |
| | | |
| | |
| | | |
| | | 审核员不得把不影响事项目标、结论、关键证据链或下游使用的边角料问题升级为阻断问题;不得通过拆分步骤审计的方式层层加码。 |
| | | |
| | | 审核员应在一轮中返回完整的实质问题集合。除非修订引入新的实质风险,不得围绕同一边界连续制造单点 supplemental 审核、权限存在性审核或逐尝试审核。 |
| | | |
| | | 在不同体系中,事项单元对应如下: |
| | | |
| | | | 体系 | 审核事项单元 | |
| | |
| | | | 实验体系 | `实验总纲.md` 中的一个实验目标或实验事项 | |
| | | | 案例分析体系 | `案例总纲.md` 中的一个案例目标或案例事项 | |
| | | | 数据体系 | 数据体系总纲或数据事项账本中的一个数据目标或数据事项 | |
| | | | 运维体系 | `运维事项总纲.md` 中的一个运维事项或一次事故处置 | |
| | | |
| | | ### 7.2 项目级审计边界 |
| | | |