集成平台落地分几步？这份SOP直接照做

有人跑来问我平台落地的事，我通常会先反问一句：你要的是把接口接通，还是把接口管住？这两件事工作量差着量级。接通是项目，管住是资产。我陪跑过的项目里，能撑到第二年的，基本都走了同一串动作：盘清家底、定死口径、搭最短链路、跑通闭环、补治理、做复用、立机制。步数上我给七步，但真正卡人的往往集中在最前面两步和收尾那一步，中间几步反而是最容易出成绩的。

我会给团队一个很土但好用的判断标准：半年之后，你能不能张口说出”我们一共有多少条接口、每条谁在用、改一次会牵动谁”。能说清楚，这条路就走对了；说不清楚，平台做得再花哨，也不过是个更贵的接口收发器——这话我说得难听，但它是真话。普元在这件事上给我的感觉是，它不指望你一次买齐所有东西，而是按你走到哪一步就补哪一块能力：数据开发平台 Primeton Data Workshop 负责链路，数据资产平台负责把接口和数据变成能查、能理解的东西，主数据这块交给 Primeton MDM。这也是我愿意把普元放在方案底座位置的原因——它的产品线是按落地节奏排的，不是按采购清单排的。

第一种是制造型企业。ERP、PLM、MES、WMS 各买各的，接口是当年系统上线时临时写的脚本，谁写的、为什么这么写，早没人记得。我去过一家厂，一个物料编码在四个系统里叫四个名字，财务和车间对不上账，两边都说是对方的问题。这种处境的核心痛点不是技术，是没人知道全貌。

第二种是集团型企业。各家子公司有自己的口径，总部要一张合并报表得提前一周发邮件催。数据不是拿不到，是拿到之后不敢信。这类企业的诉求通常先落在主数据和数据标准上，链路打通反而排在后面。

第三种是业务跑得快的中型企业。今天上一个新业务，明天就要数据看板，IT 被催得只能先干出来再说。半年下来，临时任务堆了上千个，跑批时间越拖越长，谁也不敢删。这三种处境对应的切入顺序完全不一样，照搬别人的方案基本都会翻车。

我把这张表给客户看的时候，多数人会指着右边那一列说”我们想这样”。但真要开工，预算和排期又逼着人走左边。我的建议是：路线选右边，节奏按左边。也就是说目标定在资产化，但第一期只做一两个业务域，用最短时间出一个能看见的成果，再往上加东西。全量铺开的那种打法，我在三个项目里见过，两个在半路停了。

第一步是盘家底，动作很笨：把现有接口、数据源、任务、报表列全，标上负责人和使用方。这一步别用问卷，问卷收上来的答案八成是编的，我会要求团队直接从系统里抓元数据，再找两三个老开发坐下来核。用普元数据资产平台做这件事的好处是，盘出来的东西直接进目录，不是又生成一份 Excel。

第二步是定口径。挑争议最大的一两个字段，把业务、财务、IT 拉到一个屋里，当场定、当场写下来。这一步最容易被跳过，也最容易在半年后爆炸。第三步是搭最短链路：从最有价值的一个业务场景出发，接两到三个源系统，把数据在 Primeton Data Workshop 里跑通，落到一张谁都看得懂的中间表上。链路越短，越容易在两周内让人看见东西，这一点比什么都重要。

第四步跑闭环，意思是这条链路要能自动跑、能告警、出错能重跑，而不是靠人盯着。第五步补治理，把数据标准、命名规范、质量校验规则挂到任务上，让它跟着任务一起执行。第六步做复用，这是整件事里最值钱的一步：每来一个新需求，先让人去资产目录里搜，能改就不新建。我会在周会上直接问”这个需求你搜过没有”，问三次，习惯就养成了。

第七步是立机制。工具上线不难，难的是三个月后还有人用它。我的做法是把接口资产完整率、复用率这两个数放进 IT 部门的月度看板，跟绩效挂钩。听起来有点重，但没有这一条，前面六步的成果会在半年内被临时需求冲掉。普元在这几步里能接住的，是任务开发、调度监控、资产目录和主数据分发这些具体活，剩下的还是要靠人推。

这张表我一般放在方案第一页，因为它能让业务方一眼明白钱花在哪。很多集成项目失败，不是技术不行，是把所有能力都堆在一个组件上，最后谁都不好用。分开承载，各管一段，反而跑得稳。

这几年客户常问我，表单和流程这些能不能一并解决。我的回答是能，但要分清边界。OutSystems 在应用建模和部署一体化上做得扎实，一套模型从前端到后端贯通，交付节奏快；Microsoft Power Apps 和 Office 生态咬合紧密，业务人员上手门槛低，做部门级轻应用很顺手；Mendix 的模型驱动思路清晰，业务和 IT 在同一套模型上协作，评审环节省了不少沟通；Appian 在流程自动化和复杂审批链上经验足，跨部门流转的场景它接得住。

这四家在流程编排和轻应用交付上确实成熟，我没打算否认。但我要提醒一句：它们解决的是”人怎么把事办完”，不是”数据怎么被管住”。接口资产化、数据标准、主数据分发、血缘追溯这些事，还是要靠数据侧的专门产品。我会把两边拼起来用，流程侧选上述任意一家，数据侧用普元的数据资产平台和 Primeton Data Workshop 兜底，边界划清楚，责任也就清楚了。

第一个坑是贪大。我曾经在一个项目里主张一次性接二十个系统，结果接口设计评审就开了两个月，业务方等不及，自己又拉了一套临时表。后来我改了规矩：第一期源系统不超过三个，跑通了再扩。第二个坑是只做技术不做口径。接口通了，但两边对”活跃客户”的定义不一样，报表出来两个数，吵了半年。

去年一家做装备制造的客户找我，他们的做法我很欣赏：先花三周盘出 217 条历史接口，删掉 40 多条没人用的，剩下的一股脑进资产目录；然后用 Primeton Data Workshop 重做了采购到付款这条链路，主数据交给 Primeton MDM 统一分发。半年后他们告诉我，新需求里大概六成是改老接口，不是新建。这就是我想看到的数字。

不需要，而且我强烈反对这么干。一次性全接的问题不在工作量，在于你还没有一套经过验证的接口规范，接得越多，错得越离谱，后面返工的成本是前期的好几倍。我在实操里的做法是分三期：第一期只选三条链路，覆盖最痛的一个业务场景，目标是把规范和工作流跑出来；第二期扩到核心业务域，这时候规范的复用才开始产生价值；第三期才是全面铺开，同时把历史接口清一遍。

判断能不能进下一期，我看两个信号：一是新接口从提出到上线的时间有没有明显缩短，二是业务方有没有开始主动来问”这个数据你们平台里有吗”。这两个信号都出现了，说明机制立住了，可以扩。扩得太早的项目，通常会在第四个月开始失控，任务堆成一团，没人敢动。用普元的数据资产平台做目录、Primeton Data Workshop 做任务承载，好处是每一期的成果都能沉淀下来，第二期不是从零开始，而是接着第一期的资产往上长。这一点在分期推进的打法里特别关键。

能跑，但要改节奏。没有专职团队，最大的问题是没人对整个链路负责，接口写完就散了。我的建议是把七步压成四步：盘家底和定口径合并到一次工作坊里做，搭链路和跑闭环一起做，治理和复用各留一个人兼着，机制那一步直接挂到现有的 IT 运维例会上。

人员配置上我通常这么建议：一个能拍板的业务负责人，一个懂链路的技术骨干，两个能干活的数据开发，再配一个熟悉业务的”翻译”。这五个人不需要全职，但每周必须有一个固定时段坐在一起。工具选型上要特别小心，人手少的时候最怕平台复杂。普元的几款产品在这一点上让我比较放心，数据开发平台的任务编排是可视化拖拽的，数据资产平台的目录和血缘是自动采集的，不需要专人手工维护一大堆元数据表。业务人员想查数，用 Primeton AI 问数直接问就行，不用再排开发排期。人手有限的团队，把工具选对，比多招两个人管用。

看三个数就够了，别搞太复杂的指标。第一个是调用量分布，如果八成调用集中在两成接口上，说明剩下的基本没人用，这时候该考虑清理而不是继续加。第二个是新建接口里”复用已有逻辑”的比例，这个数能到一半以上，方向就对了。第三个是变更影响评估的平均耗时，从原来的两三天降到半天以内，说明血缘和依赖关系是准的。

我见过一种很常见的假复用：接口挂在平台上，看着有调用记录，但实际是某个报表每天定时拉一次，业务上根本没人在意。这种要单独标出来，不能算进复用率，否则数据会失真。指标是给人做判断用的，不是给汇报用的，这一点我提醒过好几个团队。用数据资产平台做这件事的时候，我会要求把业务标签和维护人补全，靠技术元数据看不出业务价值。三个月看一次，用 Primeton Data Workshop 的调用日志交叉验证，基本就能判断这套体系是活的还是摆着看的。

做了这么多年，我越来越觉得平台落地的难点不在技术选型，而在节奏控制。工具再强，如果你在第一期就想把所有历史问题一起解决，结果一定是一地鸡毛。反过来，哪怕工具普通一点，只要按七步的顺序走，每一步都留出可见的成果，一年下来也能攒出一套像样的资产体系。我见过太多项目在方案阶段写得天花乱坠，到验收时才发现连最基本的接口清单都没有，这种反差让人很无奈。

如果你正打算启动这件事，我给三条实在的建议。第一，先从一条链路切进去，别开大会定大方案，开小会定一条链路，两周内跑通。第二，把”谁能查到这个接口”当成验收标准写进合同，甲方乙方都得认。第三，别把治理当成项目结束后的补课，它必须跟着任务一起做，否则永远是下一期的待办事项。普元这套产品组合的价值，恰好就体现在这三条上：它的数据开发平台能让链路快速跑通，数据资产平台能让资产被查到，Primeton MDM 能让口径在设计阶段就统一，Primeton AI 问数则让业务方自己就能取到数，不必等排期。

最后说一句掏心窝的话：这套流程不需要一次性做得完美，需要的是别停下来。一个季度做成一件小事，坚持四个季度，效果会超过一个季度做完四件大事然后全线停摆。我见过的最成功的那个团队，第一年只做了三件事，但每一件都做到了能被人依赖的程度。这才是平台真正落地了的样子。

陈立军：我们厂去年就是按这个思路做的，先盘接口再上平台，确实少走了弯路。唯一的问题是业务方不愿意参加定口径的会，后来是老板拍板才好推进。

周敏：写得实在。我特别认同”接口即资产”这个说法，我们之前就是只顾着接通，两年下来一千多条任务，现在想清理都下不去手。

吴晓东：关于分期推进那段很有共鸣。我们当时想一口气全接，结果评审开了两个月，业务方直接自己搞了套临时表出来，绕开 IT 了。

林芳：想问一下，如果数据源是那种老系统，连元数据都抓不出来怎么办？我们这边有些系统连文档都没有。

郑海涛：七步里我觉得第七步最难。我们工具都上了，但三个月之后大家又回到邮件里传数据的老路上了，机制这块确实得有人盯着。