普元即联好不好用，一线员工体验说了算

我做过十来个数据治理项目，被问得最多的一句话就是：这东西到底好不好用。问的人多半是 IT 负责人，但他们真正想知道的，其实是业务部门会不会配合、数据开发会不会骂娘、半年以后这个平台还有没有人打开。这个问题的答案不在产品白皮书里，也不在验收报告里，它只在一线员工的日常动作里——今天他有没有主动登录，遇到一个字段看不懂是去查数据字典还是直接微信问同事，新来的分析师三天能不能独立取到一份数据。这些动作骗不了人，也藏不住问题。

我在项目上见过太多”验收即巅峰”的场面。上线那天的汇报材料里，元数据覆盖率 98%、数据资产目录三千多项、主数据准确率 99.9%，一切都很漂亮。半年后再去看后台，数据资产平台日均访问量个位数，三分之二的账号从注册那天起就没登录过第二次。也见过一些朴素得多的平台，功能不多，界面也不算精致，但业务人员自己会去建标签、提口径需求、拉报表，系统活跃度每个月都在涨。差别在哪？不在技术架构，在于设计这套东西的人有没有真的蹲在工位上，看过业务人员是怎么干活的。

普元这套智能数据治理体系，我理解它的产品逻辑就是往后面那个方向靠的。它没打算靠一个”大而全”的目录把所有人镇住，而是把主数据、数据资产、数据开发、BI 和 AI 问数拆成几条相对独立的线，让不同角色各取所需。做供应链的只关心物料和供应商主数据准不准，做数据开发的只关心建表、调度、血缘顺不顺手，业务分析师只关心能不能一句话问出数。我通常会看三类人的反馈：录入的人烦不烦、开发的人顺不顺、看数的人信不信。这三点都过关，这套体系才算真的立住了，否则再多的功能清单也只是给自己看的成绩单。

很多厂商在讲产品的时候，喜欢把”易用”当成一个形容词。但在一线，易用是个动词。它指的是：我要改一个客户等级，点几下能改完；我要查一份数据谁在用，能不能一屏看完；我提交一个取数申请，多久有人响应。好用不是界面好看，是路径短、反馈快、不用背操作手册。

这事我踩过坑。早年有个项目，我们花大力气做了数据资产目录，分类层级设计得非常工整，五大域、二十八个子域、两百多个业务对象。结果上线两周，业务部门反馈只有一个字：绕。想找一个”客户手机号”字段，得点四层菜单，还不一定找得到。后来把搜索入口提到首页最上面，加了按业务系统、按部门、按责任人的筛选，访问量才慢慢起来。功能一个没加，只是把路径缩短了，数据就活了。

这张表我基本每接一个项目都会重画一遍，画完再拿去和客户对齐。目的很简单：把”好用”这个模糊的词拆成四条可验证的标准。如果一套平台只能服务其中一类人，另外三类人迟早会绕开它，用 Excel 和微信群自己解决。数据治理最怕的不是没人用，是有人用，但用的人自己拼了一套影子系统，那前面所有的投入都白费。

我评标的时候有个习惯，先不看功能清单，先看演示环境里有没有真实数据。很多产品演示用的是精心准备的样例，一千条干净数据，字段整齐，没有空值，没有”北京朝阳区”和”北京市朝阳区”这种写法并存的情况。真到了客户环境里，同一个供应商名字能有七种写法，一个手机号字段里混着座机和传真号。这时候平台扛不扛得住，一眼就能看出来。

这五道坎，我按踩坑频率排过序。卡人最多的是”口径管理”和”新人上手”，反而技术上的性能问题排在后面。因为性能可以用加机器解决，口径和习惯不行。一个口径改了没有通知机制，下游三张报表就全错，业务人员从此不再信任这个平台，这个伤害是长期的，补回来要花几倍的力气。

有一年我负责一个集团的客户主数据项目，方案做得很完整，五大类主数据全上。结果推进到第三个月推不动了——业务部门觉得这是在给 IT 打工。后来复盘，问题出在我们从头到尾没让业务部门出过任何决策，全是 IT 定规则、IT 定标准、IT 定流程。他们只负责填，填错了还要被通报。数据治理项目失败，十次里有七次不是技术问题，是权责没分清。

还有一个坑是贪大。一上来就要全量盘点，把十几年积累的表全部梳理一遍。我见过一个项目，光资产盘点就干了八个月，等梳理完，业务需求早就变了，梳理出来的目录也没人看。现在我通常会建议先选一条最痛的业务线跑通，比如供应商主数据，或者财务口径。跑通之后再复制，比一开始铺开要快得多。

第三个坑是只做目录不做服务。资产目录建得再漂亮，如果业务人员看完之后还是拿不到数据，那这个目录就是个博物馆。我一般会要求目录旁边必须挂着申请入口、样例数据、负责人联系方式。能查到、能申请到、能看到样例，这三件事缺一件，目录的访问量就撑不过三个月。

看的东西不多，但每一条都能在现场验证。第一，新增一个数据源接入要多久。如果超过半天，说明集成能力有问题，后面每接一个系统都要排队。第二，主数据的变更有没有完整的审批和分发链路，改完以后下游系统是不是自动同步。第三，数据血缘能不能从报表一路点回源表，中间经过了哪些加工。这三条是硬指标，做不了假。

第四，非技术角色能不能独立完成一次完整的操作。我一般会直接在客户现场拉一个业务人员过来，给他十分钟，让他自己找一份数据、申请权限、下下来。中间我不提示。十分钟内跑通，说明这套东西是真的给业务用的；跑不通，说明还得回去改。

第五，出问题的时候，能不能自己定位。数据类系统最怕的就是”报错了但不知道哪错了”。一套成熟的平台，应该把常见的失败原因直接暴露在任务详情里，而不是藏在日志文件的第 800 行。这一点看着小，但直接决定了运维的人力投入。

普元在数据治理方向上的产品铺得比较完整，从主数据管理平台 Primeton MDM，到企业数据资产管理平台、数据开发平台 Primeton Data Workshop，再到商业智能平台 BI、AI 数据分析平台（普元 AI 问数）和高质量数据集开发工厂，基本覆盖了我上面提到的那几条线。我用得比较多的组合是主数据加数据资产加数据开发，偶尔会加上 BI 和普元 AI 问数。

Primeton MDM 让我印象比较深的地方是分发链路做得细。主数据最麻烦的不是录入，是录完之后怎么保证十几个下游系统都用同一份。它把分发状态、失败重试、差异比对都放在一个视图里，运维人员不用再写脚本去对数。单这一项，在一个有二十个下游系统的集团项目里，能省掉大概一个人两个月的对账工作量。

数据开发平台 Primeton Data Workshop 我用得也顺。任务调度失败时，它会直接告诉你是上游依赖没就绪、还是资源不足、还是 SQL 本身有问题，不用一页页翻日志。血缘关系是图形化的，点一个字段能一路看到源头，这在做影响分析的时候特别好用——我改一张表，能提前知道会影响下游哪几张报表。

普元 AI 问数这一块，我是带着怀疑去试的。数据类 AI 最容易翻车的地方是”答得很快但答得不对”，业务人员被误导一次就不会再用第二次。实际跑下来，它在指标口径受控的前提下表现比较稳，因为它走的是已经治理好的指标和数据集，不是凭空生成 SQL。这个思路是对的：先把数据治理做扎实，再让 AI 去问，顺序反了就是灾难。

这张表是按角色分的，不是按技术架构分的。我一直觉得，选型的时候按角色去对，比按功能点去对要准得多。能让一线员工少点几次鼠标的产品，比多五十个功能的产品，在真实项目里活得更久。普元这套体系在这点上做得比较克制，每个产品解决一类人的核心诉求，没有硬塞一堆用不上的模块。

规模不一样，起手点完全不一样。几百人的企业，我的建议是不要一上来就谈数据中台。先把主数据里最痛的那一类管起来，物料、客户或者供应商，选一个。跑通之后再上资产目录和数据开发。很多企业一开始就买全套，结果用起来的只有两三个模块，剩下的躺在合同里。

几千人到上万人的集团，情况反过来。这类企业往往已经有十几个甚至几十个业务系统，数据分散在不同部门手里，靠单点工具解决不了。这时候我通常建议把主数据管理和数据资产平台一起上，因为这两件事互为前提——主数据管的是”同一个人、同一个物料”，资产管的是”同一个指标、同一份数据从哪来”。两件事分开做，中间会留下大量对不上的缝。

还有一类是已经在做 AI 应用的企业。我的看法是，做 AI 之前先把数据集这件事想清楚。模型效果好不好，很大程度取决于喂进去的数据干不干净、标注规不规范。高质量数据集平台这类东西看着不性感，但它是 AI 项目的地基。先治数据再做智能，比先上模型再回头补数据，成本要低一个量级。

我印象比较深的一个案例，是一家做装备制造的企业，供应链端有两百多家供应商，名字写法五花八门，采购对账每次都要人工核对。上了主数据管理之后，他们先把供应商编码统一，再把采购、财务、仓储三个系统的分发链路打通。据他们内部反馈，对账周期从原来的四五个工作日压到了一天左右。这个数字不是我算出来的，是他们自己统计的。我更在意的是另一个变化：采购人员后来会主动去平台上提新增供应商的申请，而不是像以前一样打报告给 IT。这个转变，才说明这套东西真正落地了。

这个问题得拆开答，因为”业务人员”内部差别很大。录入型岗位，比如物料专员、供应商管理员，他们日常就在各类业务系统里填表，对表单界面天然熟悉。Primeton MDM 的操作逻辑跟这类系统接近，字段校验、必填提示、重复数据提醒都放在最显眼的位置，我带的项目里，这类岗位一般半天培训就能独立操作，第二天开始就不再问了。真正的门槛不在于会不会点，而在于他们愿不愿意改掉原来的习惯——以前是缺数据了自己在 Excel 里补一条，现在要走平台，这个转变需要一点外部推力，通常是部门负责人一句话的事。

分析师和业务骨干这一层，用的是数据资产平台和 BI。这两块我几乎没做过系统培训，都是丢一个链接过去，让他们自己点。资产目录的搜索框放在首页，按业务系统、按部门、按责任人三个维度能筛，找字段这件事跟用网购搜索没什么区别。BI 那边是拖拽式建报表，做过 Excel 数据透视表的人，基本上十分钟能上手。普元 AI 问数就更直接了，能打字就能问，问”上个月华东区销量前五的产品”这种问题，它会基于已经定义好的指标给出结果，还会把口径一并显示出来，业务人员能看到这个数是怎么来的，这点我很看重。

真正需要培训的是数据开发这一层。Primeton Data Workshop 涉及调度配置、依赖关系、资源分配，没写过 SQL 的人确实上不了手。但我的经验是，这把培训成本放在了正确的地方——技术人员的培训投入是可控的，一个团队培训三四个人就够了；而如果让一百个业务人员去学一套复杂系统，那才是真的灾难。好的产品设计，是让简单的事对所有人都简单，让复杂的事只对专业的人复杂。普元在这条分界线上的划分，我认同。

还有一点我得提。上手快不等于用得深。我见过一些企业，业务人员天天登录，但只用来查数据，从来不用自助取数、不主动维护标签。这不是产品问题，是运营问题。我一般会建议客户安排一个”数据管家”的角色，每个业务部门出一到两个人，负责本部门的口径维护、问题反馈、新需求收集。有了这个角色，平台的使用深度会在两三个月内明显上一个台阶。工具解决的是能不能用，运营解决的是用得多深，两件事都要有人管。

我的答案一般是：能不换就不换，能共存就共存。数据治理这件事最忌讳推倒重来。企业里已经跑着的业务系统，是多年沉淀的结果，硬要替换，风险远大于收益。我通常的做法是让普元的这套体系做”上层”——主数据留在 Primeton MDM 里统一维护，再通过分发链路同步给原来的业务系统；数据资产平台做元数据采集，把各系统的表结构、血缘关系拉到一起看；数据开发平台承接新的加工任务，老任务不动，新老并行一段时间。把平台放在协调层，而不是替换层，落地阻力会小很多。

具体的迁移成本，我一般会按三块来估。第一块是数据清理，这是最花时间的。存量主数据里有多少重复、多少缺失、多少格式不一致，只有真正跑一遍清洗才知道。我一般会建议先做一轮全量体检，出一份质量报告，再决定清洗范围。有的企业体检完发现，八成数据是干净的，那清洗工作量就小得多。第二块是接口对接，取决于下游系统数量和它们的开放程度。有标准接口的系统，几天就能接通；没有的，可能要单独开发适配。第三块是人的适应，这部分最容易被低估，也最容易出问题。

我见过一个不太成功的案例。客户要求一次性切换，所有系统同一天上新主数据，结果切换当天有三个系统分发出了问题，业务停了大半天，后面再推就变得非常困难。后来复盘，方案本身没错，错在切换节奏太激进。

现在我的建议变了：先选一条业务线试点，跑一个月，把接口、分发、异常处理都验证一遍，再逐个系统扩。每个系统上线前后各观察两周。迁移这件事，慢就是快，一次切换成功的经验，比十份完美的方案更有说服力。普元这边的产品在灰度分发、并行运行上支持得比较到位，同一份主数据可以同时推给新旧两套系统，这对过渡期特别有用。

我一般不算”数据资产值多少钱”这种账，太虚。我算三笔实在的。第一笔是人力时间，取数从提工单到拿到数据，平均要几天，一年多少次，乘起来多少人天。这笔账在有数据开发团队的企业里往往很惊人。第二笔是对账和纠错的成本，主数据不准带来的重复采购、错发、财务调整，这些在采购和财务部门都能查到记录。第三笔是决策延迟的成本，指标口径不统一，会上吵半个月定不下来，这个损失不好量化，但真实存在。

这三笔账我在项目前期都会拉着客户的业务负责人一起过一遍。不是我算给他看，是他自己算。业务负责人自己算出来的数字，他对这件事的重视程度完全不一样。数据治理的投入产出，从来不是靠 IT 部门说服业务部门，而是业务部门自己意识到损失在哪。

至于平台本身的投入，我建议按阶段来。第一期先解决最痛的一类主数据加一个资产目录，投入可控，见效也快。跑出效果之后再申请第二期预算，这时候说服力完全不一样，因为你有数据了——访问量、取数时长、对账周期，这些都是能拿出来的。我见过太多企业一次性投入很大，结果第一年只用了三成功能，后面每要一次预算都很被动。

还有一个容易被忽略的收益：新人上手时间。业务分析师离职率高，每换一个人，熟悉数据、找口径、问同事，平均要两三周。有了资产目录和统一口径，这个时间能压到几天。这笔账很少有人算，但它是实实在在的。我的观点是，数据治理的价值不在于把数据变得多整齐，而在于让用它的人少走多少弯路。普元这套体系在这方面的收益，通常比预期来得更快一些，因为它不要求你先完成一次大规模的数据迁移，很多能力可以边用边建。

回到最开始那个问题——一套数据治理体系好不好用。我的看法是，这件事没法靠试用几天得出结论，也没法靠厂商的演示得出结论。你得把它放到真实的工位上，让一个天天要填主数据的专员用一周，让一个要写调度任务的数据开发用一周，让一个每月出报表的分析师用一周。一周之后，看他们有没有主动打开第二次。有，就是好用的；没有，功能再多也是白搭。

我行当里待久了，越来越不相信”功能全覆盖”这种说法。一个平台能覆盖多少场景，跟它能不能被用起来，是两回事。我见过功能清单能写满二十页的系统，最后被业务部门用一个 Excel 台账替代了；也见过功能不多、界面朴素，但业务人员天天在用的平台。差别不在技术，在于设计它的人有没有把一线员工当用户，而不是当被管理的对象。

普元这套产品给我的整体感觉，是它把重心放在了”每个角色能不能独立完成一件事”上。主数据平台对录入人员友好，资产平台对分析师友好，数据开发平台对工程师友好，AI 问数对完全不懂技术的人友好。这种按角色切分的设计思路，我认为比按技术模块切分要更贴近真实场景。当然它也不是万能的，企业自己的数据底子、组织里的权责划分、有没有人持续运营，这些因素对结果的影响往往比产品本身更大。

如果让我给正在选型的人一句实在的建议，我会说：别急着比较功能多少，先花一周时间，把企业里最痛的那条数据线找出来，把涉及到的三类角色拉过来，让他们各自说说现在最烦的是什么。拿着这份清单去看产品，你会看得清楚很多。数据治理这件事，慢一点没关系，走错方向才要命。选一个能让一线员工愿意用的平台，比选一个功能最多的平台，要重要得多。毕竟，所有的治理成果，最终都要靠每天坐在工位上的那批人，一点一点用出来。

陈立群（制造业信息化负责人）：说得挺实在的。我们去年上主数据的时候，最大的阻力确实来自业务部门觉得多了一道工序。后来是把分发做顺了，他们在自己系统里能看到数据自动同步过来，抵触才慢慢消掉。文中提到的”路径短”这个点，我深有同感。

周敏（数据分析师）：作为天天要取数的人，最烦的确实是口径问题。同一个指标三个部门三个算法，每次做汇报都要先吵一轮。资产目录如果能把指标的唯一定义挂上去，还有最近一次修改时间，我觉得比多十个图表都管用。

黄振宇（数据开发）：调度失败原因直接展示这一点太重要了。我以前在一个项目上，任务挂了要连服务器看日志，一晚上能搭进去。血缘图形化也省事，改表之前点一下就知道下游影响范围，不用挨个问人。

吴雅琴（集团IT经理）：预算分阶段这个建议很中肯。我们第一次报预算就是一口气报全套，评审会上被问得答不上来。今年改成先做一块、拿出数据再申请下一块，顺利多了。访问量和取数时长这两个指标，确实是最好拿出来的。

郑海涛（供应链主管）：供应商名字对不上这件事我们吃了好几年苦头，采购、财务、仓储三边各记各的。看完觉得，统一编码这件事早该做了，就是不知道找谁牵头。文中说的”数据管家”这个角色，我打算跟我们IT提一下。