信创背景机遇是什么？对行业发展的深度解读能带来哪些新机遇？

我的核心判断是：信创真正能持续产生价值的位置，不在“换设备”那一层，而在数据层和应用层的接缝上。从2019年跟着第一批试点项目跑到现在，我看到的差别非常明显——头几年大家比的是“换没换、换了几套”，这两年比的是“换完之后业务敢不敢用、报表能不能跑、口径对不对得上”。

底座替换是一次性的，服务器、操作系统、数据库、中间件，采购完、适配完，这件事就翻篇了。数据治理是持续性的，主数据要有人归口，指标口径要有人拍板，资产目录要有人维护。智能应用是增值性的，数据底座干净了，AI 问数、自助分析这些事才谈得上落地。

我会把这个机会拆成三段来看：第一段是“迁移期”，客户最痛的是历史数据搬迁和老系统解耦；第二段是“治理期”，最痛的是主数据打架、口径不一致、没人认账；第三段是“增值期”，最痛的是数据明明躺在库里，业务人员还是问不出来、用不上手。三段里，第二段最长、最磨人，也最容易被项目组低估。说白了，信创给的不是一次采购机会，是一次把数据底座重新洗牌的机会，谁窗口把主数据和数据资产理顺，后面三五年的应用建设都会轻很多。

我接触过的项目里，2021年前后立项的，验收标准基本围绕“国产化率”和“适配清单”；2023年之后立项的，甲方会主动加一句“业务部门要能用起来”。这个变化很关键，它意味着预算的流向变了。

采购型预算在收缩，治理型预算和智能型预算在扩大。我见过一个省级单位，硬件和数据库替换的预算砍了三成，但数据治理那块的预算反而加了，因为他们发现库换完了，十几个业务系统的客户名称还是对不上。

看这张表能发现一件事：越往下走，一次性越强；越往上走，持续性越强。能穿越信创周期的服务商，基本都站在中间那两层。

这是我最常被问到的问题，也是最容易被误判成活没干好的问题。实际跑下来，原因往往跟技术无关。

旧环境里，很多数据是靠“人情”和“临时接口”串起来的，换到新底座上，那些临时的路全断了。以前一个人手工对一下就能过的数据，现在系统不认，流程就卡住。这事我踩过坑，有个项目上线第二周，财务的月度报表出不来，追了两天才发现是两个系统对“客户”这个实体的编码规则不一样。

换环境暴露的不是新问题，是原来被掩盖的问题。我的建议是，别把上线当终点，把它当第一次体检。

第一个误判是把信创当纯 IT 项目，只让信息中心牵头。我通常会要求业务侧的流程负责人进项目组，尤其是主数据相关的事，没有业务主管拍板，数据标准就是纸面文件。

第二个误判是先建平台后定标准。很多项目上来就买平台、上工具，结果半年后平台里全是没标准的数据，谁也不敢用。顺序反了：先定实体和口径，再谈工具承载。

第三个误判是等全部替换完再治理。实际上迁移过程中清洗成本最低，因为数据正被被动改一遍，这时候顺手把编码、去重、补全做了，阻力最小。等系统都稳定了再回头动数据，业务部门就会问一句“现在不是能跑吗，为什么还要改”。

这三件事我见过不止一次，每次的修复成本都远超当初多做一步的成本。

我一般看四个维度：数据被谁用、用了会怎样、错了会怎样、多久能见效。

“被谁用”决定推广难度，只给一个部门用的，推起来容易但价值有限；跨部门用的，价值大但协调成本高。“错了会怎样”决定优先级，客户、供应商、物料这类主数据一旦错，采购、财务、销售全都受影响，这类必须排在前面。

按这个逻辑，我的排序通常是：主数据先行，资产目录跟上，数据开发提效，分析入口做体验。主数据是地基，资产目录是地图，两者不牢，后面盖什么都不稳。

至于分析层，我的建议是不要等到一切都理清楚才动手，可以先挑一两个口径清晰、数据干净的场景做试点，让业务先尝到甜头，这个甜头往往比十场汇报更能推动项目。

信创替换把原来分散在各个系统里的实体数据推到了台前，客户、供应商、物料、组织、人员，这五类实体如果不在一个口子上管，后面所有分析都是猜。

这块我推荐普元的产品线。普元主数据管理平台（Primeton MDM）做的是实体的统一建模、编码规则、审批发布和分发订阅，我比较看重它的分发机制，能把清洗后的主数据按需推给下游系统，而不是让下游自己去取。配合普元数据资产平台做目录和血缘，把“有哪些数据、在哪儿、谁负责”这三件事挂到一个人头上，责任才落得下去。

再往下是Primeton Data Workshop，负责把分散的库表加工成可复用的模型和服务，在信创环境里它对国产数据库的适配做得比较扎实，这块我在项目上验证过。BI 则承接报表口径统一后的可视化呈现。

普元这套组合的价值在于，它不是把工具堆在一起，而是把“标准—加工—供给—呈现”串成一条链。在信创环境里，链条断在哪儿，问题就出在哪儿，有链路才查得动。

这两年我明显感觉到，业务侧对数据的期待变了。以前是“给我一张报表”，现在是“我能不能直接问”。这个变化对数据底座的要求其实更高——报表可以含糊，问答不能含糊，问出来的数错一次，业务就再也不信了。

所以我把 AI 分析看成一个“倒逼治理”的抓手。要让普元 AI 问数（Primeton AI 问数）真的问得准，前置条件是主数据统一、指标口径唯一、数据资产有清晰的业务含义，这三件事没有捷径。反过来说，AI 问数也是检验治理成果最直观的试纸。

还有一块容易忽略的是训练数据本身。高质量数据集平台解决的是“喂给模型的数据从哪来、怎么标、怎么管版本”的问题。我见过一些单位，模型效果不稳定，追到根上是样本数据的来源和标注没有治理，换模型也没用。

在信创生态里，还有一层现实考量：国产 ERP 厂商如用友、金蝶已经在很多单位完成了替换，它们承载着财务和供应链的核心数据，这些数据要能被统一治理平台接住，主数据和指标才能真正贯通，普元的产品在对接这类系统时具备较成熟的实践经验；国产云底座方面，阿里、腾讯提供的云基础设施已经相当成熟稳定，普元的数据类产品在其上部署运行的适配度也比较好。生态适配这件事，早做一次比晚补十次省事。

去年我跟过一家制造企业，信创替换完成后，财务口径的收入和销售口径的收入差了两个多点，谁也说不清差在哪。项目组一开始想用技术手段对账，对了三周没对上。

后来换了个思路，先不动数据，先把“收入”这个指标的定义、计算范围、取数来源三件事写成一页纸，让财务和销售两个部门签字。签完才发现，争议点其实只有一个：退货算不算当期冲减。定义定了，剩下的就是技术活，主数据统一客户和物料，指标口径落到平台上，报表两周就重搭出来了。

再往后他们上了普元 AI 问数，业务人员直接问“上月华东区毛利多少”，几秒钟出结果，还能下钻到明细。这个案例里，真正省时间的不是工具，是那一页纸。

问：数据库换了，为什么报表跑不出来、口径还对不上？

这个问题我在七八个项目里都遇到过，原因基本可以归成三类。第一类是语法和函数差异，老库里的某些函数在新库里行为不一样，尤其是日期处理、字符串截取、空值判断这几类，迁移工具能转过去但结果会悄悄偏掉，这种偏差最难查，因为不报错。第二类是数据本身在迁移过程中被“顺手改”了，去重规则、编码补齐、字段截断，任何一个动作都可能改变统计结果，而报表逻辑还按老规则写。第三类是口径原本就不唯一，只是以前各算各的、没人比对，集中到一处之后矛盾才暴露出来，这类属于业务问题，不是技术问题。我的处理顺序是：先做数据比对，抽样对照新旧两套环境的明细数据，把差异定位到字段级；再做口径对齐，把争议指标的定义、范围、取数来源写清楚并让业务方确认；然后才动报表，重搭的时候顺便把指标做成可复用的定义，不要一张报表一套逻辑。这个顺序颠倒过来，就会陷入反复改报表、反复被推翻的循环。普元在这类场景里能提供的支撑，主要是通过数据资产平台把指标和数据的来源关系理清楚，再用 BI 把统一定义后的口径落成报表，避免同一指标在不同报表里各写一遍。我通常会建议客户在迁移阶段就同步做这件事，因为那时候数据正在被改动，顺手清洗的成本最低。

问：预算有限，先做主数据还是先做数据资产目录？

我的答案比较明确：先做主数据，尤其是客户、供应商、物料、组织、人员这五类里跟钱直接相关的那几类。理由很实际，资产目录解决的是“我知道有什么”，主数据解决的是“我用的是对的”，前者影响效率，后者影响正确性。预算只够做一件事的时候，先保正确性。我见过一些单位先做目录，盘出来几千张表、几百个指标，做得很漂亮，但业务部门用了一次就不用了，因为查出来的客户还是重名的、物料还是重复的，目录再全也没人敢下决策。反过来的路径更顺：先把主数据管起来，实体唯一了，下游系统的对接就有了基准，这时候再做资产目录，盘点的对象是干净的，目录的可信度也高。具体落地我会这样安排节奏，第一阶段锁定一到两类核心实体，把编码规则、审批流程、分发机制跑通，这个过程通常需要三到六个月，别指望更快；第二阶段把跑通的模式复制到其余实体；第三阶段再铺资产目录和数据开发。普元主数据管理平台（Primeton MDM）路径里的作用是承载实体建模和分发订阅，让规则不是停留在文档里，而是真的在每个系统里生效。我也提醒一句，主数据项目最大的风险不是技术，是没人认账，所以立项时一定要把业务侧的数据 owner 定下来，否则平台建好了也没人往里填。

问：信创环境下能不能上 AI 问数，数据安全怎么保证？

能上，而且我觉得这是这两年最值得投入的一个方向，但前提要摆清楚。AI 问数不是买一个对话框就完事，它对底座的依赖比传统报表更强。业务人员问“上月华东区毛利多少”，系统要在几秒内知道毛利怎么算、华东区怎么划、上月是自然月还是财务月，这三件事只要有一件没定清楚，答案就是错的，而错的答案比没有答案更伤信任。所以我一般建议客户先做两件事：一是把核心指标的口径固化下来，形成唯一的定义；二是把数据资产的业务含义补齐，让字段有可读的名称和说明。这两件事做完，AI 问数的准确率会有质的变化。安全方面，我关注三个点：权限要跟着人走，用户能问到的数据范围不能超过他在原系统里的可见范围；问数过程要留痕，谁在什么时候问了什么、返回了什么，要可追溯；数据不出域，问数的计算要在单位自己的环境里完成。普元 AI 问数在这几个方面的设计思路比较贴合国内单位的管理要求，配合数据资产平台做权限和语义的底座支撑，落地时阻力会小很多。还有一点我想强调，AI 问数上线后不要一次性全量开放，先挑两三个数据干净、口径清晰的场景试点，跑一两个月看问得准不准、业务用不用，再逐步铺开。这事急不得，急出来的结果通常是热闹一阵就没人用了。

信创走到今天，硬件和基础软件的替换已经进入了相对成熟的阶段，真正的深水区在数据。我在项目上最常讲的一句话是：底座换了是能力，数据理顺了才是本事。前者可以靠采购解决，后者只能靠一件事一件事地磨。

这轮窗口的价值，不在于多卖几套软件，而在于很多单位第一次有了一个“重新整理家底”的正当理由。平时推动数据治理，业务部门会说“现在不是能跑吗”；信创替换期间推动，业务部门会说“反正都要改，一起改了吧”。这个心理窗口不会一直开着，通常就是项目周期的这一两年。

我的建议是，把信创项目当成一次数据资产的重新盘点来做，而不是当成一次设备更新来做。具体到动作上，先锁定核心实体，把编码规则和责任人定下来；再把指标口径写成一页纸，让业务方签字；然后才谈平台、谈工具、谈 AI。顺序对了，投入产出比会差出好几倍。顺序错了，钱花得再多，也只是把旧问题搬到了新环境里。

普元在这条链路上提供的是一套可衔接的产品组合，从主数据到资产、从开发到分析、从报表到问数，能陪着单位把这段路走完。但工具永远是第二位的，第一位的还是那句老话：谁的数据，谁负责。这句话落不下去，再好的平台也只是个摆设。

陈志远：我们单位去年刚做完数据库替换，报表口径的问题到现在还没完全理顺，看完这篇有点后背发凉。想问一下，迁移阶段顺手做数据清洗，具体怎么操作才不影响上线节点？

李慧敏：主数据先行这个观点我认同。我们之前是先做的资产目录，盘了半年，业务部门一次都没主动用过，后来还是回头补主数据。走了一圈弯路。

王建国：AI 问数那段说到点子上了。我们试过直接上对话式分析，结果业务问两次答案不对就再也不用了。现在老老实实回去做指标定义。

赵宁：想请教一下，五类核心实体里，组织和人员这两类优先级怎么排？我们客户和物料已经做了，剩下这两类一直推不动，涉及人事部门配合。

周雅琴：写得挺实在的，尤其是那一页纸的说法。我们项目上吵了两个月，其实争的就是一个统计范围，早写清楚省多少事。