这份清单面向协作工具选型的实际评审与验收，按准备、评审、试点、验收四个阶段列出检查项，每项都给出可判断的通过标准、证据形式和负责人。它适合在需求确认后启动评估时使用，也适合在评审会、试点启动和上线验收前逐项核对。文中提到的评估流程，可以借助ONES这类协作平台承载工作项与文档记录。
要点总览（TL;DR）
- 清单按准备、评审、试点、验收四个阶段组织，每项检查都写明通过标准、证据形式和负责人，形成一条可追溯的证据链。
- 评审阶段围绕协作场景覆盖、权限与数据边界、集成与开放能力、使用门槛与推广成本、服务与合规五组标准横向比较候选，评分须对应到具体证据。
- 通过标准要写成可观察、可举证、可判断的表述，例如把场景覆盖写成“五类场景中至少四类按真实脚本走通”，避免凭印象打分。
- 数据存放位置不符、账号体系无法对接、关键集成缺失、权限模型无法满足最小授权属于阻断项，清零且必答检查项全部有证据才算整体完成。
- 清单本身可建成可分配、可跟踪状态的工作项，评审记录与验收证据挂在对应工作项下，阻断项进入统一视图跟踪到关闭。
谁在什么时点使用这份清单
清单的价值取决于用的人是否对、介入的时点是否早。选型负责人、IT/信息化人员、业务部门代表、采购与安全合规人员各自关注不同侧面，需要在对应阶段承担检查责任，避免评估变成一次产品演示后的主观投票。
下表把角色、介入时点和阶段产出对应起来，可作为评估启动时的分工依据。
| 角色 | 主要介入时点 | 承担的检查重点 | 阶段产出物 |
|---|---|---|---|
| 选型负责人 | 需求确认后、评审会前、验收前 | 评估口径统一、进度推进、结论汇总 | 需求与约束表、评审记录、验收结论 |
| IT/信息化 | 准备阶段、试点阶段、验收阶段 | 账号体系对接、部署方式、集成联调 | 集成联调记录、配置记录 |
| 业务部门代表 | 准备阶段、试点阶段 | 协作场景清单、真实任务验证、使用反馈 | 场景清单、试点报告 |
| 采购人员 | 评审阶段、验收阶段 | 预算区间、合同条款对应、服务承诺 | 评审记录、合同条款核对表 |
| 安全合规人员 | 准备阶段、评审阶段、验收阶段 | 数据存放位置、权限模型、合规要求 | 权限矩阵、合规确认意见 |
四个阶段的产出物形成一条证据链：需求与约束表是评审的基准，评审记录支撑候选取舍，试点报告验证实际可用性，验收结论作为上线放行依据。任一环节缺失，后续判断就缺少参照。
评估前的准备检查项
准备阶段的目标是在接触候选产品之前，把需求、约束和评估口径固定下来。这一步做得越具体，后续评审越不容易被演示效果带偏。
协作场景清单
按即时沟通、任务与项目跟踪、文档协同、会议与日程、跨部门流程五类梳理本组织的实际场景，每类写明使用部门、典型任务和当前痛点。通过标准是：每个场景都有明确的业务负责人确认，且能举出一个近期真实发生的例子。证据形式为场景清单文档，负责人为业务部门代表。
硬性约束
硬性约束包括部署方式、数据存放位置、账号体系对接、预算区间和必须集成的现有系统。每项约束要写成可判断的条件，例如“数据存放位置在境内”或“支持与现有账号体系对接”。通过标准是约束条件书面确认且无歧义，证据为约束表，负责人为IT与安全合规人员。
评估口径
统一评分维度、权重、评审人和一票否决项。权重应反映业务优先级，一票否决项对应后文的阻断项。通过标准是评审人已知晓口径并在评审记录上签字确认，证据为评估口径说明文档，负责人为选型负责人。
候选名单与信息收集方式
列出候选产品，并明确哪些信息需要厂商书面确认，例如部署选项、集成方式、服务响应时限。通过标准是每项待确认信息都有对应的书面答复要求，证据为信息需求清单，负责人为采购人员。
| 检查项 | 通过标准 | 证据 | 负责人 |
|---|---|---|---|
| 协作场景清单 | 五类场景均有业务负责人确认并附真实例子 | 场景清单文档 | 业务部门代表 |
| 硬性约束 | 约束条件书面化、可判断、无歧义 | 约束表 | IT/安全合规 |
| 评估口径 | 维度、权重、评审人、否决项已确认 | 口径说明文档 | 选型负责人 |
| 候选名单与信息需求 | 待确认信息逐项列出并要求书面答复 | 信息需求清单 | 采购人员 |
候选评审阶段的检查项与通过标准
评审阶段用同一组标准横向比较候选，形成可追溯的记录。五组标准分别是协作场景覆盖、权限与数据边界、集成与开放能力、使用门槛与推广成本、服务与合规。
通过标准的写法
每项标准要写成可观察、可举证、可判断的表述。例如“协作场景覆盖”不写成“功能丰富”，而写成“准备阶段列出的五类场景中，至少四类能在演示中按真实脚本走通”。这样评审人才能给出通过或不通过的判断，而不是凭印象打分。
演示与问答环节
要求候选方按本组织的真实场景脚本演示，而不是通用功能浏览。检查点包括：演示是否覆盖场景清单中的关键任务、问答是否针对约束条件给出明确答复、无法当场确认的问题是否承诺书面补充。通过标准是演示记录完整、每个场景有结论，证据为演示记录和书面答复，负责人为选型负责人与业务代表。
评审记录留存
评审记录需留存演示记录、厂商书面答复、测试账号截图等证据。通过标准是每项评分都能对应到具体证据，证据为评分记录表，负责人为选型负责人。
| 评估标准 | 通过标准示例 | 证据 | 负责人 |
|---|---|---|---|
| 协作场景覆盖 | 五类场景中至少四类按真实脚本走通 | 演示记录 | 业务代表 |
| 权限与数据边界 | 权限模型可满足最小授权，数据存放位置符合约束 | 权限说明、书面答复 | 安全合规 |
| 集成与开放能力 | 必须集成的系统有明确对接方式与验证计划 | 集成方案说明 | IT/信息化 |
| 使用门槛与推广成本 | 典型用户可在约定时间内完成核心任务 | 试用记录、培训需求评估 | 业务代表 |
| 服务与合规 | 服务响应时限与合规要求有书面承诺 | 书面答复、合规材料 | 采购与合规 |
试点验证阶段检查项
试点用真实协作任务验证工具在组织内的可用性，把评审阶段的结论落到实际使用。试点范围应覆盖主要使用部门和典型任务，周期以能观察到完整任务流转为准，参与角色包括一线使用者、部门负责人和IT支持。
关键验证点
验证点包括：任务流转是否顺畅，即任务从创建到完成的状态变化是否清晰；文档协作是否可追溯，即修改记录和版本能否查到；通知是否打扰，即消息频率是否影响正常工作；移动端是否可用，即外出场景下能否完成关键操作。每项验证点都要有观察记录，通过标准是该验证点在试点期内未出现影响任务完成的问题。
数据与反馈收集
收集活跃度、任务完成情况和用户反馈。反馈按问题类型分类，例如功能缺失、操作复杂、性能问题、培训不足。通过标准是反馈分类清晰、每类问题有数量统计，证据为试点数据表和反馈汇总，负责人为业务代表与IT。
试点结论判定
试点结束给出继续、调整或终止的结论。继续的条件是关键验证点全部通过且反馈问题可接受；调整的条件是存在可通过配置或培训解决的问题；终止的条件是出现阻断项且无法在合理范围内解决。证据为试点报告，负责人为选型负责人。
上线验收与证据留存检查项
验收阶段把结论变成可核对的证据清单，每项证据明确负责人和归档位置。证据类型包括配置记录、权限矩阵、集成联调记录、培训记录和用户确认单。
| 证据项 | 通过标准 | 负责人 | 归档位置 |
|---|---|---|---|
| 配置记录 | 关键配置与需求约束表一致 | IT/信息化 | 项目文档库 |
| 权限矩阵 | 角色与权限对应关系经安全合规确认 | 安全合规 | 项目文档库 |
| 集成联调记录 | 必须集成的系统联调通过并有记录 | IT/信息化 | 项目文档库 |
| 培训记录 | 主要使用部门完成培训并签到 | 业务代表 | 培训档案 |
| 用户确认单 | 关键用户书面确认可正常开展核心任务 | 业务代表 | 验收档案 |
验收会议要形成结论并登记遗留问题，每个遗留问题有责任人和时限。验收证据还需与采购合同条款对应，例如服务响应时限、数据存放位置等承诺，在合同中能找到对应条款，避免验收结论与合同义务脱节。
阻断项与完成条件
阻断项是必须清零才能推进的检查项。常见示例包括：数据存放位置不符合要求、账号体系无法对接、关键集成缺失、权限模型无法满足最小授权。这些项目一旦不通过，后续阶段不应放行。
阻断项处理方式
处理方式有三种：整改，即候选方在约定时间内解决；降级使用，即调整使用范围或场景，但需业务负责人确认可接受；更换候选，即当前候选无法满足硬性约束时转向其他选项。每种处理都要记录决定人和依据。
完成条件与阶段放行
整体完成条件为：阻断项清零、必答检查项全部有证据、遗留问题有责任人与时限。阶段放行规则如下表。
| 阶段 | 放行门槛 |
|---|---|
| 准备 | 场景清单、硬性约束、评估口径、候选名单均已确认 |
| 评审 | 五组标准均有评分与证据，无一票否决项未处理 |
| 试点 | 关键验证点有结论，试点报告完成，阻断项有处理方案 |
| 验收 | 证据清单齐备，阻断项清零，遗留问题登记完整 |
评估过程中的协作管理如何承载
清单本身也是一组需要跟踪的协作任务。把每个检查项建成可分配、可跟踪状态的工作项，明确负责人和截止时间，评估进度就能被直接看到，而不是散落在多个表格和邮件里。
评审记录、试点反馈和验收证据以文档形式与对应工作项关联，检查项完成时附上证据，评审人据此判断是否通过。阻断项和遗留问题进入统一跟踪视图，按阶段复盘，避免在验收前才发现问题未闭环。评估结论与放行记录留档，后续推广到其他部门时可以直接复用这套检查结构和证据模板。
ONES可以承载这类评估流程：检查项作为工作项分配给人并流转状态，评审文档和验收证据挂在对应工作项下，阻断项在统一视图中跟踪到关闭。这样，评估清单从一份静态表格变成可执行、可追溯的协作过程，验收时的证据也能按项目直接调取。
常见问题
评估启动时需求还没完全定下来，清单还能用吗？
可以先用，但要把准备阶段当作需求收敛的过程。场景清单和硬性约束允许先列出已知部分，同时标注待确认项、确认人和确认时限；评估口径中的权重可以先给初值，在评审会前定稿。需要守住的是：进入评审阶段前，硬性约束必须书面化且无歧义，否则候选之间的比较没有共同基准。
候选方在演示中无法当场回答的问题，评审记录怎么处理？
把这类问题登记为待确认项，写明问题内容、承诺书面答复的时限和跟进人，并约定答复到位后再补评分。评审记录中该项先标记为“待证据”，不计入通过。若答复超期或内容含糊，按未通过处理，避免用口头承诺填补证据空缺。
试点期间用户反馈问题较多，是否一定要终止？
先按问题类型分类再判断。功能缺失、操作复杂、性能问题、培训不足四类中，操作复杂和培训不足通常可通过配置调整或补充培训解决，属于“调整”结论；功能缺失要看是否落在准备阶段确认的硬性约束内，若涉及阻断项且短期内无法解决，才进入终止判断。分类统计和对应处理意见应写入试点报告。
验收时厂商承诺与合同条款对不上怎么办？
以合同条款为准核对验收证据。服务响应时限、数据存放位置等承诺若在合同中找不到对应条款，应作为遗留问题登记，明确责任人和补充签署时限，并在验收结论中注明。涉及阻断项的条款缺失，验收不应放行。
多个部门同时评估不同工具时，清单如何保持口径一致？
共用同一套检查项结构、通过标准写法和评分维度，各部门只替换场景清单和硬性约束的具体内容。评估口径说明文档由选型负责人统一维护，评审人签字确认后再开始评分。汇总时按同一维度对比，避免各部门各用一套标准导致结论无法合并。
