工单系统评估清单要长期可用，需要把它当作一份有版本、有负责人、有触发条件的活文档来管理。做法是：先固定评估维度与字段结构，再明确谁在什么时点提出变更、谁评审、谁发布，最后用季度例行复核加事件触发的方式检查条目是否仍然有效，并保留变更记录与评审证据。这样每次选型或复评都能追溯到清单的当次版本，而不是沿用一份来源不明的旧表格。
要点总览（TL;DR）
- 先把清单结构固定下来：按平台能力、集成、权限与安全、运维与服务、成本与合同分层，每条包含编号、判定标准、证据要求、权重、状态和最后核实日期，后续更新才有稳定的挂载点。
- 更新机制要同时写清触发条件和角色分工：产品版本变化、业务场景新增、合规要求变化、上轮遗留问题、合同变化都可触发变更，由清单负责人统筹、维度负责人修订、评审人把关、审批人确认生效。
- 一次完整变更走六步：登记变更请求、评估影响范围、修订条目与判定标准、评审与审批、发布版本并通知、归档旧版本与证据，每步都有明确输出物。
- 例行复核建议按季度进行，事件触发随时发起；选型频次低的团队可把例行复核调整为半年一次，事件触发机制始终保留。
- 用结构、机制、记录、时效四类检查项自查；无负责人、无版本记录、条目含不可核实断言属于阻断项，出现即暂停用该清单开展新评估。
清单先定结构：维度、条目与字段怎么设
更新维护能否顺利进行，取决于清单有没有稳定的挂载点。结构一旦固定，后续新增条目、废止条目、调整判定标准都能落到具体位置，不会因为每次改法不同而失去可比性。建议把清单分成维度层、条目层和字段层三级，维度层保持相对稳定，条目层允许增删，字段层统一格式。
评估维度分层
工单系统的评估维度可以按以下五类组织，每类下设若干条目。维度划分不必追求齐全，但同一份清单内应保持层级一致，便于按维度分配负责人。
| 维度 | 关注内容 | 典型条目方向 |
|---|---|---|
| 平台能力 | 工单创建、流转、分派、状态管理、自定义字段与流程 | 是否支持按业务类型配置不同处理流程 |
| 集成 | 与项目管理、知识库、消息通知、身份系统的对接 | 工单能否关联到需求或缺陷并持续跟踪 |
| 权限与安全 | 角色权限、数据可见范围、操作审计 | 能否按组织或项目隔离工单数据 |
| 运维与服务 | 部署方式、可用性、供应商支持响应 | 故障响应时限与支持渠道是否写入合同 |
| 成本与合同 | 许可方式、扩容成本、合同期限与退出条件 | 用户数增长后的计价规则是否明确 |
每个条目的字段定义
条目字段决定了清单能否被核验和追溯。建议每条至少包含以下字段，字段名和取值规则在清单首页写明，避免不同人填写口径不一。
| 字段 | 作用 | 填写要求 |
|---|---|---|
| 编号 | 唯一标识条目，供变更单和评估记录引用 | 维度缩写加序号，如CAP-01，废止后编号不复用 |
| 维度 | 归属哪一类评估维度 | 从固定维度表中选取 |
| 评估问题 | 要回答的具体问题 | 一句话，指向可观察的对象 |
| 判定标准 | 什么情况算满足、部分满足或不满足 | 给出可判定的条件，避免“较好”“较强” |
| 证据要求 | 用什么材料证明结论 | 如产品演示记录、配置截图、合同条款、测试结果 |
| 权重 | 该条目在维度内的相对重要性 | 统一采用同一量纲，如1至5分 |
| 状态 | 条目当前是否有效 | 有效、待核实、已废止 |
| 最后核实日期 | 判断条目是否过期 | 填写实际核实当天日期 |
| 来源 | 结论依据出处 | 注明资料类型与获取时间，便于复评时复核 |
条目写法要求
条目要能被不同评估人得出相近结论。写法上把握三点：一是问题指向具体功能或条款，例如“是否支持按工单类型配置独立审批节点”，而不是“流程是否灵活”；二是判定标准给出分级条件，例如“满足：可配置且无需开发；部分满足：需脚本实现；不满足：无法实现”；三是证据要求写明可提交的材料形式，避免评审时对“有没有证据”产生分歧。
版本号与变更记录的位置
清单首页固定放置版本信息区，包含版本号、生效日期、编制人、审批人和变更摘要。版本号建议采用主版本加次版本的形式，结构性调整升主版本，条目文字修订升次版本。变更记录以表格形式附在清单末尾或独立成页，逐条记录变更单编号、涉及条目、变更类型、提出人、审批人和生效日期，与版本信息区互相引用。
更新机制：谁在什么时点改清单
清单失修通常源于两个原因：没人负责，或者没人知道什么时候该改。更新机制要同时回答责任归属和触发条件，并把例行复核与事件触发配合使用。
触发条件
| 触发类型 | 具体情形 | 处理方式 |
|---|---|---|
| 产品版本变化 | 候选或在用工单系统发布新版本，功能范围、界面或接口发生变化 | 核对受影响条目，更新判定标准与证据要求 |
| 业务场景新增 | 新增服务台业务、跨部门协作流程或新的工单类型 | 评估是否需要新增维度或条目 |
| 合规或安全要求变化 | 数据留存、审计、权限管理出现新的内部或外部要求 | 补充条目并提高相关权重 |
| 上轮评估遗留问题 | 上次选型中出现的争议条目、证据不足条目 | 在例行复核中优先修订 |
| 供应商合同变化 | 计价方式、服务级别、续约条件调整 | 更新成本与合同维度条目 |
角色分工
| 角色 | 职责 | 交付物 |
|---|---|---|
| 清单负责人 | 统筹清单整体结构、版本发布与变更记录归档 | 发布版本、变更台账 |
| 维度负责人 | 负责某一维度条目的日常维护与初步修订 | 维度修订稿、核实记录 |
| 评审人 | 检查条目可验证性、判定标准是否清晰、是否引入不可核实断言 | 评审意见 |
| 审批人 | 确认变更影响范围与生效时间，批准发布 | 审批结论 |
角色可以兼任，但清单负责人和审批人不宜由同一人长期担任，以免变更缺少独立把关。团队规模较小时，维度负责人可由清单负责人兼任，评审环节保留一人交叉检查即可。
例行节奏与事件触发的配合
例行复核建议按季度进行，固定检查条目最后核实日期、证据是否仍可获取、判定标准是否仍适用。事件触发则在上述情形出现时随时发起，不受季度节奏限制。两者配合的方式是：事件触发的变更走完整流程并即时发布；季度复核集中处理积压的小修订，并对全量条目做一次时效检查。选型频次低的团队可以把例行复核调整为半年一次，但事件触发机制应始终保留。
维护操作步骤：从提出变更到发布新版本
以下六步构成一次完整的清单变更闭环，每步都应有明确的输入和输出，便于交接和追溯。
步骤一：登记变更请求
输入是触发来源，可能是版本更新通知、业务部门提出的新场景、合规检查意见或上轮评估记录。动作是把变更写成变更单，写明触发原因、涉及条目编号、期望修改内容和提出人。输出是一张带编号的变更单，进入待评估状态。完成标志是变更单信息足以让未参与提出的人理解改什么、为什么改。
步骤二：评估影响范围
输入是变更单。动作是由清单负责人会同相关维度负责人判断：涉及哪些维度和条目，是否影响权重设置，历史评估结论是否会因此失效，是否需要通知正在使用该清单的评估项目。输出是影响评估结论，附在变更单上。完成标志是明确列出受影响条目清单和处理建议。
步骤三：修订条目与判定标准
输入是影响评估结论。动作是维度负责人修改条目文字、判定标准或证据要求；对需要删除的条目保留原编号并标记为已废止，注明废止原因和替代条目编号，不直接删除行。输出是修订稿。完成标志是修订后的条目符合可验证、可判定的要求，且新旧条目对应关系清晰。
步骤四：评审与审批
输入是修订稿和变更单。动作是评审人逐条检查：评估问题是否指向可观察对象，判定标准能否让不同人得出相近结论，证据要求是否可实际获取，是否出现无法核实的断言。评审通过后由审批人确认生效日期。输出是评审意见和审批结论。完成标志是评审意见中的问题已闭环，审批人签字或确认记录留存。
步骤五：发布版本并通知
输入是审批通过的修订稿。动作是更新版本号和生效日期，在变更记录中登记本次变更，向清单使用方发出通知，说明改了哪些条目、对正在进行的评估有何影响。输出是新版本清单和发布通知。完成标志是使用方确认收到，且新版本在约定位置可获取。
步骤六：归档旧版本与证据
输入是上一版本清单及本次变更单、评审意见、审批记录。动作是按版本号归档，保留只读副本，确保历史评估项目能查到当时使用的版本。输出是归档目录和索引。完成标志是任意一次历史评估都能对应到具体版本和支撑证据。
示例：一次季度复核如何改动清单
以下为演示情景，用于说明变更单和条目修订的填写方式，不涉及具体产品结论。
情景设定
某团队在季度例行复核中发现，“平台能力”维度下关于工单流程配置的条目判定标准过宽。原条目写的是“系统是否支持灵活配置工单流程”，评估人各自理解不同，上一轮选型中有两个候选产品因此得到相反结论。
变更单内容与影响评估
| 项目 | 内容 |
|---|---|
| 变更单编号 | CR-2024-Q3-02 |
| 触发来源 | 季度例行复核，上轮评估争议条目 |
| 涉及条目 | CAP-03 工单流程配置 |
| 变更原因 | 判定标准笼统，评估结论不可比 |
| 影响评估 | 仅影响该条目判定标准与证据要求，权重不变；上轮两个候选产品的流程配置结论需按新标准重新核实 |
| 提出人 | 平台能力维度负责人 |
修订前后对比
| 项目 | 修订前 | 修订后 |
|---|---|---|
| 评估问题 | 系统是否支持灵活配置工单流程 | 系统能否在不编写代码的情况下，为不同工单类型配置独立的处理节点与流转条件 |
| 判定标准 | 灵活、可调整 | 满足：可通过界面为至少三类工单分别配置节点与条件；部分满足：需脚本或供应商协助配置；不满足：所有工单共用同一流程 |
| 证据要求 | 产品介绍 | 配置界面演示记录或测试环境操作截图，注明配置的工单类型数量 |
评审记录与版本发布
评审人确认修订后条目指向具体操作对象，判定标准可分级判定，证据要求可实际获取，未引入不可核实断言。审批人确认生效日期为下一评估周期开始日，版本号由1.3升为1.4，变更记录登记CR-2024-Q3-02。发布通知说明：CAP-03判定标准已更新，正在进行的评估项目需按新标准补充证据，已完成评估的项目保留原结论并标注所用版本。
对在用评估项目的处理
对尚未完成评估的项目，要求按新标准重新核实CAP-03并补充证据；对已完成评估的项目，不追溯修改结论，但在评估报告中注明所用清单版本，供后续复评时对照。这样既保证新评估口径一致，也保留历史结论的可追溯性。
当清单的变更单、评审意见和版本记录需要多人协作维护时，可以把变更单作为工作项管理，把清单正文和评审记录放在文档中，通过状态流转标记提出、评审、发布各阶段。ONES Desk 支持自定义工单属性与工作流调整，工单可一键关联到 ONES Project 的需求或缺陷工作项持续跟踪，也可关联 ONES Wiki 页面沉淀处理经验；这类关联方式可用于承载清单变更请求与评审记录的流转，具体配置范围以实际产品为准。
完成检查：清单是否处于可维护状态
以下自查表用于判断维护机制是否真正成立，建议在每次版本发布后和季度复核时各执行一次。
| 检查类别 | 检查项 | 通过标准 |
|---|---|---|
| 结构 | 字段齐全 | 每个条目均包含编号、维度、评估问题、判定标准、证据要求、权重、状态、最后核实日期、来源 |
| 结构 | 条目可判定 | 抽查条目能让两名评估人得出相近结论 |
| 结构 | 编号唯一 | 无重复编号，废止条目保留原编号并标记 |
| 机制 | 负责人明确 | 清单负责人和各维度负责人已指定并在清单中注明 |
| 机制 | 触发条件写明 | 五类触发情形均有对应处理方式 |
| 机制 | 评审路径可执行 | 评审人和审批人明确，评审要点已写入流程说明 |
| 记录 | 版本历史完整 | 每个版本有版本号、生效日期和变更摘要 |
| 记录 | 变更单可追溯 | 每条变更能对应变更单、评审意见和审批记录 |
| 记录 | 旧版本可查 | 历史版本以只读方式归档，可按版本号检索 |
| 时效 | 核实日期在周期内 | 条目最后核实日期未超过约定的复核周期 |
以下情形应作为阻断项处理，出现任一项即暂停使用该清单开展新评估：清单没有明确负责人；没有任何版本记录或变更记录；条目中存在无法通过证据核实的断言。阻断项解除后，再按正常流程发布新版本。维护机制的具体节奏和角色设置可结合团队规模与选型频次调整，上述检查项作为自查框架使用。
常见问题
清单条目多久核实一次比较合适？
建议按季度做一次例行复核，重点检查条目的最后核实日期是否超出约定周期、证据是否仍可获取、判定标准是否仍适用。选型频次低的团队可以调整为半年一次。产品版本变化、合规要求调整、供应商合同变化等情形不受例行节奏限制，应随时发起事件触发的变更。两种节奏配合使用，既能集中处理积压的小修订，也不会让重要变化被拖到下一个复核周期。
正在进行的评估项目遇到清单改版，原有结论要不要推翻？
按项目所处阶段分别处理。尚未完成评估的项目，要求按新标准重新核实受影响条目并补充证据，保证同一轮评估口径一致；已完成评估的项目不追溯修改结论，但在评估报告中注明所用清单版本，供后续复评时对照。这样既维护了新评估的可比性，也保留了历史结论的可追溯性。
团队规模小，清单负责人和维度负责人可以由同一人兼任吗？
可以兼任。团队较小时，维度负责人由清单负责人兼任、评审环节保留一人交叉检查即可运转。需要留意的是清单负责人和审批人不宜由同一人长期担任，否则变更缺少独立把关，容易出现条目判定标准放宽却无人纠正的情况。角色设置应结合团队规模和选型频次调整，不必照搬大团队的分工。
清单里的条目怎么判断写得够不够清楚？
一个实用的检验方法是抽查若干条目，让两名未参与编写的评估人分别判断，看能否得出相近结论。如果两人结论差异明显，通常说明评估问题指向不够具体，或者判定标准缺少分级条件。修订时把问题落到可观察的功能或条款上，判定标准给出满足、部分满足、不满足的具体条件，证据要求写明可提交的材料形式，例如配置界面演示记录或合同条款。
变更单、评审记录和清单正文分散在不同地方，怎么保证能对应上？
关键是让每条记录都引用同一个变更单编号，并在清单的变更记录表中登记该编号、涉及条目、变更类型、提出人、审批人和生效日期。清单正文按版本号归档只读副本，变更单和评审意见按同一编号归入对应版本目录。这样任意一次历史评估都能顺着版本号找到当时的清单内容，再顺着变更单编号找到支撑证据。多人协作时，可以把变更单作为工作项管理、清单正文和评审记录放在文档中，通过状态流转标记提出、评审、发布各阶段；ONES Desk 支持自定义工单属性与工作流调整，工单可一键关联到 ONES Project 的需求或缺陷工作项持续跟踪，也可关联 ONES Wiki 页面沉淀处理经验，这类关联方式可用于承载变更请求与评审记录的流转，具体配置范围以实际产品为准。
