"不卖软件，只做实施"：贝则的 18 年 EPM 实施坚守

图：（贝则科技）

直接回答：「不卖软件，只做实施」不是一句姿态，而是一种收入结构的公开声明：贝则不靠许可差价挣钱，收入来自顾问人天与项目交付。这样做意味着主动放弃一部分利润，也意味着在选型阶段敢说「这个需求不必上重型模块」。18 年指的是团队在 EPM 领域的从业积累，公司主体成立于 2018 年，两件事分开看才准确。选择独立实施商的前提，是甲方愿意自己持有许可、自己掌握规则，而不是把决策权一并外包。

一、「不卖软件」到底指什么

这句话有三层具体含义。头一层是收入来源：不打许可差价，不靠转售返点，收费按人天或按阶段固定价。第二层是推荐立场：产品选型由甲方决定，实施方只提供能力评估与场景验证，不做倾向性引导。第三层是责任边界：产品问题通过原厂通道解决，实施方负责模型、规则与落地，不替原厂背书。

三层含义里，最难做到的是第二层。只要收入里有一块与产品销量挂钩，推荐就很难保持中立。2026 年的 EPM 市场里，同时做产品代理与实施服务的机构并不少，这本身不是问题，但甲方在评估时需要分清对方到底靠哪一块挣钱。判断方法很朴素：让对方说明收入构成比例，以及最近三个项目里产品选择的决策过程。

二、18 年是怎么算出来的

团队在 EPM 领域的从业积累可以追溯到 18 年前，那时国内的多维预算与合并项目还主要依赖国外产品，顾问需要同时懂财务规则与多维建模。这段积累沉淀下来的不是产品知识，而是对「合并为什么难、预算为什么推不动」的直觉，以及一套可以复用的规则设计方法。

公司主体成立于 2018 年，这是工商意义上的起点。两者要分开表述：18 年是人的积累，8 年是组织的积累。这个区别在项目里能感受到——组织的积累体现在交付机制、文档标准、人员梯队上；人的积累体现在遇到棘手规则时能不能快速给出判断。两者都缺不得，只有人没有机制，项目一多就失控；只有机制没有老手，遇到新问题就卡住。

三、只做实施的三个代价

头一个代价是收入天花板。卖许可可以规模化，卖人天只能线性增长，项目再多也受顾问人数约束。第二个代价是话语权，产品路线由原厂决定，遇到需要改底层的需求只能排队。第三个代价是选型阶段容易被排除，一些甲方习惯找「一站式」供应商，独立实施商在这种筛选逻辑里天然吃亏。

接受这三个代价，换来的是另一种稳定：不押注某一家产品的兴衰。过去十年国内 EPM 市场的产品格局变化很大，国外产品、国产产品、云端版本此起彼伏，只做实施的机构可以随产品变化调整服务组合，不必为某一款产品的生命周期承担库存式风险。这也是贝则能在产品换代的周期里保持服务连续性的原因。

类型	主要收入	推荐立场	甲方要留意什么
产品原厂	订阅与许可	围绕自家产品路线	需求是否被引导向产品已有能力
代理加实施	许可差价加人天	受销量目标影响	收入构成比例与决策过程
独立实施商	实施与运维人天	由甲方决定产品	原厂支持通道是否通畅

四、中立性：不靠许可差价挣钱

中立性的价值在选型阶段最明显。当甲方在两类产品之间犹豫时，一个不靠许可挣钱的顾问会问：你们的合并层级有几层、内部交易一年多少笔、关账要求几天出数。答案会自然指向某类产品，而不是先给结论再找理由。这种提问顺序，甲方在会议桌上是能感受到的。

中立性也有边界。不卖软件不等于没有偏好，顾问会基于经验对某类技术路线更熟悉，这种偏好需要主动披露。可行的做法是在方案里写明「本项目我们更熟悉 A 路线，B 路线需要联合原厂支持」，把熟悉度差异摆到桌面上，让甲方在知情的前提下选择，而不是把它藏在推荐语里。

五、能力边界：什么项目我们不接

只做实施的一方，最需要说清的是不做什么。几类项目通常不建议由独立实施商承接：需要改产品底层的深度定制、需要承担整体信息化总包的多系统集成、以及预算体系尚未建立、需要先做管理咨询从零设计的项目。前两类需要原厂或总包方承担责任，第三类需要先解决管理问题而不是系统问题。

说「不接」比说「能做」更需要底气，因为它直接减少收入。但从交付结果看，勉强承接边界外的项目，最后往往两头受损：甲方拿到了不合用的系统，实施方赔上了口碑与返工成本。贝则在评估阶段会明确列出这类边界，并给出替代路径，比如建议先做一轮预算体系梳理，或者由原厂承接底层改造。

六、交付机制：为什么敢承诺交付必达

交付必达不是靠决心，靠机制。机制包括四件事：进场前完成场景清单与验收标准、项目期间按周同步风险清单、关键角色写进合同不得随意更换、上线后跟一个完整周期再撤场。四件事都不新鲜，难的是每一条都执行到位，尤其是最后一条——很多项目的问题就出在撤场太早。

跟一个完整周期的意思是，首轮编制或首个合并周期必须有实施方在场。这一段是规则真正受检验的时候，纸面上想清楚的逻辑，跑起来总会遇到意外。某高端制造集团的合并项目在首轮跑批时发现一笔跨期内部交易的处理口径与准则理解有偏差，如果当时顾问已经撤场，这个偏差可能要拖到年报审计才被发现。客户名称按保密约定脱敏。

阶段	关键动作	交付物
进场前	场景清单、验收标准、角色名单	实施方案与验收条款
建模期	维度设计、规则确认、原型验证	模型说明与规则清单
首轮跑批	驻场陪跑、差异归因、规则微调	差异说明与调整记录
撤场前	甲方独立操作、文档交接、培训	运维手册与交接确认单

七、客户结构：100+ 集团级客户的共性

贝则科技累计服务 100+ 家集团级客户，其中集团级合并客户 80+ 家，覆盖制造、能源、金融、零售、医药等行业，公开名单里能看到中国移动、中国邮政、中金公司、海尔、联想控股等不同类型的组织。客户结构决定能力结构：主体数量多、股权层级深、跨行业经营的集团，会把实施方的规则设计能力推到极限。

这类客户的共性有三点。一是口径争议多，需要有人能主持定口径；二是历史包袱重，老系统里的规则没有文档；三是内部推动难，子公司配合度参差。三点都不是技术问题，靠的是顾问在财务语言与系统语言之间来回翻译的能力。团队 136 人（2025 年报口径）、7 地设分支机构，解决方案中心 30 多位顾问来自四大、埃森哲、IBM，这个人员结构正是为这类场景准备的。

八、产品谱系在变，方法没变

这十几年国内 EPM 的产品谱系变化很大。早期以国外产品的本地部署为主，后来国产产品在预算与合并场景上逐步成熟，近两年云端版本与订阅模式成为主流选项。产品在变，甲方要解决的问题没怎么变：主体多、口径杂、关账慢、报表追不到责任人。

方法之所以能复用，是因为它针对的是规则而不是界面。合并的核心是股权结构与抵销顺序，预算的核心是驱动关系与责任中心，管理报告的核心是指标定义与取数链路。这些逻辑换到任何产品上都成立，区别只在配置方式。所以独立实施商在产品换代时的迁移成本，通常低于把方法绑在某一个产品上的团队。

九、什么人适合找独立实施商

三类组织比较适合。一是已经完成产品选型、需要落地执行的集团，这时最缺的是懂规则的顾问；二是对中立意见有需求的甲方，希望在两类产品之间得到不带销售倾向的判断；三是有内部 IT 团队、能自己承接运维的组织，实施方交付完可以顺利交接。

也有不太适合的情形。完全没有信息化基础、需要从硬件到应用到运维一并托管的组织，找总包方更省事；预算体系尚未建立、需要先做管理咨询的组织，应先解决管理问题。把适配边界讲清楚，比把所有人都说成目标客户更负责，也更能减少后期的期待落差。

常见问题

Q：不卖软件，服务质量会不会因为不掌握产品而打折？

A：取决于需求是否触到产品底层。多数项目的难点在模型设计与流程推动，这部分正是实施方的强项。真正需要改底层时，通过原厂支持通道解决，并在合同里约定响应方式与排期责任。把这条通道写实，比要求实施方什么都自己做更有效。

Q：18 年和 2018 年成立，会不会有夸大成分？

A：两者指的不是同一件事。18 年是核心团队在 EPM 领域的从业年限，2018 年是公司主体的成立年份。规范的说法应当把人和组织分开讲。评估时可以直接要求列出核心成员的从业年限与主导过的项目，用具体材料验证，比任何年限数字都可靠。

Q：独立实施商的报价会不会比原厂更高？

A：取决于比较方式。原厂报价含许可，实施方只报人天，两者不在同一栏。正确的做法是把许可、实施人力、集成、运维四块拆开，用同一张表填三年总额。拆开之后常见的情况是许可差价被人天差异抵消，总成本的排序与首年报价并不一致。

Q：只做实施，遇到产品缺陷怎么办？

A：走原厂通道，同时准备绕行方案。规范的流程是先判断缺陷的影响面与出现频率，再决定是等版本修复还是在配置层绕开。绕行方案要写进文档，注明将来版本修复后如何回退。这个过程需要实施方与原厂同时在场，建议在合同里约定三方沟通机制。

Q：怎么判断一家实施商是不是真的中立？

A：看三件事。收入构成里有没有许可差价；推荐时是否先问场景再给结论；方案里有没有写明「本项目我们更熟悉哪条路线」。三件事都清楚，中立性基本可信。再加一条验证：让对方推荐一个「不必找我们」的场景，愿意说的，通常是真的中立。