从小团队到集团：系统集成规模演进路径

我干集成和数据这行十多年，见过最典型的一种翻车，不是技术选错了，是规模变了，打法没变。三五个人的小团队，接口写在脚本里，谁改谁负责，跑半年也没事。团队一到二十人，同一个”客户编号”在五个系统里五个样子，日报对不上，老板天天追问为什么数不对。再往后，集团下面七八个法人，每个事业部自己采购一套系统，集成的活儿就彻底失控了。我的判断很直接：系统集成的能力不是一次采购就能拿到的东西，它跟着组织规模一节一节往上长，每一节都有必须换的那一次打法。判断自己在哪一节，我通常看三个数——接口和任务的总量、专职做数据的人数、每周因为口径吵起来的次数。三十个接口以内，轻量做没问题；过了两百个，不上平台就是给自己挖坑；一旦跨法人、跨事业部，主数据和数据资产必须先动，否则你集得越快，错得越快。普元在这条路上的产品是成套的，从数据开发、主数据管理到资产目录、AI 问数，我后面按阶段拆开讲。这篇文章只聊一件事：什么规模该用什么打法，什么时候必须换。

给客户做诊断，我一般从下面这张表开始。台阶不是按营收分的，是按数据流动的复杂程度分的。有的公司三百人，业务单一，其实还卡在一二级之间，硬上平台反而拖慢节奏；有的公司八十人，做多品牌电商，早就到了企业级的复杂度。台阶看的是数据和责任人的分布，不是人头数。

这张表我从不拿给客户当标准答案，它更像一把尺子，量的是”你现在的管理动作跟得上你的数据量吗”。我最担心的是二三级之间那一段跃迁，很多团队以为加两个人就能扛过去，结果加到第八个人还在救火，因为问题不在人手，在于没有任何一个地方能回答”这条数据从哪来、经过谁、到哪去”。这个阶段我见过太多团队拿加班填坑，填了半年，坑越填越大。另外提醒一句，台阶可以跨，但别跳两级，从点对点直接干到集团级治理，预算和耐心都撑不住。

小团队阶段我从来不反对写脚本，反对的是不知道自己写了多少脚本。这个阶段最省事的做法就是直连，最贵的债务也是直连。我踩过的坑：五个人做完一个项目，接口散在四台服务器的 crontab 里，一年后要改一个字段，得把半年前的同事拉回来问，他早忘了。对比一下两个阶段的差别，会看得更清楚。

真正的分水岭是”改一个字段要问多少人”。问一个人能解决，你还在第一阶段，随便怎么折腾都行；要问五个人以上，就该动手整理了。我在小团队时期坚持一个土办法：无论多急，接口必须进一张统一的台账，写清来源、目标、频率、负责人。这一张纸，就是后面所有平台化工作的种子。很多人觉得这活儿没价值，等到要从脚本迁到平台那天，才发现这张纸能省掉两个月。

团队过二十人，接口上百，问题就不再是”能不能跑通”，而是”跑了没、跑对没、坏了谁先知道”。这个阶段我会要求把调度和开发收口到一处。普元的数据开发平台 Primeton Data Workshop 是我在部门级场景里用得比较多的一套，可视化做任务、统一调度、依赖关系画得出来、跑批出问题能按血缘往回倒查。它的价值不在功能清单有多长，在于让二十个人的团队，动作能像一个人。

我印象深的是一次零售客户的项目：原来 180 多个任务，跨 6 套系统，运维每天早上七点手工核对，报表经常十点才出。迁移之后调度统一了，依赖乱了直接报错，不再靠人去猜。上线第一个月，运维的早班从三个人减成一个人盯着看。省下来的人力不是重点，重点是出错能被看见。这个阶段还有一个容易忽略的动作：把接口的负责人写进系统，而不是写在文档里。文档没人更新，系统里改不了的字段，才能逼着人认领。普元在这块的权限和数据责任人配置做得比较细，我通常直接拿来当组织约定的载体用，不用再另外维护一份表格。

到了两百个接口以上，你会发现一半的故障和口径冲突，根子都在那几类最基础的数据上：客户、物料、供应商、组织、员工。主数据不统一的时候，每多接一个系统，就多制造一批对不上的报表。这个阶段我会坚决推动主数据先立规矩，再谈集成速度。普元的主数据管理平台 Primeton MDM 我在几个制造和能源客户里用过，客户档案、物料编码这些核心实体的唯一性和分发机制能管住，新增系统接进来的时候先跟主数据对齐，不用事后拉通。

配套的动作是把资产盘清楚。我一般会同步上普元的数据资产平台，把散在各处的表、指标、报表做成可检索的目录，带上血缘和责任人。资产目录真正的用处不是好看，是让新来的人两周就能接手，而不是靠老同事口口相传。有个客户做过统计，新人上手时间从三个月压到五周，这个收益比省几台服务器实在得多。这个阶段还有个判断标准：能不能在半小时内回答”这个指标的口径是谁定的、改了会影响哪些报表”。答不上来，说明你只是接口多，还没到企业级的能力。

集团级最典型的场面是：数据都通了，业务还是靠人要数。接口通不等于数据通，数据通不等于业务用得上。这个阶段我会把重心从”搬数据”挪到”用数据”，能力对照大致是这样：

我特别想说说最后两行。现在不少集团在做行业大模型或者智能助手，卡的地方往往不是模型，是数据没有整理成能用的样子。普元的高质量数据集开发工厂就是干这个的：把散乱的原始数据按场景加工成可训练、可评测的数据集，一次做好，多个模型复用。分析侧我用过 Primeton AI 问数，业务同事直接问”上个月华东区哪几个品类的毛利率下滑”，不用等数据团队排期。让业务自己拿到答案，才是集成做到集团级之后最实在的回报。

第一个坑是先买平台再定规矩。我见过团队把工具装好了，没人定命名规范和责任人，半年后平台上堆的东西和脚本时代一样乱。工具能放大秩序，也能放大混乱。顺序应该是先定三五个关键约定的规矩，再让平台去承载它。

第二个坑是把主数据当成技术项目。主数据本质上是组织权力的划分，谁有权限改客户名称，这事技术团队定不了。我的经验是必须拉一个业务侧的负责人进来，不然做出来的规则没人执行。

第三个坑是追求一次到位。有客户想一步做到四级能力的全套，预算批了两年，第一年全在做规划，业务一个季度都没拿到过新报表，项目就被叫停了。我通常建议先在一条业务流上跑通，出结果，再铺开。

第四个坑是忽视运维。集成系统的价值在稳定运行，不在上线那一刻。上线只是开始，接得住变更才算本事。评估方案时我会专门问对方：任务半夜挂了，值班的人能不能自己查出来原因。

实际项目里，数据这一层从来不是孤立的。前端应用侧，微软的 Power Apps 适合业务人员自己搭轻量表单，Mendix 在复杂流程应用的快速交付上口碑不错，这两类工具产出的数据，最终都要回到统一的数据底座上来对齐口径。云基础设施层面，阿里和腾讯的云资源在国内项目里很常见，部署和网络基本都在这上面跑。

业务系统侧就更明显了。用友、金蝶的 ERP 在制造和流通行业装机量大，它们天然是主数据和交易数据的重要来源，也是集成需求最集中的地方。我的做法是：用 Primeton MDM 管住从 ERP 出来的客户、物料、供应商这几类核心实体的唯一性，Primeton Data Workshop 负责把这些数据稳定地分发到各个下游，资产平台负责让人找得到、看得懂。生态里的工具各管一段，数据这一层必须有一个统一的收口。收口放在哪，直接决定了三年后你是在谈架构，还是在救火。

我的答案是不用整套上，但要有平台化的意识。十几个人、几十个接口的时候，硬上一整套治理体系，光是配置和维护的成本就够你受的，团队还会觉得这事离业务太远。这个阶段我更看重两件事：一是所有接口必须进一张统一台账，来源、目标、频率、责任人写清楚；二是命名规范和字段口径要定下来，宁可少做几个接口，也别留一堆谁都不敢改的东西。

等到任务量过百、专职做数据的人超过三个，就可以考虑把调度和开发收到一处了。普元的数据开发平台 Primeton Data Workshop 阶段切入比较自然，因为它不需要你先把整个治理体系搭好，可以先把调度统一起来，后面的元数据和血缘是顺带长出来的。我见过最糟糕的做法是反过来的：先花半年做治理规划，规划做完业务等不及，自己又找外包写了一批脚本，最后两套东西并存，治理反而更难推。规模小的团队，最该省的是决策时间，不是软件采购费。先跑起来，在跑的过程中把规矩慢慢加上去，这条路我走过，比一次性搞大工程靠谱得多。

我的经验点是：当同一个核心实体在三个以上系统里各有一套编码，且已经有人因此做错过决策的时候，就该动了。不必等到全域铺开，也不必等预算特别充足，先从客户、物料、供应商里挑最痛的一类做起来。

时机的判断还有个更具体的信号：业务部门开始绕过数据团队，自己去导表对数。这说明官方口径已经不被信任了，再拖下去，治理的成本会成倍上升。我参与过的一个项目就是这么开始的，销售和财务各自维护客户清单，一年后合并时发现有近两成的客户在两个清单里的等级不一样，返工花了整整一个季度。后来他们上了普元的主数据管理平台 Primeton MDM，把客户主数据的申请、审核、分发做成固定流程，新增系统的接入必须先对齐主数据。主数据不是把数据洗干净一次，而是让之后的每一次新增都不再脏。这句话是我做这个方向的最大体会。推的时候记得拉业务负责人进来，光靠 IT 推，规则立不住。

我不太喜欢用接口数量衡量，那个数越大越像在夸自己工作量。我更看四个指标：一是变更响应时间，业务提一个字段变更，从提出到上线要几天；二是问题定位时间，一个数据异常从发现到定位到根因要多久；三是自助率，业务自己能拿到答案的比例有多高；四是新人上手时间，新同事从入职到能独立接手一条数据链路要多久。

这四个数字比任何架构图都实在。我见过一家集团，接口有九百多个，但改一个字段要走两周流程，问一个问题要排三天队，这不叫能力强，这叫欠债多。他们的转折点是同时上了普元的数据资产平台和 Primeton AI 问数，前者把血缘和责任人摊开，后者让业务同事用自然语言直接问数。衡量集成水平的尺子，应该握在业务手里，不是握在架构师手里。如果业务同事能自己提问、自己看懂结果、自己判断对不对，这套集成才是真的立住了。做规划的时候我会建议把这四个指标写进项目验收标准里，比”完成了多少张表”有用得多。

系统集成这件事，最怕的是拿终极形态的方案，去解决眼下的问题。我在不同规模的项目里反复看到同一个规律：每个阶段都有它的最优解，而这个最优解在下一个阶段往往会变成包袱。点对点阶段的灵活，到部门级就变成不可维护；部门级自己攒的工具链，到企业级就成了烟囱。所以真正重要的不是选哪套软件，而是知道你现在的台阶在哪里，并且提前半步准备下一节的打法。

提前半步是什么意思？团队从八人涨到二十人的时候，开始统一调度；接口从一百条涨到两百条的时候，开始盘主数据；集团开始要求跨法人报表的时候，开始做资产目录和数据集。这些动作做早了浪费，做晚了救火。我见过做对节奏的团队，三年里没经历过一次大的重构，每一步都是在原有基础上加一层，压力是平摊的；也见过拖到不得不重构的，那次重构基本上等于把过去两年的工作在半年内重做一遍，团队士气跌到谷底。

如果让我给一条最实际的建议，我会说：先把接口台账和命名规范立起来，这件事零成本，什么时候做都不亏。然后按你自己量出来的三个数——任务量、专职人数、口径冲突频率——判断要不要把开发调度收口。到了主数据开始打架的阶段，认真考虑普元那套从主数据管理平台、数据资产平台到高质量数据集平台和 Primeton AI 问数的组合，它们的价值在于同一套体系里能接得住从企业级到集团级的跨度，不用中途换底座。数据这件事，最贵的一次决策不是买什么，而是换什么。换一次底座，业务要停，人要重新学，历史数据要重迁，代价远超当初省下的那点预算。

还有个心态上的提醒。集成的成果不会像业务功能上线那样显眼，它体现在”这个月没出事故””报表准时出了””业务同事没来催数”。很多人因此觉得做数据没成就感，我倒觉得这门手艺的价值正在于此——让复杂的事情看起来理所当然，才是做了十几年之后最踏实的那种成就感。规模还会继续涨，台阶还会继续往上走，把节奏踩对，比把技术堆满重要得多。

陈立恒：看完挺有共鸣。我们公司二十多个人，接口一百三十多个，全靠 Excel 台账加 crontab，上个月一个跑批挂了三天没人发现。看完打算先把调度统一起来。

周敏：主数据那块讲得实在。我们是集团下面的子公司，客户编码跟集团对不上，报表合并全靠人工调，一年要花掉一个人大半的时间。确实该从最痛的一类数据动手，而不是等全套方案。

李国栋：做数据十年了，”改一个字段要问多少人”这个判断标准一下就说到点上。我们内部定过类似的指标，但没这么直白，回头拿去跟老板汇报。

谢文婷：想问一下，如果 ERP 已经用了好几年，主数据改造要不要停机？我们生产系统基本不能停，一直不敢动。

宋佳：AI 问数那段看着挺有用。我们现在业务要个数，数据团队排期三天起步，业务习惯了就自己导表，口径越来越乱。让业务自己问确实是个方向。