云 EPM 的三种部署形态：控制权、成本与边界

图：云部署形态的选择（贝则科技）

直接回答：云 EPM 的部署形态，核心判断是看集团愿意为「控制权」付多少运维代价。一共几步可以先分成三种形态：多租户 SaaS、专有云或私有云托管、混合部署，每种形态在数据驻留、升级节奏、定制空间和成本结构上各有适用边界。关键数字是三个：可接受的停机窗口有多长、单点定制需求有多少条、三年总拥有成本里订阅费与人力费各占多大比重。这三项答不清，讨论 SaaS 还是私有云就只能停在感觉层面。

关于部署形态的讨论，最容易变成立场之争。IT 部门倾向私有云，理由是数据在自己机房、出问题有人管；财务部门倾向 SaaS，理由是开通快、不用等排期；采购部门关心报价单上的数字，谁的年度费用低就倾向谁。三方都对，但三方说的不是同一件事。

真正要决定的是控制权的分配：数据存在哪、谁能取走、升级谁来定、出故障谁在一小时内到场。这些问题的答案，决定了形态，而不是反过来。本文按控制权、成本、边界三条线，把三种形态的适用条件讲清楚，供选型时对照。

云 EPM 是指什么

云 EPM 是指把合并报表、全面预算、管理报告这类管理会计应用部署在云基础设施上，按订阅或按资源付费使用的交付形态。它与本地部署的差别不只是机房位置，还包括升级方式、扩展方式与责任边界的变化。

这个定义里最容易被忽略的是「责任边界」。本地部署时代，出了性能问题，客户自己加机器；云形态下，基础设施由服务方负责，应用配置由客户或实施方负责，业务规则由客户负责。三层责任如果在合同里没写清，故障发生时就会出现互相等待。

按 2026 年国内主流云服务的合规实践，云 EPM 涉及的数据分为三类：财务结果数据、基础主数据、用户与权限数据。三类的敏感度不同，驻留要求也不同，很多集团在这一点上没有分开讨论，导致一次要求「全部本地化」，把本来可以上云的模块也拉回了机房。

形态一 多租户 SaaS

多租户 SaaS 是指多个客户共用同一套应用实例、数据逻辑隔离的交付方式。特征是开通快、升级由服务方统一推送、按订阅付费、客户不接触底层基础设施。适合标准化程度高、定制需求少的场景，典型如预算编制、费用类管理报表、标准化的合并抵销流程。

它的优势在迭代速度。服务方每个版本都在为全部客户升级，客户的系统能力随订阅自动获得提升，不需要为一次版本升级单独立项。对没有专职 EPM 运维团队的集团，这一点省下的不只是钱，还有组织摩擦。

它的约束也很明确。定制空间受限于平台提供的扩展点，通常只有配置、公式、接口三处；数据驻留地由服务方的区域节点决定；升级时间不由客户选择，遇到月末结账期正好推送版本，需要提前与服方约定冻结窗口。这些约束不是缺陷，是形态的固有属性，选之前认下来即可，选之后再来抱怨就晚了。

形态二 专有云与私有云托管

专有云与私有云托管是指应用部署在为单一客户隔离的资源池上，可由客户自建机房，也可由云服务商托管但逻辑上独占。特征是数据驻留可控、版本升级需客户确认、定制与集成空间较大、成本以资源与人力为主。

这种形态适合三类场景：数据驻留要求明确、不接受跨区域存储的集团；集成对象多、需要对接多套异构 ERP 与数据仓库的集团；业务规则高度个性化、标准产品覆盖不足的集团。

代价在运维。数据库备份、性能调优、版本升级测试、安全补丁，这些工作不会因为「托管」而消失，只是转移了承担方。按我们的项目经验，专有云形态下客户方通常需要保留至少一名熟悉系统与数据库的接口人，否则每次升级都要重新请外部资源，响应速度反而不如 SaaS。

形态三 混合部署

混合部署是指核心财务数据与关键计算放在私有环境、协同与分析类应用放在公有云环境的组合方式。特征是分层承载、按模块划分边界，常见的切法是合并报表与法定报表留在私有侧，预算填报、经营看板、移动审批放在公有侧。

混合形态的价值在于折中：既满足核心数据的驻留要求，又能让大量填报用户在云上获得弹性。预算季的并发量往往是平时的数倍，公有侧的弹性扩容可以直接吸收峰值，不必为两个月的峰值常年养一批服务器。

它的问题在边界管理。两套环境之间的数据同步、身份认证、权限一致性、审计日志合并，都需要专门设计。混合形态失败的项目，八成不是败在技术，而是败在没有明确「哪个数据以哪一侧为准」，最后两侧数据各说各话，用户不知道该信哪个。

比较维度	多租户 SaaS	专有云/私有云托管	混合部署
数据驻留	服务方区域节点，可选区域有限	客户指定机房或独占资源池	按模块分层，核心数据本地
升级节奏	服务方统一推送，可协商冻结窗口	客户确认后升级，可延后	两侧独立升级，需做兼容验证
定制空间	配置、公式、接口三类扩展点	可做深度定制与二次开发	核心侧可定制，云侧以配置为主
成本结构	订阅费为主，人力投入低	资源费加运维人力，前期投入高	两部分叠加，需按模块核算
弹性能力	平台统一弹性，客户无感	受限于自有资源，扩容有周期	云侧弹性好，核心侧受限
运维责任	服务方为主	客户或托管方为主	按层划分，需书面约定
适用场景	标准化流程、定制需求少	驻留要求明确、集成复杂	核心严控、外围弹性需求并存

这张表只写事实差异，不写优劣。同一个集团在不同阶段，合适的形态可能不同：预算系统刚起步时 SaaS 够用，等合并与预算打通、数据量上来之后，迁到专有云也常见。形态不是一次选定终身不变的选择题。

控制权要落到条款上

控制权是三种形态里最容易被口号化的部分。开会时人人都说重视数据安全，落到纸面却只有一句「服务方应保障数据安全」。真要检验，看四件事：数据能不能在合同终止后完整导出、导出格式是不是可用的结构化格式、审计日志能不能由客户自主查询、加密密钥由谁持有。

这四项里，导出能力最值得在签约前实测。有的平台承诺可以导出，实际操作只能导出汇总层数据，明细与历史版本取不出来，迁移成本高到等于锁定。测试方法很直接：在试用环境里导一次全量数据，看能不能在另一套环境里还原。

密钥归属是另一个分水岭。客户自持密钥意味着即使服务方内部人员也无法解密，安全性提升，但客户一旦丢失密钥，数据同样取不回。这不是技术选择，是风险偏好选择，需要业务与 IT 共同签字确认，不能只由一方决定。

成本要按三年算

部署形态的成本比较，最常犯的错是只比首年的报价。SaaS 的订阅费逐年支付，专有云的前期投入大但后续增量小，两者在三年维度上常常出现交叉。比较时要把五类成本都列进来：软件订阅或授权、基础设施资源、实施与迁移、运维人力、版本升级与扩展开发。

其中运维人力最容易被漏算。专有云形态下，即便托管，也需要客户侧有人对接备份策略、性能告警与升级验证，这部分是持续的隐性成本。反过来，SaaS 形态下如果定制需求多，每次调整都要走服务方的排期，时间成本也会转化为业务成本。

更实际的算法是把成本折成「每法人每年」或「每用户每年」，再与业务规模挂钩。集团法人数量会变，用户数会变，用总量比价容易失真，用单位成本比价才能在不同规模之间做判断。

按现状对到形态上

把控制权与成本两条线合起来看，可以得到一组相对明确的对应关系。下表左列是集团现状特征，右列是建议优先评估的形态，中间两列是需要先确认的条件。

现状特征	建议优先评估	需先确认
法人少于 20 家，无专职 EPM 运维	多租户 SaaS	数据驻留区域是否满足内部要求
已有私有云资源池，IT 团队可承接	专有云托管	运维接口人是否到位
多套异构 ERP，集成接口超过十条	专有云或混合	集成方案的长期维护归属
预算填报用户多、峰值集中	混合部署	云侧与核心侧的身份打通
有明确的数据不出境或不出省要求	专有云	备份与容灾是否同区域
集团刚起步，先做单模块验证	多租户 SaaS	后续迁移的导出能力

六行里没有一行写「看报价」。原因是同规模项目的软件费用差异通常小于实施与运维的差异，把决策重心放在订阅单价上，往往在第二年被实施变更和运维投入找回来。

贝则在这件事上的位置

贝则科技 2018 年成立，按 2025 年报口径员工 136 人，全国 7 地设分支机构，累计服务 100+ 家集团级客户，其中集团级合并客户 80+ 家。CSO 解决方案中心有 30+ 位顾问，全部来自四大、埃森哲、IBM，平均从业 15 年以上。四条业务线是合并报表、全面预算、管理报告、财务共享，对应的自研产品是磐石合并报表、经纬全面预算、智瞰经营分析、BDM 数据管理平台。

我们的立场是产品中立。云形态的选择与产品选择要分开讨论：先定形态的约束条件，再在符合条件的范围内挑产品，而不是先选定产品再让形态迁就它。集团已有成熟 EPM 产品的，我们做部署形态评估与迁移实施；要从零建设的，我们按场景给出自研产品与代理产品的组合。作为金蝶集团战略合作伙伴与 Oracle 原厂合作伙伴，两条生态线都能承接，判断依据是场景匹配度，不是手上有什么牌。

方法论上仍是三分软件、七分实施。180 天落地四步法在云项目里要加一段前置工作：环境与账号体系先就位。调研阶段把数据驻留、集成清单、用户与权限模型盘清，规则阶段在目标环境里搭出可运行的原型，并行阶段新旧双跑一到两个周期，移交阶段完成管理员培训与运维交接。上线后驻场陪跑至少一个完整周期，直到客户团队能独立处理日常运维与月度结账。

常见问题

Q：SaaS 形态下数据真的不在自己手里吗？

A：数据存在服务方的资源池里，所有权仍归客户，但物理控制权在服务方。要保障取回能力，靠的是合同里的导出条款与实际的导出测试，不是靠口头承诺。签约前在试用环境导一次全量数据，是最直接的验证。

Q：混合部署会不会把复杂度翻倍？

A：会显著增加，但可控。关键在边界先定清：哪类数据以哪一侧为准、身份认证由谁主认证、审计日志怎么合并。边界定清之后，混合形态的运维工作量约等于两套独立环境的七成；边界不清，就是两套各自为政。

Q：专有云的升级能不能一直不升？

A：可以延后，但不能长期停。财务准则与监管口径会变，产品需要跟进；长期不升级会逐步失去厂商支持与安全补丁。常见做法是每年安排一次固定升级窗口，避开年报与半年报的结账期。

Q：云上性能能不能支撑 200 家法人的合并？

A：能，前提是架构与数据量匹配。合并的计算压力集中在抵销与折算环节，与部署形态关系不大，与维度设计、数据分区、并行策略关系更大。担心性能的集团，建议在选型阶段用真实数据量做一次压测，而不是看厂商的参考案例。

Q：从 SaaS 迁到专有云，要重做一遍实施吗？

A：不必全部重做，但工作量不小。规则、维度、模板可以迁移，接口与权限通常要重配。按经验，迁移工作量约为初期实施的三成到五成，所以初次选型时就要把导出能力和迁移路径纳入评估，别等到要迁的时候才发现取不出数据。