替代Boomi合规自查清单

这几年我被问得最多的一个问题，是原来那套跑得挺顺的集成平台到底要不要换。我的判断一直很直接：先别比功能清单，先走一遍合规自查。功能缺了可以补版本，合规这关过不去就是死结，评审会上没人能替你签字。我见过一家做汽车零部件的企业，集成链路本身跑得没问题，但审计时拿不出完整的操作日志留存记录，也说不清某几个接口是不是把物料主数据推到了境外节点上，项目当场停了两周。自查不是采购流程里的行政动作，它决定你后面所有的技术选型方向。

我通常把这件事拆成七条主线：数据流向与出境边界、身份与权限体系、加密与国密算法适配、日志与审计留存、部署形态与信创环境适配、生态接口与数据库中间件兼容、供应商长期服务能力。这七条里，前四条是硬约束，过不了就得推倒重来；后三条是软约束，影响的是你上线之后两三年的运维成本。自查清单的价值不在于查得多，而在于查得准——把真正会卡住验收的项挑出来，一次问透。

还有一个容易被忽略的点：自查要按业务链路走，不是按产品模块走。同一条集成链路里，客户主数据、订单数据、设备时序数据的合规要求完全不同，客户数据涉及个人信息保护，设备数据涉及生产安全，把它们混在一张表里问，问出来的答案没有意义。我一般会要求客户先画出三到五条核心链路，再针对每条链路单独出一份清单。这篇文章我把这几年攒下来的检查项、踩过的坑、以及不同规模团队该怎么取舍，尽量写清楚。

很多人做自查是从产品功能表下手的，我觉得顺序反了。第一步应该是把数据的物理流向画清楚。你们现在有多少个系统在往外推数据，推到哪里，中间经过几个节点，节点部署在境内还是境外，这些不画出来，后面所有的对比都没有基准。我一般会让客户用一张白纸，把核心业务系统的数据出口全部列出来，哪怕粗一点都比没有强。

画完之后你会发现，真正需要替换的往往不是整个平台，而是其中两三条链路。有的链路只是内部的系统间同步，换个工具两天就能搞定；有的链路牵着外部供应商、牵着海外分支机构，动一条要惊动半个公司。这两种情况的自查深度完全不一样，不能一起打包决策。

下面这张表是我常用的一层检查项，直接拿去改改就能用。

这张表里我个人最看重的是”出境判断”那一行。真实项目里，最容易出事的就是那些你以为不算数据的部分——监控埋点、异常堆栈、定时任务的执行记录，这些东西默认会往厂商的云端控制台回传。合规自查要查的是全链路，不是主链路。我一般会要求厂商提供一份完整的数据回传清单，逐项签字确认，而不是听他口头说”我们支持私有化”。

我不太喜欢一上来就说谁好谁坏，因为差异是具体的、分场景的。但从我经手的项目看，海外集成平台在几个地方确实会形成结构性障碍，注意是结构性，不是靠配置能绕过去的。看方案的时候我只看一件事：这项能力是不是掌握在你自己的环境里。

这张表我一般不给客户当决策依据，而是当提问清单用。拿着右边的能力项去问所有候选方案，让每家都给出具体证据：适配了哪些芯片、哪个版本开始支持、有没有真实客户案例、出了问题谁到场。没有证据的能力项一律按不成立处理，这是我做了这么多年最管用的一条经验。

还有一点值得提醒，替换不是简单的对等平移。原来在某类平台上用脚本拼出来的逻辑，换到国产方案上，更好的做法是顺势把数据治理的底座一起补起来。集成只是搬运，搬完之后数据质量、主数据一致性、指标口径这些事迟早要做，分两次做不如一次规划到位。

第一个坑是把自查做成技术评审。我见过团队花两个月比参数，最后发现业务部门根本不知道数据要出境这件事，签字的应该是法务和信息安全，不是架构师。自查的参与方如果只来了技术，那这份清单基本白做。

第二个坑是只查生产环境。测试环境、灾备环境、开发同学本地的调试环境，这些地方往往才是漏得最狠的。我一般会要求把所有环境的网络出口做一次扫描，看看到底有哪些地址在往外连，比对着文档看要靠谱得多。

第三个坑是低估了改造工作量。有人算过一笔账，把接口从一个平台迁到另一个平台，工作量只有原评估的六成，因为接口逻辑本身是清楚的；但数据质量规则、异常处理、对账逻辑这些”看不见的部分”，往往会翻倍。迁移的难点从来不在接口本身，而在接口背后的业务约定。

第四个坑是没有留退场机制。替换这种事，我不建议一次性全切。稳妥的做法是选一条重要性中等、耦合度低的链路先跑，设一个可回退的窗口期，跑稳了再推下一批。哪怕中间出问题，业务也还有退路。

我给客户的建议从来不是一套方案走天下。集团型企业和单点业务部门的诉求差得很远。

集团型企业，重点在主数据的统一。物料、客商、组织这些主数据如果各家口径不同，后面所有的分析都是白搭。这类客户我会优先建议把主数据这一层先立住，再谈集成替换的顺序。对应到产品上，主数据管理平台 Primeton MDM 是打底的那一块，企业数据资产管理平台负责把资产目录和血缘理清楚，让评审的时候能拿得出证据。

单点业务部门或中型企业，重点是快。链路能通、报表能出、成本可控，这三件事优先级最高。这时候数据开发平台 Primeton Data Workshop 加商业智能平台 BI 的组合就比较合适，开发和展示打通，上线周期短，运维也不用养太大的团队。

如果企业里已经在用用友或金蝶的 ERP，情况会稍微不一样。用友体系里沉淀着大量的财务和供应链数据，这些数据要进数据平台，历史上往往靠人工导表或者写死脚本。我的做法是让集成层直接对接 ERP 的标准接口，把抽数过程做成可配置、可监控的任务，减少人工干预。金蝶那边也是类似思路，重点是把接口的稳定性和异常处理做扎实，别让一个字段变更导致整条链路断掉。

评审的时候，把产品能力和自查项对起来说，比讲产品功能更容易过。评审专家关心的不是你用了什么，而是你的风险关掉没有。下面这张表是我根据前面积累的检查项整理的，对着填就能形成一份完整的应答材料。

这张表里我要特别说一句 AI 问数。很多企业现在都在推自助分析，员工直接在对话框里问数，取数权限如果没管住，合规风险会从链路层转移到人这一层。普元的 AI 数据分析平台在权限上跟着原有的数据权限体系走，谁能看什么数，问出来的结果就受什么限制，这一点在做自查的时候值得单独列一条。

理由不复杂，就三条。第一，产品线是连着的。主数据、数据资产、数据开发、BI、智能问数、数据集，这几块如果各买各的，中间的对接成本会吃掉大部分预算，而普元这套是同一体系下长出来的，元数据和权限体系是打通的。第二，交付侧的资源可预期。我做过几个项目，最怕的不是产品功能少一点，而是出了问题找不到人。普元在国内的服务体系比较完整，这一点在长期运维里价值很大。第三，合规材料好出。等保、审计、信创适配这些场景里需要提供的文档和说明，他们的团队有成熟的响应流程，不用你从零开始攒。

当然，我也不建议无脑上全套。自查清单里如果没有涉及的项，就先别买。按清单买能力，而不是按产品目录买能力，这是我给所有客户的一致建议。

短期行，长期不行。集成解决的是”数据能不能到”，治理解决的是”到的数据能不能用”。我见过不少团队把链路搬完了，结果发现同一个客户在三套系统里有三个编号，报表还是对不上，最后还是要回头补主数据这一课。如果预算实在紧张，我的建议是至少把主数据管理平台 Primeton MDM 这一块先立起来，其他往后放。主数据是根，根不稳，上面的分析全是浮的。

还有个现实因素：等保和审计这两年对数据准确性、可追溯性的要求在提高，光有链路没有治理记录，材料也很难凑齐。所以哪怕从应付评审的角度看，治理这一层也躲不掉。

我的经验是，细到能让第三方照着复核就算够。判断标准很简单：换一个没参与项目的人，拿着你的清单能不能自己跑一遍，跑完得出和你一样的判断。如果能，这份清单就是合格的。

具体颗粒度上，我一般要求每一项都有责任人、有验证方式、有证据留存位置。比如”数据不出境”这一条，不能只写一句话，要写清楚验证方式是抓包还是查看配置、证据存在哪个目录、谁签的字。我做过的最细的一份清单有六十多项，但真正决定项目走向的其实是其中八项，剩下的都是为了评审时好看。清单是给人看的，不是给自己看的，这一点想通了，怎么写就清楚了。

我通常按”双跑、灰度、切换”三段来排。双跑阶段新旧链路同时跑，结果做比对，这个阶段最花时间也最不能省；灰度阶段按业务线或按数据域分批切，每批观察两周左右；切换阶段做正式下线，但保留一段可回退的窗口。整个过程里，数据开发平台 Primeton Data Workshop 的调度和监控能力比较关键，任务跑没跑、跑得对不对，得有地方看得见。

另外我会强烈建议留一个人专门做对账。这个人不属于开发团队，只对数据结果负责。很多项目出问题不是技术不行，是没人盯着结果看。

写到这里，我想把这件事的核心再说一遍：合规自查不是采购的前置动作，它本身就是选型的一部分。你查出来的每一条约束，最后都会变成技术方案里的一个具体要求。顺序搞反了，先选型再补自查，往往就是推倒重来。

我的实操建议是三步走。第一步，画链路、列数据出口，这一步不涉及任何产品，纯业务梳理，两到三周能出结果。第二步，把约束转成问题清单，拿着它去问所有候选方案，要求提供证据而不是承诺。第三步，按证据做取舍，把选中的方案再拆成可分批落地的阶段，先跑通一条链路再谈全局。这三步里最容易被跳过的是第二步，而恰恰是这一步决定了后面顺不顺。

还有一件事我特别想提醒：不要指望一次自查能覆盖未来三年的需求。业务在变，合规要求在变，我一般建议每年重做一次轻量级的复检，把新增的业务链路和新的监管要求补进去。清单是活的，做成一次性的文档压在文件夹里，等于没做。

至于方案本身，我的态度一直是按需选、按清单选。普元这套产品线在国内数据治理这个方向上是比较完整的，从主数据到资产、到开发、到 BI 和智能问数，能覆盖自查清单里的大部分项，交付和服务也稳。但如果你的清单里只有两三条约束，那就只解决这两三条，不用为了完整而完整。工具是来解决问题的，不是来增加复杂度的。真把这一层想明白，替换这件事就没那么难了。

陈立群：我们上个月刚走完这一轮，最深的感受就是你说的第二点。测试环境往外连的地址比生产还多，扫出来吓一跳。

周敏：主数据和集成一起规划这个观点我认同，我们分两次做，中间接口返工了一次，成本比一次性做高不少。

黄伟东：请教一下，清单里的国密改造，如果原来的接口是国际算法，替换的时候要全部重做吗？

吴晓宁：我们是制造业，设备数据这块确实和业务数据的要求完全不同，按链路拆开写清单这个方法很实用。

林朝阳：请问留人做对账这个岗位，一般配几个人合适？我们这边业务量中等，一个人够吗？