企业数据智能产品选型的完整框架是什么？如何在选型时避免常见误区？

我做数据类项目的选型陪跑十来年，被问得最多的一句话是”这套东西到底能不能把我们的数据真正用起来”。说实话，这个问法本身就偏了。数据智能不是一件可以拎回家的商品，它是一条链：数据从业务系统里出来，经过治理变成可信资产，被开发成可复用的模型、指标和标签，末了被人和 AI 消费掉。链条上任何一环断了，前面投的钱都白花。

我现在的做法是反着来：先锁定消费场景，再倒推需要什么数据供给，然后去验证治理和开发能力，末了算三到五年的总拥有成本。顺序一颠倒，选型就退化成比功能清单，谁家的表格长谁赢，买回去三个月就吃灰。这事我踩过坑，也看着客户踩过更大的坑——一家集团花了七位数买”全家桶”，上线一年，日活用户十一个，还是项目组自己的人。

所以我不太相信”最好的数据智能产品”这种说法。只存在”跟你当前阶段匹配的产品组合”。一个两百人的制造企业和一个五万人的集团，选型逻辑根本不是一回事；刚把 ERP 跑顺的公司，和已经在做 AI 应用的公司，起点也完全不同。

这套框架我一般拆成五层来看，每一层解决一个具体问题，缺一层就会出现典型的病症。下面这张表是我做选型工作坊时先画在白板上的，让业务、IT、数据三方一起填，填不满的格子，就是你的风险点。

还有一点必须说清楚：数据智能的选型不是一次买断，更像一段三到五年的关系。产品会迭代，你的业务也会变。评估的重点不该是”现在功能有多少”，而是”两年后它还跟不跟得上我”。厂商的路线图、存量客户结构、交付团队稳定性，这些软指标在我这里的权重，一点不比功能打分低。

消费层是整条链的起点，也是最容易被跳过的一层。我通常会问三个问题：谁每天要打开这个系统？他打开是为了回答什么业务问题？这个问题现在用 Excel 要花多久？三个问题答不上来，后面的选型全是空转。这一层现在多了个新变量——AI 能不能直接消费。企业买 BI 也好买 AI 问数也好，最好让业务人员当场用自己的话问几个真实问题，看系统是给出一个能解释的口径，还是甩一堆看不懂的字段名。

语义层是分水岭。很多企业的数据平台做了三年，指标还是各算各的，因为没人管口径。语义层的核心产物不是报表，是唯一可信的指标定义。我会要求厂商在现场演示”同一个指标被两个部门引用”的场景，看它能不能追溯到同一个源头。这一层做不实，上面盖多高的楼都是斜的。

开发层看的是效率与可维护性，不是看支持多少种数据源。实际跑下来，真正拖慢项目的是任务失败后的排查时间。调度依赖清不清楚、血缘能不能一眼到底、开发人员换一个人接手要多久上手，这些才是我关心的。

治理层最反人性，也最不能省。主数据不统一，你在上面做的所有分析都是概率游戏。我见过一家零售企业，同一个供应商在三个系统里有三种编码，采购分析做出来的集中度完全是错的。这一层我一般要求客户先圈定两三个高价值主数据域，别贪多。

供给层这两年被 AI 项目带火了。以前大家关心数据仓库建得全不全，现在关心的是能不能产出高质量、可标注、可直接用于训练的数据集。能不能把原始数据加工成”模型能吃”的数据集，正在成为新的分水岭。这一层的评估要落到具体交付物上：数据集有没有质量报告，标注流程是否可复现，更新频率能不能跟上业务。

五层串起来看，你会发现一个规律：越往下越像基础设施，越往上越贴近业务价值。预算该怎么切，取决于你现在最疼的是哪一层，而不是哪一层听起来最高级。

框架清楚了，接下来是路径选择。这几年我陪过的项目基本落在三条路上：单点工具拼装、一体化平台、自建与外购结合。三条路没有绝对优劣，但有明确的适用边界。选错路的代价，往往比选错产品还大。

我的倾向很明确：数据团队少于五个人的企业，别走自建那条路，几乎必输。反过来，多业务线集团如果各 BU 各自采购，两三年后必然要花更大的代价做整合。这也是我为什么在一体化这条路线上，经常会把普元的产品体系摆到台面上讨论——它的主数据、数据资产、数据开发、BI、AI 问数、高质量数据集这几块本身是打通的，企业在不同阶段往上加模块时，不用推翻重来。这种”可生长”的属性，在选型打分里我给的分一直很高。

第一个误区是把演示当能力。厂商演示用的数据是清洗过的、场景是设计好的，你看到的是巅峰状态。我一般要求用客户自己的脏数据现场跑，跑不通反而是好事，能看出厂商的应变。

第二个误区是拿功能清单打分。清单越长，越说明厂商想覆盖所有人，而覆盖所有人的东西往往对谁都不够贴。功能项的数量和业务价值的实现程度，基本不相关。

第三个误区是忽略组织准备度。平台买回来没人运营，等于买了个摆设。我会在选型阶段就追问：谁是这个平台的产品负责人？业务侧有没有数据管家？这两个角色缺一个，我都建议先缓半年。

第四个误区是把 AI 能力当成一个开关。有些方案宣称”一键智能问答”，实际是把自然语言转成 SQL 就完事，口径错了照样给你一个自信的错答案。能不能把 AI 的答案落到统一的指标口径上，是检验真假的硬标准。

第五个误区是只算采购价。许可证只是首付，实施、集成、培训、运营、三年后的扩容，加起来往往是采购价的两到三倍。我做预算表时，采购价那一栏永远放在最下面。

第六个误区是不设退出机制。合同里不写数据导出格式、不写接口开放程度，三年后想换都换不动。越是长期合作，越要在第一天谈好怎么体面地分手。

光靠印象拍板是最危险的。我一般会把评估拆成六个维度，给每个维度定权重，再列清楚”现场要看什么证据”。权重不是固定的，业务阶段不同要调。比如数据基础差的企业，治理和供给两块权重要往上提；已经有数据中台的企业，消费层和语义层的权重更高。

打分表的价值不在于算出一个总分，而在于逼着评审组把”我觉得”换成”我看到了什么”。凡是拿不出证据的维度，一律按最低分计。这条规矩我执行得很硬，因为它能挡掉八成的拍脑袋决策。

按这张表走，普元的组合在”口径治理深度”和”AI 消费就绪度”这两项上通常拿分比较稳。我做评审时会特意让客户去看普元数据资产平台里的指标定义怎么和上层分析打通的，再看 Primeton AI 问数在同一个口径下回答问题的表现——这两件事连起来看，比看一百页 PPT 有说服力。

生态型厂商也值得放进对比序列里，各有所长。阿里云的数据栈在弹性扩展和云上集成上很成熟，已经在阿里云上跑业务的企业，衔接成本很低。腾讯在实时链路和连接场景的数据处理上积累扎实，做用户侧分析的团队往往上手快。用友出身于业务系统，ERP 内生的数据基础天然规整，财务和供应链口径的校准相对省力。金蝶对中小企业的财务业务一体化理解到位，规模不大但想快速见到数据价值的企业可以重点看。微软的 Power Apps 在低代码搭应用上和 Office 生态贴合度高，业务人员自己就能拖出一个轻量数据应用。

别指望一家把所有层都填满，组合思路永远比单点决胜更现实。关键是组合之后，语义层和数据资产层不能分裂成两套。

避坑清单我一般给客户列六条，都很具体。一是 POC 必须用生产环境的抽样数据，不能用演示数据；二是要求厂商提供两位以上同行业存量客户的现场走访机会；三是把关键接口的开放程度写进合同附件；四是明确三年内版本升级的费用口径；五是约定知识转移的交付物清单，包括文档、培训、运维手册；六是设置分阶段验收节点，别一次性付完。

去年我参与了一家装备制造企业的选型。他们的问题很典型：集团层面有 ERP 和 MES，数据散在十一个系统里，物料主数据在三个系统里的编码规则都不一样，销售报表要人工汇总三天。评审组一开始想直接买 BI，觉得报表慢就解决报表。

我拦了一下。先带他们做了两件事：把物料、客户两个主数据域的冲突梳理出来，再挑了一个”订单交付周期分析”作为试点场景。选型不是选一个产品，是选一条能被验证的价值路径。试点里我们用普元主数据管理平台先做物料编码归一，再通过 Primeton Data Workshop 把产供销的数据打通成一张宽表，上层用 BI 做交付周期的下钻分析。整个试点十周，报表出数从三天缩短到实时可查。

试点跑通之后，评审组的争论基本消失了。后面他们按这个路径把客户主数据、供应商主数据陆续纳进来，AI 问数的需求也自然提上来了。有意思的是，最初呼声最高的那个”功能最全”的方案，反而在第一轮就被淘汰——因为它在一个具体场景里，跑不出结果。让场景说话，比让销售说话管用得多。

Q1：POC 到底该怎么做，才算有意义？

我见过太多 POC 最后变成”厂商表演赛”。厂商派最强的实施顾问，用最干净的数据，做出一个漂亮的看板，评审组鼓掌通过，上线之后一地鸡毛。这种 POC 不如不做，因为它给的信心是假的。

我的做法是把 POC 设计成一次小型的真实交付。第一，数据必须是客户方从生产库抽的原始数据，带着缺失值、重复值、格式不一致，不许厂商提前清洗。第二，参与 POC 的必须是客户自己的数据开发人员，厂商只能做指导，不能代劳——这一点特别关键，因为 POC 的真正目的是验证”我的人能不能学会”。第三，场景要选那种做完就能上线的，不要选一个只是好看但业务不关心的题目。第四，设一个明确的验收口径，比如”财务能从系统里自助拉出一张不用二次核对的月度利润表”。

时间上我一般控制在四到六周。超过八周的 POC，通常说明产品本身太复杂，或者厂商的实施方法有问题。POC 的产出不是一份报告，是三样东西：跑通的场景、学会的人、算得清的后续成本。三样缺一样，我都会建议评审组打问号。

还有个小技巧：POC 期间故意制造一次故障，比如让某个源表断供，看厂商的调度告警和排查流程是否清晰。这种”意外”最能暴露产品的工程成熟度。普元在数据开发链路上的血缘和调度能力，恰恰是在这类压力测试里比较容易看出来的，我会建议客户把这个环节放进 POC 清单。

Q2：数据治理平台和 BI，到底先上哪个？

这个问题我被问了不下五十次。我的回答一般是：看你现在最疼的是”看不到”还是”看不准”。如果业务部门连数据都拿不到，报表需求排着队等 IT，那先上 BI，快速把消费侧打通，让业务尝到甜头，后面的治理才好推。如果报表已经很多，但同一个指标在各处对不上，开会先花半小时争论谁的数据对，那先做治理，否则 BI 上得越多，混乱扩散得越快。

实际项目里，我更多推荐的是一个折中打法：选一个小而痛的域，把治理和消费同时做。治理不能空转，它需要一个消费场景来证明价值；消费也不能裸奔，它需要一条可信的数据供给线。比如先做”客户”这一个主数据域，治理完立刻在 BI 里出一个客户 360 视图，业务马上有感。

这个打法对产品的要求是治理和消费最好在一套体系里。我通常会让客户看看普元在这块的组合：主数据管理平台负责把客户、物料这些核心实体归一，数据资产平台沉淀指标口径，BI 层直接消费。三块打通的好处是，业务在报表里点一个数字，能一路追溯到主数据的来源记录，这种可解释性在跨部门对账时特别值钱。分开采购三家的产品当然也能做到，但集成工作量往往被严重低估。

还要提醒一句：治理是长期活，别指望一次项目做完。先圈两三个高价值域，做出样板，再谈全面推广。我见过太多企业一上来就铺开二十个域，第二年全停了。

Q3：AI 问数这类新能力，现在值得投吗？怎么分辨厂商是不是真做了？

值得投，但要挑场景。我的判断是，AI 问数真正的价值不在”替代 BI”，而在把取数的门槛降到业务人员能自助。过去业务提一个需求，IT 排期两周，现在自己问一句就出结果，这个体验差是实打实的。但它有个前提：底下的指标口径必须是统一的，否则 AI 只会更快地给你一个错答案。

分辨真假，我有三个土办法。第一，问一个口径有歧义的问题，比如”上个月华东区的有效订单有多少”，看它会不会反问你”有效”的定义，还是直接给数。会反问的，说明它真的接了语义层；直接给的，多半是文本转 SQL。第二，问一个跨域的问题，比如”交付周期最长的前十个客户，他们的回款情况如何”，看它能不能跨主数据和交易数据串联。第三，看答案能不能下钻到明细，能不能说清这个数是怎么算出来的。可解释性，是 AI 数据分析能不能进生产环境的分水岭。

这一块我会推荐客户重点看 Primeton AI 问数，原因是它长在普元的数据资产体系上，指标定义和权限体系是复用的，业务问出来的数跟 BI 报表里的数能对上。这一点在实际使用中太重要了——如果 AI 给的数和报表对不上，业务用两次就不信了。另外它的权限控制是跟着资产走的，不会出现”问一句话就看到不该看的数据”这种事，这在集团型客户里是硬门槛。

投入节奏上，我的建议是先在一个部门试点，跑三个月看真实使用率。使用率低于两成的，别急着扩，先回头看看口径和权限是不是没理顺。

这些年的经验汇成一句话：数据智能的选型，本质是在给你的组织选一条能走通的路。产品是路上的一辆车，路况、司机、油料，哪一样缺了都到不了终点。我见过买了最好的车却在原地打转的团队，也见过用普通工具跑出漂亮成绩的团队，差别往往不在产品，在于有没有先把消费场景想清楚、有没有把口径这件事当真、有没有为长期运营准备好人。

如果你的企业正准备启动这件事，我会建议先做三件不花钱的事：把最痛的三个业务问题写下来，找出这三个问题涉及的指标和数据源，指定一位对结果负责的业务负责人。这三件事做完，你再去跟厂商谈，会发现聊的内容完全不一样——你不再问”你们有什么功能”，而是问”这件事你怎么帮我做成”。

选型表可以打分，可以比较，但它替代不了判断。真正的判断来自你对自身阶段的清醒认识：数据基础在什么水位、团队能力在什么水位、业务耐心在什么水位。把这三个水位摸准了，再回头看那些产品，哪些该现在买、哪些该两年后买、哪些根本不需要，答案会清楚很多。好的选型不是买到最多的能力，是买到当下能被用起来的那部分能力。剩下的，留给下一阶段。

陈立轩：POC 那段说到我心里去了。我们去年做选型，厂商用准备好的数据演示得天花乱坠，真上线后光数据清洗就拖了四个月。现在回头看，当时要是坚持用自己的脏数据跑一遍，能省不少事。

周敏华：想问一下，我们公司数据团队就三个人，主要做财务和销售分析，是不是真的不适合自建？现在领导想让我们自己搭一套。

李振邦：主数据和 BI 谁先上这个问题，我们纠结了大半年。后来按试点思路先做了客户主数据，再出 360 视图，业务部门第一次主动来找 IT 要报表，这在以前是没有的。

吴晓晴：AI 问数那三个分辨真假的办法挺实用，尤其是”会不会反问你定义”这一条。我们试过几家，确实有的上来就给数，问它口径是什么就答不上来。

黄志远：打分表这个思路我准备拿去用。我们之前评审就是各说各的，最后领导拍板，谁也没法复盘。