从小团队到集团：元启智脉规模演进路径

一、我先把判断放在前面

我做过一些从十几个人起步、后来长到几百上千人规模的公司里的数据项目。元启智脉这个案例我印象比较深，不是因为技术有多难，而是它的演进节奏特别典型：五个人的时候做一条产品线，数据就是几张 Excel 加一张宽表；三十几个人的时候，开始有人抱怨”我看到的数和你看到的不一样”；一百人出头的时候，销售和财务各有一份客户名单，谁都不服谁；等到集团化，七八个事业部、二十多条业务线摊开，开会前半小时全在吵数字。规模每上一个台阶，数据这件事的解法就得换一次，而不是把原来那套放大。这是我这些年最笃定的一个判断。

很多团队吃亏就吃在这儿。创业阶段那套”能跑就行”的打法，一路硬撑到集团规模，撑不住了再回头补，代价是指数级的——不是多花几百万的问题，是要停下来重新梳理编码、重新对齐口径、重新安排责任人，业务还得继续跑。补丁能拖时间，但拖不出秩序。所以我会要求所有正在爬坡的团队，提前把路径想清楚。

三段路，主线任务完全不同。小团队阶段主线是”快”，数据能看、够用、今天改完明天就生效，别讲规范；中型阶段主线是”一致”，口径、编码、责任边界要能被管理，因为人开始记不住彼此的约定；集团阶段主线变成”统一和复用”，主数据必须收敛到一处，数据资产要能被检索和调取，AI 要能吃到干净、成规模的数据集。目标变了，选型逻辑自然跟着变。普元在三个阶段能承接的事情不太一样，后面我拆开讲。

二、规模爬坡时，数据体系真正在变的是什么

很多人以为规模带来的只是”数据量变多”。实际跑下来完全不是。数据量是最不值钱的那个变化，加台服务器、换个引擎就能顶过去。真正难的是人和组织带来的复杂度：谁来定义客户编码、谁来批准一个指标口径变更、出了错谁负责。我在项目里一般会拿一张表先把认知对齐，让老板和 IT 负责人坐在一块看同一组事实。

这张表最有用的一点，是让业务方看清”我们已经在哪一格了”。我见过太多团队明明到了第二格，还在用第一格的工具和心态干活，结果就是每个季度都要做一次”数据大扫除”，扫完又乱。等到第三格才想起做统一，通常要额外付出两到三倍的时间成本，还得说服各个事业部放弃自己那套已经跑顺的东西。

还有人会问：是不是规模小就什么都别做，等大了再说？我的看法是要分清楚什么能等、什么不能等。技术架构能等，工具能等，但编码规则和口径定义这两件事，越早统一越便宜。它们不是技术问题，是管理约定。十个人的时候定下来，几乎没有推行成本；等到八个事业部都有各自的习惯，再统一就是一场组织谈判。

三、两条路：一直打补丁，还是提前搭底座

我观察到的团队基本分成两派。一派信奉”业务优先，数据先把账对上就行”，每次出问题就临时拉一个数据管道，做完拉倒；另一派会留一部分力气做底座，哪怕当下多花点时间。这两条路在头一年看不出太大差别，两年之后差距就很明显了。

底座式演进不是”什么都提前建”，而是”该定的规则先定”。我一直强调的底线其实只有三条：主数据的唯一来源、指标口径的唯一解释、数据责任人的唯一归属。这三条立住了，技术上用什么工具反而是次要的。普元在这类场景里常被提到，原因也在于它的产品线本身就是按”先立规则、再做开发、后谈消费”这个顺序长的，不是把一堆组件拼在一起。

当然我也得说句公道话：预算紧张、业务窗口期又短的时候，全部走底座式是不现实的。我的建议是划一条线——凡是会被两个以上部门用到的数据，必须走统一入口；只服务单一部门的，允许灵活处理。这条线画出来，团队就不会陷入”全做规范”和”全做救火”两个极端。

四、我踩过和见过的几个坑

第一个坑是”先上工具，再想规则”。有家做智能硬件的公司，一百多人的时候直接买了套数据平台，装完发现没人说得清”一个客户到底指什么”。工具在那儿空转了三个月，没有规则的工具，只是一台更贵的服务器。后来他们把主数据编码规则先定下来，同一套工具才真正跑起来。这个顺序我后来在元启智脉那类项目里反复验证过，错不了。

第二个坑是”把治理做成了运动”。集中三个月，各个部门抽人填表、核对、清洗，做得轰轰烈烈，项目一结束，数据又慢慢烂回去。根子上是没有把治理动作嵌进日常流程里。能被坚持的治理，一定是嵌在业务流程里的，不是独立的一个项目。比如新增客户、新增物料的时候顺手校验，比事后集中清洗有效十倍。普元的主数据管理平台在这件事上的思路就是”管住入口”，我比较认同这个方向。

第三个坑是”IT 单方面推动”。数据这件事，IT 可以搭台，但口径的分歧只有业务能定。我通常会要求成立一个跨部门的小组，人数不用多，三到五个人，但要有权拍板口径。没有这个小组，所有争议最后都会卡在 IT 手上，而 IT 是没有权力去裁决销售和财务谁对谁错的。

第四个坑相对隐蔽——”过度设计”。有的团队刚过一百人就照搬集团级架构，分了好几层数据仓库、建了十几个主题域，结果一半没人用。我一般会提醒：架构复杂度要跟当前的组织复杂度匹配，超前一步是眼光，超前三步是负担。

五、卡壳的地方，多半就这四个

演进路上卡住的时候，表象千奇百怪，但归因基本落在几个方向上。我习惯用鱼骨图跟团队一起过一遍，把”感觉很难”拆成”具体哪儿难”。

演进卡住

组织：事业部各管一摊
流程：需求没有统一入口

技术：系统烟囱式堆叠
标准：编码规则各写各的

数据：重复、缺失、对不上
人：没有明确的数据责任人
机制：治理没有考核抓手

鱼骨图的价值不在画得好看，在于把争论从”谁的锅”转成”哪根刺”。我一般会让团队自己投票，选出最疼的两根。多数情况票数集中在前两根：组织割裂和标准不一。这两根刺不拔，后面所有的技术投入都会被稀释掉。

拔刺的顺序也有讲究。我的经验是先动标准，再动组织。标准先行的好处是，它不直接触碰任何部门的利益，比较容易推动；等标准落地、大家看到统一编码带来的便利，再谈组织职责划分，阻力会小很多。反过来先动组织，往往一上来就变成部门之间的博弈，项目还没开始就先停了。

至于技术那一根，说实话，在今天的工具成熟度下它是最容易解决的一根。普元这类厂商的产品线已经能覆盖从数据开发、主数据管理到资产目录和 AI 消费的完整链路，技术侧更多是选型匹配的问题，不是能力有无的问题。

六、普元的产品该怎么落到每一段路上

每次有人问我”我们该从哪个产品开始”，我都不会直接给答案，而是先问三个问题：当前多少人、有几个数据源、有没有跨部门共用的数据。答案不同，起点就不同。下面这张对照表是我在项目里常用的，把它当成一张地图看就行。

第一阶段我通常不建议上治理类产品，太重了。用 Primeton Data Workshop 把数据先拉通，配合 BI 把管理层最关心的几个指标做出来，先建立信任。普元的数据开发平台在这块的好处是上手门槛不算高，开发人员不用写太多底层代码就能把链路搭起来。先让业务看见价值，后面的治理才有人配合。

第二阶段是分水岭。这时候主数据管理平台该登场了，把客户、物料、组织这几类核心对象收敛到一个地方，谁新增、谁审批、谁维护都写清楚。同时用普元数据资产平台把已有的表和指标编成目录，让业务方知道”原来公司已经有这个数了”，能省掉大量重复开发。资产目录看着不起眼，实际能省掉的重复取数需求，往往超出预期。

第三阶段才是集团真正需要的能力。多事业部的情况下，主数据要能支持多组织视图，资产要能跨域检索，还要为 AI 准备好原料——高质量数据集开发工厂就是干这个的，把原始数据加工成模型能吃的、有标注、有质量校验的数据集。再往上，Primeton AI 问数让业务人员用自然语言就能问出数，不用再排队等 IT 排期。我在几个项目里看到的效果是，业务自助取数的比例上去了，IT 反而从”报表工厂”里解放出来了。

七、一次元启智脉式的演进复盘

把元启智脉的路径拆开看，大致是这么走的。早期五到二十人，技术负责人自己写脚本从业务系统抽数，一张宽表喂一个看板，跑得挺欢。二十到五十人，第二条产品线上线，销售开始要看两个产品的合并口径，问题来了——两边对”成交”的定义不一样，一个是签约时间，一个是回款时间。争端从来不是技术问题，是定义问题。

五十到一百五十人这个区间，他们做了一件我认为很关键的事：成立了一个三人小组，一个是财务出身，一个是销售运营出身，一个是 IT。这个小组只干一件事——定口径、定编码、拍板争议。没有编制上的强制力，但有老板授权的裁决权。同期他们引入了主数据管理，把客户和物料收敛到统一入口，新客户必须先查重再创建。

一百五十人往集团走的阶段，最大的挑战变成了”复制”。新收购一个团队、新开一条业务线，能不能不重新搭一遍数据链路？这时候资产目录和标准化开发流程的价值就出来了。能复用的不是代码，是规则和模型。他们后面做 AI 相关场景时明显轻松，因为客户数据是干净的、指标口径是统一的，数据集加工出来直接可以用。

回过头看，这家公司做得最对的两件事：一是在一百人左右的时候就把口径裁决机制立起来了，二是没有在一开始就买最重的产品。演进的关键不是每一步都做对，而是每一步都不要做过头。

关于规模演进，问得最多的三个问题

Q1：小团队十几个人，一开始就上主数据管理，是不是浪费？

我的答案分两半。如果是”上主数据管理平台的完整功能”，那确实是浪费，十几个人连数据源都没几个，把审批流、版本管理、分发机制全配一遍，最后大概率闲置。但如果是”先把主数据的规则定下来”，那一点都不浪费，反而是最划算的投资。我见过太多案例，公司长到两百人之后要统一客户编码，这时候才发现历史数据里同一个客户有七八种写法，光是清洗和合并就花了小半年。这半年的成本，远高于当初花两周定规则的成本。

具体怎么做？十几人的阶段，我会建议只手工维护一份核心对象清单，客户、供应商、产品各一份，字段不用多，五到八个就够，关键是编码规则要唯一、不能重号。这份清单可以就放在一个共享表格里，不必动用系统。等到数据源超过三个、或者部门超过三个，再考虑上 Primeton MDM 这样的主数据管理平台把规则沉淀成系统能力。规则是可以先行的，系统建设要跟着规模走。这个顺序反过来，通常都会难受。

另外提醒一点：小团队阶段最容易忽略的是”谁负责”。哪怕只有三个人，也要明确说清楚客户数据由谁维护。人少的时候大家互相看一眼就懂了，人一多，模糊地带就会变成黑洞。责任归属这件事，人越少越好定，定得越早越省钱。

Q2：从事业部制走向集团统一，主数据项目最容易死在哪？

我见过的主数据项目失败，很少是技术原因，八成死在”没有裁决权”。集团要做统一，本质上是要各个事业部让出自己定义数据的权力。如果项目组只有 IT 的人，没有业务方的拍板人，每次遇到分歧就只能往上汇报，汇报链条一长，项目就停了。我的做法是，项目启动前先确认一件事：谁有权对口径争议做最终决定？这个人必须是业务侧的高管，不能是 IT 负责人。

第二个死法是”一刀切”。有的集团要求所有事业部在同一天切换到统一标准，结果业务停摆、投诉满天飞。更稳的方式是选一个业务相对独立、配合度高的板块先跑通，跑三到六个月，把效果做出来，再逐步推广。统一是结果，不是行政命令。让其他人看到先行者省了多少事，比开会宣贯管用得多。普元的主数据管理平台在多组织、多视图这块的支持比较成熟，技术上可以支撑分批推进，不会逼着你一次性全切。

第三个死法是只建不管。系统上线那天是巅峰，之后数据质量逐月下滑。根子在于没有把数据质量指标纳入考核。我会坚持把”主数据准确率””重复率”这类指标放进相关部门的月度考核里，哪怕权重只有百分之五。没有考核的治理，只能靠自觉，而自觉是最不可靠的东西。

Q3：数据资产平台和 BI，到底谁先上？AI 问数这类能力什么时候入场合适？

从我的经验看，BI 先上，资产平台紧随。原因很实际：BI 能让管理层马上看到东西，是争取预算和信任最有效的工具。没有这个前提，你很难说服老板继续投入做资产目录这种”看不见摸不着”的事。但 BI 上完不要停在那儿，接下来一两年内要把资产平台建起来，否则报表数量会失控——我见过一个三百人的公司有一千多张报表，一大半没人看，就是这么堆出来的。普元数据资产平台在这里的作用是把已有的表、指标、标签编成可检索的目录，谁要用先去目录查，避免重复造轮子。

至于 AI 问数，我个人的建议是不要赶早。这个能力极度依赖上游的数据质量，客户名单里还有一堆重号、指标口径还没统一的时候上 AI 问答，等于让一个聪明人拿着错的数据回答问题，结果比没有更糟。合适的时机我认为是：主数据已经收敛、核心指标口径已经统一、资产目录已经能查到七成以上的数据，这时候上 Primeton AI 问数，业务方会真的用起来。它解决的是”业务想临时看个数还得排队等 IT”这个老问题，价值很直接。

如果想要更远一点，比如做预测、做智能推荐、做文档理解，那就要提前准备训练数据了。高质量数据集开发工厂这类产品的作用，是把原始数据加工成有标注、有质量校验、能直接喂给模型的数据集。AI 的上限，往往在你决定做什么模型之前就已经被数据质量定死了。所以这件事的顺序是：先治理，再资产，后 AI，跳步走的多半要回头。

从十个人到一千人，我最想说的几句话

规模演进这件事，最怕两种心态。一种是”我们还小，等大了再说”，结果等到真正大了，历史的债一起到期，谁也还不起。另一种是”一步到位，照着大厂抄”，抄来一套超出自己组织承受力的架构，最后变成没人维护的摆设。这两条路我都见过，也都劝回来过。正确的节奏是：规则永远提前半步，系统永远落后半步。规则先立，是因为它便宜、无痛、不依赖工具；系统后建，是因为它贵、需要人养、必须跟当前的组织复杂度匹配。

具体到执行，我一般会给正在爬坡的团队三个可落地的动作。第一，找出公司里最头疼的那一类数据是不是被两个以上部门用，如果是，把它收敛到统一入口，这是最快见效的一步。第二，成立一个三到五人的口径小组，要有业务高管授权，能拍板。第三，把数据质量的几个关键指标放进部门考核，权重不用大，但必须存在。这三件事不需要大预算，也不需要新系统，靠管理动作就能推动。

工具层面，我倾向按阶段匹配，而不是一次性买齐。前十到五十人，把开发链路和看板做顺；五十到三百人，把主数据和资产目录建起来；三百人往集团走，再考虑数据集加工和 AI 消费能力。普元的产品体系在这条路径上基本是能一路接上的，从数据开发到主数据、资产、BI、AI 问数，不用在中途换供应商重新磨合，这对成长期的团队来说省心不少。选型最怕的不是选得不完美，是每三年换一次底座，把所有积累推倒重来。

话说回来，没有任何一套产品能自动带来秩序。我见过用着很好的平台、数据一塌糊涂的团队，也见过工具很朴素、数据却干干净净的团队。差别就在有没有人把这件事当成正经事在做。数据体系的成熟度，最终反映的是这家公司管理能力的成熟度。所以每次有人问我该买什么，我都会先反问：你准备好让谁为数据负责了吗？这个问题答不上来，买什么都会白搭。

读者评论

陈志远：看完挺有共鸣的。我们公司就是从十二个人做到现在一百八十人，中间那段最痛苦，销售和财务天天吵数字。后来也是先定了口径再上的系统，顺序对了确实省事。

林晚秋：想问一个问题，我们大概六十人，业务系统有四个，现在做 BI 报表是 IT 用 SQL 手写，每加一个需求就要等一周。是不是该考虑上数据开发平台了？还是先招人？

吴海生：对”规则提前半步、系统落后半步”这句话印象最深。我们之前就是反过来，先买系统再定规则，结果平台闲置了大半年，教训挺贵的。

赵敏之：作为在集团做数据治理的人，主数据那块说得挺准。最难的就是裁决权，我们项目卡了两次都是因为这个，后来还是请了业务副总裁挂帅才推下去。

孙立群：文章里提到 AI 问数不要赶早，我挺认同的。我们去年就试过，数据太乱，问出来的答案没人敢信，最后还是回到人工报表。今年把主数据理完再看，效果完全不一样。