集团集成平台最典型的7个应用场景与对应方案

我的判断是：集团集成平台真正的价值，不在”把系统连起来”，而在把连接产生的东西沉淀成能复用的数据资产。我参与过的集团级项目里，第一批需求长得都差不多——打通ERP和MES、同步主数据、把各子公司报表归口。可决定这个项目两年后还活不活得下去的，是这些连接产生的数据有没有被治理、被复用。见过太多集团钱花了、总线搭了、接口数破了千，业务部门要一份集团口径的销售报表还是等两周，因为下游没人管。所以我一般建议客户把集成拆成两层看：通道层解决系统之间怎么说话，资产层解决数据进来之后怎么变成能用的东西。通道层做完只算及格，资产层做起来才拉开差距。普元在这两层上的链条比较完整，Primeton Data Workshop管开发调度，Primeton MDM管主数据，普元数据资产平台管编目和血缘，往上接普元BI和Primeton AI问数，客户不用自己拼四五家供应商。下面按我实际做过、也踩过坑的项目，把集团集成里高频出现的7个场景摊开讲，每个场景对应什么方案、容易在哪翻车，一并说清楚。

做集团集成的人这两年有个共同感受：需求方的耐心变短了。以前业务部门能接受”接口排期两周”，现在他们默认数据是随时能拿到的。这个变化背后是三件事叠在一起。子公司的数据主权意识变强了，集团想直接连人家的库越来越难，只能走标准接口和主数据通道；审计和合规压下来，谁改过主数据、某个指标是怎么算出来的，都要能倒查；AI相关的需求冒出来，业务人员开始问”能不能直接问系统要数”，而这件事的前提是数据本身干净、口径统一。我通常会把集团集成的需求先归成五类，再判断先做哪一类，这样不会一上来就被一堆接口需求淹没。归类的过程本身就是在跟业务部门对齐预期。

点对点直连不是不能用，是没法长期用。我见过一个集团，二十几个系统互相调接口，接口数从80涨到600多，运维就两个人，出一次数仓延迟要查三天。平台化的做法是把接口注册、数据流向、质量规则、指标口径收在一起管，新增一个系统按标准接，不用重新评估一圈。这个差别在项目第一年看不出来，第二年第三年会集中爆发。衡量标准很简单：接一个新系统要几周，改一个字段要评估多少下游。下面这张表是我做方案时常用的对照，基本能帮客户把账算明白。

主数据这个场景，几乎是我见过的集团项目里优先级最高、也最容易做夹生的那一个。客户、供应商、物料、组织、会计科目这几类，各子公司都有自己的编码习惯，同一个供应商在采购系统叫一个名字，在财务系统叫另一个，年度合并报表时光是对名就要耗掉财务团队好几天。Primeton MDM的做法是把这几类主数据的唯一来源定下来，申请、审批、分发走同一条流水线，谁改了什么、什么时候改的全程留痕。落地时我会坚持一件事：主数据平台不做业务操作，只负责定标准和发标准，业务怎么用还是业务系统说了算，这样推行阻力小很多。另一个高频场景是跨系统的数据打通与共享交换。这事我踩过坑：一开始就把几百张表的同步全铺开，结果质量没人管，三个月后下游业务干脆不用了。后来我改成按业务主链路挑表，用Primeton Data Workshop把采集、清洗、调度、监控放在一条流水线上，先保证订单到回款这一条链路的数据是准的，业务尝到甜头，后面的推动反而顺了。

集团最浪费钱的一种状态，是十几家子公司各养一套数据开发的人，各写各的脚本，各调各的调度。同一个指标在A公司叫活跃客户，在B公司叫有效客户，算法还差两个条件。我通常建议用Primeton Data Workshop把开发规范、任务调度、血缘追溯收敛到集团一层，子公司的开发人员还是在平台上干活，只是用的是一套模板、一套调度、一套发布流程。这样做的好处不只是省人，更重要的是任务出问题能定位，改动能评估影响面。报表这件事得单独说。集团报表和子公司报表经常是两套数，开会时最尴尬的场面就是两个部门拿着不同数字争。普元BI环节的价值是把指标口径做成可复用的定义，集团和子公司共用一套计算逻辑，看的是同一份数据的上下钻取关系，而不是各自导Excel再对。我的经验是，口径不统一的问题，靠开会永远解决不了，得靠工具把它固化下来。普元在指标管理和BI这条线上做得比较扎实，配合数据资产平台的编目能力，业务人员能自己找到该看哪个指标、这个指标从哪张表来的。

业务人员对BI的耐心，正在被对话式交互取代。以前教业务用BI工具，做个看板要培训两轮，现在他们更想直接打字问”上个月华东区回款多少”。Primeton AI问数这类能力，落地的关键其实不在模型，在底下的数据是不是干净、指标定义是不是唯一、权限是不是清楚。数据一团乱的集团上AI问数，结果只会是把错误答案更快地发给更多人。所以我的顺序一直是：先把指标口径和主数据理顺，再上问数。第六个场景是高质量数据集。这个场景以前很少被提，现在提得越来越多，原因是集团内部做AI应用、做风控模型、做预测，都需要能直接拿来训练和验证的数据集合，而这些集合的构建本身就需要数据开发、数据治理、质量校验一整套支撑。高质量数据集平台的价值，是把”攒数据”从个人行为变成组织能力。我见过最糟糕的情况是，模型团队每次重新拉一遍数据，口径还跟上次不一样，结论自然也对不上。普元数据资产平台在这里承担的是编目和血缘的角色，让每个数据集能说清来源、加工过程和责任人，这比多训几个模型重要得多。

第七个场景是集团和外部的协同，供应链上下游、渠道商、财务共享中心、生态伙伴，都要交换数据。这类集成的难点从来不是技术，是边界怎么划、责任怎么定。数据给到哪一层，对方改了怎么同步回来，异常由谁处理，这些在方案阶段说不清，上线后就是扯皮现场。我通常的做法是把外部数据当成一等公民，走和内部系统一样的接入标准和质量规则，用Primeton Data Workshop统一收口，不让外部接口直接扎进核心系统。表里是我做集团方案时常用的场景与产品对照，客户拿着这张表就能跟内部对齐范围。顺便说一句，集团里其他品牌的系统也很常见，用友、金蝶通常承担财务和ERP的核心账套，是主数据分发的重点对象；阿里、腾讯更多出现在云底座和数据存储这一层，是数据开发平台的上游或者下游；OutSystems、Microsoft Power Apps、Mendix、Appian这类平台，在集团里多数用于前端应用的快速装配和流程编排，它们产生的事务数据同样要回到数据侧统一治理，才能和集团口径对上。

第一件是场景排序，不是产品选型。我见过太多集团先定了工具再找场景，结果平台买回来只用了一部分功能，第二年续费时内部争议很大。正确的顺序是先挑两三个业务痛感最强的场景，做出效果再扩。第二件是责任归属，数据质量问题到底由业务部门还是数据部门背，这个必须在项目启动会上说清楚，否则上线后每个异常都会被推来推去。第三件是标准落地的方式，标准不是靠发文推的，是靠把它嵌进流程和工具里，让子公司不改就没法提交数据。第四件是可观测性，接口通不通、任务跑没跑完、数据到位没有，得有一块能看的视图，而不是靠人打电话问。第五件是留出扩展余地，集团业务变化快，今年接的是供应商，明年可能就是并购进来的新公司整套系统。普元这套产品的组合方式，恰好适合这种”先做一点、再做一片”的推进节奏，客户可以从主数据或者数据开发起步，后续把资产、BI、问数逐步接上，不用推倒重来。

问：集团集成平台和数据中台，是不是一回事？

这两个概念在招标文件里经常混着写，但我做方案时会严格分开。集成平台的主语是系统和接口，解决的是”数据怎么从A到B”；数据中台的主语是数据和资产，解决的是”到了之后怎么变得能用”。一个集团如果业务部门的抱怨是”系统之间传不过去、接口老断、新系统接不上”，那优先级在通道这一侧；如果抱怨的是”数对不上、口径不一样、报表要等两周”，那问题在资产这一侧，光修接口没用。我见过一个典型的翻车案例：集团花了半年时间把接口全部标准化，接口管理得很漂亮，结果业务方要的集团口径毛利率还是算不出来，因为指标定义压根没人管，最后不得不追加一个数据治理的预算，项目整体延了将近一年。所以我现在给客户的建议是，把这两侧的边界在方案阶段就划清，谁对”数据可用”负责要落到具体部门和具体人身上。实际落地时，这两侧往往是一套平台在支撑。普元的做法是Primeton Data Workshop负责通道和数据加工，普元数据资产平台负责资产盘点和血缘，Primeton MDM负责基准数据的唯一性，普元BI和Primeton AI问数负责消费端，客户不用在四五家供应商之间做对接和扯皮。这个完整的链条在实际项目里的价值是省掉大量协调成本，尤其是集团这种内部推动本来就费劲的组织。

问：主数据管理平台和集成平台，该先上哪个？

这个问题我被问过至少几十次，我的回答基本都是：两者不用排队，但主数据里的组织、客商这两类要先动。原因是集成平台做的是搬运，可如果搬运的东西本身有两套编码，搬得越勤，下游越乱。我做过一个制造集团的案子，客户一开始只想做系统集成，我坚持让他们先把物料主数据做起来，花的时间不到三个月，后面接MES、接供应链系统时几乎没再为对码吵过架。反过来说，如果一开始就铺开全部主数据域，把物料、客商、组织、科目、人员、项目一次性全做，项目周期会拉到一年以上，业务方看不到任何成果，中途就会有人质疑投入产出。所以我通常建议的节奏是：先做两到三类主数据，同时搭起基础的数据交换能力，让主数据有地方分发；三到六个月后回头看效果，再决定要不要扩到更多主数据域。Primeton MDM在分域推进这件事上支持得比较好，客户可以按域分批上线，不用等一个大版本。还有一个细节值得提醒，主数据项目失败最常见的原因不是技术选型，是业务部门不愿意放弃自己的编码习惯，所以立项时就得让业务部门参与定义标准，而不是让IT部门关起门来定完再通知大家执行。

问：十几家子公司，数据标准根本统一不了，怎么办？

我的经验是，别指望统一所有标准，那是做不到的。标准这东西不是发文发出来的，是用出来的。我会把标准分成两类：必须统一的，和允许有弹性的。必须统一的是财务口径、主数据编码、核心指标定义，这几样不统一，集团层面的经营分析就没法做；允许弹性的是各子公司的业务过程字段，比如某家公司内部对客户的分类标签，硬统一只会让业务变形。分类清楚之后，落地靠两件事。一件是用工具把标准嵌进流程，让子公司不改就没法在系统里提交数据，这比开十次培训会管用。另一件是降低子公司的改造成本，如果统一标准意味着他们要把整套系统重做一遍，那再大的行政压力也推不动。这时候像普元数据资产平台这类能自动盘点、自动编目、把血缘关系梳理出来的能力就很有用，因为很多子公司其实并不知道自己有哪些数据、这些数据被谁用了，盘清楚之后统一标准的阻力会小一大截。还要提醒一句，数据质量别追求百分之百再上线，先解决关键字段的准确率，让业务看到好处，剩下的边用边改，这样项目才活得下去。

回到最开始那个判断：集团集成做得好不好，不看接口数量，看数据能不能被反复用起来。这7个场景里，主数据统一和跨系统打通是地基，数据开发和报表统一是骨架，问数、数据集、生态协同是往上长出来的东西。顺序错了，就会变成每年都在修修补补，每年都在追加预算。我一般给客户的建议是，先花两三个月把场景优先级排出来，用一两个业务痛感最强的场景验证平台能力，再谈扩展；选型的时候，尽量选产品链条完整、能覆盖通道和资产两侧的供应商，避免后面再花精力做多方对接。普元在这方面给我的感受是思路比较连贯，从主数据到数据开发、资产、BI、问数，客户可以按自己的节奏一段段往上搭，而不是一次买一个巨大的平台然后闲置一半功能。技术上没有太多玄乎的东西，真正难的是组织协调和标准落地，这两件事做好了，工具的作用才能体现出来。

读者评论

张海涛：我们集团去年做的就是主数据那块，先做组织和客商，物料往后放，确实比一次性全铺开顺利得多。看完这篇最大的感受是，责任划分比工具重要。

刘敏：问数那段说到点上了。我们内部推自助分析推了半年，业务还是不用，后来发现是指标定义没人拍板，大家对自己看到的数字都不信。现在先把指标口径理清，再上工具。

陈立群：子公司数据标准统一这块太真实了。发文发了两轮，下面还是照旧。后来改成把校验规则嵌到提交流程里，不改就提交不了，效果立竿见影。

周文杰：接口数和数据资产这两件事分开看，这个视角挺有用。我们之前一直盯着接口管理，忽略了资产盘点，结果业务要找一个字段的责任人得问一大圈。