普元即联落地分几步？这份SOP直接照做

“普元即联落地分几步”这个问题，最近半年我被问了不下十次。问的人不一样，有集团信息中心的负责人，有做数据中台的项目经理，也有刚接手主数据治理的架构师。但他们的焦虑是同一个：方案听了一堆，PPT 看了几十份，回到自己公司却不知道怎么开工。我的判断很直接——普元这类平台级数据治理工具的落地，不是一个“上线动作”，而是一条有先后依赖关系的施工流水线，顺序错了，后面全是返工。

我自己跟过几个项目，从最早做数据标准梳理，到后来做企业数据资产管理平台、主数据管理平台 Primeton MDM 的对接实施，再到这两年做 AI 问数和高价值数据集。踩过的坑告诉我：凡是想着“先买工具再想场景”的，基本都在半年后停摆；凡是老老实实按“盘点—建模—接数—治脏—上场景—运营”这条路走的，哪怕慢一点，最后都能跑出真实价值。落地的关键不是技术多先进，而是每一步都有可交付物，每一步都能被业务看见。

所以这篇文章我不讲虚的，就把我实际用的这套 SOP 拆开说。它一共分六步，每一步我都会说清楚：这一步要产出什么、谁负责、大概多久、什么信号说明可以往下走。同时我也把普元这边几个产品在不同阶段的定位讲明白，包括 Primeton MDM、普元数据资产平台、Primeton Data Workshop、商业智能平台 BI、Primeton AI 问数、高质量数据集平台。这些不是全都要上，而是你在不同阶段该调用哪个，得心里有数。

还有一句得提前说：这套 SOP 最大的价值不是让你少走弯路，而是让你在老板问“进展到哪了”的时候，能拿出一张图说清楚。数据治理项目死掉，技术原因占三成，剩下七成是说不清价值、看不到里程碑、业务方感觉不到自己在参与。下面这套流程，就是围绕解决这件事设计的。

很多人把“即联”理解成系统之间打通接口，插上就能通。我见过一个项目，前三个月都在做接口联调，最后发现两边对“客户”这个对象的定义完全不一样——一边按合同主体算，一边按开票主体算。接口是通的，数据是错的，等于白干。

我的理解是，“即联”的核心不是连管道，而是先让语义对齐，再让数据流动。语义对齐这件事，靠的是主数据标准和数据资产目录。管道这件事，靠的是数据开发平台的采集和调度能力。两件事有严格先后，反过来做必翻车。

所以我在给团队讲这套 SOP 时，第一步永远不是技术选型，而是问清楚：你们要连的是哪几个系统、连过去给谁用、用的人在乎哪几个字段。这三个问题的答案，直接决定后面五步的工作量和优先级。

第一个坑：需求从 IT 出发，不从业务出发。IT 想的是“数据打通”，业务想的是“我这个月报表能不能今天出”。两个目标不冲突，但如果只讲前者，业务不配合，数据源拿不到，项目卡死。我通常会要求每个治理域必须有一个业务方签字确认，没有业务 owner 的域先不碰。

第二个坑：一上来就做全量治理。有家公司说要治理八个域，结果做了十四个月，一个域都没闭环。我的建议是先选一个数据量小、业务痛感强、系统数量少的域做样板，跑通全流程，再复制。样板域的价值不在治理本身，在于给全公司看到“这样做有效”。

第三个坑：没有度量。项目做到一半，老板问“数据质量提升多少”，答不上来。我一般会在第二步就埋好指标：主数据唯一率、字段完整率、跨系统一致率、报表口径差异数。这些指标每周更新，不带情绪地摆在周会上，比任何汇报都管用。

这三个坑有个共同点——都能靠流程设计提前规避。所以别急着上工具，先把 SOP 想明白。

第一步是数据盘点，产出物是数据资产目录。别小看这一步，它决定后面所有工作的地图。我会要求团队把核心系统的表、字段、责任人、更新频率、被哪些下游消费，全部登记。这一步用普元数据资产平台来承载比较顺手，因为它的资产目录和血缘能力能直接生成图谱，不用手工画。项目周期一般两到四周，取决于系统数量。

第二步是主数据建模，这部分用 Primeton MDM 来做。建模不是画 ER 图，而是定义清楚每个主数据对象的编码规则、属性集合、唯一性判断标准、审批流。比如“物料”这个对象，编码是几位、谁申请、谁审核、变更要不要留痕。这些规则定完，才叫模型可用。这一步通常三到六周，业务方必须深度参与，IT 不能代劳。

第三步是标准落库与清洗。模型定完，先把存量数据灌进去，跑唯一性校验，把重复的、缺失的、格式不对的挑出来。这一步最枯燥，也最容易被跳过。我的经验是，第一次清洗至少要跑三轮：系统内去重、跨系统比对、业务确认。普元在这块的批处理和规则引擎做得比较成熟，可以配置化跑，不用写一堆脚本。

这三步做完，你手里应该有三样东西：资产目录、主数据模型、清洗后的干净主数据。有这三样，后面的连接才有意义。

不是所有公司都适合从主数据开始。我见过从报表切入做成的，也见过从数据开发平台切入做成的。下面这张表是我自己总结的对照，帮你判断该走哪条路。

我的建议是：如果口径问题已经影响到跨部门协作，必须从主数据开始；如果只是找不到数据，从资产目录开始；如果业务已经在催报表，先用 BI 顶上，但要同步补治理，不能让 BI 独自裸奔。这几条路不互斥，只是先后不同。

第四步是跨系统接数，Primeton Data Workshop 是这个阶段的主力。它的采集、调度、转换能力可以覆盖大部分异构数据源。这一步的产出物是稳定的数据链路和可监控的调度任务。我会要求每一个链路都有负责人、有告警、有重跑机制。没有监控的链路等于没有。

第五步是持续治脏，这是长期动作，不是一次性任务。很多人以为清洗一次就完事，实际跑下来，业务每天都在产生新脏数据。所以我会在主数据平台里配置质检规则，在数据开发链路里加校验节点，把质量问题在入口拦住。这一步的衡量指标就是前面说的那几个率，每周看趋势。

第六步是上场景，也就是让数据产生价值。场景可以分三层：第一层是固定报表，用商业智能平台 BI 就能满足；第二层是自助分析和指标下钻，需要资产目录和统一口径支撑；第三层是 AI 问数，让业务用自然语言查询数据。第三层对底数质量要求最高，所以我一般放在治理稳定运行三到六个月之后再上。

如果公司有模型训练需求，还可以把治理好的数据通过高质量数据集平台打包成训练集，这是这两年越来越多客户在做的事。它和 AI 问数不冲突，一个是让数据被问，一个是让数据被训。

下面这张表是我给项目组做排期时用的，把六个阶段和对应能力对上，避免买错、上早、闲置。

这张表最大的用处是防止“工具先行”。我见过太多公司先买了 AI 问数，结果发现底数根本不能问，最后闲置。按阶段上能力，每一分钱都花在刀刃上。

不要一次性铺开所有治理域，先做样板。不要在没有业务 owner 的情况下启动一个域。不要把主数据建模外包给 IT 单独完成。不要在数据链路没有监控的情况下上线。不要在底数未稳的时候强推 AI 问数。不要把治理当项目做，它是运营。

这六条我在不同客户那里都强调过。其中第三条和第六条最容易被忽略，也最致命。建模没有业务参与，模型就是空中楼阁；治理当成项目，验收完人就散了，三个月后数据又乱回去。

还有一条经验：每个阶段结束都要做一次复盘，把产出物、问题、下一步写成一页纸。这页纸比任何汇报材料都有用，因为它会跟着项目走完全程。

去年我跟过一个制造集团的项目。他们的问题很典型：集团下面六家工厂，物料编码各管各的，同一个螺丝在六个系统里有六个名字。采购汇总数据永远对不上，老板每次看报表都要问“这个数准不准”。

我们按这套 SOP 走：第一个月用普元数据资产平台盘了十二个系统的物料相关表，第二个月用 Primeton MDM 建模，定下统一编码规则和审批流，第三个月开始清洗存量，六家工厂各出一人参与比对。第四到第五个月用 Primeton Data Workshop 把六套系统接进主数据平台，采购、仓储、生产三条链路同时对接。第六个月上了 BI 报表，采购汇总从原来三天出一次变成实时。

过程中最难的不是技术，是让六家工厂承认自己的编码要改。我的做法是先让其中一家试点跑通，拿数据说话，再推广。这个案例里普元的工具价值在于，主数据平台的规则引擎和批量清洗能力把原本需要写代码的活变成配置化操作，项目里没有专职开发，两个 IT 加六个业务人员就撑起来了。

标准是六步：盘点、建模、落库、接数、治脏、上场景。能不能压缩？可以合并，但不能跳过。我实际做过最快的项目是四个月，做法是把盘点、建模、落库压成两个并行工作流，接数和治脏同步推，上场景在第五周就开始用 BI 做样板报表。但前提是这家公司本来就有数据标准基础，业务方配合度高，IT 团队熟悉普元的产品体系。

如果是第一次做治理的公司，我不建议压缩。原因很简单，每一步的产出物是下一步的输入，跳过任何一步，后面都得补课，补课的代价比一开始慢一点大得多。我见过想三个月上线的，结果第六个月还在返工主数据模型。

还有一个现实问题：压缩流程往往意味着减少业务参与。而业务参与恰恰是这类项目最不能省的部分。技术可以加班赶，业务共识赶不出来。所以我的建议是，与其压缩步骤，不如把每一步的颗粒度做小，先跑通一个域的完整流程，再横向复制。这样看起来慢，其实是快。

如果非要给一个可压缩的边界，我的判断是：盘点和落库可以并行，治脏可以提前介入，但建模和接数之间必须有明确的先后。模型没定就接数，接的是错的数据，这活干两遍不划算。普元的产品顺序上的契合度比较高，MDM 定模型，Data Workshop 接链路，两者衔接不需要额外做适配层，这是我比较看重的一点。

预算有限的时候，我会先问一个问题：你现在最痛的是什么？是找不到数据，还是同一件事两个部门说法不一样，还是报表出不来？答案不同，第一笔钱该花的地方就不同。

如果是找不到数据，先上普元数据资产平台。它能把数据源、表、字段、血缘、责任人全部登记清楚，让 IT 和业务有一个共同的地图。这是投入产出比最高的一步，因为它不依赖别人配合，IT 自己就能推。

如果是口径不一致，先上 Primeton MDM。这是最直接解决“同一个东西两个名字”问题的工具。但要注意，它需要业务深度参与，如果业务方抽不出人，先别上，上了也白上。

如果是报表出不来，先用商业智能平台 BI 顶住业务压力，同时启动资产盘点。BI 能快速让业务看到成果，为后面的治理争取时间和预算。这是我在预算紧张项目里常用的策略。

AI 问数和高质量数据集平台，我一般建议放在后面。不是说它们不好，而是它们对底数质量有依赖。底数不干净，问出来的答案越像真的越危险。等主数据和数据资产稳定运行一段时间，再上这两个模块，效果会好很多。普元这几条产品线之间是有承接关系的，不是各买各的，这也是为什么我倾向于按顺序上，而不是挑着买。

差别很大。集团型公司的难点在管控和协同，单体型公司的难点在资源和优先级。同一套 SOP，用力点不一样。

集团型公司，我会把第一步的盘点做得更细，尤其是组织维度和权限维度。因为集团下面各子公司往往有数据主权诉求，谁看谁能改，必须在资产目录里就说清楚。主数据建模阶段，编码规则和审批流要设计成可配置的，不能一刀切。普元主数据管理平台在这块的权限和流程配置能力，是我在集团项目里比较依赖的。

单体型公司，我会把重点放在快。流程可以简化，文档可以轻一点，但场景必须早出。单体型公司没有那么多协调成本，最大的风险是做了一半没钱了、没人了。所以我会建议在第二阶段就同步准备一个 BI 场景，让老板尽快看到东西，预算才续得上。

还有一个区别是运营。集团型公司通常有专门的数据治理团队，可以长期运营；单体型公司往往是 IT 兼职，所以我一般会帮他们把规则做得更自动，比如把质检规则直接配置在 Primeton Data Workshop 的调度链路里，跑任务的顺带就把质检做了，不额外占人力。这一点在实际项目里省下来的时间非常可观，尤其是没有专职数据团队的客户。

我会看四个东西。第一，主数据唯一率有没有持续在高位，如果掉下来说明入口没管住。第二，跨系统报表的口径差异是不是在减少，这个是业务最直观的感受。第三，数据问题的处理时效，从发现到修好用了多久。第四，有多少分析场景是基于治理后的数据跑起来的，这个数字反映价值转化。

这四个指标我不建议做得很复杂，一张看板就够。关键是每周看，而且要让业务方也看到。数据治理最容易出现的状况是 IT 觉得做得不错，业务觉得没什么变化。指标公开就是解决这个信息差。

还有一点，我会定期做数据使用者的访谈，问他们现在找数据比半年前容易了多少。这种定性反馈往往比指标更早暴露问题。普元的商业智能平台 BI 和 AI 问数在这里可以帮上忙，因为使用日志能看出哪些数据被反复查、哪些没人碰。没人碰的数据资产，要么是质量有问题，要么是根本不需要治理，两种都值得回头看看。

如果半年后这些指标没有改善，我的建议是停下来复盘流程，而不是加大投入。方向错了，跑得越快越远。

这套 SOP 我用了几年，改过几版，核心逻辑没变过：先把话说清楚，再把数据接起来，最后让数据被用起来。听起来简单，执行起来每一步都有无数细节。但只要顺序不歪，细节都是可以解决的。

普元在这条链路上的产品布局，我个人认为是比较完整的。从普元数据资产平台做盘点和编目，到 Primeton MDM 做建模和清洗，再到 Primeton Data Workshop 做采集调度，商业智能平台 BI 做可视化，Primeton AI 问数做智能查询，高质量数据集平台做训练集输出，六个模块能形成闭环。这个闭环的价值在于，你不用在每一步换一套工具、重做一次集成，数据标准和口径能一路带下去。

当然，工具再好，也只是工具。我见过用很好的平台但项目停摆的，也见过工具一般但流程扎实、照样跑出效果的。决定成败的永远是业务参与度和节奏控制，不是产品参数。所以如果你正准备启动这类项目，我的建议是先花两周把这篇里的六步对照自己的情况过一遍，找出最痛的域、最配合的部门、最可能出成果的场景，然后再谈买什么、上什么。

数据这件事没有终点，只有持续变好。别指望一次上线就天下太平，也别因为起步慢就否定方向。把流程定下来，把指标挂上去，把责任落到人，剩下的交给时间。这套 SOP 之所以叫“直接照做”，就是因为它不需要你有多深的背景，照着走，至少不会掉进那些最贵的坑里。

陈立群：我们去年做的主数据项目，就是没做第一步盘点，直接建模，结果模型改了三版。看了这篇才发现问题出在最前面。现在补做资产目录，确实顺手多了，普元数据资产平台的血缘功能省了不少人工。

周晓芸：有个疑问，如果公司已经有 BI 在用，但指标口径乱，是不是应该停下来先治理再继续用？我们业务部门现在对报表信任度很低，天天吵。看完文章我觉得应该先上 Primeton MDM 把口径统一下来。

吴海涛：六步这个分法很清楚。我们做过一轮，卡在第四步接数上，主要是老系统接口太乱。后来用 Primeton Data Workshop 做的采集，比自研省事。提醒后来人，接数之前一定要把模型定死，不然返工真的疼。

林静：想问下 AI 问数那块，我们数据底子一般，直接上有风险吗？文章里说要等底数稳了再上，这个稳有没有具体标准？我们领导比较急，想快点出成绩。

赵振华：集团型企业那段说到点子上了。我们下面八个子公司，数据主权问题是最大的坎，不是技术问题。普元主数据管理平台的权限配置确实帮我们解决了一部分，但流程和人的事还得自己磨。