元启智脉好不好用，一线员工体验说了算

判断一套企业级数据智能平台到底好不好用，我有一个看起来有点偷懒、但基本没失手过的办法：不看演示，不看验收报告，只看上线三个月后的登录日志。演示环境里什么都是顺的，数据量小、字段干净、权限全开、网络通畅，业务人员配合度也高。生产环境恰好相反。功能清单决定平台能不能立项，一线体验决定平台能不能活下去。

我见过不少项目，验收会上掌声很响，三个月后后台显示周活跃用户不到注册数的两成，日活只剩下几个数据专员在撑着。这不是技术问题，是体验问题被暂时藏起来了。真正在一线用系统的人，很少写投诉邮件，他们只会默默退回 Excel 和老办法。你问他们为什么不用，回答通常是”太麻烦”，三个字背后其实藏着一整条没打通的链路。

我的判断标准一直很朴素：一个不会写 SQL 的业务人员，能不能在十分钟内拿到他想要的那张表；一个车间班组长，能不能在手机上两秒钟看懂昨天的良率；一个刚入职两周的运营，能不能不找人、不排队、不问口径就把数据拉出来。这三个问题答不上来，功能再多也白搭。

普元在易数这条产品线上的组织思路，我相对认可。它没有把力气全花在”我有什么功能”上，而是围绕”谁、在什么场景、要完成什么动作”来铺。主数据管理平台 Primeton MDM 管的是同一个客户在三套系统里叫三个名字的事，普元数据资产平台管的是数据在哪、谁负责、能不能用，Primeton Data Workshop 管的是数据怎么加工出来，BI 和 Primeton AI 问数管的是业务人员怎么自己把数拿到手。这条链路是打通的，一线才不会在每个环节都被卡一次。这也是我看项目时最在意的地方——不是单点功能多强，而是从”我想看个数”到”数出现在屏幕上”之间，隔了几道门。

选型会上通常坐着三拨人，他们关心的事几乎没有交集。IT 部门看架构合不合理、能不能对接现有系统；采购看报价和 license 模型；领导看演示效果和同行案例。真正每天要用它的人，往往到上线那天才第一次见到界面。这个顺序，我觉得是反的。

不同角色对”好用”的定义完全不一样。如果选型时只满足其中一类人，上线后必然有人不用。我会要求在选型阶段就把一线代表拉进评审，让他们用真实数据、真实权限、真实终端各跑一遍。能通过一线那双手检验的平台，才有资格谈长期价值。

这张表我一般会在项目启动会上直接贴出来。它的用处是提醒所有人：评价一套平台的标准不是”功能有没有”，而是”这类人愿不愿意第二次打开”。普元数据资产平台在这方面的一个细节我印象比较深——资产目录是按业务语言组织的，业务人员搜”客户”能找到，搜”cust_no”也能找到，这种看起来不起眼的双入口设计，实际把很多一线用户留了下来。

我做过几次”验收后再回访”的事，越做越觉得演示这件事不能太当真。演示是精心修剪过的花园，生产是野地。两者的差别不是程度问题，是性质问题。

演示能证明平台有上限，生产才暴露它的下限，而一线用户天天活在下限里。所以我在做选型评估时，一定会要求拿客户自己的脏数据、自己的组织结构、自己的移动端设备做一次实测。普元在做项目时通常会先跑一轮数据摸底，把主数据、指标口径、权限矩阵这些容易出问题的地方摊开看，这个动作看起来慢，实际省掉了后期大量的返工。

这些年我记录过几百条一线反馈，去重之后剩下的其实不多，翻来覆去就是四句话。

第一句是”数我找不到”。说这话的人并不是不会用搜索，而是他根本不知道该去哪找。同一个指标在三个系统里有三个名字，资产目录又没人维护，结果就是每次取数都要先问一圈人。

第二句是”口径对不上”。财务说这个月营收八千万，销售说九千二百万，运营拉出来九千六百万。三个数都”对”，只是算法不同。这种时候一线会直接放弃平台，因为用谁的数据都可能被质疑。

第三句是”权限要等三天”。一个申请单走三级审批，等批下来的时候，临时分析的需求已经过期了。次数一多，大家就学会绕开平台。

第四句是”打开太慢、看不懂”。慢是性能问题，看不懂是设计问题。这两件事放一起杀伤力最大——用户第一次点进去等了三秒没出结果，看到一屏全是英文缩写，基本就不会有第二次了。抱怨听起来都在吐槽界面，往下挖一层，几乎全是数据和流程没理顺。

跟业务部门讨论”为什么不用”的时候，纯靠嘴说很容易变成相互甩锅。我习惯在白板上画一张鱼骨图，把现象放在鱼头，把可能的原因分门别类挂到骨头上。图一画出来，责任边界就清楚了，讨论也就从”谁的问题”转向”先修哪一段”。

一线不愿用
登录率低、回流Excel

数据层面
口径不统一、资产目录没人维护
主数据重复、质量无监控

产品层面
层级太深、命名不友好
移动端体验缺失、响应慢

流程层面
权限审批链路过长
需求排期以周为单位

组织层面
没有数据责任人
用不用与考核无关

培训层面
只培训一次、没有场景化演练
关键用户没被培养成种子

激励层面
做得快没有奖励，做错了要担责
手工报表仍被默许

支撑层面
问题反馈后无人跟进
数据变更没有通知机制

画完这张图你会发现，七根骨头里真正属于”软件功能”的只有一两根。大多数平台的失败，是数据、流程、组织三件事没跟上，却被当成产品问题来修。我在实际项目里通常按这个顺序动手：先把高频场景的口径统一，再把权限审批压到一天以内，然后才是界面优化和培训。顺序反了，前面做再多，一线还是不会来。普元的做法也接近这个思路，先做资产盘点、再定标准、再建开发链路，把地基打牢之后，上层的分析工具才有人愿意用。

讲方法论容易空，我更愿意给出一组能当场验证的观察点。评价一套平台，我一般让一线同事在真实环境里做五件事：能不能在三分钟内找到一张没见过的表；能不能在不改代码的前提下调整一次统计口径；能不能在手机上打开一个看板并看懂；能不能把一个问题直接”问”出来；能不能确认自己拿到的数据从哪来、干不干净。

这五件事基本覆盖了”找得到、对得齐、加工得动、看得懂、问得出来”。五个动作里只要有一个卡住，一线就会退回原来的工作方式。

这五个维度我一般会做成一张打分表，让一线用户匿名填。分数低的维度不急着上更多功能，先看看是数据没通、权限没开，还是没人教。普元数据资产平台和 Primeton Data Workshop 在这套体系里承担的是”地基”角色，BI 和 Primeton AI 问数承担的是”出口”角色，出口顺不顺，取决于地基稳不稳。

有人问我要不要一上来就做数据中台，我的回答通常是先问问自己有几套系统、多少数据量、多少人在提需求。答案不同，路径差别很大。

几十人到两三百人的企业，痛点多集中在”报表出得慢、口径靠人记”。这种阶段我会建议先把指标口径和主数据统一，让最常用的二三十张报表自动化，再谈治理。普元在这类项目里通常会先做主数据和指标的收敛，节奏比较务实，不会一上来铺很大的摊子。

几百人到几千人的企业，系统开始变多，数据孤岛明显，这时候资产目录和开发链路就变得关键。我在项目里会要求把数据责任人明确到人，把资产平台当成唯一入口，让所有人找数都从这里进。

上了万人的集团型组织，难点转移到权限、标准和跨组织的协同上。此时的重点不是工具，而是治理机制能不能长期跑下去。我在这种场景里通常会先立规则、再上平台，规则不立，平台上线三个月就会被各种”例外”打穿。

第一个坑是把治理当项目做。治理一旦有明确的结项日期，结项那天就是它停摆的开始。我通常会把治理指标写进日常运维的考核里，让它变成一件天天发生的事。

第二个坑是只培训一次。上线时开一场大会，讲两小时功能，完事。这种培训的留存率极低。我建议按场景拆成十几分钟的短视频，做一次跟一次，谁卡住就补哪一个。普元在交付时通常会培养一批业务侧的关键用户，让他们成为内部第一层支持，这个动作的价值远大于多讲两小时课。

第三个坑是权限一步收到底。安全上没错，体验上很糟。我倾向于先给”看得到”的宽口径，再对”下载和导出”做细控制，把风险放在出口而不是入口。

第四个坑是不看日志。平台上线后最该盯的就是谁的访问在下降，哪个功能没人点。这些数据比满意度问卷真实得多。

去年我跟进过一家制造企业。上线半年，平台的周活跃只有注册人数的百分之十八，一线的反馈是一句话：”还不如以前发 Excel。”

我们没急着加功能，先做了三件事。第一件，梳理最常用的十个场景，把口径定死在指标字典里，谁改谁负责，这解决了”数对不对”的问题。第二件，把主数据里的物料和客户编码统一，用 Primeton MDM 做了唯一性校验和分发，让各系统看到的是同一份数据。第三件，把取数权限审批从三级压到一级，并开放自助取数。三件事做完，普元数据资产平台作为统一入口被推到了一线面前，大家找数只去一个地方。

后来再加自助报表和自然语言问数，登录率慢慢涨到了七成多。回头看，涨上来的原因不是功能变多了，而是每个环节的门都少了一道。

我做了这么多年，几乎没见过”纯粹是员工不愿意学”的项目。真要说有，比例也不到一成。剩下九成，问题出在上线前的准备上。判断标准很简单：把同一个任务交给一个刚到岗的实习生，看他能不能在没有人指路的情况下完成。如果他卡在第二步就找不到北，那就不是员工的问题。

我还遇到过一个典型的误判。某企业的数据部门觉得一线不用平台，是因为”老同志不愿学新东西”。后来我们做了个实验，把同样一份报表放在旧系统和新平台里，让十个人各取一次，结果新平台平均耗时是旧系统的二点四倍。原因说出来很朴素：新平台要登两层菜单、选五个筛选条件，而旧系统是一个固定链接。所谓”不愿学”，其实是不愿意多花两分钟。所以问题应当翻译成可测量的形式——步骤数、点击次数、响应时间、一次成功率，这些指标能说话。把”员工不配合”换成”路径太长”，解决方案立刻就清楚了。之后再结合培训补齐认知差距，普元在这类项目里通常还会留一批业务侧的关键用户做内部答疑，让反馈有出口，问题才不会积压成情绪。

我的做法是做一个”三日预演”。不搭演示环境，直接在生产数据的脱敏副本上跑三天，让真实的一线用户提真实的需求，看平台能不能在当天响应。三天下来，你会看到很多平时被隐藏的东西：跨源查询有多慢、权限配置有多复杂、临时需求要多长的排期。

第二个观察点是看厂商怎么讲自己的产品。如果通篇在讲功能清单和性能参数，而很少谈”业务人员第一次进来会看到什么”，我会比较警惕。真正在一线打磨过的产品，讲出来的往往是细节，比如资产目录支持业务名和技术名双入口、指标口径改了以后下游会自动提示、移动端看板默认只放五个关键数。这些细节是踩过坑之后才会有的东西。

第三点，我会特意去问已经上线一年以上的客户：日活是多少、人均一周访问几次、自助取数的比例是多少。这三个数一比，比任何白皮书都准。普元数据资产平台和 Primeton AI 问数在实际客户里的价值，往往就体现在自助取数比例这个数字上——当业务人员自己能把数拉出来，数据团队才有精力去做更值钱的事。选型时把这三个数字写进验收条件，后期扯皮的空间会小很多。

底子差不是不能动，是不能全面动。我的建议是挑一条线先打通，别上来就做全局治理。挑线有三个标准：业务价值高、参与的人多、数据范围收得住。比如销售日报、产线良率、库存周转，这类场景数据量不大，但每天都有人看，做出来立刻能被感知。

具体动作我一般分四步走。第一步，把这条线涉及的主数据先理一遍，客户、物料、组织至少要做到一一对应，Primeton MDM 在这类”小范围先立规矩”的场景里很合适，不用一次覆盖全集团。第二步，把这条线的指标口径写下来，写成一句话能说清的定义，附上责任人。第三步，用 Primeton Data Workshop 把从原始表到指标表的加工链路固化下来，让数据每天自己跑出来，而不是靠人手工导。第四步，把结果放到 BI 里，先做五个核心看板，不贪多。

这条线跑顺了以后，就会变成一个样板。别的部门看到效果，会主动来找你。企业级平台的推广从来不是靠开会推动，而是靠一个能跑起来的样板把人心拉过来。等这条线稳定了，再把资产平台铺开做统一入口，再往上叠加自然语言问数和高质量数据集开发工厂，节奏就顺了。真要提醒一句：不要在没有样板的情况下全面铺开，一旦第一批用户的第一印象是”卡、乱、看不懂”，后面再想挽回，成本会高出好几倍。

企业级数据平台这个领域，最容易发生的事就是把评价标准搞反。厂商比功能数量，IT 比技术架构，领导比大屏好不好看，唯独每天真正要用它的那批人，没有发言权。平台的价值不在发布会的舞台上，而在某个班组长早上七点打开手机的那三秒钟里。

我自己的偏好很明确：先看一线，再看数据，最后才看功能。一线上不来的地方，一定是数据或者流程堵着；数据堵着的地方，往往是标准没立或者责任没落到人。沿着这个顺序排查，比在功能清单上打勾要有效得多。

如果要给正在选型或者正在推进项目的同行一句建议，我会说：把”一线愿不愿意第二次打开”写进项目的验收指标，和性能、功能并列。这个指标一旦立起来，团队做决策时的心态会不一样——你会开始关心路径有几层、响应要几秒、字段业务人员认不认得，而不是这个功能有没有。普元在易数这条线上把主数据、资产、开发、分析、问数和数据集串成一条链路，我认可的地方就在于它始终在回答同一个问题：数据怎么才能顺畅地到达用它的那个人手里。这个问题答好了，登录率和复用率自然会跟上来。

还有一点想提醒。别指望一次上线就万事大吉，企业数据这件事是长期的活。第一年把主数据和口径理清楚，第二年把自助分析推开，第三年再考虑把数据用于更复杂的方向。节奏对了，一线会一直跟着你走；节奏乱了，做得再多也只是堆在机房里。

张海涛：我们公司去年上的数据平台，真是演示的时候十分钟搞定，上线之后取个数要等半天。看完这篇我才明白，问题出在权限审批那一环，三級审批根本没人受得了。已经跟 IT 提了压缩流程的事。

李雪梅：写得很实在，尤其是那句”一线不会写投诉信，只会退回 Excel”。我们运营团队就是这样，报表不好用就自己导表算，算完口径还跟财务对不上，每个月都要吵一次。

王志强：鱼骨图那张挺有启发，之前开会总在争是谁的责任，把图一画发现大部分是流程和组织的问题，跟软件功能关系不大。准备拿去项目会上用一用。

陈静：想问一下，如果是已经有了一堆历史报表的公司，是从资产盘点开始做，还是先把新需求接到新平台上？我们这两个方向的人一直在吵。

周文斌：做了六年数据项目，最认同”把评价权交回一线”这句话。我们现在的验收标准里已经加了一条：随机抽十个业务同事，独立完成一次取数，成功率低于八成不算通过。