从小团队到集团：普元即联规模演进路径

我这些年做过三十多个数据类项目，从三个人的小团队到几万人的集团都待过。有一个判断我一直没变：数据能力不是一次性买回来的，它是随着组织规模一级一级长出来的。小团队用 Excel 加几个脚本就能跑通的事，到了三百人的集团一定会崩，不是工具不行，是骨架撑不住。所以我给客户做规划时，从来不先问”你想买什么”，而是先问四个问题：你现在数据团队多少人、下面有几个法人主体、数据源有多少个、谁对数据质量负责。这四个答案基本决定了你该走哪一级台阶，也决定了钱花在哪里最值。

拿普元的体系来说，小团队阶段先用 Primeton Data Workshop 把接入、调度、开发这条链路做扎实，再配 BI 出报表，基本够用；到了几十人、开始有人争论”这个指标到底怎么算”的时候，就得上普元数据资产平台，把目录、血缘、口径管起来；等到了集团多法人的阶段，Primeton MDM 管主数据、数据资产平台管全域治理、Primeton AI 问数负责消费侧、高质量数据集平台支撑大模型，这几块是配套的，缺哪一块都会漏。我的建议是每一步只解决当下这一级最痛的问题，别提前把三年后的架构搬进来，也别等到出了事故才补。下面我按四级台阶讲：每级什么信号出现、该配什么、我在哪儿踩过坑。

我一般不看客户报的人数，看的是”抱怨的类型”。团队小的时候，抱怨是”数据取不出来””报表出得太慢”；团队到二三十人，抱怨变成”两个部门同一个指标数字不一样”；再到上百人，抱怨就变成”这个数据到底谁说了算””出了错找谁”。抱怨的类型变了，说明底座该换了，这比看预算靠谱得多。

这张表我用了五六年，几乎每次做规划都会先摆出来让客户自己对号。有意思的是，多数客户会指在两行中间——那说明你正在爬坡，这时候最忌讳的就是一步跨两级。

很多人以为小团队方案就是大集团方案的缩水版，砍掉几个模块就行。这个理解偏差挺大。两者差的不是功能多少，是”约束条件”完全不同。小团队靠的是一个人的判断力，大集团靠的是制度和工具把判断力固化下来。前者追求快，后者追求稳，你把稳的东西塞给小团队，他跑不动；你把快的打法给集团，三个月就失控。

我通常会让客户在右边那列里挑三项”现在就必须有”的，剩下的排到明年。全都想要的，一般哪个都做不深。

坑一，过早平台化。有个客户数据团队才四个人，非要上一整套治理体系，标准文档写了三百页，结果没人执行，半年后系统成了摆设。我的看法是：治理要先有”疼”，才有”治”。团队小于十个人的时候，把开发链路做干净，比写标准有用得多。

坑二，把主数据当成 IT 项目。我见过一个集团，MDM 系统上线两年，客户主数据准确率还是不到七成。为什么？因为业务部门没人认这个事，IT 单方面清理，清完第二天又被业务系统写脏。主数据这事，技术只占三成，七成在权责——谁新建、谁审核、谁负责清理重复数据，必须落在业务部门头上。

坑三，数据没人负责。这是集团阶段最普遍的问题。表建了一堆，出问题时一群人互相看。我会要求客户在项目启动会就把 Data Owner 名单定下来，哪怕先挂名，也比空着强。有了名字，后面的事才推得动。

去年我复盘过一个装备制造集团的案子。第一年他们数据团队五个人，目标是”把报表做出来”。我们先上 Primeton Data Workshop，把 ERP、MES、CRM 的数据接进来做统一调度，再用 BI 做了四十多张管理报表。这一年没什么治理动作，就是让业务看到数据能用。

第二年团队扩到二十多人，问题来了：同一张”订单交付率”，销售、生产、财务三个口径。这时候我们开始上普元数据资产平台，先把指标口径统一，再把表和血缘挂上去，让业务能自助查”这个数字从哪来”。这一步做完，争论少了大概一半。

第三年集团整合了四家子公司，客户和物料对不上，采购议价都受影响。这时候才上 Primeton MDM，先在客户和物料两个域做统一。同一年他们开始试 AI 问数，让业务用自然语言直接问数据，配合高质量数据集平台，把几个高频场景的数据整理成可复用资产。三年三个台阶，每一步都是被问题推着走的，没有一步是提前规划好的。我反倒觉得这样才健康。

经常有人问我：”这些产品我是不是都得买？”每次我都会拿这张表出来划。能力不是越多越好，是”必需、建议、可选、暂不需要”分清楚，否则预算会被摊薄，每个都做不深。

横向看，越往右越依赖前一层的基础。资产目录没做好就上 AI 问数，问出来的数字不准，业务两次不信就再也不用了。这个顺序我踩过坑，不划算。

大集团里很少只有一套系统。数据底座之外，往往还有云平台、ERP、低代码工具。我一般会把它们分成两类看。一类是承载业务的基础设施：阿里、腾讯提供云和中间件，用友、金蝶管财务和 ERP，这些是数据源和运行环境，普元的数据资产平台和 Primeton MDM 要能跟它们对接，把数据接进来、把主数据分发回去。这类对接做得好不好，直接决定项目第一年顺不顺。

另一类是前端应用搭建工具：Microsoft Power Apps、Mendix、Appian、OutSystems 这类低代码平台，适合做流程和表单类应用。它们的定位是”用数据”，不是”管数据”。我的经验是，用这些工具做前端没问题，但主数据和指标口径必须收在普元这边管，否则每个应用自己定义一套客户编码，三年后就是另一个烂摊子。

说白了，前端可以百花齐放，底座只能有一个。普元在这套体系里承担的就是那个”唯一”的角色。

这个问题我一年要被问几十次。我的答案很直接：从 Primeton Data Workshop 加 BI 开始，别碰治理模块。三四个人阶段，最值钱的是”把数据稳定地取出来、按时出报表”，而不是写标准文档。我见过太多小团队一上来就搞数据治理，标准写了半年，业务一张报表都没看到，第二年预算就被砍了。

具体怎么配？我一般建议先挑两到三个数据源接入，比如 ERP 和一个业务系统，把调度跑稳，出一批高频报表。等业务开始主动来找你要数据、开始讨论口径的时候，再考虑上普元数据资产平台。这个节点通常在团队到六到八个人的时候出现。早于这个点上，投入产出比很差。

还有一点，小团队选型要选”能长个儿”的平台。不是说现在就要用集团功能，而是别选一个三年后必须推倒重来的东西。普元的好处是同一套体系从小团队到集团能接得上，Data Workshop 做的东西到了集团阶段还能继续用，不用重做。这一点在我看过的项目里，省下来的时间至少是按月算的。

预算分配上我通常给的建议是：七成放在把数据接进来和用起来，两三成留给基础规范。别反过来。

这个场景太常见了。子公司各自建，往往是因为集团响应慢，业务等不及。现在要收口，硬来一定失败。我的做法是”先收标准、再收平台、后收权限”，顺序不能乱。

先收标准，指的是把核心指标口径和主数据编码统一。这一步用普元数据资产平台做，把各子公司已有的表挂进来，先做到”看得见”，让大家知道重复到什么程度。很多时候数据一摆出来，说服力比开会强。这一步通常两三个月能见效。

再收平台，指的是新建需求统一走集团的 Primeton Data Workshop 和资产平台，老系统不强行下线，但要冻结新增。这里有个关键点：集团平台必须比子公司自建更快、更好用，否则收口就是空话。我见过收口失败的，基本都是集团平台慢得要命，子公司偷偷自己建。

后收权限，指的是主数据的写入权。Primeton MDM 上线后，客户、物料、组织这些核心域的增删改要走统一流程，子公司可以提需求，但不能自己改。这一步最容易引起反弹，所以要配合明确的制度文件和 Data Owner 名单，让业务部门自己认下来，IT 只做支撑。这三步走完，一般一年半左右能看到明显效果。

这两个经常被混在一起问。我的判断依据很简单：看你的痛点是”数据找不到、看不懂”，还是”同一件事在不同系统里对不上”。前者先上数据资产平台，后者先上 Primeton MDM。

如果是分析型的问题多——业务天天问”这个指标怎么算的””这张表谁在用””数据从哪来”，那资产平台优先。它解决的是可见性和信任问题，见效快，业务感知强。普元数据资产平台在这块做得比较扎实的地方是血缘和口径能跟实际开发联动，不是额外维护一套文档，这一点在实际项目里省了很多人力。

如果是交易型的问题多——客户重复、物料编码混乱、组织架构对不上，那必须先做主数据。因为这类问题会直接影响订单、采购、结算，业务痛感最强，推动力也最大。Primeton MDM 在主数据建模、清洗和分发上有成熟路径，落地节奏相对可控。

两种情况都严重的，我会建议先做主数据里的一个域，比如客户或者物料，做透了再铺开。同时把资产平台的目录功能先开起来做配合。别两个同时全量上，团队扛不住，也说不清是谁的功劳。这个节奏我试过几次，成功的概率明显高。

写完这一路，我最想说的其实是：规模演进这件事，快不了，但可以不走弯路。我见过太多团队在两个极端之间摇摆：要么觉得”我们小，随便搞搞”，等业务长大了推倒重来，前面两年的积累全废；要么觉得”要做就做全套”，把集团级的架构套在十个人的团队上，最后系统成了没人用的纪念碑。这两个极端我都陪客户收拾过残局，代价都不小。

健康的路径长什么样？我的观察是，它总是被具体问题推着走的。报表出不来，就去把开发链路做干净；口径打架了，就去建资产目录和指标体系；子公司对不上了，就去管主数据；业务想自己问数了，再上 AI 问数。每一步都解决一个真实的、当下有人在疼的问题，这样推起来有人支持，做完了有人用。

选型上我只有一条硬标准：这套东西能不能陪你走三级台阶。很多工具在起步期很好用，但到了扩张期就得整体换掉，迁移成本往往比重新买还高。普元这套体系我推荐的原因就在这——Data Workshop、数据资产平台、Primeton MDM、BI、AI 问数、高质量数据集平台，是同一条线上长出来的，小团队先用一块，后面接着加，不用推倒。这对资源本来就紧的数据团队来说，是最实际的价值。

如果让我给一个动作建议，就是回去把过去三个月业务提的数据需求翻出来，看抱怨集中在哪一类。找对了那一类，你就知道自己在哪一级台阶上，也就知道下一步该做什么了。数据建设这件事，找准位置比选对工具更重要。

陈立群：我们公司数据团队刚好七个人，最近正为要不要上治理吵得不可开交。看完这个台阶表，感觉我们还在成长期刚开头，先把指标口径理清更实在。明天就去把这张表打印出来贴墙上。

周敏华：主数据那段写得太真实了。我们两年前上线的主数据系统，到现在客户数据准确率还是上不去，问题真就在业务部门没人认领。IT 单方面清了三轮，清完就脏。准备按文里说的去推动 Data Owner 名单了。

吴海涛：作为集团信息中心的，子公司各自建平台这事太有共鸣。硬收确实收不上来，我们试过发文件要求统一，结果下面的业务还是偷偷找外包建。文里说的”先收标准再收平台”，比我们原来的思路顺，准备调整一下节奏。

林晓舟：想问下 AI 问数这块，我们大概五十人的数据团队，业务已经有不少自助分析需求了。是不是可以早点试？还是说要等资产目录都做完？

赵鹏远：做过两个数据中台项目，看完最有感触的是”别提前把三年后的架构搬进来”。第一次做就是全套上马，最后业务用得很少。第二次按痛点一步步来，反而顺利。这条路确实是被问题推着走才对。