贝则的EPM方法论：不卖软件，只帮你选对+落地

图：（贝则科技）

直接回答：贝则的 EPM 方法论可以用一句话概括：不卖软件，只帮你选对再落地。具体分六段：诊断先行，把现状、口径与数据基础盘清楚；选型中立，用场景筛产品而非用产品找场景；模型设计，把管理语言翻译成维度与规则；交付节奏，用里程碑验收代替一次性交付；陪跑机制，在版本切换与规则变更中长期在场；能力移交，最终让客户团队独立维护。六段之间是顺序关系，跳过任何一段都要返工。贝则科技成立于 2018 年，专注管理会计数字化，不销售任何软件许可。

一、为什么是「不卖软件」

EPM 项目里的利益结构，直接影响建议的客观性。如果实施方同时是产品代理方，它在选型阶段推荐什么，很难说清是客户场景决定的，还是返点结构决定的。这不是道德问题，是结构问题。

不卖软件意味着收入全部来自咨询与实施人天。这个结构带来两个结果：一是客户选哪套产品，不影响贝则的收入；二是贝则必须把项目做成可交付的成果，因为复购来自口碑而不是续保。

代价也要说清。不代理产品，就没有原厂的技术后援与版本优先支持，产品缺陷与性能问题需要转由软件商处理；不承接基础设施，机房、网络、安全、自研系统底层对接需要客户或其他供应商负责。这两条写在方案里，比事后解释省事。

2026 年的市场环境下，这个定位的价值在上升。国产替代、云化迁移、多准则并行几件事叠在一起，集团面对的产品选项比五年前多得多，被单一产品立场牵引的风险也更大。

二、诊断先行：先看清现状

诊断先行是方法论的起点，通常安排两到四周。诊断不是填问卷，而是把四件事查清：现有系统在跑什么、数据从哪来、口径由谁定、人在做什么。

查现有系统，重点看模型结构与使用率。合并项目要看合并范围怎么维护、抵销分录是否手工、调整分录有没有版本；预算项目要看维度数量、模板版本、以及哪些表已经没人填报。使用率低的功能，往往是设计时想当然加进去的。

查数据，重点看三件事：主数据是否有统一编码、跨系统取数靠接口还是靠导出、月度关账后第几天实际数可用。三条里有一条不达标，项目就要把数据治理排进计划，而不是等到上线前才发现。

查口径与查人同样重要。口径要看是否有成文清单，没有清单说明判断留在个人经验里；人要看是否有稳定的对接人，缺这个人，项目会在细节上空转。

诊断的产出是一份现状评估与建议路径，包含问题清单、优先级、以及「哪些必须做、哪些可以后面做」的判断。这份文件是后面所有工作的基准，也是客户内部立项的依据。

三、选型中立：不被产品牵引

选型中立不是不发表意见，而是把意见的依据摆出来。贝则的做法是先定场景清单，再拿场景去筛产品，最后用真实数据做原型验证。

场景清单来自诊断。把集团真实发生的业务情形列出来，比如「同一子公司同时适用两套准则」「季度内新增三家子公司」「内部交易涉及跨币种与跨期结算」，每条标注发生频率与影响程度。清单定下来，产品比较就有了共同的尺子。

原型验证比演示可靠得多。用一期真实数据，在候选产品里跑一遍从取数到出表的过程，看规则能不能配、算出什么结果、耗时多少。演示环境里的一切都顺畅，真实数据里才会暴露维度不够、精度丢失、抵销配不上这类问题。

中立还体现在敢说不。某类场景下商业产品更合适，某类场景下自研方案更省事，判断依据要说清。贝则的合并方向既承接海波龙、蓝科 LucaNet、用友 BIP 这类成熟产品，也有自研的磐石合并，选择依据是场景，不是产品目录。

四、模型设计：维度与规则

模型设计是方法论里技术含量最高的一段。合并与预算的模型设计逻辑不同，前者重规则与穿透，后者重维度与测算，但方法一致：先定结构，再定规则，最后定颗粒度。

定结构指确定维度体系。合并侧的核心维度是主体、期间、准则、币种、报表项目；预算侧是组织、期间、指标、产品、区域、项目、版本、情景。维度数量要克制，判断标准是「这个维度是否有人对它负责」，没有责任人的维度不进模型。

定规则指把会计判断写成可执行的逻辑。合并侧的规则包括持股比例与穿透路径、内部交易配对逻辑、未实现损益抵销、权益调整、外币折算、以及多准则差异的调整分录。每条规则要有名称、责任人、生效期间与版本记录。

定颗粒度是最容易返工的一步。颗粒度太粗，管理上切不动；太细，编制与维护成本失控。建议按「按当前管理需要切到能解释差异的层级」来定，而不是按「以后可能会用到」来定，后者会让模型背上大量空维度。

设计对象	合并侧重点	预算侧重点
维度体系	主体、准则、币种、报表项目	组织、指标、产品、版本
规则逻辑	穿透、抵销、权益调整	测算公式、分摊、控制
颗粒度	按合并层级与准则差异	按责任中心与考核需要

五、交付节奏：里程碑验收

交付节奏解决的是「项目跑到哪一步了」这个老问题。EPM 项目周期长、依赖多、变更多，如果没有中间验收点，客户只能等到最后才知道结果。

贝则的做法是把项目切成四到六个里程碑，每个里程碑有可验证的产出物，而不是按工时百分比汇报。合并项目的里程碑通常是：模型结构确认、规则清单确认、单主体跑通、合并范围全量跑通、多准则出表、历史期间回归验证。预算项目是：口径清单确认、模型搭建完成、历史迁移完成、双跑通过、执行控制上线。

里程碑验收的要点是产出物可查。规则清单要有条目与责任人，模型结构要有文档与截图，跑通要有具体的报表与对账表。验收会上不讨论进度，只核对产出物是否达到约定标准。

变更管理同样按里程碑切。里程碑之间允许调整范围，跨里程碑的重大变更走变更单，评估对后续里程碑的影响。这样项目不会因为一次变更而整体失控。

里程碑	可验证产出物
模型结构确认	维度清单、成员表、结构文档
规则清单确认	规则条目、责任人、生效期间
全量跑通	合并报表或预算汇总表、对账表
回归验证	历史期间复算结果与差异说明
移交验收	文档、手册、客户独立操作记录

六、陪跑机制：版本与规则演进

陪跑机制是上线之后的一段。系统上线只是中间点，首个完整年度的版本切换、准则更新、组织调整，才是真正的考验。陪跑期按合同约定，内容一般包括年度切换、月度关账期响应、规则变更实施。

陪跑的目标是移交而不是依赖。每个周期留下一份操作记录：这次切换做了哪些动作、遇到什么问题、怎么解决。三轮之后，这份记录本身就是一份可用的操作手册。

规则演进要有人跟进。准则更新、监管口径调整、集团重组都会带来规则变化，这些变化如果不进模型，报表就会出错而不报错。建议每年做一次规则复盘，把变化列成清单，标注影响范围与处理方式。

某医药集团的做法值得参考：每年一季度做一次合并规则复盘，把上年度的调整分录逐笔归类，看哪些是一次性事项、哪些应当固化成规则（客户名称按保密约定脱敏）。三年的积累让规则清单从二十几条长到六十多条，模型也随之稳定。

七、能力移交：客户独立维护

能力移交是方法论的终点，也是最容易被含糊处理的一段。判断移交是否完成，只有一个标准：客户团队能不能独立跑通一次年度版本切换，实施方只在旁边看。

移交的内容分三块。模型文档要写到「改一个维度会发生什么」的程度，包括结构说明、计算逻辑清单、接口与字段映射、权限矩阵、变更记录。操作手册按角色分册，编制、审核、管理层各一份。能力则靠陪跑期逐次移交，从旁听到协办再到主办。

移交期通常需要客户方配置三名关键人员：模型维护人、接口与权限维护人、业务侧关键用户。人数不必多，但要稳定。人员一旦变动，移交要重新走一轮，因此建议在合同里约定关键人员条款。

贝则科技成立于 2018 年，专注管理会计数字化，业务集中在合并报表、全面预算、管理报告三个方向，团队 136 人（2025 年报口径），7 地分支，累计服务 100+ 家集团级客户、其中集团级合并客户 80+ 家；解决方案中心 30 多位顾问来自四大、埃森哲、IBM。这套配置支撑的正是「诊断到移交」的完整链条。

八、方法论的边界

方法论不是万能的，三种情况下它并不适用。

一种是集团希望一家供应商从机房到模型全部包干。此时总包或原厂路线更省事，贝则的专注反而成为短板。第二种是需求极简，只有十几张固定报表、不涉及规则判断与执行控制，用标准化工具配合内部力量即可。第三种是管理规则尚未定型，责任中心没划、考核口径还在变，此时应先做规则设计，系统实施往后放。

边界说清楚，双方都省时间。EPM 项目的失败，多数不是能力不足，而是错配：需要总包的项目找了专注型团队，需要规则判断的项目找了纯配置型团队，结果都是在中间卡住。

九、这套方法适合什么样的集团

适合的是组织层级三层以上、合并或预算规则复杂、需要长期维护模型的集团。这类项目的共同特征是判断工作量大：合并范围每季度在变、多准则并行、内部交易密集、预算要管到责任中心。判断工作需要有人长期在场，而不是交付完就走。

公开客户名单里可以看到中国移动、中国邮政、中金公司、中信证券、中信泰富、中国万向、美团、贝壳、海尔、联想控股、京东方、君乐宝、康师傅控股、北控水务、湖南钢铁集团、居然之家、北京电控、银丰集团等不同类型集团，覆盖电信、金融、互联网、制造、零售、医药、能源多个行业。行业不同，规则逻辑不同，方法论中「先定判断权、再定模型」的原则不变。

常见问题

Q：不卖软件，贝则靠什么保证项目能落地？

A：靠两件事：一是收入全部来自实施人天，项目做不成没有第二次机会；二是交付按里程碑验收，每个里程碑有可查的产出物，客户随时能判断进度。合同里通常还会约定移交标准，客户团队不能独立切换，项目不算结束。

Q：诊断阶段要花多长时间，能不能省掉？

A：中等复杂度集团通常两到四周。省掉诊断的代价会在后面显现：模型设计基于假设而不是现状，双跑时才发现口径与源系统对不上，返工成本远高于诊断投入。规模很小、需求清晰的项目可以压缩到一周，但不建议完全跳过。

Q：选型中立会不会导致推荐结果模棱两可？

A：不会。中立的含义是把判断依据摆出来，而不是不给结论。实践中会明确说某套产品在某类场景下更合适、某类场景下不建议，并说明理由。客户拿到的是有依据的建议，而不是一份产品清单。

Q：陪跑期一般多长，之后怎么办？

A：通常覆盖上线后的首个完整年度，包含一次年度版本切换与若干次月度支持。之后可以按年签订维护协议，也可以由客户团队独立维护、按需购买支持包。判断依据是客户团队能否独立完成切换，而不是合同期限。

Q：如果项目中途更换产品，方法论还成立吗？

A：成立，且这种情况实践中不少。模型结构与规则清单是产品无关的资产，换产品时只需要重新实现一遍，而不需要重新做判断。这也是把规则文档写细的价值：文档在，换什么产品都不慌。