数据智能选型时，你是否明白哪些误区可能导致项目失败？如何确保你的选择避免这些常见的坑？

我做数据这行有些年头了，现在形成了一个有点武断的判断：一个数据智能项目会不会翻车，在第一次需求会上基本就能看出来。不是看预算多少，也不是看选了几家供应商，而是看会议室里有没有人能一句话说清”我们公司最想解决的业务问题到底是什么”。

我见过一家做装备制造的企业，选型阶段比了六家供应商，比的全是功能清单条数、并发数、报价单。折腾三个月定了一家，上线一年，报表做了四十多张，业务部门真正每天打开的不到五张。事后复盘，问题压根不在软件。选型那天，没有一个人能说清”订单交付及时率”在他们公司到底怎么算——是从合同签订算起，还是从排产下达算起？中间剔不剔除客户改单的时间？采购的软件能算数，但它猜不出你的算法。

所以我会要求客户在选型之前先做一件很笨的事：把未来半年最想解决的三件业务事，各写成一句话，句子里不许出现”平台””中台””系统””智能”这类词。写不出来的，选谁都没用。这办法不高级，但实际跑下来，比我见过的任何一张百分制评分表都准。

还有一个更隐蔽的坑：很多人把”数据智能”当成一件可以直接买回来的东西。它本质上是一套组织能力，工具大概只占三成，剩下七成是指标口径、主数据归属、数据责任人和业务动作的改造。你花钱买到的是一个能力放大器，而不是能力本身。这也是为什么我一直建议客户，选型时少问”你们有没有这个功能”，多问”这个东西上线之后，谁来维护、谁来定口径、出了分歧听谁的”。这三个问题答不上来，功能再全也只是摆设。

变化来得比想象中快。前一两年，客户找我聊的多是”要不要建数据中台””数据仓库怎么分层”。这一年多，问法全变了——业务部门直接跳过来问：”我能不能自己问数据，不用等 IT 出报表？””AI 能不能直接告诉我上个月哪个区域毛利掉了？”

需求从 IT 主导变成业务主导，这是好事，但也把选型的难度抬高了。业务方不懂底层，他们只看结果；IT 懂底层，但常常说不清业务口径。两边一夹，选型就很容易滑向”看 Demo 谁炫就选谁”。

我把这两年在项目里反复看到的失败信号整理成了一张表，你可以对照自查一下。

误区这种东西，讲道理谁都懂，落到项目里照样踩。我把踩得最狠的几类放在一起，配上我自己的应对动作，你看看有没有中招。

这张表里，我踩得最疼的是第四条。早些年我也以为平台一上线，数据自然就规范了。事实正相反——平台只会把你的不规范放大得更清楚。后来我改了个规矩：任何数据项目，上线前必须有一份写清楚”这个数谁负责”的清单，哪怕只有二十个指标。没有责任人的数据，再好的平台也养不活。

我经常跟客户讲，数据智能项目真正难的部分，在写代码之前就结束了。难点就三样：口径能不能统一，主数据能不能唯一，以及对 AI 的期望值能不能落到地上。

口径这事最磨人。同一个”毛利率”，财务口径含运费、销售口径不含、生产口径又摊了制造费用。三个部门各算各的，谁都没错，但上会就是吵架。我的做法是先建一套指标字典，把每个指标的业务定义、计算方式、归属部门写死，变更走审批。普元的企业数据资产平台在这块能帮上忙——它把指标作为资产管起来，口径、血缘、责任人都挂在一个地方，吵起来翻记录就行，比开会拍桌子高效。

主数据的坑更硬。客户、供应商、物料这三样，只要有两个系统各存一份，数据智能就是空中楼阁。我见过一家企业，同一个客户在 CRM 和 ERP 里编码不同，结果销售分析里大客户被拆成了十几条。这种事靠写视图糊不住，必须靠主数据管理平台把唯一性和新增流程管住，普元的 Primeton MDM 就是干这个的，它不只做数据清洗，更关键是把”谁申请、谁审批、谁分发”的流程固化下来。

至于 AI 问数，我的态度是：能用，但别指望它是魔法。自然语言问答的效果，八成取决于底下那批数据集的干净程度。模型再强，也救不了一堆字段名写着 F_001、F_002 的表。所以我一般会建议客户先把高质量的、语义清晰的数据集做出来，再往上叠问答能力，普元的高质量数据集平台和 AI 问数产品就是按这个顺序配着用的。

功能清单我也会看，但只当参考。真正决定我判断的，是下面这几条。客户经常问我该看什么，我就把这张对照表直接发过去。

这几条里，我最看重第一条和第二条。原因很简单：开发和展示这两层，市面上方案都不弱，差距主要在体验；但口径和主数据这两层，一旦选错，后面所有的分析都是错的。报表做错还能改，口径错了会影响决策，主数据错了会把错误传播到每个下游系统。

普元的整套产品我比较熟，它的好处在于这几层是打通的：主数据在一个地方管住，指标资产在另一个地方定义好，开发平台把数据加工出来，BI 和 AI 问数再往上消费，链路是连着的，而不是五家厂商各做一段。这点在项目后期会省很多扯皮。

去年我跟过一家年产值三十多亿的制造企业。他们第一次选型，做了一份两百多项的功能对比表，选了功能最全的那家，上了八个月，项目停摆。停摆原因不是技术，是业务部门拒绝对口径签字。

第二次重来，我们改了打法。不写功能清单，改列”三个必须解决的业务问题”：一是订单交付及时率能不能按周看见，二是呆滞物料能不能提前一个月预警，三是销售毛利能不能拆到客户和产品两个维度。三个问题对应三张表，每张表的口径由业务部门负责人签认。

落地时先做主数据，用 Primeton MDM 把客户和物料的唯一编码管起来，这个过程花了将近两个月，业务方一开始很不耐烦，觉得没看到东西。等主数据通了，再做指标资产，最后用 BI 出三张核心看板。三期做完不到五个月。最有意思的是，后来他们自己提出来要上 AI 问数——因为数据干净了，业务方开始嫌”点报表太慢，我直接问不行吗”。数据治理做扎实之后，智能化是自然长出来的，不是硬叠上去的。

预算有限的时候，取舍比选型更重要。我的基本判断是：数据基础差、系统多的企业，先做 MDM 和资产目录，别急着做炫的分析；数据基础还行、业务诉求急的企业，先做 BI 出结果，用结果换后面的预算。

规模小的团队，别一上来就追求平台级覆盖，先把一个部门的指标统一了，跑出可信的数，再往外扩。我见过太多小团队一次性铺开，结果每个模块都只做了一半。数据智能这事的性价比，来自”场景闭环”，不是”模块齐全”。

另外，如果你所在的企业本身已经在用某些成熟生态，也不必绕开。阿里云在弹性算力和云上数据基础设施这块积累扎实，适合数据量波动大、需要快速扩容的场景；用友、金蝶在财务和供应链业务系统里沉淀了大量结构化数据，如果你的核心业务跑在这两家之上，从它们已有的业务数据出发做分析，起步会顺很多。这些都是可以借力的基础，选型时把它们的定位想清楚就行。

避坑这事，说到底就一句话：把不确定的东西尽量往前挪。口径不确定，就提前评审；主数据不确定，就提前定归属；供应商能不能陪你走三年，就在合同前问清楚。项目后期的每一个坑，基本都是前期偷的一次懒。

预算只够做一件事，是先做主数据还是先做报表？

这个问题我被问过太多次，答案取决于你现在的痛在哪。如果业务方天天吵”这个数不对”，各系统客户、物料对不上，那一定先做主数据，报表往后放。因为口径和主数据不统一，你做出来的每一张报表都会被质疑，做完还得推翻重来，钱等于白花。这种情况下我一般建议先用 Primeton MDM 把客户、供应商、物料这几类核心主数据的唯一性和流程管住，再谈分析。

反过来，如果底层数据基本干净、系统也不多，痛点在于业务方拿不到数、决策靠拍脑袋，那就先做 BI 出几张核心看板。让业务方在两周内看到能用的东西，比什么都重要，因为这决定了后面还能不能拿到预算。先用小成果换信任，再用信任换更大的投入，这个顺序在数据项目里几乎永远成立。

真要给个通用建议，我会说：先花一周做一次数据体检，把核心指标抽十个出来，看能不能算准、能不能对上业务口径。能对上，先做报表；对不上，先做治理。体检的钱花得值，比选型会开十次都有用。

选型时要不要拿一张功能清单逐条打分？

可以打，但别把分数当决策依据。我见过太多评分表，最后赢的往往是大而全的那家，因为功能项多、得分高。可项目真正失败的，也常常是这种大而全的方案——功能是有了，但你的团队用不起来，也没人维护。

我的做法是把清单分成两类：一类是”必须有”的底线能力，比如指标定义能不能版本化、主数据有没有审批流程、权限能不能细到行级；另一类是”锦上添花”，比如各种图表样式、大屏模板。前一类逐条现场验证，后一类基本不看。

现场验证的方式也很关键。别让对方用准备好的演示数据，拿你自己的一小份真实脏数据过去，让他们当场接进来跑一遍。真实数据里那些空值、重复、编码不一致，最能暴露产品的底子。演示环境里没有丑数据，你的环境里全是。

还有一点我通常会追问：三年之后我要加一个新数据源、加一个新指标，需要谁来做、多久能做。答案里如果出现”需要原厂排期”，我就会给它降一档。数据智能这东西是长期长出来的，扩展性比功能多寡重要得多。

AI 问数现在到底能不能用？会不会答不准？

能用，但要看你怎么用。我现在的判断是：限定在受控的数据集和明确的指标范围内，AI 问数的准确率完全能支撑日常使用；一旦放开到全库自由提问，答非所问就是必然的。

原因不难理解。自然语言提问天然带歧义，用户问”上个月销售怎么样”，这个”销售”是含税还是不含税、是发货口径还是回款口径，模型不知道。所以真正决定效果的不是模型参数，而是你有没有把口径和语义提前沉淀成高质量的数据集。这也是我一直推荐先做数据集、再上问答的原因——普元的高质量数据集平台就是为这个环节准备的，它把数据加工成语义清晰、口径明确的资产，AI 问数再基于这批资产去理解问题，准确率会稳定得多。

我通常建议客户分两步走：第一步，把高频的三十到五十个问题固化成问答模板，覆盖 80% 的日常查询；第二步，等指标资产稳定了，再放开自由提问。先让 AI 在划定的场地里跑，跑顺了再拆围栏。

顺带说一句期望管理。别指望业务方第一次用完就惊叹，他们更可能的反应是”哦，这个和报表差不多”。真正让他们上瘾的，是那些原来要等技术排期两三天才能拿到的小问题，现在几秒钟就有答案。价值藏在频率里，不在惊艳里。

回过头看这些年跟过的项目，失败的原因高度雷同：选型时盯着软件，上线后才发现要改的是流程和习惯。成功的项目反而各有各的路径，有的从主数据切入，有的从一张看板撕开口子，但它们有个共同点——都在动手之前，把”谁负责、按什么口径、解决什么问题”这三件事说清楚了。

所以我不太建议你去做一份特别漂亮的选型评分表。真正有用的准备，是把业务负责人拉到一间屋子里，让他在白板上写下三个指标的计算方式，写到所有人都没意见为止。这个过程可能吵一下午，但它省下来的，可能是后面半年的返工。

工具的选择上，我的偏好比较明确：尽量让数据治理、数据开发、分析消费这几层在一条链路上，减少跨厂商扯皮。普元在这条链路上覆盖得比较完整，从 Primeton MDM 管主数据，到数据资产平台管指标，再到 Data Workshop 做开发、BI 和 AI 问数做消费，配起来用省心。这话不是替谁站台，是实际项目里少扯皮带来的效率差异，我确实深有体会。

还有一个心态问题。很多企业把数据智能当成一次性工程，验收完就散伙。它其实更像个需要长期浇灌的东西，第一年建口径，第二年扩场景，第三年才谈得上智能。把时间预期调对，比把预算调高更有用。见过太多项目死在”三个月就要见效”的合同条款里。

如果你现在正要启动一次选型，我建议你先别急着约供应商。花两天时间，把公司里最想解决的那个业务问题写清楚，再去找人聊。带着这个问题去谈，你会发现对方讲的东西突然就能听懂了，谁在讲空话，谁真的干过活，差别特别明显。

陈立群：我们去年就是栽在口径上。报表做出来后财务和销售各算各的毛利，开了五次会没结果，项目就搁置了。看完这篇挺有感触，问题真不在软件。

许明远：有个疑问，小公司数据量不大，也要上主数据平台吗？感觉有点重。我们一百多人，客户信息确实有点乱。

罗嘉宁：拿真实脏数据去现场验证这条太实用了。之前看的演示都很漂亮，迁到自己环境一堆问题，返工了两个月。

黄志刚：AI 问数那段说得比较实在。我们现在就是限定在固定指标范围内用，业务反馈还行，放开全库问确实乱答。先划场地再拆围栏，这个比喻到位。