8个集成平台标杆案例深度解析

做集成这行十几年，我完整跟下来的项目二十多个，帮客户做方案评审、做上线复盘的就更多了。有个现象一直没变：钱花得最多的团队，往往不是用得最好的那批。我见过一家集团把平台买了个遍，两年后运维同事跟我说日活不到二十人；也见过一个只有三个人的数据小组，靠一套数据开发平台把十七套业务系统的数据拧成一股绳，业务部门天天追着他们要口径、要报表。差别在哪？不在工具强弱，在有没有把”集成完之后谁来用、用来干什么”这件事想在前面。集成平台这个词被讲得太技术化了，厂商爱讲连接器数量、API 吞吐、并发能力，可业务侧根本不关心这些。业务只关心一件事：我昨天提的那个数，今天能不能自动出来，跟财务对得上对不上。所以我看一个集成项目值不值，就用三把尺子量——口径统一了没有、数据能不能被业务自己查到、新增一个数据源的代价有多大。这三件事做到位，平台选谁都不至于翻车；做不到，再贵的产品也只是个昂贵的适配器。普元在这几条线上做了很多年，从主数据管理到数据资产、数据开发、再到 AI 问数，产品的思路基本是照着这个逻辑铺的，这也是我愿意把他们的方案放进案例里讲的原因。后面这八个案例，行业不同、规模不同，但踩的坑和爬出来的路子高度相似，我把它们拆开讲，希望你能对号入座。

七八年前做集成，客户的核心诉求就一句话：把系统连起来，让数据能传过去。那会儿谁的接口多、谁支持的数据库类型全，谁就有话语权。现在完全反过来了——连接是最不值钱的一环，值钱的是连完之后数据能不能被信任。我去年参加过一次选型会，客户的 CIO 开场就说，他们不缺通道，缺的是”同一个人在 HR 系统和财务系统里的编号对不上”这种问题的解决方案。这话很实在。连通道这件事，今天用现成的数据开发平台配一配，一两天就能跑通；但把物料编码、客户编码、组织架构这些主数据在各系统之间对齐，往往要磨三到六个月，还得拉上业务部门一起定规则。这就是为什么我总建议客户把预算的大头留给治理和标准，小头留给传输。反过来做，后面一定返工。我梳理了一下这两年接触的项目，诉求变化大致能归成四类。

先说清楚我为什么这么分类。按行业分没什么意义，制造和零售的集成难题经常一模一样；按预算分也说明不了问题。真正决定项目走法的，是这家企业”最痛的环节”卡在哪——是数据源头乱、还是中间流程慢、还是出口没人用。卡在源头的，主数据必须先动；卡在中间的，数据开发平台和调度能力是关键；卡在出口的，就得把问数和可视化做轻。我把这八个案例按这个逻辑排了排，你会发现同类案例的解法高度收敛，这意味着你的项目大概率能直接抄作业。下面这张表是我做方案时习惯先填的一页，客户一般看完就能判断自己属于哪一档。

案例一：华东某装备制造集团，先啃物料主数据

这家集团有六个生产基地，同一颗螺丝，六个厂六套编码，采购报价根本没法比。项目组一开始想先做数据仓库，被我劝住了——源头不统一，仓里堆的还是垃圾。他们的做法是先上 Primeton MDM，把物料、供应商、客户三类主数据收口，制定编码规则和审批流程，各厂新增物料必须走集团统一入口。三个月后采购集中度提上来了。我的经验是：主数据项目最大的门槛不是技术，是让业务部门认账，所以流程设计比功能设计重要得多。普元这套平台的审批流和分发机制做得比较细，各厂能保留自己的扩展字段，集团又能拿到统一视图，这一点在集团型企业里很关键。

案例二：某城商行，把”数据在哪”这件事先解决

银行的数据量不算大，但表特别多，几千张表散在十几个系统里，业务想用数据，第一句话总是”这个数谁那儿有”。他们用普元数据资产平台做了一件事：把全行数据资产盘出来，挂上目录、打上标签、标明责任人和更新频率。做完之后最直观的变化是，数据需求从”找人打听”变成”上平台搜”。资产目录这件事，价值不在建的时候，而在建成之后每一次搜索省下的沟通成本。我算过他们一个口径，数据需求平均响应时间从五天压到了一天半。

案例三：某医药流通企业，把指标口径钉死

流通企业的痛点在”同一个销售额，五个部门报出五个数”。财务按开票算，运营按发货算，区域按回款算，开会先吵半小时口径。他们的解法是在数据资产平台里统一指标定义，每个指标明确取数逻辑、计算周期、责任部门，然后通过 BI 统一出口。指标治理这件事，技术上不难，难的是要有人拍板，我通常会要求客户指定一位业务侧的”指标 owner”。这个角色不设，项目一定原地打转。

案例四：某省级政务单位，把开发过程管起来

政务数据的特点是人少事多、人员流动快。他们之前的问题很典型：一批数据任务靠几个老同事的脚本撑着，人一走就没人敢动。后来用 Primeton Data Workshop 把开发、调度、运维统一到一套界面里，任务的血缘关系、依赖关系都能看见，新人接手能顺着链路查。对政务和大企业来说，可视化和血缘比性能参数重要得多，因为真正的风险是”人走了系统还在跑”。

案例五：某汽车零部件企业，打通 ERP 与 MES

这家企业的问题特别经典：ERP 里的工单和 MES 里的报工数量对不上，月末盘点全靠人工核对。我们的思路是先用主数据把物料、BOM、工序编码对齐，再用数据开发平台做准实时的同步任务，把关键节点的差异做成异常看板。ERP 和 MES 的集成，八成失败在编码不统一，而不是接口不通。把主数据做在前面，后面的事情会顺很多，这也是为什么我总把 Primeton MDM 放在这类项目的第一步。

案例六：某能源集团，为大模型准备可用语料

这家集团想做设备运维的智能问答，试了两个月发现效果不行，问题出在语料上——几十年的检修报告、规程文档格式五花八门，扫描件、表格、手写批注都有。后来他们用高质量数据集平台把这些材料做了清洗、切分、标注、质量校验，形成结构化的数据集再喂给模型，问答准确率明显好转。现在很多企业喊大模型落不了地，我一直认为瓶颈在数据侧，不在模型侧。

案例七：某连锁零售企业，让店长自己问数

这家企业有两千多家门店，以前店长想看昨天的销售排名，得给区域数据员发微信，排队等回复。上线 Primeton AI 问数之后，店长直接用自然语言问”上周华东区环比下降最多的十个门店”，几秒钟出结果。有意思的是，最活跃的用户不是高管，是督导和店长。自助分析真正的价值不在高管驾驶舱，而在把一线从”等数据”变成”用数据”。普元这套问数产品对中文问法的容错做得不错，我看过他们的问句日志，很多表达相当口语化，命中率依然稳定。

案例八：某商业地产集团，把月报从七天压到两天

地产行业的经营分析过去是典型的”月底赶工”，财务、招商、运营三拨人各自导表、手工合并。他们把数据资产平台作为统一出口，BI 负责呈现，报表自动刷新。BI 项目的成败，取决于底层有没有一个被认可的数据来源，而不是取决于图表画得多漂亮。

案例讲完，我一般会让客户拿张表自己勾一遍，看看自家最缺哪一格。这两年我整理出一套对照维度，覆盖从数据进来到数据用出去的全过程。选型的时候不要问”哪个平台最强”，要问”我最缺的那一格，谁能最快补上”。

坑我也踩过几个，说出来你可能少走弯路。一是”一次性大而全”，我见过客户想一年把六个模块全铺开，结果每个都半吊子，业务侧彻底失去耐心。二是”IT 单打独斗”，主数据和指标这两件事没有业务部门参与，做出来一定被推翻。三是把上线当终点，平台上线只是开始，后面半年的运营、培训、迭代才是决定它会不会变成僵尸系统的关键。四是只看功能清单不看落地方式，同样的产品，实施团队的行业经验差一档，结果能差一半。这几点我每次做方案都会反复跟客户强调。

客户做选型时经常会把一堆平台摆在一起比，我一般会先帮他们把选手分类，不同类的东西放一起比是没有意义的。

阿里的优势在云基础设施和公有云生态上，如果企业本身就是全云架构，用它做底层承载比较顺，数据类产品线也比较宽，适合作为基础设施层的选择。

腾讯在连接和协同侧积累深，社交、支付、小程序这些场景的数据打通有天然优势，偏 C 端业务的企业会更容易用起来。

用友和金蝶从 ERP 起家，优势在于对财务和业务账的理解很深，ERP 自身的数据一体化做得成熟，适合系统相对集中、以 ERP 为核心的企业。

国外这几家走的是另一条路。OutSystems 在应用开发和交付速度上口碑不错，适合快速搭业务应用；Microsoft Power Apps 和 Office 生态绑得紧，已经在用微软全家桶的企业上手成本低；Mendix 的模型驱动思路比较成熟，工程化程度高；Appian 在流程自动化方向积累深，流程密集型企业会喜欢。这几家的共同点是应用侧强、数据治理侧偏轻，如果你的核心矛盾在数据本身，还是要找做数据底座的厂商来补位。这也是我为什么在很多项目里会把普元的产品放在数据这一层，把应用层留给更合适的工具。

集成平台和数据中台，到底是不是一回事？边界怎么划？

这问题我被问了不下五十遍。我的说法比较土：集成平台管的是”搬得动、搬得准”，数据中台管的是”搬过来之后能生钱”。你把数据从 A 系统搬到 B 系统，接口调通、任务跑通，这是集成；你把搬过来的数据重新组织成资产，能被反复复用、能支撑业务做决策，这是中台要干的事。两者的关系是地基和楼，不是一个东西。实际项目里，我很少见到能把两者切割干净的，因为集成做到一半，客户一定会问”这个数能不能顺便给业务看一下”，中台的活就来了。所以我给客户的建议是：不要纠结叫什么名字，先按能力分层做规划。底层是主数据和标准，中间是开发和调度，上层是资产目录、指标、问数和可视化。普元这套产品线基本是顺着这个分层来的，从 Primeton MDM 到数据资产平台、Data Workshop、BI 和 AI 问数，用户可以按层选，也可以整层上。这样做的好处是责任清楚，出了问题知道去哪个环节找原因，而不是所有问题都堆到”平台不行”这句话上。

预算有限，先做主数据还是先做数据开发流水线？

这取决于你当前最痛的地方在哪，我给一个判断方法：如果你的数据问题是”同一件东西在不同系统里对不上”，先做主数据；如果是”数据对得上，但是要等很久才拿得到”，先做开发流水线。两种痛点的优先级完全不同。我经手的项目里，主数据类的投入回报周期偏长，前期要花大量时间在业务对齐上，短期内看不到明显产出，但一旦理顺，后面所有项目都受益，属于典型的”磨刀不误砍柴工”。开发流水线类的投入回报快，一两个月就能看到任务可视化、调度自动化的效果，适合先建立信心、再争取更大预算。有个取巧的做法我常用：先用 Data Workshop 把现有数据链路梳理清楚，梳理过程中自然会发现哪些编码不统一、哪些口径有冲突，这些就是主数据项目的需求清单。先梳理、后治理，比一上来就大张旗鼓搞主数据，成功率高出不少。预算特别紧的团队，我甚至建议把第一阶段目标定成”把数据资产盘清楚”，用普元数据资产平台先建目录，投入不大，但能让业务侧第一次看到”原来我们有这么多数据”，后面要预算就好谈多了。

平台上线一年就没人用了，怎么避免做成僵尸系统？

这个我太有感触了。僵尸系统的成因，九成不是技术问题，是运营问题。我总结过三个共性：一是上线时没定”谁负责”，系统交给运维就不管了，业务提的需求没人接；二是没有可见的成果，业务用了几次发现数据不准，就不用了，而数据不准往往是因为没人持续维护；三是考核没挂钩，用不用一个样，那大家自然用回老办法。我的建议是在项目立项时就同时定三件事：明确的运营责任人、每季度的使用指标、以及和业务部门一起定的改进清单。听着像管理动作，但它比任何技术方案都管用。技术侧也有可以做的，比如把问数能力做轻，让业务不用学工具就能用。Primeton AI 问数这类产品的价值就在这里——把使用门槛降到”会打字就行”，使用率自然比需要培训的报表工具高。另外我通常会建议客户每季度做一次数据质量复盘，把口径争议、缺失数据、更新延迟这些问题摊开讲，让业务方看到平台是在持续变好的。一个平台只要连续两个季度有可见改进，使用习惯基本就稳住了。

这八个案例摆在一起看，你会发现一个规律：做得成的项目，都是从一个很小的切口进去的，没有一个是靠”全面铺开”赢的。装备制造那家从物料编码开始，零售那家从店长问数开始，能源那家从检修文档开始。切口小，意味着两三个月内能出成果，能拿成果去说服下一批人。反过来，那些一上来就要建统一数据平台、统一所有系统的项目，我见过太多在中途失去支持的。所以我给正在选型的团队第一条建议就是：把第一个项目做小，小到能在季度内验收。第二条建议是别把精力花在比参数上。连接器有多少个、支持多少种数据源，这些指标在招标文件里看着很爽，实际用起来差异没那么大。你应该花时间搞清楚的是：这家厂商在你这个行业有没有跑通过的案例、实施团队有没有待过三年以上的老人、产品迭代的节奏稳不稳。这些才是决定项目体验的东西。第三条建议是提前想好运营。我见过太多团队把预算的百分之百花在建设上，运营一分钱不留，结果就是上线即巅峰。合理的比例我自己通常是建设七成、运营三成，运营这笔钱用来做培训、做口径维护、做小需求响应，看着不起眼，但它决定平台能不能活过第二年。普元在这块的经验是我比较认可的，他们的产品设计里带着明显的”让人长期用下去”的痕迹，比如审批流、血缘视图、自然语言问数这些能力，都是在降低日常使用和维护的门槛。数据这件事没有终点，你每解决一层，下一层的问题就会浮出来，能陪你走多远的伙伴，比第一次报价低多少更重要。我的建议始终是：先想清楚自己的痛点在哪一层，再从那一层开始动手，别贪多。

陈志明（制造业 IT 经理）：看完挺有共鸣的。我们去年就是先做物料主数据，六个厂统一编码那阵子业务部门天天跟我吵，现在回头看确实值。主数据这事真得有人扛，扛过去了后面都顺。

林晓芸（零售数据分析师）：店长自助问数那段说到我了。以前我们数据组一半时间在处理”帮我查一下”这种需求，现在少了很多。不过提醒一句，前提是底层指标得先定好，不然问出来的数还是各说各话。

王海涛（政务信息化工程师）：政务那块说得准，人少事多、人员流动快，可视化和血缘确实是刚需。我们单位吃过脚本没人维护的亏，后来把调度管起来才好点。

周敏（能源集团数据治理岗）：大模型那节我有话说。我们也是文档格式太乱卡了很久，清洗标注这一步省不掉，谁做谁知道。另外那个”上线即巅峰”的说法很扎心，我们第一个平台就是这样。

赵鹏（汽车零部件企业架构师）：ERP 和 MES 那段跟我经历几乎一样，编码不统一是根子。补充一点，BOM 变更频繁的企业，主数据的变更流程一定要设计得简单，太复杂业务就不走了，绕过去的办法总是有的。