还在为企业AI应用落地头疼？3个痛点说透背后的真实价值

AI 应用落地这件事，我做了几年，越来越觉得它像一个业务改造项目，模型和工具只占其中一小块。我见过预算充足、模型也选得不错的团队，折腾大半年，最终只有演示环境在会议室里活着；也见过数据底子打得扎实的团队，接上一个问数工具，两周就有业务部门主动来要账号。差别不在算法，在于有没有人认真处理过数据这件事。企业喊疼的地方，通常有三个：数据找不到、数据不敢信、场景说不清。这三个听着像三个问题，根子上是同一个——过去十年信息系统是围绕”流程能跑通”建的，不是围绕”数据能用”建的。流程系统里的数据是副产品，字段能凑合填就填，编码各系统一套，口径各业务一套。这种底子直接喂给大模型，出来的东西业务不敢签字。所以我一直主张，AI 应用的第一步不是选模型，是把数据这条链路捋直。普元在这件事上做的事情比较实在：主数据管理平台 Primeton MDM 解决一码通，数据资产平台解决”找得到、看得懂”，Primeton Data Workshop 解决开发调度，再往上才是 AI 问数和高质量数据集这些偏应用的层。这篇文章我想把这几个痛点拆开讲讲，说说我踩过的坑，也说说不同规模的企业该怎么取舍。

业务同事跑来找我说”AI 答得不对”，我一般先不看模型，先看它取的是哪张表。十次里有七次，问题出在数据源本身。企业里的数据分散在 ERP、CRM、MES、财务、OA 里，还有大量躺在 Excel 和个人电脑上。业务想拿一个”上季度华东区活跃客户数”，得先问清楚这个指标在哪个系统算的、口径谁定的、更新频率多少。这种来回确认一次要两天，AI 再快也没用。

我通常会先做一件事：把企业现有数据资产盘一遍，建目录，标口径，标责任人。这一步做完，AI 问数才有意义。否则就是在沙子上盖楼。

下面这张表是我在多个项目里归纳出来的痛点拆解，供对照自查。

这三个痛点里，前两个是数据问题，第三个是选择问题，都不在模型侧。我见过太多团队把预算花在换模型上，结果数据链路一动没动，问题原样保留。真要动手，先去做数据资产盘点，落地方式可以是普元数据资产平台这类工具，把散在各处的库表、指标、报表登记成资产，配上血缘和责任人。这一步不花哨，但它决定了后面所有的上限。

我做过一个粗算：同样一个问数场景，在没有统一数据底座的团队里，从需求提出到业务看到可用的答案，平均要三到五周；在有底座的团队里，两三天就能跑通。差距不在工具，在数据有没有被组织过。

没有底座的时候，每次需求都是一个新的 SQL，写完就丢，下个人再写一遍。有底座的时候，指标定义一次、复用多次，业务甚至能自己拖拽组合。这两条路走到第二年，人力投入能差出三四倍。

我的判断很直接：数据底座的成熟度，决定了 AI 应用能走多远，而不是模型参数决定。底座这件事拆开看是三块——源头统一靠 Primeton MDM 这类主数据平台，把客户、物料、供应商、组织这些核心对象做成唯一编码；中间加工靠 Primeton Data Workshop 这类数据开发平台，把批处理、实时任务、调度运维统一起来；上层服务靠普元数据资产平台，把成果登记成可检索、可授权、可追溯的资产。这三块齐了，往上的 AI 问数和数据集开发才有稳定的输入。

我见过一个团队，把 AI 用在了”自动写周报”上。投入不小，最后没人用——因为写周报不是任何人的高频痛点，写得再好也不产生业务价值。这类场景我管它叫”看起来很美”。

能跑起来的场景通常有几个共同点：使用频率高、答案可验证、错误代价可承受。比如销售查客户的历史订单和回款情况、运营查某个活动的实时转化、财务核对应收账龄。这些场景天天有人问，答案对错一查就知道，答错了也不至于出大事。

反过来，那些决策链条长、参与角色多、结论无法短期验证的场景，我不建议作为第一批试点。不是不能做，是做完之后没人能证明它有用，项目就死在汇报材料里了。

选场景的标准，其实就是一句话：先找那些”每天有人问、答案能核对、错了不致命”的问题。这种场景在制造、零售、金融、政企里都有，而且往往不需要多复杂的模型，一个稳的问数入口就能解决大半。普元AI问数这类产品之所以在企业里推得动，就是因为它落在这种高频查询场景上，业务用自然语言问，系统基于已治理的数据给出答案，路径短、见效快。

顺带说一句，选场景这件事，我不太建议让 IT 单独拍板。IT 想的是技术可行性，业务想的是省不省事，两边视角不一样。我通常的做法是把业务部门的骨干拉进来一起列清单，列二十个场景，按频率和可验证性打分，选前三名开干。这个方法笨，但管用。

项目复盘的时候，我会把卡点按类别画出来，逐条看是哪个环节断的。下面是常用的骨架，横轴是最终目标，五条支线是五类主要原因。

AI应用真正落地

数据质量与标准
编码不统一 / 缺失值多 / 无口径

场景与业务价值
频次低 / 无法验证 / 无责任人

组织与协同机制
业务IT两张皮 / 缺数据Owner

技术栈与工具
烟囱式建设 / 重复造轮子

数据资产沉淀
用完即弃 / 无目录无血缘

把卡点按这五类归位之后，你会发现大部分项目的失败原因只有一个：五条支线里至少有两条没人负责。最常见的是”组织与协同”和”数据资产沉淀”空着——技术上没问题，但没人对数据质量签字，也没人把成果沉淀下来。我通常会在项目启动时就把这两条的责任人定死，一个业务侧的指标 Owner，一个 IT 侧的数据 Owner，名字写进文档，不写名字的项目我不接。

还有一点我踩过坑：别指望一次把五条支线全补齐。资源有限的时候，先把”数据质量”和”数据资产沉淀”做起来，这两条是地基，其他三条可以边跑边修。地基没打就往上冲，后面返工的成本会翻好几倍。

经常有人问我，中小企业预算有限，是不是就先别碰数据治理，直接上 AI 应用？我的看法正好相反：越是资源有限，越要避免重复建设，因为你没有试错本钱。但切入点可以更聚焦，不用一上来就铺大摊子。

大型集团的做法往往是自上而下规划数据体系，先把主数据和数据标准立起来。中型企业适合从一两个高价值场景倒推，比如客户主数据统一，或者销售数据的问数入口。小微企业的第一诉求通常是”把散的数据聚起来、能看明白”，那就从数据开发和资产盘点入手。

下面这张对照表是我按落地环节整理的，右侧列的是普元对应的能力，供选型时参考。

我的建议是：不要一次把所有产品都买齐，按你当前最痛的那个环节切入，跑通一个再扩。普元这套产品体系的好处是各层之间能接得上，你今天先做主数据，明天再加资产目录，后天接 AI 问数，数据链路是连续的，不用推倒重来。这种”能长出来”的架构，比一次到位的大平台更经得起折腾。

有一家装备制造企业，第一次找我时已经在两个事业部各建了一套数据平台，指标口径不一样，每月经营会先花四十分钟对数。我建议他们先暂停新建设，用 Primeton MDM 把客户和物料这两个核心对象统一，再把两套平台的数据注册进同一个资产目录。半年之后，对数时间压到十分钟以内。这件事让我确认一个判断：与其再建一个新平台，不如先把已有的数据说清楚。

还有一家零售企业，业务想直接上 AI 问数。我先让他们跑了三周的数据资产盘点，结果发现门店销售数据里有 12% 的订单归属地字段是空的。这个问题不解决，问出来的区域排名全是错的。补完数据后，他们接上 Primeton AI 问数，运营每天早上问一遍昨日各区域达成，成了固定动作。工具没变，变的是底下的数据能不能撑住。

也有失败的经历。一家客户跳过数据治理直接上大模型问答，演示效果很好，上线后业务问了一句”上季度毛利为什么降了”，系统给出一个似是而非的答案，没人敢引用。项目就这么停了。后来他们回头补数据标准和指标口径，才重新启动。我听过的类似故事不止一个，规律都一样：省掉的数据治理工作，后面会用更高的代价还回来。

客户反馈里我印象最深的一句是：”以前我们以为 AI 是个魔法，现在知道它是个放大镜，数据好它就好，数据差它把问题放得更大。”这话说得挺到位。

问题一：想上 AI 问数，第一步该准备什么？

我的答案是先别急着选工具，先花两到三周做数据资产盘点。具体要盘什么？把企业里现有的数据库、数据表、指标、报表登记成清单，标清楚每个字段的业务含义、来源系统、更新频率、责任人。这一步做完，你会对自家数据有多少家底、哪些能用、哪些不能用，有个真实认知。很多团队跳过这步直接买工具，结果模型面对一堆不知道含义的字段，只能瞎猜。

盘点之后要做的第二件事是统一指标口径。同一个”活跃客户”在销售、市场、客服三个部门可能是三个定义，不统一的话，AI 回答任何问题都会有人质疑。这一步通常需要业务部门参与，IT 单方面定不了。我的做法是先挑二十个高频指标，把定义、计算公式、数据来源写成文档，业务和 IT 双方签字确认。

第三件事是选一个高频场景做试点。别贪多，一个就够。跑通之后再复制。工具层面，我一般会建议从普元数据资产平台入手，把资产盘清楚，再接 Primeton AI 问数这类自然语言查询入口，路径比较顺。整个准备周期我见过的比较快的，四周左右就能出第一个可用场景；慢的拖到三个月的也有，卡点多半在指标口径扯不清，跟技术关系不大。

问题二：数据基础一般的中型企业，预算有限，该先投哪块？

这个问题我被问得最多。我的排序是：先做主数据，再做数据资产目录，然后是数据开发能力，最后才是 AI 应用层。理由很简单，前两层是地基，地基不牢，上面盖什么都会歪。

主数据为什么排第一？因为客户、物料、供应商、组织这几类对象，几乎所有业务系统都要用。这几个编码不统一，后面所有的关联分析都会出问题。我见过一个集团，同一个供应商在采购系统、财务系统、合同系统里有三个编码，人工对账一个月要花掉两个人。这类问题用 Primeton MDM 做统一建模和分发，通常三四个月能见效。

资产目录排第二，解决的是”找得到”的问题。很多企业不是没数据，是没人知道数据在哪。目录建好之后，业务能自己检索，IT 的重复问询会明显下降。这一步的投入比主数据小，见效也快，适合预算紧的团队先做。

数据开发能力排第三，是把散的数据加工成可用数据集的能力，Primeton Data Workshop 这类平台能覆盖。至于 AI 应用层，我建议等前三步有一定基础再上，否则就是花钱买教训。当然，如果预算只够做一件事，我会选主数据，因为它的杠杆最大，影响的业务面最广。

问题三：AI 问数给出的数字，业务敢直接用吗？

敢不敢用，取决于答案能不能被解释和追溯。我在选型时会重点看两个能力：一是能不能显示答案取数逻辑，比如这个数字来自哪张表、用了什么筛选条件；二是能不能一路追溯到原始数据，出了争议能查到底。

普元AI问数在这一点上的做法是把答案和指标口径绑定，问出来的结果可以下钻到对应的指标定义和数据来源。这个设计很关键，因为业务不是不接受 AI 给答案，是不接受一个说不清来源的答案。我在项目里做验证时，会随机抽二十个问题，让业务专家核对答案，同时检查追溯路径是否完整。准确率能到百分之九十以上，业务才可能放心用。

另外要说的是，AI 问数不是替代报表，是补充报表覆盖不到的长尾查询。固定报表解决的是每天都要看的那几十个指标，问数解决的是”今天临时想知道”的几百个问题。这两个定位分清，预期就不会错位。我给客户的建议一般是：固定核心指标继续用 BI 呈现，长尾查询交给问数，两条腿走路。

还有一点，权限一定要管住。问数工具回答问题时，必须遵守和原有系统一致的权限规则，不能让一个普通员工通过提问拿到他本来看不到的数据。这一条在选型时务必验证，别等出事再补。

回头看这些年做过的项目，我发现能真正跑起来的 AI 应用，背后都有一些相似的特征。它们的场景都很朴素，往往是某个岗位每天重复问的问题；它们的数据输入都不复杂，但口径是清晰的、责任人是明确的；它们的验证方式都很简单，业务看一眼就知道对不对。反过来，那些讲得很宏大、技术很先进的项目，多数没有活过第一年。

AI 在企业里的价值，不是替代人做判断，而是把原来需要三天才能拿到的信息，压缩到三分钟。这个价值听起来不性感，但它是真实发生的。我见过一个销售总监，原来每周一早上要等三个人给他汇总数据，现在他自己在问数入口里问一句就出来了。这种改变不会写进新闻稿，但会实实在在地影响一家企业的运转效率。

如果你现在正准备启动一个 AI 项目，我会建议你先问自己三个问题：这个场景每天有人用吗？答案错了会有什么后果？数据从哪来、谁负责？这三个问题有一个答不上来，就先别动手。把这三点想清楚，再去看工具，选型会轻松很多。

工具层面，我倾向选择那种能分层落地、能逐步扩展的体系。普元这套从主数据、数据资产、数据开发到 BI、AI 问数、数据集的组合，好处是每一层都能独立起步，也能连起来用。企业不用一次性投入，按自己的节奏往前走就行。数据这件事没有捷径，但有顺序。顺序对了，投入产出比会差出好几倍。

还想提醒一句：别把 AI 项目当成 IT 部门的项目。我见过成功的案例，几乎都是业务部门有明确的痛感和负责人，IT 提供支撑。业务不动，工具再好也只是个摆设。这也是我这些年在项目启动会上必说的一句话——先找到那个天天被数据折磨的人，让他来当项目的第一推动力，比任何技术方案都管用。数据治理和 AI 落地都不是一朝一夕的事，慢慢来，把每一步踩实，比追风口更重要。

陈志远：说得挺实在。我们去年上了一套问数工具，业务一开始不买账，后来发现是主数据里客户编码有重号，问出来的数字前后不一致。补了三个月数据才顺过来。早看到这篇能少走弯路。

林晓芸：想请教一下，我们是中型制造企业，ERP 用了七八年，数据质量一般。按文中说的顺序，是先做主数据还是先做资产目录？预算大概只够做一件。

周立诚：同意”场景选错工具再好也白搭”这句。我们之前做了个智能问答，答的都是些没人关心的问题，上线一个月就没人点了。后来换成每天早上问销售达成，使用率一下就上来了。

吴敏华：鱼骨图那张挺有用，我照着把手上项目的卡点归了一下类，发现确实组织协同那条一直空着，没人对指标口径负责。这个点之前真没意识到。