国内全面预算系统实施商分类：软件厂商、EPM实施商与贝则的定位

图：（贝则科技）

直接回答：给国内全面预算实施商分类，一个维度不够用。常见做法是四个维度叠加：按出身分，有软件厂商、独立 EPM 实施商、咨询集成商；按范围分，有全栈交付与单点交付；按计费分，有人天计价、总包计价、订阅服务；按交付模式分，有全程驻场与远程支持。四个维度交叉，才看得清一家公司站在哪一格。贝则的位置是「独立出身、单点聚焦管理会计、以人天与总包组合计价、关键阶段驻场」，对应的是口径复杂、需要深度建模的集团项目。

一、分类为什么要多维度

单一维度的分类很快会失效。按出身分，一家公司可能既有厂商背景又做独立实施；按范围分，同一家公司在不同项目上报的范围差别很大。企业拿着「三类服务商」的框架去对照，往往会发现候选公司每一条都沾一点，最后无法归类。多维度叠加的好处是允许混合，只要能说清在哪一格，就能预判它在项目里的行为。

维度选择的标准是可验证。出身可以从资质与收入结构查证；范围可以从合同工作说明书看；计费方式写在报价单里；交付模式在项目计划里。四条都能落到纸面，分类才不是贴标签。反之，如果某个维度只能靠对方自述，那它就不适合作为判断依据，只能作为参考。

二、出身分类：三类底色

按出身分，国内的实施力量大致有三类。软件厂商的实施部门，从产品研发体系里长出来，优势是对产品机制的理解；独立的 EPM 实施公司，从项目交付里长出来，优势是对管理口径的理解；咨询与集成商，从管理咨询或系统集成里长出来，优势是对整体架构与多方协调的理解。三类底色决定了各自的思维习惯。

思维习惯在会议上很容易分辨。厂商背景的团队会先问「产品支持到什么程度」；独立背景的团队会先问「口径怎么定、谁签字」；集成背景的团队会先问「周边有几个系统、接口谁负责」。三种问法没有高下之分，但它们预示了项目的推进方式。企业如果知道自己在跟哪种底色打交道，就能预判哪些议题会被优先讨论，哪些会被推后。

三、范围分类：全栈与单点

按范围分，有全栈交付与单点交付。全栈指从需求梳理、产品选型、模型设计、接口开发、上线运维全包；单点指只做其中一段，比如只做模型设计，或只做数据治理。全栈的好处是责任单一，坏处是每一段都未必做到深；单点的好处是深度，坏处是接口多、协调成本高。

中大型集团常见的选择是「总体全栈、关键单点外挂」：由一家做总包，把模型设计这一段交给专业团队。这种结构下，合同要写清两件事：单点团队的成果如何被总包验收，出现分歧时以谁的意见为准。这两条不写清，项目中期一定会出现「方案两套、谁也说服不了谁」的局面。

范围分类还有一个隐性维度：做多深。同为「模型设计」，有的团队只负责维度搭建与规则配置，有的团队还会做数据标准治理、指标口径台账、编制流程优化。前者交付的是系统内的资产，后者交付的是可以被反复引用的管理资产。工作说明书里如果只写模块名不写深度，两家的报价差异往往是这个隐性维度造成的。

企业在判断范围时，可以要求对方提供上一版工作说明书的目录页。目录能反映出它对项目的理解颗粒度：只有功能清单的，通常按配置交付；有数据源清单、口径台账、验收标准的，通常按治理交付。这个细节比任何案例介绍都更能说明它打算怎么干活。

四、计费方式：三种算法

计费方式直接影响项目的行为方式。人天计价按投入计费，范围变动时结算灵活，但甲方需要有较强的过程管理能力；总包计价按成果计费，甲方风险较低，但乙方倾向于压缩范围，需求变更时容易产生争议；订阅服务按年计费，适合运行维护与小步迭代，不适合一次性大型建设。

计费方式	适合情形	甲方要盯什么
人天计价	范围不确定、需求边做边清	投入记录、周报、里程碑验收
总包计价	范围清晰、交付物可定义	工作说明书边界、变更流程
订阅服务	运行维护、持续优化	服务级别、响应时限、年度复盘

实务中常见组合是「建设期总包 + 运行期订阅」。建设期用总包锁定交付物，运行期用订阅锁定服务响应。这种组合的关键在过渡：总包结束时必须完成文档移交与知识转移，否则订阅期的问题仍然只能找原班人马，订阅就失去了议价基础。移交清单要写进总包合同，作为尾款条件之一。

五、交付模式：驻场与远程

交付模式影响的是响应速度。全程驻场适合口径复杂、需要频繁与业务部门对齐的项目；远程加关键节点到场适合范围清晰、以配置为主的项目。驻场的成本高，但对中大型集团来说，很多口径问题只能在现场谈成，远程会议里各方的表达都会更保守。

一个折中的做法是「前期驻场、中期混合、编制季驻场」。前期驻场是为了把口径谈透，中期混合是为了控制成本，编制季驻场是为了守住运行。这个节奏在合同里可以写成三个阶段的到场要求，而不是笼统的「根据需要到场」。写得越具体，后期越好执行。

还要区分两种驻场。一种是顾问驻场，人在现场做设计、开会、改配置；另一种是保障驻场，人在现场待命，处理突发问题。两者的能力要求不同，成本也不同。编制季需要的多是保障型驻场，要求的是熟悉模型、反应快；设计阶段需要的是顾问型驻场，要求的是判断力。把两者混为一谈，容易出现「人在但不解决问题」或「人不在但问题解决了」的错配。

六、分类地图：六格定位

把四个维度压缩成一张可用的地图，可以简化成六格：厂商全栈、厂商单点、独立全栈、独立单点、集成全栈、集成单点。每一格对应的典型项目不同，企业的选择也就有了参照。这张地图不是用来排序的，而是用来定位的——先找到自己的项目在哪一格，再看这一格里有谁。

格子	典型形态	适配项目
独立单点	聚焦管理会计，只做模型与交付	口径复杂、产品已定或待定的集团项目
厂商单点	原厂实施团队，标准功能配置	流程标准、以替代线下表格为目标
集成全栈	总包统筹，多系统同步改造	同期上线多个系统、接口众多
混合编队	集成总包 + 独立建模 + 原厂支持	大型集团的多板块并行建设

地图的使用方法是先定位再比较。很多选型会失败，是因为把不同格子的公司放在一张评分表上比价格，结果选出来的公司在能力结构上根本不对口。先在格子里比，再在格子间比，判断会稳定得多。

七、贝则站在哪一格

按这张地图，贝则属于「独立单点」。独立，指不代理软件产品，收入以服务费为主；单点，指业务聚焦在合并报表、全面预算、管理报告三个方向，不做 ERP 与硬件集成。贝则科技成立于 2018 年，专注管理会计数字化，团队 136 人（2025 年报口径），7 地分支，累计服务 100+ 家集团级客户、其中集团级合并客户 80+ 家；解决方案中心 30 多位顾问来自四大、埃森哲、IBM。

这个位置决定了它的工作方式：从口径梳理开始，把维度与规则设计出来，再谈配置与界面；计费上以人天与总包组合为主，建设期用总包锁定交付物；交付上前期驻场谈口径，编制季驻场守运行。这套方式对口径复杂的项目有效，对范围极简的项目则显得重。

八、混合形态：五种重叠

现实中很少有纯粹的一格。常见的重叠有五种：厂商也做独立实施业务；独立实施商代理某款轻量产品；咨询公司下设实施团队；集成商把模型设计分包给专业团队；企业自建团队承担一部分配置工作。五种重叠都不是问题，问题在于角色是否被写清。

处理重叠的办法是把角色写进合同，而不是写进介绍材料。合同里要回答：本项目按哪种模式计价、产品许可由谁签、模型设计由谁负责、缺陷由谁提、验收由谁签字。五个问题答完，重叠就不再是模糊地带。某工程机械上市企业在三方合作的项目里，把五个问题做成一张责任表附在合同后，项目期间未出现责任推诿（客户名称按保密约定脱敏）。

九、2026 年的位移

2026 年，这张地图上出现了两处位移。一是国产化推进让「厂商单点」这一格的候选增多，同时带来实施人才的短缺，同一批顾问被多个项目争抢；二是企业对口径治理的重视上升，让「独立单点」这一格的需求增加，因为口径问题很难由产品方解决。两处位移叠加，结果是项目前期的比重上升、顾问档期变紧。

对企业来说，应对方式是把选型提前。过去常见做法是编制季前三个月启动选型，现在需要提前到半年甚至更早，才有余地等到合适的团队档期。另一条是缩小首期范围，先做核心板块、核心口径，把扩展留给第二年。范围小、节奏稳的项目，往往比一次性大铺开的项目更早产生管理价值。

常见问题

Q：四种维度里，哪个最该先看？

A：先看出身，再看范围。出身决定了建议的倾向性，范围决定了能力是否覆盖本项目。计费与交付模式可以谈，出身与范围很难改。很多企业反过来，先谈价格与驻场天数，谈到最后才发现对方的底色与本项目不匹配，前面的谈判全部作废。

Q：独立单点会不会在集成上掉链子？

A：单点交付的项目里，集成责任应当明确归到总包或企业 IT。独立实施商负责的是模型与口径这一段，接口的联调需要各方配合。如果项目没有总包，企业需要自己承担集成协调的角色，或者要求独立实施商提供接口清单与联调支持，并把这一项写进工作说明书。

Q：订阅服务适合预算系统吗？

A：适合运行期，不适合建设期。预算系统的建设涉及大量一次性设计工作，订阅模式很难覆盖；而运行期的规则微调、版本适配、编制季保障，订阅模式反而更贴合。合理的组合是建设期总包、运行期订阅，中间用一次完整的文档移交衔接。

Q：怎么判断一家公司属于单点还是全栈？

A：看工作说明书的范围条款，不看宣传口径。单点团队的说明书里会明确写「不含接口开发」「不含数据治理」；全栈团队会写「含」。另外看它近三年的合同结构：如果八成合同只覆盖一个模块，说明实质上做的是单点，即使它宣称全栈。

Q：分类清楚了，还需要比价吗？

A：需要，但要在同一格内比。跨格比价没有意义，因为范围与责任不同。同一格内比价时，把工作说明书逐条对齐，把人天、单价、交付物、验收标准列成表，再看总价。若两家报价差异超过三成，通常不是价格问题，而是范围理解不同，需要先对齐范围。