信创 OA 改造，为什么很多单位改完反而更难用了

信创改造这两年在湖北的政企单位里几乎全面铺开。做完一轮之后，有一种反馈出现得特别频繁：系统确实能用了，国产化率也达标了，但一线员工觉得比原来难用，办公室里的抱怨比改造前还多。

这不奇怪。信创改造的验收标准和真实使用之间，本来就隔着一层。验收测的是能不能启动、能不能登录、能不能发起一条流程；员工每天面对的是公文打印出来是不是那个样子、高拍仪插上认不认、批量导入五千条要转多久。两套标准，两个结论。

下面这五个地方，是我在信创项目里见得最多、也最容易被前期方案漏掉的。它们的共同点是：测试环境里不出现，正式切换后高频出现。

一、字体：Linux 上没有「仿宋_GB2312」

这件事听起来最小，实际影响最大，因为它直接砸在公文上。

党政机关的公文排版有明确国标（GB/T 9704），正文用仿宋，标题用小标宋，一级标题用黑体，二级标题用楷体。这些字体在 Windows 上是系统自带的，在国产操作系统上通常没有——不是缺一个两个，是整套都缺。

表现是什么？系统里看着还凑合，因为有字体替换机制兜底；一旦打印成纸质文件，或者导出 PDF 上报，问题就出来了：字被换成了替代字体，字的宽度变了，原来一页装得下的内容溢出到第二页，行距和字距全走样，红头文件的版式对不上模板。

更麻烦的是字体是有版权的。很多单位习惯从网上下一个字体包装上，这在个人电脑上没人管，在单位统一部署的终端上就属于批量侵权使用。政府采购正版字体是一笔真实成本，但这笔钱必须在方案里列出来，不能等到交付时才发现预算里没有。

二、浏览器：那些依赖 ActiveX 的老控件

很多运行了十年以上的 OA，身上挂着一批只在 IE 里活的控件：电子签章、UKey 驱动、扫描仪上传、PDF 在线批注、甚至简单的附件上传按钮。这些控件当年基于 ActiveX 或 NPAPI 开发，到了国产浏览器上集体失效。

国产浏览器（奇安信、360、红莲花等）对老插件的兼容程度并不一致。有的提供了 IE 兼容模式，能跑到什么程度取决于控件本身的实现方式；有的干脆不支持。同一套系统，在 A 浏览器上签章能点出来，在 B 浏览器上按钮是灰的。

这件事的坑在于责任边界模糊。签章点不出来，是 OA 厂商的问题、浏览器厂商的问题、还是签章服务商的问题？三方都能说不是自己的。项目一旦卡在这里，进度就停住了。

务实的做法是：在方案阶段就把「哪些功能依赖插件」列成清单，逐项确认国产浏览器下的替代方案——是升级到新版本的服务端签章、是改用 USBKey 的国产驱动、还是改造前端。清单没列全，后面就是无穷的扯皮。

三、数据库：迁移的不是数据，是方言

从 Oracle 换到达梦、人大金仓或者 OceanBase，很多人以为这是一个数据搬运问题：把表建好，把数据导过去，对一遍总量，就成了。

真正的难点在SQL 方言。一套跑了十年的系统里，通常埋着这些东西：

• 存储过程和自定义函数——PL/SQL 语法在国产库上大多要重写，不是改个关键字的事；
• 序列与自增策略——Oracle 的 sequence 和国产库的实现方式不同，主键生成逻辑要跟着调；
• 分页写法——ROWNUM 那套写法换库后直接报错，得改成 LIMIT 或对应的方言；
• 字符集与排序规则——中文排序结果变了，按姓名排的列表顺序和以前不一样，用户第一眼就发现；
• 隐式类型转换——Oracle 帮你默默转的地方，新库可能直接抛异常。

典型的翻车现场是：数据量对得上，页面也能打开，但某张统计报表的数字和改造前不一样。查半天发现是某个金额字段在迁移时精度被截了，或者是日期函数的时区处理变了。

判断一家实施方懂不懂数据库迁移，问他一个问题就够了：「这套系统里有多少个存储过程，迁移后准备怎么处理？」答不上具体数量的，通常还没真正盘过。

四、性能：ARM 上的单核不是 x86 的单核

鲲鹏、飞腾这些 ARM 平台，核数多、能效好，但单核性能与同代 x86 存在差距。而 OA 这类系统恰恰是单线程敏感型的：一条流程提交要串行走完十几个节点的校验，一次页面渲染要串行查十几个表。核再多，这条链路上也只用一个核。

于是出现一种很典型的退化：原来点提交一秒出结果，现在要等三四秒。单看一次不算什么，一天点五十次就是两三分钟的干等，用户的感受是「卡」。

还有一类问题在后台：定时任务、批量导入、报表跑批。这些任务在 x86 上跑一小时，换到 ARM 上可能翻倍。如果原来的时间窗口刚好卡在上班前跑完，换平台后就跑不完了，第二天早上一堆人发现数据没更新。

这两件事都有解，但都需要在方案里预留调优工作量和压测环节：JVM 参数不能照搬 x86 的配置，连接池和缓存策略要重新算，慢 SQL 要单独优化，跑批任务要重新排时间窗。这些工作量如果不写进人天，实施方就只能糊过去。

五、外设：插上不认，是最难解释的故障

OA 系统周边通常挂着一串设备：高拍仪、身份证读卡器、指纹仪、扫码枪、手写签名板、专用打印机、扫描枪。这些设备的驱动，绝大多数是厂商针对 Windows 开发的。

国产操作系统上的驱动生态还在补。表现是：设备插上，系统能识别到一个 USB 设备，但业务系统调不起来；或者厂商直接回复「暂不支持该操作系统版本」。

这类问题的麻烦在于它不属于软件实施方的工作范围，但会被算在软件项目头上。用户不会区分是 OA 的问题还是驱动的问题，他只知道「新系统用不了高拍仪」。

六、为什么这些问题总在验收之后才爆发

三个原因，都跟项目组织方式有关。

试点部门选得太「友好」

信创试点通常挑配合度高、业务相对简单的部门。这本身没错，但试点得出的结论会被当成全单位的结论。试点部门没有公文红头、没有高拍仪、没有复杂的跨系统审批，这些坑自然测不出来。

测试环境太干净

测试库里跑的是造出来的几百条数据，正式库里是十年的历史数据、几十万条流程实例、上千个附件。数据量差两个数量级，性能和稳定性表现完全不同。

责任边界没在合同里画清

信创项目往往涉及软件厂商、集成商、硬件厂商、操作系统厂商四方。字体谁买、驱动谁找、性能谁调，合同里常常只写「由乙方负责」，但乙方是谁、负到什么程度，没写。

七、把风险提前的四件事

最后

信创这件事本身没有争议，方向是明确的。有争议的是用什么标准衡量「改完了」。

如果标准是国产化率达标、系统能启动、流程能走通，那大部分项目都算成功。如果标准是员工用得比原来顺、公文打出来还是那个样子、外设插上就能用，那相当一部分项目其实还没完成。

把后一套标准写进验收条款，是甲方在项目开始前唯一真正有效的动作。等到切换之后再来补，成本会高出一个量级——因为那时候能改的只剩下钱和时间，而这两样都不富裕。