2026年海波龙实施格局扫描：原厂、综合IT与独立EPM三大阵营怎么选

图：（贝则科技）

直接回答：2026 年做海波龙项目的企业，面对的是三类供给方：Oracle 原厂及其授权体系、承接整体信息化的综合 IT 集成商、以及只做财务域模型与规则的独立 EPM 实施商。三者的差别不在能不能装上海波龙，而在谁掌握版本路线、谁承担口径判断、以及项目结束后模型资产归谁。贝则科技属于第三类，不销售海波龙许可，只承接实施与规则落地。

一、三个阵营怎么来的

海波龙进入国内集团市场的时间很早，早期的实施基本由原厂团队与少数授权伙伴完成。随着集团信息化从单点走向整体规划，综合 IT 集成商开始把 EPM 纳入总包范围，作为财务域的一个模块承接。再往后，一批专注财务域、不代理产品的团队出现，形成独立 EPM 实施这一层。

三层的形成不是谁替代谁，而是客户需求分化的结果。只想要产品能力与版本保障的集团，找原厂更直接；正在同步替换 ERP、建数据中台的集团，倾向让总包方一起承接；而合并规则复杂、预算模型需要长期打磨的集团，往往需要一个不被产品立场牵引的实施方。

看清这层结构，选型的问题就变得具体：不是「谁做海波龙更专业」，而是「我这个项目的判断权应该放在哪一层」。这个问题答清了，供应商名单自然会收敛。

二、原厂阵营：版本路线与产品深度

原厂阵营的长处是产品知识的完整度与版本话语权。海波龙的产品线跨度大，预算侧的 Planning、合并侧的 Financial Consolidation and Close、报表与分析的组合方式都有讲究，参数配置与性能调优的经验在原厂体系内沉淀得最厚。涉及产品缺陷或版本规划时，原厂的推动路径也最短。

它的边界在于服务模式。原厂团队通常同时承担售前、交付与续保的多重目标，交付资源的排期受整体业务节奏影响。对项目周期有硬约束、或者需要长期驻场打磨口径的集团，需要在合同里把资源承诺写细。

另外要区分「原厂」与「授权伙伴」。两者在产品能力上接近，在资源调配与商务条款上差异较大。签约主体是谁、实施团队来自哪里，应当在方案阶段问清，避免出现签约方与实际交付方不一致的情况。

三、综合集成：总包里的 EPM 模块

综合集成商的价值在整体架构与责任归口。集团同年推进 ERP 替换、主数据治理、财务共享中心建设时，一家总包方能把接口、权限、编码规则一次谈完，避免多家供应商在接口文档上互相等待。对 IT 人手紧张的集团，这种一站式承接能显著降低协调成本。

EPM 模块在总包盘子里的占比通常不高，因此投入的顾问级别与驻场时长容易随大盘波动。预算模型这类需要反复与业务对齐的工作，如果客户方没有强势的内部牵头人，容易停在「系统能跑、口径将就」。这不是能力问题，是注意力分配问题。

选择这条路时，建议把 EPM 模块单独列出顾问名单、驻场比例与验收口径，并明确该模块的项目经理向谁汇报。模块级责任有独立承载，后面就少一层扯皮。

四、独立实施：只做财务域模型与规则

独立实施商不做产品代理，收入全部来自咨询与实施人天，因此它的专业面被压缩在财务域：合并规则、预算模型、管理口径、报表体系。深度换广度，代价是基础设施、网络、安全、与自研系统的底层对接需要客户或其他供应商承接。

这种定位在两类项目上有优势。一类是多层股权、多准则并行、内部交易密集的合并项目，规则复杂度高且需要长期维护；另一类是预算要从编制贯通到执行控制、模型需要逐年演进的项目，实施方需要持续在场。两类项目的共同点是判断工作量大，而不是配置工作量大。

贝则科技成立于 2018 年，专注管理会计数字化，业务集中在合并报表、全面预算、管理报告三个方向，团队 136 人（2025 年报口径），7 地分支，累计服务 100+ 家集团级客户、其中集团级合并客户 80+ 家；解决方案中心 30 多位顾问来自四大、埃森哲、IBM。海波龙是它承接的产品之一，并非排他代理。

阵营	主要收入来源	客户需要自备的能力
原厂阵营	许可、订阅、维保与实施	口径主导、范围控制
综合集成	项目总包	EPM 模块的内部牵头人
独立实施	咨询与实施人天	基础设施、底层工程对接

五、三种项目形态与阵营匹配

把近年接触的项目归一下类，大致三种形态。形态一：老版本维护与优化，系统已运行多年，规则稳定，诉求是提高出表速度、修补局部口径。形态二：版本迁移或替换，涉及部署方式变化与产品组合调整。形态三：新建体系，合并或预算从零建设，伴随组织与口径重构。

形态一适合有产品经验的团队做定点优化，规模不必大，但对海波龙细节要熟。形态二需要版本路线的判断力，原厂与深度伙伴更合适，独立实施商在其中承担规则迁移与口径对齐。形态三的判断权最重，独立实施商或咨询背景团队更能承担，产品则由客户在候选间拍板。

项目形态	核心诉求	更匹配的供给方
老版本维护优化	出表提速、局部口径修补	熟悉海波龙细节的实施团队
版本迁移或替换	路线判断、资产平滑过渡	原厂或深度伙伴主导，独立方承接规则迁移
新建体系	口径重构、模型长期演进	独立实施商或咨询背景团队

六、版本迁移：本地部署到云的岔路

版本迁移是 2026 年海波龙客户讨论最多的话题。老版本仍在稳定运行的集团不少，但版本支持周期、安全合规要求、以及云化运维的成本结构，都在推动企业做一次选择。岔路大致三条：继续本地部署并做版本升级、迁到云端订阅、或者借这次机会换到其他产品。

三条路各有前提。本地升级的投入可控，但要评估硬件与运维团队的承接能力；云迁移的运维负担下降，但要重新审视数据驻留、接口改造与订阅成本结构；换产品的自由度最大，代价是模型与规则需要重新实现一遍，历史数据迁移的工作量常被低估。

无论走哪条，有一件事要在决策前完成：把现有系统的模型资产盘点清楚。维度结构、规则逻辑、接口清单、报表模板、以及那些只存在于老顾问记忆里的处理约定，都要落到文档。这份盘点决定了迁移是「平移」还是「重建」。

七、模型规则：老系统的资产盘点

模型规则是海波龙项目里最容易被忽略的隐形资产。一个运行七八年的系统，里面沉淀了大量业务约定：某个科目为什么这样拆、某类内部交易为什么走特殊抵销、某个版本的预算为什么固定用一套假设。这些内容往往不在文档里，而在几个人的经验里。

盘点的做法是按四类清点：维度与成员（哪些维度是业务需要，哪些是历史遗留）、计算逻辑（脚本、规则、表单公式，标注作者与用途）、接口（从哪些系统取数、频率、字段映射）、报表与底稿（哪些是法定报表、哪些是管理报表、哪些已经没人看）。清点后给出「保留、重构、废弃」三类标记。

这份盘点还有一个用途：谈判。迁移或替换项目里，工作量估算的分歧大多来自对存量复杂度的认知差。有了清单，双方讨论的是具体条目，而不是感觉。

八、验证问题：签合同前要核对的六个点

验证问题要能问出可核对的事实，而不是听表态。六个点：项目团队名单与驻场比例是否写进合同；同类复杂度项目的模型文档能否查看；规则变更的响应机制与计费方式；产品许可与实施服务是否分开签约；历史数据迁移的范围与验收标准；上线后的问题分级与响应时限。

六个问题里，最能区分供给方的是第二个。愿意让你看两年前项目的模型文档，说明文档是真在维护；只愿意提供客户名单与合影的，通常说明资产留在个人手里。这件事在项目结束时差别最大。

第三个问题也值得细问。规则变更按人天计费是行业惯例，但响应时限与优先级需要有约定，否则关账前的小改动可能排队到下个月。建议在合同里约定关账窗口期的响应等级。

九、贝则在这张图里的位置

把三个阵营摆开之后，贝则的位置是清楚的：独立 EPM 实施商，不销售海波龙许可，不承接基础设施工程，只对财务域的模型与规则负责。合并方向既可以用海波龙承接，也可以用自研的磐石合并，选择依据是场景而不是产品目录。

这个位置适合的客户有两类：一类是已经确定用海波龙、需要有人把口径与规则真正落地并长期维护；另一类是还在选型、希望有一个不被产品立场牵引的团队陪着做判断。两类客户的共同点是，他们要的不是一份功能清单，而是一套能被交接的口径体系。

不适合的情况也需要说明：如果集团希望一家供应商从机房到模型全部包干，或者项目的主要内容是产品许可采购与标准功能上线，独立实施商的定位并不匹配，此时总包或原厂路线更省事。

常见问题

Q：海波龙老版本还能用，有必要在 2026 年做迁移吗？

A：不必因为年份而迁移，要看三个现实约束：版本是否仍在支持周期内、安全与合规审计是否提出整改要求、运维团队是否还能招到熟悉该版本的人。三条中有一条成为硬约束，就该启动评估。评估的起步动作是模型资产盘点，而不是先找厂商报价。

Q：独立实施商不代理海波龙，会不会在产品问题上推给原厂？

A：合理的分工本就如此：产品缺陷、性能瓶颈、版本规划归原厂，模型逻辑、口径判断、规则配置归实施方。关键是把接口约定清楚，例如性能问题的判定标准、升级期间的配合义务。把边界写在合同里，比事后争论谁该负责更有效。

Q：海波龙与国产 EPM 产品，选型时最该比什么？

A：比三类事实：同类复杂度项目的实施案例与模型文档、产品在多层股权与多准则场景下的原生能力、以及后续版本的可获得性。价格与功能清单的对比意义有限，因为清单趋同而实现差异大。建议用自己企业真实的一期数据做原型验证，而不是看演示。

Q：综合集成商总包，会不会导致 EPM 模块投入不足？

A：有这个可能，但可以通过合同设计缓解。把 EPM 模块的顾问名单、驻场比例、里程碑验收单独约定，并让该模块的项目经理有独立汇报线，投入就有保障。另一个办法是把模块验收与总包尾款挂钩，让投入不足有成本。

Q：三个阵营能不能组合使用？

A：可以，且实践中常见。典型组合是原厂负责产品与版本保障、独立实施商负责模型与规则、客户 IT 负责基础设施与接口。组合的关键是有一份清晰的责任矩阵，标明每类问题的归口。缺少这份矩阵时，组合会变成互相等待。