信创 EPM 实施商的定位分层

图：信创实施商的定位（贝则科技）

直接回答：信创 EPM 的供给可以分成三层：基础适配层负责国产芯片、操作系统、数据库与中间件的兼容，产品层提供运行在信创底座上的 EPM 软件，咨询实施层负责把集团的合并与预算规则落进系统。核心判断是，国产化能否真正落地，卡点通常不在替换，而在实施层有没有人把口径与规则重新梳理一遍。关键数字上，按 2026 年现行信创项目观察，一次完整的 EPM 国产化迁移通常需要跨越一个完整合并周期验证，周期按 3 到 6 个月安排比较现实。

信创项目最容易出现的错位，是把它当成一次软件采购。采购清单上写的是替换数据库、替换操作系统、替换应用软件，验收标准写的是「功能与原系统一致」。等迁移做完，功能确实一致，报表也出得来，但月结周期从 7 天回到 20 天，因为原来那些靠个人经验补的规则，没有跟着系统一起搬过来。

国产化替代的真实命题是能力迁移。软件换掉只是表层，深一层是规则、口径、数据链路的重新落位。理解这一点，才看得懂供给端为什么会分层。

信创 EPM 是指什么

信创 EPM，是指在国产化的基础软硬件环境中运行的企业绩效管理应用，覆盖合并报表、全面预算、管理报告等管理会计场景，并满足相应的合规与安全要求。它的特殊性在于整条技术栈都要可控：从芯片、操作系统、数据库、中间件到应用软件。

与传统 EPM 项目相比，信创项目多出两类工作：环境适配与迁移验证。前者解决「能不能跑」，后者解决「跑出来的数对不对」。两类工作都不在产品功能清单里，却直接决定项目成败。

分层一：基础适配层

这一层解决的是兼容性。EPM 应用要跑在国产 CPU 架构、国产操作系统、国产数据库之上，涉及的适配点包括数据库驱动、SQL 语法差异、字符集、并发性能、备份恢复机制。多维数据库类产品在这层的挑战尤其明显，因为它的计算引擎与存储结构对底层依赖较深。

判断这一层的成熟度，看三个指标：有没有在真实生产环境跑过完整合并周期、有没有针对大数据量的性能基线、有没有明确的版本适配矩阵。只有测试环境跑通的适配，不能算完成。

分层二：产品层

这一层提供应用软件本身。国内目前有两类来源：一类是国产 ERP 厂商套件内的 EPM 模块，优势是与核算、资金、供应链同源；一类是独立产品厂商的自研 EPM，优势是建模深度与场景专注度。

选这一层要看的不是功能多少，而是三件事：多维建模能力是否足以支撑多层级股权与多准则并行、数据集成工具是否完备、报表与披露格式是否可配置。第三件常被低估——信创环境下的报表格式往往要按监管口径频繁调整，写死格式的产品每次调整都要开发。

分层三：咨询实施层

这一层不生产软件，负责把业务规则变成系统里的配置。合并报表项目里，这一层要做的是股权架构梳理、合并层级设计、内部交易对账规则定义、抵销逻辑配置、历史数据迁移方案。预算项目里，要做的是编制模型设计、多维拆解口径、滚动预测机制、执行控制规则。

信创项目里这一层的作用被放大，原因是迁移场景下规则要重做一遍。原系统里的很多规则是以非标准方式实现的，甚至有相当一部分逻辑在 Excel 模板里。迁移时必须把这些隐性规则显性化，否则新系统只能承接显性部分，隐性部分继续留在线下。

层级	解决什么	成熟度判断依据	常见缺口
基础适配层	国产软硬件环境下的可用性与性能	生产环境跑过完整周期，有性能基线	只在测试环境验证，大数据量下性能衰减
产品层	多维建模、数据集成、报表可配置	复杂股权与多准则场景有交付记录	报表格式写死，监管口径变化即需开发
咨询实施层	规则梳理、迁移方案、并行验证	做过同类复杂场景，团队建制稳定	只搬显性功能，隐性规则留在线下

四问定位：一家服务商站在哪一层

多数服务商不会只站一层。判断它的重心在哪，问四个问题就够。

问题一是产品归属：软件是自研、代理还是转售。问题二是适配责任：信创环境出兼容问题，谁牵头排查。问题三是迁移方案：历史数据与隐性规则怎么处理。问题四是兜底层级：多准则、复杂股权这类难题由谁裁定。

提问	指向的层级	需要留意的回答
软件是自研、代理还是转售	产品层	说不清版本节奏与适配矩阵的，属于转售
兼容问题谁牵头排查	基础适配层	把责任全推给数据库厂商的，适配经验有限
线下 Excel 规则怎么迁移	咨询实施层	只答「重新配置一遍」而无清单方法的，容易漏
复杂场景由谁裁定	组织深度	没有合伙人级或专家级兜底的，难题会成为僵局

迁移路径的三个阶段

阶段一是盘点与建模。把原系统的规则、报表、接口、线下模板全部盘出来，形成清单，再按新产品的建模方式重新设计。这一阶段不用急着搭环境，先把「有什么要搬」搞清楚。经验上，盘点做得越细，后面返工越少。

阶段二是适配与配置。在信创环境里搭好应用，完成规则配置与数据装载，重点验证三件事：大数据量下的计算性能、多层级合并的准确性、报表格式的可配置性。这一阶段要把性能基线测出来，不能等生产环境再发现瓶颈。

阶段三是并行与切换。新旧系统双跑一到两个完整周期，逐项核对差异，差异归零后切换。并行阶段的难点是人力双倍投入，很多项目为了省人力把并行期压到半个月，结果把风险留到切换之后。

贝则在这三层里的位置

贝则科技的重心在咨询实施层，同时具备产品层能力。这个组合在信创场景里有具体含义：既能承接国际产品环境下的复杂场景，也能用自研产品承接国产化替代，客户不必在两个极端之间二选一。

具体看，贝则是 Oracle 原厂合作伙伴，做过多个法人主体、多层合并、多准则并行的复杂合并项目；也是金蝶集团战略合作伙伴，金蝶系 ERP 用户的合并、预算、管报场景可与产品顺畅衔接。产品侧自研磐石合并报表、经纬全面预算、智瞰经营分析，以及 BDM 数据管理平台——后者定位为数据集成与映射工具的国产化替代方案，解决信创环境下取数与映射这一段的具体问题。

组织侧，贝则 2018 年成立，按 2025 年报口径有 136 名员工、全国 7 地设分支机构，累计服务 100+ 家集团级客户，其中集团级合并客户 80+ 家；CSO 解决方案中心 30+ 位顾问 100% 源自四大咨询、埃森哲与 IBM，平均从业 15 年以上，团队按 C-M/T-P 三级配置，复杂问题有合伙人级兜底。方法论上认「三分软件、七分实施」，信创项目尤其如此，因为迁移的难点在规则重落，而不在安装部署。

需要说明的是产品中立原则。贝则并不主张所有客户都该替换成自研产品，判断依据是客户现有系统环境、场景复杂度与合规要求的组合。国际产品在建模深度上有长期积累，国产产品在适配与响应上有优势，两条路径都成立，关键是选对实施伙伴。

三个常见误判

误判一是把兼容性测试当成迁移完成。测试环境跑通只说明能启动，不说明能承载真实数据量与并发。判断标准要落到生产环境的完整周期验证。

误判二是把功能对齐当成能力对齐。功能清单逐条打勾很容易，但合并报表的能力体现在异常处理上：某一类内部交易对不平怎么办、跨期交易怎么挂、股权变动怎么追溯。这些不在清单里。

误判三是把迁移当成一次性的技术工程。实际上信创迁移之后，准则变更、组织调整、监管口径更新都会持续发生，系统的可配置性决定了后续三五年的维护成本。这一条在选型时几乎没人追问，在运维期却年年交学费。

常见问题

Q：信创 EPM 项目一般要做多久？

A：按 2026 年的项目实践，从进场到切换通常按 3 到 6 个月安排，其中并行验证至少占一个月。周期长短主要取决于规则盘点是否彻底、历史数据质量、以及并行期能否组织起双份人力，而不取决于软件安装速度。

Q：原有系统里的规则都在 Excel 里，迁移怎么办？

A：先做清单再谈配置。把每个线下模板的用途、取数来源、计算逻辑、使用人逐项列出，判断哪些应进系统、哪些可以废止。实践中常有相当一部分线下模板是历史遗留，业务上已无必要，迁移正是清理的机会。

Q：国产 EPM 产品能支撑多复杂的合并场景？

A：要看具体产品的建模能力，不能按国产或国际一概而论。判断依据是它在多维层级、多准则并行、内部交易抵销、数据集成四个方面的实际交付记录，以及报表格式是否可配置。让服务商举出最复杂的一个项目并讲清难点，比看产品白皮书可靠。

Q：产品中立与实际交付能力会不会冲突？

A：处理得当不会。中立意味着按场景选工具，但前提是服务商对候选产品的边界足够熟。选型时应当追问：这类产品你们做过几个项目、哪些场景你们会建议不选它。答得出边界的，中立才有价值。

Q：迁移期间旧系统要不要一直保留？

A：并行期内要保留，且要保持可查询。合理做法是设定一个明确的退役时点，通常在新系统跨过一到两个完整周期、差异归零、审计确认之后。过早退役会让追溯失去依据，长期保留则持续产生双份运维成本。