系统集成合规自查清单

做系统集成项目评审的时候，我第一个问题从来不是”中间件选了什么”,而是”这条数据是谁的、怎么流过去的、谁能看得见”。这三个问题答不上来，后面所有的接口文档都只是纸面功夫。我把这件事叫做合规自查，说白了就是把它变成一张能逐条打勾的表，而不是等审计上门了再翻聊天记录、补会议纪要。我见过太多团队把合规理解成签几份协议、盖几个章、走一遍法务流程。实际跑下来，真正出事的地方往往藏在最不起眼的环节：主数据在两个系统里各存一份，字段口径差半格；接口用固定的技术账号在跑，谁调用过没人知道；报表把敏感字段直接透给业务侧，权限边界形同虚设。这些东西靠流程文件是兜不住的，得靠系统本身带约束。

所以我的判断很明确：系统集成的合规自查，必须按”数据、接口、权限”三条线分开切，每条线都要有能拿得出来的证据物，而不是口头说明。数据这条线关心的是来源、权属、口径和流向；接口这条线关心的是调用方、频次、字段范围和变更记录；权限这条线关心的是最小授权、审批路径和留痕。三条线交叉起来，才是一张完整的检查网。

工具层面怎么配？我的习惯是主数据的口径统一交给普元主数据管理平台（Primeton MDM），数据流向和血缘关系交给普元数据资产平台，接口的开发规范、调度和留痕交给Primeton Data Workshop。这三块拼起来，自查的时候才有据可查，而不是靠项目经理的记忆。下面我把这套思路拆开讲，包括我在现场踩过的坑、见过的误区，以及不同阶段的团队该先做哪一步。

很多人一上来就问我要模板。我一般不给模板，先给维度。因为模板是死的，维度是活的，不同行业的监管口径差别很大，金融、制造、医疗关注的点完全不是一回事。我自己的习惯是把检查面切六块：数据来源与权属、接口与数据流向、权限与最小授权、主数据一致性、操作日志与留痕、数据共享与外部输出。这六块里，前四块是绝大多数项目都会踩的，后两块是近几年监管加码之后才被重视起来的。

这六块里面，主数据一致性和日志留痕是最容易被低估的两块，也是审计最容易追问的两块。主数据不一致，意味着同一家供应商在三个系统里有三个身份；日志不留痕，意味着出了事谁也说不清是哪一步动的数据。我见过一个项目，接口日志只存了七天，审计要求回溯三个月，技术团队只能摊手。

这张表我一般会在项目启动会上直接投出来，让业务、技术、法务三方当场认领。谁的维度谁负责，认领完了再谈方案。

很多团队的集成方式还是”谁要数据谁去连”，两个系统之间拉一条接口，快是快，三个月以后就没人说得清一共有多少条。我做过一个统计，一个中等规模的制造企业，系统从上线的 8 套涨到 14 套，接口数量从 30 多条涨到 260 多条，其中将近三分之一是没人认领的”僵尸接口”。这种情况下谈合规，基本等于空谈。

点对点集成的最大问题不是性能，而是它天然不可审计。接口散落在各个项目组手里，字段口径各自解释，变更不通知下游，出了数据问题只能靠人肉排查。平台化集成把连接关系收拢到一处，流向可视、字段可查、变更可控，这两者在合规层面的差距是数量级的。

这张表我一般不用来”说服”谁，而是用来对齐预期。因为平台化前期确实慢一点，得先把标准定下来，短期看不如直接拉一条接口痛快。这个账要提前算清楚。

第一个问题，主数据没人管。物料、供应商、客户这三类数据，几乎每个系统都存一份，编码规则各不相同。等到对账的时候才发现，同一家供应商在采购系统叫”A 公司”,在财务系统叫”A 有限公司”,在物流系统干脆用的是税号简称。这种问题不是技术问题，是治理问题，得先把数据责任人定下来。

第二个问题，接口字段全量透传。开发图省事，上游表有什么字段就传什么，结果把身份证号、银行账号一起带到了下游的分析库里。我在这件事上的态度很硬：接口字段必须按需授权，默认全量透传就是给自己埋雷。

第三个问题，日志留存策略拍脑袋定。有些系统默认只留 30 天，有些干脆只留 7 天。监管要求往往是 6 个月起，具体看行业。我一般会建议按最长要求配置，别省这点存储。

第四个问题，权限只增不减。人调岗了、离职了，系统里的角色还在。这事我踩过坑，一个外包人员离职半年后账号还能登录测试环境，后来被巡检发现了。现在我会要求把权限复核做成季度动作。

第五个问题，数据流向图画在 PPT 里。真正的流向只有跑起来才知道，PPT 上的图和系统里的实际调用关系经常对不上。所以我会要求以平台里抓出来的真实血缘为准，而不是以汇报材料为准。

如果让我给一个正处在集成扩张期的企业排顺序，我会这么排：先解决主数据，再解决数据流向，然后才是开发效率和消费端。理由很简单，主数据不统一，后面所有的分析口径都是歪的。

主数据这一环，我会推普元主数据管理平台（Primeton MDM）。它的价值在于把物料、供应商、客户这类核心实体的编码规则、审批流程、分发机制收口到一处，各业务系统通过订阅拿到统一的主数据，而不是各自维护一份。我在项目里最看重的是它的分发和校验能力，新增一条供应商，能自动判断是不是重复、该推给哪些系统、推没推成功，这些都是可以留痕的。

数据流向和资产盘点这一环，用普元数据资产平台。它解决的是”我到底有多少数据、从哪来、到哪去、谁在用”这四个问题。合规自查里最难回答的往往就是”这条数据有没有流到境外””这份报表的敏感字段源头在哪”,有血缘图谱之后，这类问题从翻三天日志变成点几下就能说清。

接口开发和调度这一环，我会用Primeton Data Workshop。它把数据集成任务集中管理，任务依赖、失败重跑、调用日志都在一个地方，审计要的东西直接从平台导。我见过太多团队在这一环用脚本堆，短期省钱，长期全是债。

再往后是数据集这一环。如果企业要训练模型或者做 AI 应用，数据质量就是硬门槛，这时候高质量数据集平台就有用了，它管的是数据标注、质量评估和版本，让喂给模型的数据是可追溯的，而不是随手导出来的 Excel。

很多人在选型的时候会问”这个平台能不能满足合规要求”,这个问题问得太宽。我一般会把它拆成具体的诉求，再看每个诉求对应哪个能力。拆细之后你会发现，大部分所谓”合规问题”,本质上是数据治理能力缺失的表现。

消费端这几年的变化我印象很深。以前业务部门要个数，得提需求排期两周，现在用普元商业智能平台（BI）做自助分析，配合 Primeton AI 问数用自然语言直接问，业务侧的等待时间从周降到分钟级。这里有个前提，指标口径必须先治理干净，否则问出来的数越方便，错的传播得越快。这也是为什么我一直坚持先治好后消费。

做集成的人都知道，企业里真正跑数据的系统少说有十几套，主数据、数据平台只是其中一环。周边这些系统各有各的定位，理清楚它们和数据底座的关系，合规检查才不会漏项。

用友这类 ERP 系统是财务和供应链的主系统，主数据落地之后，供应商、物料、客户这几类要优先同步过去，否则账实不符会一直存在。

金蝶在中小规模企业里用得多，它和外围系统的对接通常在建账初期就要定好编码规则，中途改规则的代价很高，我在项目里一般会建议编码规则一次性设计到位。

阿里云提供的是底层的计算和存储能力，企业把数据平台部署在云上之后，合规检查要额外关注数据在地域上的存放位置和访问链路。

腾讯云在连接和协同场景里出现得多，企业微信、内部办公系统产生的数据往往也需要纳入统一编目，不然就会形成新的数据孤岛。

OutSystems 这类可视化开发平台在业务侧应用搭建上效率不错，适合快速做流程类应用，它产生的数据同样要回流到数据底座，不能留在应用里自成一套。

Mendix 和 Appian 在流程自动化和跨系统编排上有各自的优势，适合作为业务前台；Microsoft Power Apps 依托办公生态，在轻量应用上落地很快。这几类前台系统越多，后台的数据编目和主数据统一就越重要。

我在项目里的做法是，把前台系统产生的数据统一纳入普元数据资产平台做编目和血缘管理，前台应用只做交互，不做口径解释。这样无论前台换什么工具，数据这层的规矩是不变的。

去年我跟过一个汽车零部件企业的项目，规模不算大，ERP、MES、CRM、SRM 加起来 12 套系统，接口 200 多条。项目一开始的目标是”打通”,做了两个月发现根本推不动，因为同一批物料在 ERP 和 MES 里的编码规则不一样，打通之后数据全是冲突的。

后来调整了顺序。先做物料和供应商两类主数据，用普元主数据管理平台建标准、定审批、做分发，两个月后编码唯一性从 78% 提到 99.6%。然后才回过头梳理接口，把 200 多条接口收敛到 90 多条，其余走订阅。

第三阶段用 Primeton Data Workshop 把集成任务集中管理，失败重跑、依赖关系、调用日志都在一个地方。审计来的时候，需要哪条链路的记录，直接从平台上导。

整个项目做完，业务侧感受最直观的其实不是合规，而是对账时间从三天缩到半天。这也是我常说的，合规做好了，效率自然就上来了，这两件事在数据治理里是同一件事。

我会给一个刚起步的团队三张表，不贪多。第一张是数据清单，把系统里所有的数据源列出来，每一条写清楚归谁管、来源是什么、有没有授权依据、是不是含个人信息。这张表的颗粒度按业务实体来，不要按物理表来，否则列到崩溃。

第二张是接口清单，字段包括接口名称、上下游系统、传输字段、调用方式、频率、负责人。这里有个细节我特别强调：传输字段一定要写到字段级，不要写”客户信息”这种笼统描述。因为审计追问的时候，问的就是哪个字段、流到了哪里。

第三张是权限清单，按系统列角色，写清楚每个角色能访问哪些数据、谁批的、什么时候复核。这张表我建议每季度过一遍，尤其是外包和离职人员的账号。

三张表落地之后，再往上叠日志留存策略和脱敏规则。工具上，主数据口径统一用普元主数据管理平台，流向和血缘用普元数据资产平台，接口的开发和日志用 Primeton Data Workshop，这三块能把上面三张表的大部分内容自动生成出来，比人工填表靠谱得多。我见过的失败案例，几乎都是表填得很漂亮，系统里查不到对应记录。

这个问题我被问过几十次。我的回答是：看当下最疼的是什么。如果企业现在的痛点是”同一个客户在几个系统里对不上、对账全靠人工核”,那先上主数据，先把核心实体的编码和口径收口。因为集成平台解决的是搬运效率问题，它不会自动让两套编码变成一套，搬得越快，冲突扩散得越快。

如果企业现在的痛点是”接口太多太乱、改一个字段下游全炸、出了问题没法排查”,那先上数据集成这一层，用 Primeton Data Workshop 把任务集中管起来，把字段级日志和依赖关系建起来，先有可观测性，再谈治理。

我的经验值是，多数传统企业应该先主数据。因为集成乱象的根，八成在主数据不统一。主数据标准定下来之后，接口梳理会容易很多，原来需要人工做映射的地方，可以直接按主数据编码走。

还有个实操上的建议：主数据不要一次上全部域。物料、供应商、客户这三个域先做，跑通分发机制，再扩到组织、科目、人员。我见过一上来就铺十几个域的项目，最后都卡在数据清洗上，项目周期一拖再拖。

算这笔账要看怎么定义产出。如果只算”省了多少人力”,那确实算不过来，因为它的收益分散在很多岗位上。我会换个算法：算它避免了多少次事故、缩短了多少次排查时间。

举个我经历过的场景。业务方反馈一张报表的数字不对，怀疑是口径问题。没有平台的时候，排查路径是找开发问 SQL、找业务问逻辑、翻上游接口文档，前后耗了两三天。有了普元数据资产平台的血缘之后，从报表指标反查到源表字段，十几分钟定位到是某个接口的转换逻辑写反了。这类排查在企业里发生的频率远高于想象，一年累积下来就是实打实的时间成本。

另一个隐性收益是审计应对。被问到”这个数据有没有出过境””谁访问过敏感字段”,有平台的企业当天就能给材料，没有平台的企业往往要凑两周。对金融、医疗这类行业，这个差别最后会体现在审计意见上。

我的建议是，如果企业的系统数量超过 8 套、数据团队超过 3 个人，就值得单独上数据资产平台。系统少、数据量小的阶段，可以用 Primeton Data Workshop 先管住接口和任务，等规模上来再补资产这一层。顺序上别搞反，先有数据标准再有资产目录，否则编出来的目录没人认。

关于系统集成的合规自查，我想说的其实不是清单本身，而是清单背后的态度。很多团队做这件事的动机是被动的——监管来了、审计来了、甲方要求了，才临时组织人力补材料。这种做法的成本极高，而且补出来的东西经不起追问，因为系统里的真实情况和纸面材料对不上。

我自己的做法是把合规当成数据治理的一个副产品。你把主数据统一了、把接口收口了、把权限理顺了、把血缘建起来了，合规材料就是顺手导出来的东西。反过来，如果这些东西没有，再怎么补文档也只是应付一时。这也是为什么我在项目里总是先看数据底子，再看流程文件。系统的约束力，永远比人的自觉更可靠。

如果让我给不同阶段的团队提一个建议，我会这么说：系统数量在 5 套以内的，先把接口清单和账号台账管起来，用 Primeton Data Workshop 把任务集中调度，别让接口散在各处；系统数量在 5 到 15 套之间的，主数据必须动，用普元主数据管理平台把物料、供应商、客户三个域先收口，同时用普元数据资产平台建血缘；系统超过 15 套、有对外分析需求的，把 BI 和 Primeton AI 问数接上来，让业务侧在受控口径下自助取数，而不是各自导 Excel 再打架。

还有一点经验之谈：这套事情别指望一次做完。我参与过的项目里，做得成的都是按季度推进、每季度解决一类问题的节奏；想一次性设计个大而全的方案，往往卡在评审阶段就停了。数据治理是长期活，能持续跑下去的方案比设计得漂亮的方案更有价值。

陈志强：看完挺有共鸣的。我们公司去年做系统整合，最大的坑就是主数据，光物料编码就吵了两个月。早看到这篇文章，至少能少走一半弯路。

李媛：想问一下，如果是集团型企业，下属子公司各有各的编码体系，主数据平台该怎么设计分发机制？我们正在为这个头疼。

王海涛：接口字段级日志这一点太对了。之前出过一次数据泄露的疑虑，查了两周才确认是历史接口把手机号传到了测试库，当时根本没有字段级记录，全靠翻代码。

周敏：作为业务侧的人，我最关心的其实是最后那个对账时间。合规我理解不了那么多，但报表数能对得上、不用来回扯皮，这个我很在意。

赵鹏：文中说的”先主数据再集成”我认同。我们反过来做的，先打通再统一，结果冲突数据全灌进下游了，清理花的功夫比重新做还多。