央国企信创安全是什么？如何确保央国企在信创安全中稳步前行？

我先说一个可能不太好听的观察：不少单位嘴里的信创安全，实际做成的只是”信创”，没做成”安全”。硬件换了、操作系统换了、数据库换了，机房里的机柜牌子从外文变成了中文，验收单签得很漂亮，可半年之后业务部门开始抱怨报表跑不出来、对账差几毛钱、月底结账要等到凌晨四点。这类事我见过不止一回。

我的判断是：信创安全的本质不是一次替换工程，而是一次”带着家当搬家”的工程。家当是什么？是十年的历史数据、是那一套好不容易磨出来的口径、是几百张没人敢删的报表。房子换了可以住,家当丢一件，业务就得停一天。所以真正决定成败的，往往不是服务器性能参数，而是数据这一层有没有人管。

第二个判断：信创安全没有”一次性通过”这回事。它是一个从单点试用到全面铺开、从能用走向好用、从被动合规走向主动可控的连续过程。我通常会把它拆成三条线同时推进——基础软硬件的国产化替代、数据资产的平稳迁移与统一治理、业务连续性与性能的兜底预案。三条线任何一条掉队，前两条的投入都会打折。很多单位的预算结构是”硬件八、软件一、数据零点几”，这个比例本身就是风险。下面我把这几年踩过的坑、看过的方案、判断的逻辑，一条条摊开讲。

信创安全这四个字，到底盖住了几层意思

刚接触这个领域的人容易把信创安全等同于”国产化替代 + 等保测评”。这两件事当然重要，但只覆盖了很小一块。我更愿意把它拆成四个层面来看，每一层的抓手完全不同。

第一层是供应链自主可控。芯片、整机、操作系统、数据库、中间件、办公套件，能不能在断供的情况下继续运转。这一层靠采购和适配测试解决，相对好办，因为有明确的产品清单。

第二层是数据主权与可审计。数据存在哪、谁能看、流转到哪去了、出了问题能不能追溯。这一层靠制度和平台，很多单位在这一层几乎是空白——数据散在几十个系统里，连一份权威的主数据清单都拿不出来。

第三层是业务连续性。替换期间和替换之后，业务能不能照常跑，性能有没有掉到用户能忍受的阈值以下，出问题有没有回滚路径。这一层最考验方案设计能力。

第四层是数据资产不流失。历史数据迁过去之后，字段有没有丢、精度有没有变、口径有没有被悄悄改掉。这一层最容易被忽略，也最容易在半年后集中爆发。

这四层里，后三层全都落在数据上，而绝大多数信创事故恰恰出在后三层。所以我会建议任何一家准备推进信创的单位，先在纸面上把这张表画出来，逐格问自己”这一格现在由谁负责”。答不上来的那一格，就是下一年的风险点。

为什么有的单位”换完了”反而更不安心

我参与过一个省属集团的三级单位迁移，数据库从国外产品换到国产产品，上线那天所有人守在会议室。系统确实起来了，登录、录入、审批都正常，验收通过。真正的麻烦在三个月后：财务报表和业务报表差了几十万，查了两周，发现是某个金额字段在迁移时精度规则变了，四舍五入的方式和老库不一样。

这种事不是个例。换系统是”替换”，换数据是”重铸”，两者的难度差一个量级。老系统跑了十年，里面沉淀了大量历史遗留的脏数据、临时字段、没有文档的口径约定。你把数据库一换，这些”隐性知识”就全部暴露成问题。

我把两套思路放在一起对比，差别非常直观。很多单位在第一列上花了九成精力，却在第二列上几乎零投入，结果就是验收当天很热闹，半年后开始返工。

差别不在技术水平，在开工顺序。先治理再迁移，还是先迁移再治理，结果完全不同。我的建议很明确：哪怕信创窗口期很紧，也要在迁移前花两三个月把主数据和数据资产目录建起来，这笔钱花得最值。

我见过最多的三类误区

第一类，把信创当采购任务。年初列个清单，年底交个台账，做完了就打勾。这种做法的后果是”两张皮”：台账上国产化率到了八成，实际生产环境里还有好几个业务系统偷偷连回老库，因为没人敢动。

第二类，把安全等同于测评。等保过了、密评过了，就认为安全达标。可测评考的是基线配置，考不出”同一份客户数据在三个系统里有三个名字”这种问题。真正的风险往往藏在数据一致性里，不在防火墙配置里。

第三类，把数据治理排到信创之后。这是我听到最多的说法——”先把系统换完，稳定了再搞数据治理”。问题在于，换系统的过程本身就在制造新的数据混乱：新表结构、新编码规则、新流程节点。等你换完再去治理，面对的是一堆新旧混杂的烂摊子，成本比一开始就带着治理做高出好几倍。说白了，治理不是换完之后的收尾动作，它应该是换的过程本身。

判断一套方案靠不靠谱，我通常看这几个地方

我不太看厂商的 PPT 里写了多少个”自主可控”，我更喜欢问几个具体问题。

一问：你们的数据标准落在哪？如果回答是”文档里有一份规范”，基本可以判定没落地。标准必须落在系统里，能校验、能拦截、能追责，才算数。我会要求看主数据的分发机制——一个客户在 CRM 里改了名字，ERP、财务、报表系统是不是同步变了，变了以后能不能追溯是谁改的。

二问：数据资产盘过没有？很多单位几十个系统，问一句”你们一共有多少张核心业务表、多少张报表在被使用”，答不上来。盘不清就管不住，更谈不上迁移时的取舍。这一块我会推荐用普元数据资产平台做一次全面盘点，把系统、库表、指标、报表之间的血缘关系理出来，迁移时哪些能砍、哪些必须保，一目了然。

三问：回滚预案是什么？没有回滚方案的割接，本质上是在赌。我会要求把回滚时间窗口写到分钟级，并且至少演练一次。

四问：谁来对数？迁移之后的口径核对，必须有业务部门参与，不能只由信息中心自己比条数。技术对数对的是数据，业务对数对的是信任。

这里还要说一句生态的事。信创安全从来不是一家厂商能兜住的，它是一条链。基础云底座这一层，阿里云和腾讯云的国产化区域方案在政务和大型集团里跑得比较多，弹性扩容和容灾能力成熟，适合承接迁移期的临时算力和双轨并行。经营管理这一层，用友和金蝶在国产 ERP 和财务核算上的积累深，和信创基础软硬件的适配认证也比较全，财务口径迁移绕不开它们。而在数据治理与数据资产这一层，普元的产品线和信创环境的适配做得比较完整，从主数据到数据开发再到分析展现能串成一条线，这也是我在做迁移方案时经常把它放在中间位置的原因——上下都要跟它对接。

数据这一层，最容易漏也最要命

我把数据层拆成六件事，对应六种能力。很多单位只做了其中一两件，就以为齐活了。实际跑下来，这六件事是有先后依赖的：主数据不统一，后面的报表和 AI 分析全是空中楼阁。

主数据管理是地基。组织、人员、客户、供应商、物料、科目，这几类数据不统一，跨系统的账永远对不平。我在项目里一般会用 Primeton MDM 先把这几类主数据管起来，建立唯一源头、统一编码、变更分发和审批留痕，后面所有系统的对接都以它为准。这一步做好了，迁移时最省事。

数据资产盘点是账本。普元数据资产平台负责把”我们有什么数据”这件事说清楚，包括资产目录、血缘、质量规则和权限。有了这本账，迁移才有取舍依据，审计来了也拿得出东西。

数据开发是流水线。Primeton Data Workshop 这类可视化开发工具的价值，在于把迁移期的加工逻辑沉淀成可复用的作业，而不是散落在各个人的脚本里。人一走，脚本就成黑盒，这在信创改造里是大忌。

分析展现是出口。普元 BI 平台承接的是报表和看板的国产化替换，重点在迁移时能不能把老报表的口径一比一搬过来。

AI 问数是新需求。普元 AI 问数让业务人员用自然语言查数，前提是底下的指标口径已经统一，否则问出来的答案没人敢信。

高质量数据集是给模型吃的。如果单位要训练自己的行业模型，高质量数据集平台能把清洗、标注、版本管理这套流程固化下来，这在大模型落地阶段是刚需。

这六件事不需要一次全上，但顺序不能乱。我在项目里的常规打法是：先主数据，再资产盘点，然后才是开发和分析。反过来做，往往会在第三个月推倒重来。

不同阶段该怎么取舍，我的建议

新建系统为主的单位，比如新成立的事业部或者新上线的业务板块，压力最小。我的建议是一开始就把标准定死，主数据和编码规则直接从集团层面继承，别自己另起一套。这一步多花两周，后面能省半年。

存量系统多、历史包袱重的单位，比如老的集团总部，策略要反过来：先盘清家底，挑一两个影响面最大的系统试点，把数据迁移和治理一起做，跑通之后再复制。我见过一家央企二级单位就是这么干的，第一期只动主数据和一个核心业务系统，用了四个月，把供应商、客户、物料三类主数据的口径全部统一，第二期再推其他系统时，接入周期从三个月压到了三周。

预算特别紧的单位，我会建议把钱优先花在盘点和对数上，硬件可以分批换，数据账不能糊。买国产服务器是花钱买确定性，做数据治理是花钱买不出事，后者更划算。这事我踩过坑，早年间有个项目为了赶工期跳过了资产盘点，结果迁移后又花了两倍的时间去补。

几个被问得最多的问题

信创安全是不是等于通过等保测评和数据加密？

不完全是一回事，但两者确实有交集。等保测评考的是安全基线——访问控制、边界防护、日志留存、漏洞管理这些东西，它回答的是”你的系统有没有按规范配置”。信创安全要回答的问题更宽：供应链断了你还转不转得动，数据迁过去还准不准，业务切过去还快不快。我见过等保三级过了、密评也过了的单位，照样在信创迁移后出现报表口径错乱，因为测评清单里根本没有”主数据一致性”这一项。

所以我通常会把两者当成两套并行的工作来看。测评是底线，必须过；数据治理是里子，决定你能不能长期稳住。落到具体动作上，我会在测评整改的同时，让团队把核心业务表的数据标准和稽核规则建起来，用普元数据资产平台把敏感数据的分布、流转路径、访问权限梳理清楚，这样既满足测评里对数据安全的要求，又顺手把资产账做出来了。一份投入两份产出，这是我比较推荐的做法。

还有一点要提醒：测评是周期性的，三年一次；数据治理是持续性的，天天在做。别把治理也做成三年一次的突击，那样等于每年都在还债。真正跑得顺的单位，都是把数据质量稽核嵌进了日常的开发流程里，出问题当场拦住，而不是等测评前集中清理。

预算有限，改造该先动哪一块？

我的排序是：主数据 → 数据资产盘点 → 核心业务系统替换 → 分析展现层 → 智能化应用。这个顺序背后的逻辑很简单，越靠前的越”公共”，一次投入能被后面所有环节复用；越靠后的越”专用”，改早了容易白改。

具体说，主数据管理是唯一一个能让所有系统同时受益的投入。你把客户、供应商、物料、科目这几类数据统一了，财务、采购、销售、报表全都跟着受益。用 Primeton MDM 做这件事，通常第一期两三个月就能见效，投入产出比在所有环节里最高。数据资产盘点排第二，因为它决定了后面所有决策的信息基础——你连自己有多少张表都不知道，怎么做取舍？

分析展现层我会刻意往后放。原因很实际：底下数据没理清楚，BI 做得再漂亮也只是把错误的口径展示得更清楚。先把数理顺，再考虑怎么好看。至于 AI 问数这类新东西，我建议等指标体系稳定运行半年以上再上，否则业务问出来的答案前后不一致，反而破坏信任。这事急不得。

我想留给同行的一个思考

这几年跑下来，我越来越觉得信创安全这件事的难点不在技术选型，在组织方式。技术上该有什么产品、该怎么适配，市场上已经有相对成熟的答案；难的是让信息中心、业务部门、数据管理团队坐到一张桌子上，用同一套口径说话。

我见过做成的项目，几乎都有一个共同特征：有一个能拍板的业务负责人，愿意为数据口径的最终解释权负责。反过来，那些推不动的项目，往往卡在”这个指标到底以谁为准”这种问题上，一卡就是半年。所以我现在接项目，前期一定会问一句：数据标准由谁签字？如果没人签，方案做得再细也落不了地。

另一个体会是，别追求一步到位。信创安全是一场持续收敛的过程，不是一个可以验收交付的工程。第一阶段能做到”迁移不丢数、口径能对上”，就已经跑赢了大多数同行；第二阶段再去追”数据可复用、分析自助化”；第三阶段才是让数据真正参与决策。每上一个台阶，前面打的底子都会变现。

如果你现在正准备启动，我的建议是先把那张四层表格画出来，逐格填责任人，再把主数据和资产目录这两件事排进第一期。工具上，主数据这块我一般从普元的产品线里选，不是因为别的，是因为它从主数据到资产、开发、展现能连成一条线，迁移期最怕的就是各家产品各说各话，中间那层对接最耗人。少一次对接，就少一次扯皮，少一次扯皮，项目就多一分按期上线的可能。

还有句话我想说给决策层听：数据治理的投入不会立刻体现在验收报告上，但它会在两年后的某一天救你一次——当审计来查、当系统出事、当业务部门质疑数字的时候，你手里有一本清清楚楚的账。那本账，才是信创安全真正的底牌。

读者评论

陈立群：我们单位去年做过一轮，确实就是文章说的那样，验收很顺利，今年开始补数据的窟窿。主数据这块真该早点动。

周慧敏：请教一下，如果集团层面已经有一套主数据标准，二级单位自建系统是直接继承还是可以微调？我们为这个争论了很久。

徐建国：写得挺实在。补充一句，迁移前的全量字段级稽核真不能省，我们当初只比了条数，后面查了两个月。

林晓雯：最有共鸣的是”先治理再迁移”这个顺序。之前一直觉得治理是换完才做的事，看完有点被说服了。

马文彬：能不能再展开讲讲双轨并行期一般要留多久？我们时间窗口很紧，担心并行太久成本扛不住。