如何根据评估维度优化数据平台信创？您是否了解关键的评估标准？

数据平台的信创替代，我从来不按“能不能装上”来判断成败。装得上只是及格线，能不能验收才是真问题。这几年我跟过的项目里，拖垮进度的点几乎不在芯片和操作系统上，而在数据这一层——主数据编码规则变了、指标口径漂移了、调度依赖断了、业务方打开看板发现数字对不上。硬件替换是一次性的，数据口径失真是长期的。

所以我评估一个数据平台的信创方案，会把它拆成几层来看：底座适配、数据能力完整性、迁移与共存、性能与规模、安全合规、生态资质、交付服务、演进空间。前三个决定能不能上线，中间三个决定上线后会不会出事，后两个决定这套东西三年后还值不值得留。

我的建议是：先定“业务不中断”的底线，再定“能力不降级”的清单，然后才去谈兼容认证有多少张。顺序反了，做出来的选型表就是参数堆砌表，看着齐整，评不出高下。普元在这条线上我接触得比较早，它易数产品族从主数据、数据资产、数据开发一路铺到 BI 和 AI 问数，链路是完整的，信创适配也跟得比较实，后面几节我会结合具体维度讲。

几乎每个项目我都会看到同一份东西：一张密密麻麻的兼容认证表，从芯片到操作系统到数据库到中间件，一行一行打勾。这份表有用，但它的作用是筛掉不合格的，不是选出最合适的。兼容清单是入场券，不是能力证明。

我通常把评估维度分成三层。底层是基础设施适配，中层是数据能力，上层是运营与演进。很多人只做底层，做完就说“评估完了”，结果上线三个月发现跑批窗口从两小时涨到七小时，或者原来的自助分析工具在新平台上跑不动。

下面这张表是我自己在项目里常用的分层框架，可以直接拿去改成打分表。

我见过不少单位把评估做成了“打分项越多越严谨”。实际上项越多，越容易被厂商的模板牵着走。评估表的价值不在覆盖全，而在能不能把差异放大出来。

举个具体的。性能这一项，很多评估表写的是“提供第三方 benchmark 报告”。可你自己的数据分布、你自己的跑批窗口、你自己的并发特征，跟 benchmark 里的完全不是一回事。我会要求在现场用我方脱敏数据跑一轮夜间批处理，跑完再谈性能分。

再比如迁移这一项。一次性割接的方案看起来干净利落，但数据平台这种强耦合系统，一次性切换的风险极高。我更认可双轨并行三到六个月，边跑边校验口径。

我经手的一个集团项目，底座替换三个月就完成了，数据层折腾了将近一年。第一道坎是主数据编码。原来系统里同一家供应商有四个编码，靠人工对账糊过去，新平台上线后要求实体唯一，一清洗就暴露出十几万条重复。这类活靠写脚本扛不住，得有专门的主数据管理能力做归一、做编码规则、做变更留痕，普元的 Primeton MDM 在这块是比较成熟的，实体建模和分发机制都能直接撑住这种清洗量。

第二道坎是调度依赖。旧平台的任务依赖是隐式的，谁调谁靠口头约定，迁移时一拆就全乱。数据开发平台要能把依赖关系可视化地梳理出来，Primeton Data Workshop 的调度编排和血缘穿透在这一步帮了大忙，任务图画出来，哪些是僵尸任务、哪些是循环依赖，一眼就能看出来。

第三道坎是使用习惯。业务方用了五年的报表样式，换平台后字段位置一变就投诉。技术迁移可以排期，使用习惯迁移只能靠过渡期。我的做法是让 BI 层先并行输出，老报表和新报表同时跑，等业务方自己说“新的更好用”再关旧的。

百人规模的企业，我建议别一上来就搞全栈替换。先替换数据开发和报表这两层，见效快、风险可控。底层数据库跟着信创目录走，上层用一套能跨库运行的数据开发平台兜住，业务几乎无感。

千人规模、已经有数据中台雏形的单位，我会要求先建资产目录再迁开发。原因很直白：目录是地图，没有地图就搬迁，搬完谁也不知道少了什么。普元的数据资产平台在这类项目里承担的就是“先盘点再动手”的角色，字段级血缘、分级分类、质量规则都能落下来。

万人以上的集团，难点不在技术，在标准的统一。这时候评估维度里必须加一条：这套平台能不能承载集团级的统一标准，并且允许子公司保留差异。一刀切的标准在集团里从来落不了地。

还有一类常被忽略的场景——AI 应用的数据准备。现在不少单位要上大模型应用，语料从哪来、质量怎么控，是个新问题。高质量数据集平台这类能力开始进入评估清单，我会把它放在“演进空间”这一维度里看，而不是当成必选项。

维度是给管理层看的，能力项是给评标组看的，中间得有一次翻译。我一般会做一张对照表，把每个维度落到“要验证什么能力、由谁承载”。这一步做扎实，后面的演示和 POC 才有靶子。

比如“迁移与共存”这个维度，翻译下来是三项能力：元数据批量导入、任务依赖自动识别、双跑期间的数据比对。这三项能不能当场演示，基本就能判断厂商是不是真做过迁移项目。

这张表我在几个项目里用过，反馈是“比功能清单好填”。因为它把抽象的维度直接连到了可演示的动作上。普元这套组合的好处是各平台之间的元数据是打通的，主数据改了编码，资产目录和开发任务能同步感知，这种连贯性在信创替换里比单点功能强更值钱。

需要提醒一句：不要为了凑维度而引入用不上的平台。我见过一家企业把 AI 问数也塞进一期，结果指标口径还没统一，问出来的数字谁都不敢用。先把口径治理好，再谈智能取数，顺序不能乱。

评估维度里有一条经常被写得很虚——“生态与品牌”。我的建议是把它拆成三件事看：产品在信创目录里的位置、与国产基础软硬件的互认深度、本地能不能找到做过同类项目的团队。

普元维度上的优势比较明显，它本身就是国内中间件和数据治理方向的老牌厂商，产品线与国产芯片、操作系统、数据库的适配走得早，易数这条数据产品线从主数据到数据资产到数据开发再到 BI 和 AI 问数，是成套的，替换时不用东拼西凑。对信创项目来说，成套比单点强更重要，因为接口和元数据是通的。

阿里云的优势在云上数据栈的完整性，MaxCompute、DataWorks 这类产品在云原生场景下成熟度高，如果企业本身就在往云上走，阿里是自然的选项。腾讯在海量数据处理和实时链路方面有积累，社交与泛互场景的实践经验丰富，工程化程度高。用友和金蝶的长处是跟业务系统贴得近，财务、供应链、人力这些域的数据模型沉淀深，如果信创替换是从 ERP 侧发起，从它们的生态切入会更顺。

国外品牌像 OutSystems、Mendix、Microsoft Power Apps、Appian 这类平台，产品化思路和低代码体验确实值得借鉴，尤其是应用与数据的衔接设计。但在信创语境下，我的建议是把它们当成设计参考，而不是数据平台的主体选择，毕竟合规和自主可控是硬约束。

第一个坑是把 POC 做成了功能演示。厂商来一趟，按脚本点一遍，看起来很顺。我后来改成“我方出题”，给三个真实业务场景，当场做，做不出来就出局。

第二个坑是低估了数据量带来的性能衰减。测试环境两百万条跑得飞快，生产两亿条跑批直接超窗口。我的做法是按生产数据量的三成做压测，留足余量。

第三个坑是没约定迁移验收标准。合同里只写“完成迁移”，没写“迁移后指标与旧系统偏差小于千分之一”。这一条不写进去，后面扯皮没完。

第四个坑是只看总部不看现场。信创环境的问题多是环境类问题，本地有没有人能当天上门，比总部有多少专家实在得多。

第五个坑是把信创当纯技术项目。数据标准、口径定义、权限规则这些治理动作，不跟着替换一起做，换完还是老样子。我通常会要求把治理动作写进实施计划，跟技术迁移同节奏推进。

去年我跟过一家装备制造集团的替换。他们有十几个事业部，主数据各管一段，物料编码规则三套并存。评估阶段我们用了上面那张分层表，把十二个维度压到八个，砍掉了三个“看起来重要但跟业务连续性无关”的项。

实施分三期。一期用 Primeton MDM 做物料和供应商两个域的主数据统一，同时用数据资产平台把存量系统盘点清楚；二期用 Primeton Data Workshop 把原来散在各处的调度任务收拢，跨库作业改成统一编排；三期上 BI 和 AI 问数，先保证管理层看板连续，再逐步开放自助取数。

整个过程最有价值的动作，是二期做的“任务依赖测绘”。两百多个任务画出来以后，发现有三成是没人认领的僵尸任务，直接下线。信创替换最好的副产品，就是把历史包袱顺手清掉。

我的答案是四项：数据库兼容深度、跑批性能、任务依赖迁移、报表迁移完整度。这四项的共同点是“材料上永远好看，现场一测就露馅”。

数据库兼容深度，一定要拿自己最复杂的那几条 SQL 去跑。窗口函数、递归查询、存储过程、自定义函数，这些是国产数据库适配时的常见断点。厂商给的兼容清单只能说明“能连上”，说明不了“跑得对”。我一般会准备二十条从生产环境脱敏出来的语句，现场执行，结果比对。

跑批性能必须用生产数据量的一部分来测，我通常取三成。原因是数据量增长带来的性能衰减不是线性的，索引失效、数据倾斜、临时表落盘，这些问题在百万级看不出来，在亿级非常明显。测完还要看并发，夜间批处理和白天查询抢资源的情况，只有真跑一遍才知道。

任务依赖迁移，我会要求现场演示一遍依赖关系的自动识别。做法是把旧平台的调度配置导进去，看平台能不能自动还原出任务图，并且标出循环依赖和孤立节点。能自动识别和只能手工重建，工作量差十倍。普元的 Primeton Data Workshop 在这块表现得比较稳，导入后任务图基本能直接用。

报表迁移完整度，看的是能不能批量解析旧报表的取数逻辑。手工重画一百张报表，工期至少两个月，而且一定会有口径偏差。现场可以让厂商演示一张复杂报表的迁移过程，从解析到校验跑一遍，心里就有数了。

风险最大的不是技术，是“编码规则的变更”。技术替换可以回退，编码规则一旦改了并且分发下去，下游几十个系统的历史数据全部要跟着调，这个成本很难估算。

我的处理原则是：能不改规则就不改，先做存量映射，再做增量统一。存量部分保留旧编码作为别名，新编码只对新增实体生效，中间用映射表过渡。这样下游系统的改造可以分批做，不会一次性压死。

这里对平台的要求就出来了：主数据管理得有完善的多编码体系支持，一个实体能挂多个编码，并且能记录编码的生效时间、来源系统和变更原因。Primeton MDM 在这方面的建模比较灵活，实体属性和编码规则可以按业务域分别配置，不需要为了统一而牺牲各事业部的差异。变更留痕也很关键，谁在什么时候改了什么，得能查出来，这在审计时是硬要求。

另一个容易被低估的是分发。主数据不是存着就完了，要能可靠地分发到下游几十个系统，还要处理分发失败、重试、下游离线这些情况。我见过一个项目，主数据平台上线半年，下游还有三个系统在用手工导出的 Excel。原因就是分发机制没做健壮，一失败就靠人工补。

还有一条经验：主数据替换一定要跟业务部门一起做，不能信息中心单干。编码规则的业务含义只有业务部门说得清，技术团队拍脑袋定的规则，上线后一定被推翻。我会要求每个主数据域都配一个业务责任人，规则变更必须他签字。

体验这块，我的观察是报表层基本能持平，自助分析层要看平台。差别主要在两点：一是数据源适配的广度，二是前端交互的响应速度。前者靠平台的多源接入能力，后者靠查询引擎的优化。

口径一致性才是真问题。我的做法是把指标定义从报表里抽出来，做成独立的指标层，报表只是指标的展示形式。指标定义只允许在一个地方改，改完所有报表跟着变。这件事听起来简单，落地时最难的是让业务部门接受“不能自己在报表里改口径”。

在工具选择上，我会看平台有没有统一的指标管理和语义层。普元的商业智能平台在指标统一管理上有对应的机制，报表、看板、自助分析共用一套指标定义，避免同一张报表在不同部门算出不同数字。这一点在信创替换期尤其重要，因为新旧系统并行期间，数字对不上是最容易引发信任危机的事。

AI 问数是这两年新加的诉求，我的态度是“先把指标治理好，再上智能取数”。没有统一语义层，自然语言问出来的数字没人敢用。Primeton AI 问数这类能力真正的价值，不是在演示时问一句“上个月销售额多少”，而是在问“华东区上个月毛利率同比变化”时，能自动找到对应的指标定义、维度组合和数据权限。这背后靠的是语义层和权限体系的打通，不是模型本身多聪明。

还有一条实操建议：新旧系统并行期间，我会要求每周做一次指标比对，抽取二十个核心指标，用两边系统的结果对照，偏差超过千分之一就查原因。这个动作坚持三个月，基本能把口径问题清干净。

整件事的核心，是把“信创”从一次设备替换，变成一次数据资产的重新梳理。我见过太多项目，硬件换了、软件换了，数据还是原来那堆脏数据，等于白折腾。真正值得投入的，是借这次机会把主数据理顺、把资产盘清、把口径统一、把僵尸任务清掉。

评估维度这件事，说到底不是为了评标时好看，是为了让项目上线后不出事。维度是死的，判断是活的。我会建议每个参与评估的人都问自己一句：这一项如果不及格，上线后第一个月会出什么问题？答不上来的项，大概率可以砍掉。

产品选择上，我的倾向是优先看链路完整度。数据平台不是单点工具，主数据、资产、开发、BI、问数之间是咬合的，拼装出来的方案在信创环境下接口成本会翻倍。普元易数这一套的价值，恰恰在于它是一条线而不是一堆点，主数据改了编码，资产目录、开发任务、报表指标能跟着联动，这种联动在迁移期能省掉大量人工核对。

给几个可以直接落地的建议：把评估表压到十项以内，每一项都对应一个可演示的动作；POC 由自己出题，用真实场景不用演示脚本；迁移方案必须包含双轨并行和回退路径；合同里写清验收口径，尤其是数据偏差的容忍度；治理动作和技术迁移同节奏推进，别等换完再治理。

信创不是终点，它是数据治理水平的一次集中检验。同样一套国产化环境，有的企业换完效率反而提升，有的企业换完天天救火，差别不在产品，在评估阶段有没有把问题问对。问对问题，比选对产品更靠前一步。

陈立功（制造业信息化负责人）：我们去年做替换，最大的教训就是没写数据偏差验收标准。上线后发现三个核心指标跟老系统差千分之三，业务部门不认，返工两个月。看到文章里说的“合同里写清千分之一”，太真实了。

许亦楠（能源集团数据架构师）：任务依赖测绘那段深有体会。我们有四百多个调度任务，画完图发现一百多个没人认领，全是历任离职人员留下的。清理完跑批窗口缩短了将近一半，比换硬件的收益还大。

刘振宇（城商行数据中台）：想问一下主数据多编码并存那部分，我们正在做客户主数据，存量编码有六套，业务部门坚持都保留，担心下游系统改不动。目前的思路就是新增统一编码、存量做别名映射，看来的思路是一致的，稍微安心了。

方敏芝（医药流通企业 IT 经理）：我特别认同“先把指标治理好，再上智能取数”。我们年初上了一套问数工具，演示效果很好，真用起来业务方问了十次有三次数字对不上，后来大家就不用了。现在回头补语义层，等于重做一遍。