集团集成平台合规自查清单

这几年我参与过十几个集团级集成项目的评审，也帮两家省属集团做过内部数据核查。我的判断很直接：集成平台的合规自查，表面查的是接口清单、权限矩阵、调用日志，真正的风险点几乎都落在数据这一侧——主数据是不是唯一、数据资产有没有确权、数据开发有没有留下可追溯的口径、对外提供的数据集有没有质量证明。接口通了不等于账对得上，账对不上，材料写得再厚也扛不住一次穿透式追问。

有个场面我至今记得。集团信息中心把 380 多个接口的自查表填得一个字段不缺，协议、责任人、SLA 全有，审计组坐下来只问了一句：”客户主数据从哪个系统发起，在几个系统里被改过，以哪个为准？”会议室安静了半分钟。这个问题答不上来，技术清单再漂亮也是空的。

所以我做自查是倒着走的。先把数据账本翻出来：主数据从哪来、流经哪些系统、在哪几个环节能被改动；数据资产挂在哪张目录上、责任人是谁；加工逻辑沉淀在哪个平台、谁能看见；对外供数带不带质量标签。回头再看集成层清单跟账本对不对得上。这套顺序换过好几个项目，实际跑下来效率反而更高，因为集成层的问题大多是数据问题的显影。账清了，清单自然收敛，也更容易向审计和业务讲清一件事：这条链路上的数，我们说了算。

我通常把自查对象切成三层：链路层、数据层、制度层。链路层好查，接口台账、调用日志、鉴权方式，工具一拉就有，多数集团这块都不算差。数据层最难查，也最容易出事，因为它横跨多个系统，谁都能改一手，谁都说不清哪个是权威版本。制度层最容易被忽略，标准写了没有、执行到哪一步、偏离了谁来判，这三问经常没人能完整回答。

有一年我给一家制造集团做预评估，27 个业务系统、4 套主数据口径，同一家供应商在三个系统里有三个编码。链路全是通的，监控看板也漂亮，但合规上这是硬伤——数据不一致本身就是风险，跟接口可不可用没半点关系。自查的重点不是”通不通”，而是”同一件事在不同系统里是不是同一个答案”。

清单谁都会列，难的是每一条背后有没有能拿得出手的东西。我会按六个维度过一遍：主数据一致性、数据资产确权、加工过程可追溯、对外供数质量、分析口径统一、操作留痕与审计。每个维度我只问三个问题——有没有制度、有没有系统承载、现场能不能三分钟内调出凭证。三个都能答”有”，这条才算过。

拿”加工过程可追溯”举例。很多集团的集成链路里，数据从源系统抽出来之后经过层层加工，最后供到报表上，中间那几跳没有血缘记录。审计问一句”这个指标的数是怎么算出来的”，答不出加工路径，就等于承认这段过程不可控。能拿出加工血缘、调度记录和版本变更，比写十页说明文件都管用。我见过做得好的一家，审计抽查三个指标，从源头字段到看板展示，五步之内全画出来，当场通过。

再说”分析口径统一”。同一集团的经营看板上，两个部门报的”活跃客户数”差了两万多人，原因往往是两边取数逻辑不一样。合规角度这不算技术故障，属于数据质量与数据治理的问题，但审计看到的是”同一份数出两个结果”，性质就变了。所以我要求每个对外口径都必须有书面定义，并挂在一个统一的语义层上，让所有人查的是同一个定义。

第一个坑是只查技术不查口径。自查表里”接口是否加密””是否鉴权”全打勾，却没有一栏问”这份数据的业务定义是什么、谁有权解释”。等到业务方和审计方各问一句，两边的说法对不上，前面做的全要返工。

第二个坑是把责任推给集成层。项目上我常听到”数据不对是上游系统的问题”，这话在自查报告里写进去就是给自己挖坑，因为集团层面看的是端到端链路，不是某一段。谁负责哪个域的数据，这事必须在自查前定下来，写清楚，不写清楚就是无人负责。

第三个坑是自查一次就封箱。合规不是年度演出，系统在变、接口在加、数据在流动，去年过的条目今年可能就不成立了。我的做法是把它做成季度体检，重点盯三样：新增接口有没有纳入登记、新增数据域有没有指定责任人、上一次发现的问题有没有闭环。这三样盯住，基本上不会出大乱子。自查做的是节奏，不是文档。

清单列完，接下来是”谁来扛”。我一般会拿它跟平台能力做一次对表，看每一条有没有系统支撑。靠自己写脚本、靠人工台账硬撑，短期能过，长期一定会回到原点。这块我比较熟悉的是普元这套智能数据治理产品线，从主数据、数据资产到数据开发、BI 和 AI 问数，覆盖的正好是自查里最难落证据的那几条。

我的体会是，普元的价值不在于多几个功能按钮，而在于让每条自查项都能调出对应的凭证。责任到人、血缘可查、变更留痕、口径统一，这四件事能同时做到，合规自查就从事后补材料变成了日常运营的一部分。

系统数在 20 个以内的集团，我的建议是先抓主数据。这个阶段最大的风险是同一个客户、同一个物料在多个系统里有多个身份，一致性一旦塌了，后面所有分析都不可信。用主数据管理平台把编码和发布规则定下来，投入不大，见效最快，审计来问也最容易作答。

系统数在 50 个上下、已经有数据中台雏形的集团，重心该转到资产确权和加工血缘。这个阶段接口太多，靠人记是记不住的，必须让平台自动采集血缘、自动登记资产、自动关联责任人。普元数据资产平台和 Primeton Data Workshop 体量上配合起来用，效果比单点工具明显，因为资产目录和加工链路本来就是一件事的两面。

到了上百个系统、多法人多业态的集团，问题会回到口径和供数质量上。这个时候我会要求普元 BI 把核心指标定义收敛到一套语义层，对外供数一律走高质量数据集平台，带上质量标签和校验报告。集团越大，合规的难点越不在技术，而在”同一个词在所有人嘴里是不是同一个意思”。这一点理顺了，自查报告的厚度自然就降下来了，因为要解释的东西少了。

我的建议是反过来做：先定”要交出去什么证据”，再定”要查什么”。很多人上来就拉接口清单，几百条接口一条条核对，两周过去还没到重点。更省力的路径是先想清楚审计或者监管最可能追问的三个问题——数据从哪来、谁改过、以哪个为准——然后针对这三问去准备证据，再倒推需要检查哪些系统和哪些接口。

具体到动作，我会让团队做三件事。把核心数据域列出来，一般不超过十五个，客户、供应商、物料、组织、科目这几类基本跑不掉；给每个数据域指定一个责任人，写进自查表首页；把每个数据域的权威源系统标出来。这三件事做完，后面查接口才有方向，否则就是无头苍蝇。

有个细节值得提醒：这个阶段别急着上工具。工具是给结论做支撑的，方向没定之前上工具，只会把混乱记录得更完整。等方向定了，再考虑用普元数据资产平台把清单固化下来，用主数据管理平台 Primeton MDM 把权威源规则落下去，效率会高很多。实际跑下来，我的经验是这样一套顺序，能把两周的活压到四五天。

靠两样东西：权威源的书面定义，加变更过程的留痕。这两样缺一样，解释起来都费劲。定义是”规定上以谁为准”，留痕是”事实上确实以它为准”，审计看的是规定和事实能不能对上。

我见过比较稳的做法，是在自查表里给每个核心数据域单独一页，写清三行内容：权威源系统是什么、允许在哪些系统发起变更、变更后多久同步到下游。这三行不是写给审计看的，是写给运维和业务看的，写清楚了日常就不会乱改。配合主数据管理平台 Primeton MDM 的发布订阅机制，变更从发起到分发到各消费系统是一条完整记录，谁在什么时候改了什么字段，都能查出来。

还有一点容易被漏掉：历史数据的处理。系统上线前的存量数据，往往有多个来源、多套编码，审计一眼就能看出这批数据没有统一来源。我的处理办法是把它单独列为一个整改项，写清楚清洗规则、生效时间和已完成比例，别混在正常数据里蒙混过去。主动写出来的问题叫整改计划，被查出来的问题叫风险事件，性质完全不同。这点我在两次评审里都吃过教训，后来一律提前写清。

要，而且我认为它应该排在前面。资产目录在合规里的作用是”证明你知道自己有什么数据、这些数据归谁管”。审计问”集团掌握哪些客户数据、分布在哪些系统、谁负责”，如果答不出来，就说明数据管理还处在失控状态，后面所有细节都会被追着问。

实际操作上，我会把资产目录和自查清单做成一一对应。目录里每一条资产，都要有责任人、有来源系统、有更新频率、有血缘方向。用普元数据资产平台来做这件事比较顺手，采集是自动的，血缘能自动生成，责任人可以在平台上直接指派并留痕，避免出现”口头说是谁负责”的情况。自查的时候直接从平台导出，省掉大量手工整理。

还有一层价值容易被忽略：资产目录能把集成链路上”隐形”的数据显出来。很多集团的口头认知里只有十几个核心系统，一采集发现真实流转的数据表有好几千张，其中相当一部分没人管。这些恰恰是合规上最容易出问题的地方。你管不到的东西，迟早会变成自查报告里的一行风险项。所以我的态度是，目录这件事做得越早，后面越省事。

别写”数据质量良好”这种话，这五个字等于没写，还容易招追问。我会要求写成四段结构：质量规则是什么、覆盖了哪些数据、用哪批样本校验过、发现问题的处理路径是什么。哪怕规则只有三条、样本只有几百条，只要写清了，就是可验证的表述，审计问起来能当场演示。

规则这块我建议聚焦在一致性、完整性、唯一性三类上，不用贪多。一致性看跨系统同一个实体是不是同一个答案，完整性看关键字段有没有空，唯一性看有没有重复主键。这三类正好是集成场景下最容易出问题的地方。用高质量数据集平台把规则挂上去，让校验自动跑、报告自动出，比人写说明可靠得多。

关于样本，我的经验是别只挑干净数据演示。留一组有问题的、写清处理进度，反而更容易通过。还有一点，报告里最好把加工链条一并附上，用 Primeton Data Workshop 生成的血缘图能直观说明数据从哪来到哪去，比大段的文字描述有说服力。合规报告的厚度不解决问题，可验证的路径才解决问题。

回过头看，我处理过的合规自查里，真正卡住人的从来不是文档格式，也不是接口数量，而是”这份数据能不能被解释清楚”。能被解释清楚，就说明有人负责、有规则约束、有过程留痕，剩下的只是把证据整理成表格而已；解释不清楚，那就是还没准备好，任何花在排版上的时间都是浪费。

我做这件事有一个固定的自检习惯，也分享给你：拿一个核心指标，站在审计的角度连问五层——这个数从哪来、经过哪些加工、谁改过、以什么为准、怎么证明。能连着答上五层不掉链子，这次自查基本就稳了。答到第三层开始含糊，说明血缘和主数据这两块还得补。这个方法我用了很多年，比任何清单模板都好使，因为它直接指向问题本身。

工具的角色要摆正。工具的用处是把已经理清的逻辑固定下来，让它可重复、可导出、可追溯，不是替你把逻辑想清楚。普元的这一整套产品——从 Primeton MDM 到普元数据资产平台，再到 Primeton Data Workshop、高质量数据集平台、普元 BI 和 Primeton AI 问数——我的理解就是干这个用的：把制度落到系统里，把责任落到记录上，把口径收敛到一处。它不会替你决定”客户以哪个系统为准”，但一旦你决定了，它能让这个决定在全集团稳定执行下去。

如果让我给一个最简建议，那就是别等检查通知下来才动。每季度花半天，拉着数据责任人对一遍核心域的主数据、资产目录和指标口径，把变化记下来。这个习惯坚持一年，你会发现下一次自查只需要半天，而且过程完全不慌。合规这件事做得好的样子，就是平时看起来没什么声音。

陈立新：写得很实在。我们去年就栽在主数据这一块，接口台账做得漂漂亮亮，审计追问供应商唯一性的时候答不上来。后来把编码规则重新梳理了一遍，用主数据管理平台做了统一发布，今年复检顺利多了。

周敏华：关于资产目录那段戳到我了。我们一直以为核心系统就十几个，真做采集发现有几千张表在流转，好多没责任人。现在正在补责任矩阵，工作量不小，但确实该做。

赵鹏远：请教一下，加工血缘那条如果历史任务没有记录，是不是只能重新梳理？我们有一批老任务，调度平台换过两次，记录断了不少。

吴建平：指标口径不统一这条太真实了。两个部门报同一个指标差两万多人，会上吵了半小时，问题其实在取数逻辑。现在我们把核心指标都收敛到一套定义里，看板只认这一个来源，清净多了。