S1000D 项目角色与工作流怎么设计？权限、审核和审计追溯
S1000D 项目不只是编写数据模块，还要让创作、技术审核、质量批准、配置控制和发布动作在同一条可追溯链路上协作。清晰的角色边界、状态流转、签入签出和最小权限，能减少未经审核的内容进入交付物，也便于定位每次变更的责任和证据。
项目需要哪些角色？
角色是职责集合，不一定对应固定人数。小型项目可以由一个人承担多个角色，但应在高风险内容和正式发布环节安排独立复核。下面是常见分工示例，实际名称、权限和替代关系应以项目计划和质量体系为准。
| 角色 | 主要职责 | 关键输出或决定 | 不应默认承担的职责 |
|---|---|---|---|
| 项目/内容负责人 | 定义范围、读者、交付物、计划和资源，协调问题关闭。 | 项目基线、范围变更、里程碑和发布决策。 | 不应绕过技术/质量审核直接批准高风险内容。 |
| 数据模块作者 | 编写、更新和自检 DM、媒体说明、引用及适用性信息。 | 草稿、修订说明、自检记录和待审核提交。 | 不应将未经批准的草稿直接放入正式交付基线。 |
| 技术审核人 | 检查技术准确性、步骤可执行性、工具/材料、安全信息和配置适用性。 | 审查意见、问题关闭结论和技术批准。 | 不应只检查 XML 结构而跳过现场或专业内容。 |
| 语言/编辑审核人 | 检查术语、语言一致性、可读性、图文关系和翻译对照。 | 语言审校、术语确认和翻译问题清单。 | 不应替代专业责任人判断设备操作安全性。 |
| 质量/合规负责人 | 监督流程执行、独立抽检、问题升级、豁免和证据完整性。 | 质量批准、豁免记录、审计结论和改进要求。 | 不应在没有可追溯证据时仅凭口头确认放行。 |
| 配置管理员 | 维护版本、状态、基线、关系、权限和发布清单。 | 配置基线、变更记录、版本矩阵和回退包。 | 不应擅自改变技术内容或审批结论。 |
| 发布/部署负责人 | 生成 PDF、IETP 或交付包，在目标环境验证并归档。 | 候选输出、日志、哈希、部署记录和发布包。 | 不应用未批准的源数据或临时配置生成正式包。 |
| 系统管理员 | 管理账号、权限、备份、运行环境、日志和可用性。 | 账号/权限记录、备份恢复、系统变更和安全事件记录。 | 不应以管理员身份代替业务审批或修改内容。 |
角色可以由项目合并，但“创作与批准”“配置控制与内容修改”“发布与质量放行”之间的职责分离应按风险保留。兼任时要记录补偿检查和批准理由。
状态流转怎么设计？
状态用于约束对象当前可以做什么。项目可以采用不同名称，但每个状态都应有入口条件、允许操作、责任人、退出条件和回退路径。以下流程是可配置的示例：
| 状态 | 进入条件 | 允许操作 | 离开条件 |
|---|---|---|---|
| 新建/草稿 | 对象建立或提出修订需求。 | 作者编辑正文、媒体、引用和适用性草稿。 | 自检完成，提交待审核或退回删除。 |
| 待技术审核 | 内容完成自检，作者提交版本和说明。 | 审核人批注、提出问题；作者按项目规则修改。 | 问题关闭并通过技术审核，或退回草稿。 |
| 待质量/语言审核 | 技术内容通过，语言和证据准备齐全。 | 质量/语言角色抽检、核对流程和记录。 | 完成批准，或记录问题并退回相应环节。 |
| 已批准/可引用 | 规定的审核和批准完成。 | 被出版物和交付候选基线引用；原则上冻结正文。 | 进入发布基线、产生新修订或因问题撤回。 |
| 已发布 | 输出、目标环境和发布记录通过验收。 | 只读使用；变更通过新版本或受控更正。 | 被新发布替换、撤回或废止。 |
| 废止/撤回 | 对象被替代、过期或发现不能继续交付。 | 只读查询和审计；保留替代关系和原因。 | 项目批准恢复或永久归档。 |
“待审核”不是一个万能状态。大型项目可以拆分技术、语言、适用性、安全和质量审核，但要避免状态过多导致责任不清；每个状态都应映射到明确的角色和通知。
签入签出如何协作？
签出（check-out）通常表示某个用户取得受控编辑权，签入（check-in）则提交本次修改、版本说明和验证结果，解除编辑锁或进入下一状态。具体行为取决于 CSDB 或协同工具；项目要把工具规则写进工作指引，避免用户凭经验操作。
| 环节 | 建议控制 | 需要留下的记录 |
|---|---|---|
| 签出前 | 确认对象状态、当前版本、是否已有锁、变更原因和预期影响。 | 签出人、时间、对象版本、变更单或任务号。 |
| 编辑中 | 使用工作副本或锁定机制；不直接覆盖已批准基线；定期保存。 | 操作日志、草稿版本、附件和中间验证结果。 |
| 签入前 | 完成自检、引用/媒体检查、变更说明和影响范围确认。 | 修订说明、自检清单、问题关联和目标状态。 |
| 签入后 | 由审核角色接收通知；异常签入进入待处理队列，不能静默覆盖。 | 签入版本、工具配置、时间、提交人和校验结果。 |
| 异常处理 | 处理超时锁、人员离岗、冲突合并、误签入和回退。 | 解锁/回退授权、冲突决议、恢复版本和复核证据。 |
如果工具不支持真正的签入签出，也应通过只读基线、任务分配、版本分支或人工锁定建立等效控制，并明确谁有权合并和发布。
权限怎么配置？
权限配置遵循最小授权和职责分离：用户只获得完成任务所需的对象、操作和状态权限；管理员权限用于系统维护，不自动等于内容批准权。
| 权限维度 | 示例 | 配置建议 |
|---|---|---|
| 对象范围 | 项目、产品线、语言、数据模块类型、媒体库、出版物或交付基线。 | 按项目和任务授予，避免所有人可见/可改全部客户数据。 |
| 操作类型 | 查看、编辑、签出、签入、审核、批准、发布、撤回、导出。 | 拆开高风险操作，尤其是批准、发布、批量导出和删除。 |
| 状态转换 | 草稿→审核、审核→批准、批准→发布、发布→撤回。 | 每条转换指定角色、前置检查和回退条件。 |
| 环境权限 | 开发库、审核库、发布库、现场阅读器和备份介质。 | 分离开发/发布环境，限制直接登录生产或现场目录。 |
| 临时授权 | 外部专家、代班人员、紧急修复和问题排查。 | 设置期限、范围、审批人，结束后回收并审查操作日志。 |
如何审计追溯？
审计追溯应连接“对象—版本—人员—操作—状态—证据—交付物”。日志不应只记录登录成功，还要能够解释某个发布包由哪些源对象生成、谁在什么时间批准、使用了什么工具和配置。
| 追溯链 | 至少回答的问题 | 建议证据 |
|---|---|---|
| 对象追溯 | 交付包中的内容来自哪个 DM/PM/媒体版本？ | 对象清单、引用关系、版本与哈希。 |
| 人员追溯 | 谁创建、修改、审核、批准和发布了对象？ | 账号、角色、时间、操作日志和批准记录。 |
| 决策追溯 | 为什么改？影响什么？谁批准了豁免或紧急流程？ | 变更单、影响分析、问题单和评审意见。 |
| 工具追溯 | 用什么 Schema、规则、编辑器、转换器和配置生成？ | 版本矩阵、运行参数、转换/校验日志。 |
| 交付追溯 | 何时、向谁、以什么格式交付，如何回退？ | 发布清单、哈希、接收记录、旧包位置和恢复演练。 |
日志本身也应受到访问控制和备份保护。对于包含客户、设备或敏感项目的信息，项目应按合同和组织要求定义查看范围、保留期限、脱敏和删除规则。
角色与工作流验收检查
- 角色矩阵已批准，明确作者、技术审核、质量、配置、发布和管理员的职责边界。
- 每个状态有进入/退出条件、允许操作、通知对象、回退路径和责任人。
- 签入签出、并发编辑、超时锁、冲突合并和异常解锁有可执行的处理规则。
- 批准与发布权限已和普通编辑分离；临时授权有期限、范围和回收记录。
- 代表性对象完成从创作到发布的演练，所有状态变化和审批意见均可查询。
- 变更影响分析能找到直接/间接引用、适用性、媒体和交付物，并触发相应回归。
- 发布包可追溯到源基线、工具配置、校验报告、哈希和批准记录，回退步骤可验证。
常见工作流风险
- 所有人都使用管理员账号，导致无法判断实际操作者和审批责任。
- 作者可以直接把草稿状态改成已发布，审核记录只存在聊天或邮件中。
- 签出后长期不签入，没有超时、交接或异常解锁机制。
- 审核只检查格式和拼写，没有验证步骤可执行性、适用性和安全信息。
- 发布人员使用本机临时模板或未记录的工具补丁，导致结果无法重现。
- 撤回或紧急修复直接覆盖线上包，没有通知、回退和事后复盘。
常见问题
S1000D 是否规定了所有项目必须使用同一套角色名称？
不一定。项目通常需要根据合同、质量体系和工具能力配置角色名称与职责，但应明确谁负责创作、技术审核、质量批准、配置控制、发布和系统管理，并定义职责分离与替代安排。
签出数据模块后其他人还能修改吗？
签出行为和并发编辑规则取决于 CSDB 或协同工具。常见做法是由签出者获得受控编辑权，其他人只读或提出变更请求；项目应明确锁定、超时、交接和异常解锁规则。
作者和审核人可以是同一个人吗？
是否允许由项目质量要求和风险等级决定。涉及安全、关键维护步骤或正式发布时，通常应设置独立复核；若资源有限需要兼任，应记录理由、补偿检查和批准人。
审计追溯至少要记录什么？
至少记录对象和版本、操作人、时间、状态变化、变更原因、审批意见、工具/配置、校验与回归结果、发布编号以及回退位置。具体保留期限和字段按项目及组织要求确定。
系统管理员可以批准内容发布吗？
系统管理员可以维护账号、权限、备份和运行环境，但不应因为拥有技术管理员权限就自动获得业务批准权。发布批准应由项目定义的内容、技术或质量责任人完成，并留下独立记录。