维度一：链路闭环
不看功能条数，看一条业务链路能否走完：输入、判断、生成、复核与留痕是否齐全。怎么打分：让候选方走完一条真实链路，缺一环就按缺口扣分；只有入口没有回写的方案，功能再多也给低分，验收时难以核对。
维度二：行业术语
垂直型的优势在术语、字段与行业惯例，全能型要靠配置补齐。怎么验证：用行业黑话与内部简称各出十道题，看回答是否需要反复解释。边界是术语可配，业务规则的理解深度难配，改动还要厂商排期。
维度三：集成与嵌入
平台再强，进不了日常工作界面就用不起来。看是否支持单点登录、消息入口、审批回写与权限继承。怎么打分：以必须打通的两个系统实测，能读能写给高分，要中间件对接的给中档，人工导表的给低分。
维度四：扩展与锁定
全能型靠插件市场，垂直型靠开放接口，两者都要看自定义字段、脚本能力与数据导出。怎么判断：问清哪些改动属于配置、哪些要厂商排期、导出是否含附件；锁定越深，迁移成本越高，合同要写明归属。
维度五六：合规与存续
部署形态、日志留存与内容标识属门槛项，不参与加权；供应商的客户结构与路线图决定三年后还在不在。怎么做：合规设准入门槛，存续看近两年迭代记录与停服条款，别把系统押在单一产品线上。
适用与不适用
适合谁
- 正在做平台级选型、候选类型不同的项目组
- 需要把主观印象转成依据的负责人
不适合谁
- 只有一个候选方案、走单一来源采购的项目
典型场景
综合办公平台与一款运输管理产品同时进入终选。某物流企业的项目组按六维打分：综合平台在集成与入口得分高，垂直产品在深度与术语上得分更高，加权后只差零点二分。评审会用二十条异常运单实测，最终由垂直产品承载核心业务。
可执行步骤
- 先把要闭环的业务链路写清楚，作为打分、实测与验收的基本单位之一
- 六项权重由业务、IT 与财务分别给出，再对齐口径后取中位数值
- 为每个维度写清三档评分锚点与证据要求，避免评委凭主观印象给分
- 加权之后，对分差小于零点五的维度安排实测，并要求补充证据材料
常见坑
- 把功能条数当成覆盖度，打分表变成宣传册摘抄，选出的平台在实际链路里缺环、无法闭环。
- 权重由 IT 单独定，业务真正关心的场景深度被压低，上线后一线抵触、使用率长期偏低。
- 评分锚点写得含糊，评委各按各的理解打分，结果既无法横向比较也无法复现，评审沦为表态。
自检与验收清单
- 是否以业务链路为单位定义场景深度与验收口径
- 六项权重是否由业务、IT 与财务共同给出并留痕
- 每个维度是否都有三档可对照的锚点与证据要求
- 合规项是否设为准入门槛，而非并入加权总分
常见问题
六项权重一定要固定吗？
不必。不同阶段关注点不同：试点期可加重场景深度与集成，规模化阶段加重合规与持续性。关键是同一轮比较中权重一致，并在报告里写明调整理由，别按结果回头改权重。
分数接近时怎么定案？
转成实测。挑两到三条最容易出问题的链路，用同一批真实样本跑一遍，比较人工接管次数与处理时长。真正的差异往往藏在异常路径里，别只看顺利路径，也别把演示当日常。
供应商自评的分数能用吗？
只能当线索。自评普遍偏高，尤其在集成与合规项。做法是要求提供可核验证据，例如接口文档、测评报告与现场演示，由客户方复评后再入表，拿不出证据的一律按零分计入表。