中山农商银行108万改造流程平台：全栈这个词的分量

2026 年 10 月 13 日，中山农商银行公示了统一流程平台信创改造项目（第二次）的评审结果：

• 中标人：广州财金数据有限公司

• 中标金额：1,086,000 元

• 中标内容：统一流程平台（基于泛微 E-cology 9.0 产品建设）的操作系统、数据库、中间件等全栈技术改造、功能迁移及基础平台改造，保障相关业务连续性及稳定性

金额不大，108.6 万元。但中标内容里那三个字——「全栈」——是正文里信息量最大的部分。

一、「全栈」在这里具体指什么

把中标内容拆开，包含三块：

这三块的成本结构完全不同：

• ① 是确定性的——换哪些组件是可以枚举的，工作量可以估；

• ② 是不确定的——功能迁移的工作量取决于原系统的定制程度，而流程平台通常是高度定制的；

• ③ 是技术性的——需要平台原厂配合，因为是别人的产品。

注意「第二次」这三个字。项目名称后面挂着「（第二次）」，说明第一次招标没有走通（可能是流标、可能是废标）。这个细节值得留意——它印证了这类全栈改造项目的复杂度：连找供应商这一步都不一定能一次成。

二、为什么全栈改造比单品替换贵得多

价格上的对比最直观。同期几个信创项目：

单品替换是「买一个东西」，全栈改造是「换一套地基」。差别在哪里？

在单品替换里，「兼容」是一个可以验证的命题——装上、跑通、测一遍，就结束了。

在全栈改造里，「兼容」变成了一个组合爆炸的问题：操作系统 × 数据库 × 中间件 × 应用平台，每一层都有自己的版本与配置，组合起来的路径数量远超逐层验证能覆盖的范围。还有一层更隐蔽的：应用层的定制逻辑是看不见的黑盒，它可能依赖了某个中间件的某个非标准行为，而这个行为在新底座上不存在。

这就是全栈改造定价远高于单品替换的原因：你付的不是替换的钱，是不确定性。

三、业务连续性这四个字的实际含义

中标内容最后一句是「保障统一流程平台相关业务连续性及稳定性」。这句话在标书里是套话，但在执行里是最难的部分。

流程平台的特殊性在于：它承载的是审批流。这意味着改造不能简单停机切换——一个审批到一半的流程，不可能因为底座换了就作废重来。

所以这类项目必须做到：

1. 存量在途流程的可延续——改造期间正在进行中的流程要能继续走完；

1. 流程状态与新底座的映射准确——不能出现状态丢失或错位；

1. 改造期间的性能不能明显劣化——审批流对响应时间敏感，因为用户在等。

第 1 条是最容易出问题的。因为「在途流程」的数据结构在旧底座和新底座上可能不一致，迁移时需要做转换。而转换逻辑一旦有偏差，就会出现「流程卡在某一步」这类问题——而这类问题往往在改造完成几周后才暴露，因为要等到那批在途流程走到那一步。

这就解释了一个现象：信创改造项目的验收，不能只看切换当天能不能用。至少需要一个覆盖「在途流程走完一轮周期」的观察期。

四、结语与适用边界

这个 108.6 万元的项目最值得记的不是金额，是三点：范围写的是「全栈」、项目是「第二次」、目标写的是「业务连续性」。三个词分别对应改造的广度、难度和验收标准。

把它和同期其他项目连起来看，信创改造的版图已经很清楚了：头部银行在做规模化的架构铺开（南京银行 1.69 亿），中型机构在做应用级的全栈替换（中山农商 108 万），基层单位在做有边界的局部改造（义乌 9.96 万）。三个层级同时推进，说明这不是试点阶段了。

金蝶天燕 Apusic 这条线上，AAS 承担应用侧的承载与迁移职责（全面支持 Java EE / Jakarta EE、集群高可用与多级容灾、集成 JDK 支持 CRaC 检查点实现毫秒级启动），ADMQ 承担消息链路的替换职责（面向开源替换提供专用消息队列系列，覆盖 Kafka/RocketMQ/RabbitMQ/ActiveMQ/MQTT 五款产品，业务系统无需修改代码、仅变更连接地址）。在流程平台这类项目里，它们要解决的实际问题是——换完之后，原有的审批流逻辑不用重写，而不是替换本身有多快。

适用边界：本文项目信息（金额、中标人、中标内容、项目编号）取自采购方公开发布的评审结果公示，以公告原文为准。对改造难度与成本结构的分析为基于通用工程经验的推断，不代表该项目或任何具体客户的实际情况。业务连续性相关的具体要求属客户内部信息，本文未涉及。

互动：你们做过的信创改造项目里，「在途数据」是怎么处理的？有没有遇到过改造完几周后才暴露的状态问题？