平台选型最容易犯的错误，是拿供应商的功能清单做逐项打钩。功能清单可以写得很好看，但决定项目成败的往往不是"有没有这个功能"，而是"这个功能在真实数据量、真实工况下能不能用，用起来要花多少人力"。选型是一项风险定价工作，核心是把未来三到五年的不确定性尽量提前暴露。
评估维度的权重设计
不同企业的评估维度权重差异很大，但维度本身相对稳定。
维度 | 关键问题 | 验证方式 | 常见陷阱 |
数据接入 | 支持哪些协议，接入改造量多大 | 现场设备实测 | 演示环境用模拟数据 |
存储与写入 | 峰值写入能否稳定，压缩比多少 | 真实数据压测 | 标称值未说明硬件配置 |
查询性能 | 典型查询的P95延迟 | 真实查询语句压测 | 只测简单点查 |
分析能力 | 是否支持窗口函数、降采样、流计算 | 业务场景验证 | 功能有但性能不达标 |
生态兼容 | BI、Grafana、API、SDK | 现有工具链对接 | 接口封闭需定制开发 |
运维成本 | 部署复杂度、监控、升级 | 试用运维 | 隐性人力成本 |
服务能力 | 实施、培训、响应时效 | 客户访谈 | 售前与交付团队脱节 |
权重设计要结合企业现状。数据量大的企业，存储与写入权重高；分析需求复杂的企业，查询与分析权重高；IT人力薄弱的企业，运维与服务的权重应显著提高。把权重写进评估表并事先达成共识，能避免后期被单一维度带偏。
POC的设计原则
POC是选型中信息量最大的环节，也是最容易被做成"演示"的环节。有效的POC有三个原则。
真实数据。用企业自己的历史数据，而不是供应商准备的样例数据。样例数据通常干净、规整、规模适中，掩盖了真实数据的乱序、缺失、时间戳错误、标签不一致。真实数据一上，很多问题立刻暴露。
真实场景。POC的查询与写入模式要贴近生产。若实际业务是高频写入加长周期聚合查询，就不要只测单点查询的响应时间。把最耗资源的几个查询拿出来跑，比跑一百个简单查询有用。
可量化指标。POC开始前就定义验收指标：峰值写入速率、P95查询延迟、压缩后存储占用、数据导入耗时、故障恢复时间。指标要写进POC方案，双方确认，避免结束后各说各话。
POC的周期不宜太短。一周的POC只能验证功能，验证不了稳定性。建议至少两到四周，覆盖一次数据导入、一次压力测试、一次故障演练。
TCO的完整构成
总拥有成本不是软件报价，而是三到五年内的全部支出。
成本项 | 内容 | 常见低估点 |
软件许可 | 平台授权、模块授权 | 按点位/设备数的阶梯价 |
硬件 | 服务器、存储、网络 | 高可用与容灾的冗余配置 |
实施 | 部署、接入、数据迁移 | 现场改造与协议适配工作量 |
集成 | 与MES/ERP/BI对接 | 定制接口开发 |
运维 | 人力、监控、升级 | 专职运维人员编制 |
培训 | 管理员与业务用户 | 持续培训而非一次性 |
迁移退出 | 数据导出、替换成本 | 合同未约定导致锁定 |
硬件成本容易被低估。供应商报价常基于理想配置，实际生产环境要考虑高可用、备份、灾备，硬件投入可能是报价的一点五到两倍。
运维人力是最隐蔽的成本。一个需要专职DBA与运维工程师的平台，三年人力成本可能超过软件许可。选型时要问清楚：日常运维需要什么技能、是否需要厂商驻场、升级是否影响业务。
迁移退出成本在签约时几乎没人关注，但在更换供应商时会变成现实问题。数据能否完整导出、导出格式是否通用、历史数据迁移需要多长时间，这些都应在合同中明确。
供应商评估的非功能维度
功能之外，几个非功能维度更影响长期合作。
存续性。平台厂商的经营状况、融资情况、客户续费率。选择一家三年后可能不存在的厂商，风险远大于功能上的小差距。
路线图可信度。厂商的版本路线图是否兑现过。可以要求提供过去两年的路线图与实际发布记录的对比。
交付团队。售前承诺与交付团队往往是两拨人。POC阶段就应让未来的交付负责人参与，评估其专业度与响应速度。
客户结构。厂商的客户集中在哪些行业、哪些规模。若你的场景在其客户中占比很小，未来需求优先级会很低。
合同的关键条款
技术条款之外，几类商务条款决定了长期风险。
SLA要具体。可用性指标的定义（按月还是按年、如何计算停机）、响应时效的分级、未达标的补偿方式，都要写清楚。"99.9%可用性"若没有计算口径，争议时无法执行。
数据归属要明确。企业产生的数据归企业所有，厂商只能在授权范围内用于服务与改进，不得用于训练对外产品。这一点在AI时代尤其重要。
退出机制要可执行。合同终止后，数据导出的格式、时限、费用，以及过渡期支持，都应约定。避免"数据是你的，但导不出来"的局面。
价格调整机制。订阅制的续费涨幅、按量计费的单价调整，应有上限或提前通知期。
知识产权边界。定制开发部分的归属、平台升级是否包含定制功能、二次开发的限制，都要提前明确。
选型中的常见认知偏差
第一个偏差是"功能越多越好"。功能多意味着复杂度高、学习成本大、出问题的面也大。很多企业最终只用了平台三成功能，却为全部功能付费并承担运维负担。
第二个偏差是"性能看跑分"。跑分测试往往在理想环境下进行，与真实业务负载差异大。真实性能要在POC中用真实数据和真实查询验证。
"低价中标"是更隐蔽的偏差。低价可能对应的是缩减的实施范围、不足的硬件配置、或后期的涨价。TCO视角下，低价方案的三年总成本未必低。
还有一类偏差是"忽视组织适配"。平台再强，若企业没有相应的数据治理能力与运维团队，也发挥不出价值。选型应同时评估组织 readiness，而不只是产品。
结语
平台选型的本质，是在信息不对称的条件下为长期风险定价。功能清单可以缩短到一页，POC与TCO才需要花时间。演进方向上，平台的开放性（标准协议、开放API、可迁移的数据格式）会比单点性能更重要，因为它决定了企业未来是否有换供应商的自由。像TDengine这类AI原生的工业数据平台，正是以开放接口与低于传统平台的价格进入选型清单，值得作为对照方案纳入POC。工业互联网平台的选择，最终不是选一个产品，而是选一段三到五年的技术合作关系。把退出成本想清楚，往往比把功能想清楚更能保护企业利益。选型结论应形成书面评估报告，记录各维度的打分与依据，供后续复盘与续约参考。
