多个候选工具进入替换评估时，评分表最容易出现的问题是每个候选各用一套说法：有人强调功能多，有人强调价格低，最后总分无法比较。可复用的做法是先固定评估维度、权重和评分口径，再让所有候选在同一张表里逐项打分，用加权总分配合关键否决项形成取舍结论，并保留每项打分的证据来源。本文面向已有替换动因、正在多个候选之间做取舍的团队，给出从建表到试点验证的完整方法；评分表和决策记录可以沉淀在 ONES 的工作项与文档中，便于后续复核。
要点总览（TL;DR）
- 统一评分的前提是先固定3–6个与替换动因直接相关的维度，用百分制分配权重，并为每个维度写明评分刻度和判定依据，确认后冻结。
- 所有候选使用同一张评分表，每格同时填写分数和证据来源；资料不足的维度标注“未确认”，不用默认分填补。
- 权重冲突回到替换动因的必须解决、希望改善、可以接受现状三档排序；打分分歧区分事实分歧与判断分歧分别处理，关键否决项不参与加权抵消。
- 结论要附敏感性检查、关键假设和未验证项，形成可追溯的决策记录；落地前用小范围试点验证高分维度，并预设回退条件。
先定评分维度与权重：把替换目标翻译成可打分项
统一决策标准的第一步，是把“为什么要换”写成可以打分的维度。替换动因通常来自几类具体问题：现有工具的功能无法覆盖某些研发环节、迁移和集成成本过高、长期投入超出预算、服务响应跟不上、安全合规要求无法满足。从这些动因中提炼3–6个核心维度即可，维度过多会让打分变成走形式，过少则容易漏掉关键约束。
常见的维度集合包括功能覆盖与替换匹配度、迁移与集成成本、使用与学习成本、总拥有成本、服务与支持、安全与合规。团队应结合本次替换的实际动因删减：如果替换主要由合规要求驱动，安全与合规的权重就应明显高于其他维度；如果现有工具的主要问题是协作流程割裂，功能覆盖与替换匹配度应排在前面。
权重分配建议采用百分制，所有维度权重之和为100%，便于横向比较和敏感性检查。分配时先按替换动因排序，再给排序靠前的维度分配更高权重，避免平均分配掩盖真正的决策重点。每个维度还需要定义评分刻度和判定依据，例如1–5分制，并写明每个分值对应的事实标准，而不是留给打分人凭印象判断。
| 维度 | 权重示例 | 评分刻度 | 判定依据 |
|---|---|---|---|
| 功能覆盖与替换匹配度 | 30% | 1–5分 | 现有工作流中必须保留的环节能否被承接，插件或定制场景是否逐项评估 |
| 迁移与集成成本 | 20% | 1–5分 | 可迁移的数据范围、迁移工具成熟度、与现有系统的集成工作量 |
| 使用与学习成本 | 10% | 1–5分 | 团队上手所需培训量、日常操作步骤变化程度 |
| 总拥有成本 | 15% | 1–5分 | 许可、实施、运维和后续扩展的综合投入 |
| 服务与支持 | 15% | 1–5分 | 原厂支持范围、响应约定、迁移服务能力 |
| 安全与合规 | 10% | 1–5分 | 部署方式、权限控制、合规要求满足情况 |
表中的权重是示例，实际取值应由替换动因决定，并在评估启动前由参与决策的角色共同确认，确认后不再因某个候选的表现临时调整。
统一打分表：让多个候选在同一口径下比较
维度确定后，把候选工具作为行、评估维度作为列，组成一张评分表。每一格填写两项内容：分数和证据来源。分数按S1定义的刻度给出，证据来源写明依据的材料，例如功能演示记录、迁移方案说明、报价单、合规材料或试用观察。没有证据支撑的分数应视为待确认，而不是有效评分。
打分人约定同样影响可比性。建议每个维度指定一名主要打分人，由最熟悉该领域的人负责，例如迁移成本由负责数据迁移的工程师打分，安全与合规由安全或法务角色打分；跨领域维度可由两人独立打分后取一致结果。所有打分人使用同一份评分口径说明，避免同一分值在不同人那里含义不同。
缺失信息必须显式标注。候选在某维度上资料不足时，填“未确认”并列入待核验清单，不用默认分、平均分或行业惯例填补。用默认分填补会制造虚假精度，让总分看起来完整，实际却把不确定性藏进了排序里。待核验项应在结论形成前尽量补齐，确实无法补齐的，要在决策记录中说明其对结论的影响。
| 候选 | 功能覆盖（30%） | 迁移与集成（20%） | 使用与学习（10%） | 总拥有成本（15%） | 服务与支持（15%） | 安全与合规（10%） | 加权总分 |
|---|---|---|---|---|---|---|---|
| 候选A | 4（演示记录） | 3（迁移方案） | 4（试用观察） | 未确认 | 4（服务说明） | 3（合规材料） | 待补 |
| 候选B | 3（演示记录） | 4（迁移工具说明） | 3（试用观察） | 3（报价单） | 3（服务说明） | 4（合规材料） | 按公式计算 |
这张表的价值在于可复用：同一结构可以用于本轮评估，也可以在后续新增候选时直接追加行，保持口径一致。评分表、证据附件和待核验清单放在同一处管理，评审时能直接追溯到依据。
权重冲突与分歧怎么处理
权重争议通常出现在两类场景：不同角色对本次替换最想解决的问题排序不同，或者某个候选在某一维度表现突出，有人希望提高该维度权重。处理方式是回到业务约束排序，而不是迁就候选的强项。具体做法是把替换动因按“必须解决、希望改善、可以接受现状”三档排列，权重向必须解决的动因倾斜；如果两个动因都属必须解决，则看哪个不解决会导致替换失去意义。
打分分歧的处理需要区分事实分歧和判断分歧。事实分歧指双方依据的材料不同或对同一事实理解不同，应补充证据后重新打分；判断分歧指证据一致但对分值的判断不同，可由该维度的主要打分人说明理由，再由评审组按评分口径裁定。分歧和裁定结果都应记录，避免同一问题在后续评审中反复出现。
关键否决项与加权总分配合使用。数据迁移可行性、合规硬约束、核心工作流能否承接等条件，适合设为一票否决项：候选不满足时直接排除，不参与加权总分的抵消。否决项应在评估启动时明确列出，数量控制在少数几条，否则评分表会退化成条件清单。加权总分用于在通过否决项的候选之间排序，两者分工清晰，结论才站得住。
- 权重冲突：按替换动因三档排序重新确认权重，确认后冻结。
- 事实分歧：补充证据，重新打分并注明变更原因。
- 判断分歧：主要打分人说明理由，评审组按口径裁定并记录。
- 否决项：评估前明确列出，不满足即排除，不参与加权抵消。
从分数到取舍结论：可解释的决策记录
加权总分算出后，先做敏感性检查：调整关键维度的权重，观察候选排序是否发生变化。如果排序稳定，说明结论对该维度依赖较弱；如果排序翻转，就要在结论中说明本次决策对哪个维度最敏感，以及该维度的评分证据是否充分。敏感性检查能防止一个证据不足的高分把整体排序带偏。
取舍结论应写成可追溯的决策记录，而不是只给一个排名。记录中要写明关键假设，例如“假设现有插件功能可通过平台能力逐项匹配”，以及未验证项，例如“总拥有成本中运维人力投入尚未测算”。这些内容决定了结论在什么条件下成立，后续条件变化时也能据此重新评估。
| 记录字段 | 填写内容 |
|---|---|
| 评估范围与替换动因 | 本次替换要解决的问题及优先级 |
| 维度与权重 | 最终确认的维度、权重和评分口径版本 |
| 候选与得分 | 各候选逐项得分、加权总分和否决项结论 |
| 证据来源 | 每项得分对应的材料或演示记录 |
| 关键假设 | 结论成立所依赖的前提 |
| 未验证项 | 尚未确认的信息及其对结论的影响 |
| 敏感性结论 | 调整权重后排序是否变化 |
| 结论与后续动作 | 推荐候选、试点安排和复核时间点 |
这类记录适合以文档形式与评分表放在一起管理。ONES 的文档与工作项可以把评分表、证据附件、评审意见和试点任务关联在同一处，评审结论和后续动作有明确的负责人和状态，替换评估过程本身也成为可复核的项目资料。
评分之外的验证：用小范围试点确认判断
评分反映的是评估时的信息和判断，落地前还需要用试点验证高分维度的实际表现。验证应针对得分最高、对结论影响最大的维度设计，例如功能覆盖得分高的候选，重点验证核心工作流能否完整跑通；迁移成本得分高的候选，重点验证实际数据迁移的范围和耗时；服务与支持得分高的候选，验证响应是否达到约定。
试点范围控制在能覆盖关键场景的最小集合，选择一个真实项目或一条完整业务流程，参与人包括日常使用者和负责迁移的技术人员。观察指标应与评分维度对应，例如流程完成率、迁移数据完整情况、单次操作耗时、问题响应时间。试点前明确观察周期和记录方式，避免试点结束后凭印象总结。
结论回退条件也要提前约定：试点中若发现关键工作流无法承接、迁移数据出现不可接受的缺失，或实际使用成本明显高于评分时的判断，应回到评分表修正对应维度并重新计算，而不是在试点结论中绕开问题。试点结果与评分一致时，结论可以进入实施决策；出现偏差时，修正后的评分和决策记录同样需要留档。
- 验证项：针对高分维度设计，每项对应一个可观察结果。
- 试点范围：一个真实项目或一条完整业务流程，覆盖关键场景。
- 观察指标：流程完成率、迁移完整性、操作耗时、响应时间。
- 回退条件：关键流程无法承接、数据缺失超出可接受范围、实际成本明显偏离评分判断。
- 记录要求：试点发现、评分修正和最终结论一并归档。
按这套方法推进，多个候选的比较从各自陈述变成同一口径下的打分，权重争议有明确的回退依据，结论附带假设和验证安排。评分表、决策记录和试点任务集中管理，后续复核时能直接看到每个判断来自哪份证据、在什么条件下成立。
常见问题
评分表里某个候选的资料一直补不齐，还能不能出结论？
可以出结论，但要把不确定性写进结论本身。做法是保留“未确认”标注，在决策记录中说明该维度缺失对排序的影响：如果补齐后即使给最低分也不改变排序，结论可以成立；如果可能改变排序，就应把该候选列为条件性推荐，并约定补资料的复核时间点。用默认分或平均分填补会让总分看起来完整，却把风险藏进了排序里。
业务方和技术团队对权重的看法不一致，怎么定？
先把替换动因按“必须解决、希望改善、可以接受现状”三档排列，权重向必须解决的动因倾斜，再让各方在同一份动因排序上确认，而不是各自坚持某个维度的百分比。如果两个动因都属必须解决，就看哪个不解决会让替换失去意义。权重在评估启动前确认并冻结，评估过程中不因某个候选的表现临时调整。
加权总分最高的候选，是不是就可以直接定？
不一定。先看它是否通过了评估前设定的一票否决项，例如数据迁移可行性、合规硬约束、核心工作流能否承接；否决项不满足的候选直接排除，不参与加权抵消。通过否决项后，还要做敏感性检查，确认调整关键权重后排序是否稳定，并对高分维度安排小范围试点验证实际表现。总分是排序工具，最终结论要结合否决项、敏感性和试点结果一起给出。
试点发现实际表现和评分不一致，评分表要改吗？
要改，并且要留档。试点中若发现关键工作流无法承接、迁移数据出现不可接受的缺失，或实际使用成本明显高于评分时的判断，应回到评分表修正对应维度的分数和证据来源，重新计算总分，而不是在试点总结里绕开问题。修正后的评分、变更原因和最终结论一并归档，后续复核时能看到判断是如何演进的。
评分表和决策记录放在哪里，后续复核才方便？
关键是让评分表、证据附件、评审意见和试点任务能相互追溯。可以把它们放在同一处管理，例如用 ONES 的文档承载评分表与决策记录，用工作项跟踪待核验项和试点任务，评审结论和后续动作有明确的负责人和状态。这样后续复核时，每个判断都能直接对应到证据材料和当时的条件假设。
