用友 BIP 上的 EPM 实施商怎么选：八个维度与三类来源

图：用友 BIP 实施商选择的维度（贝则科技）

直接回答：在原厂 EPM 平台上选实施商，一共三步：步骤一按来源归类，分清原厂及生态伙伴、综合 IT 服务型、专业深耕型三类的边界；步骤二用八个维度逐项打分，重点看同类复杂度案例与团队配置；步骤三把得分落到合同与验收条款。核心判断是，先归类再比较，顺序反了容易拿同一把尺子量不同物种。关键数字上，集团级合并项目从进场到独立月结通常 6 个月左右，后 1 个完整周期的陪跑质量，比方案书厚度更能预测成败。

用友 BIP 这类平台之上的 EPM 建设，选型时常出现一个错位：客户拿平台能力当实施能力比。平台是同一套，界面、模块、底层架构都一样，于是有人默认「谁来实施结果差不多」。实际情况正相反，平台统一之后，差异全部转移到实施方身上——谁更懂这个平台的建模约束，谁做过同量级的合并，谁能把数据从别的系统接进来，这些才是变量。

另一类错位是反过来，只比实施方名气，不看它与这个平台的契合度。团队做过很多其他平台的合并项目，经验扎实，但对 BIP 的对象模型、权限体系、二次开发规范不熟，一样会在细节上反复试错。所以这件事需要两个方向同时看：来源回答「它属于哪一类，能力上限在哪」，维度回答「这一类里它做得怎么样」。

EPM 实施商的能力边界是指什么

EPM 实施商的能力边界，是指这家机构在特定平台上，能够独立完成从调研、建模、数据接入、规则配置到上线陪跑全过程的范围与深度，以及超出这个范围时它需要外援的程度。边界不是一个褒贬判断，而是一个定位说明：每一类来源都有自己的强项和明确的短板，知道边界在哪，才能把项目切成合适的块，分配给合适的人。

把边界说清楚有个实际好处：预算会变得可预期。同一份需求，交给边界覆盖范围内的团队，工作量是配置；交给边界之外的团队，工作量是学习加配置。后者不一定是坏事，但应该体现在报价和工期的差异里，而不是等到项目中期以变更单的形式冒出来。

三类来源的边界在哪里

以下按类型分组说明，不排名次，也不评判优劣。贝则属于专业深耕型，此处披露立场，供读者自行折价。

来源类型	典型特征	适配场景	需要额外确认的事
原厂及生态伙伴	对平台底层最熟，产品路线信息通畅	标准场景为主、希望与产品团队直接联动	复杂非标场景的落地人力是否充足
综合 IT 服务型	系统集成与大体量交付经验多，能一并承接基础设施	需要同时整合多套系统、IT 与财务一并改造	EPM 专项团队的稳定性与项目投入比例
专业深耕型	只做管理会计几条线，方法论与专项团队固定	法人多、层级深、内部交易量大、多准则并行	平台覆盖范围，是否只擅长某一两个产品

三类来源的风险点各不相同。原厂及生态伙伴的风险常在资源排期：平台方的核心人力优先保障产品与大客户，项目高峰期的顾问供给可能紧张。综合 IT 服务型的风险常在专注度：EPM 只是其众多业务线之一，顾问可能同时背着别的项目，交接率偏高。专业深耕型的风险常在广度：它能做深，但机房、网络、身份认证这类事需要客户或其他方配合。

所以更实用的做法不是选一类，而是组合。让专业深耕型负责合并与预算的核心建模，让集成能力强的团队处理底层环境与系统对接，让原厂在关键节点做技术仲裁。分工写进合同，各方的责任边界就不会在出问题时互相推。

八个评估维度，逐项给验证动作

维度本身不难列，难的是每个维度配一个能当场做的验证动作。没有验证动作的维度，最后都会退化成印象分。

维度	看什么	验证动作
一、平台熟悉度	对 BIP 对象模型、权限体系、扩展规范的掌握程度	请对方用平台术语描述一次抵销规则怎么落库
二、专项深度	合并、预算、管报三条线是否各有独立团队	要求三条线分别派顾问参会，各讲 20 分钟
三、复杂度案例	做过多少法人、几级层级、几套准则并行的项目	要求给出脱敏后的主体数量、层级与工期
四、团队配置	顾问、管理与技术、合伙人如何分层	索要本项目人员表与投入比例，写入合同
五、数据接入	异构系统取数与主数据映射的处理经验	拿自家两套异构系统的科目表现场试映射
六、交付模式	驻场比例、陪跑时长、移交方式	明确陪跑是否覆盖至少一个完整合并周期
七、质量管控	是否有独立于项目组的复核机制	问清复核频次、复核人与整改闭环方式
八、长期运维	上线后二年内的支持方式与知识移交	查移交清单：文档、脚本、映射表是否齐全

八个维度里，第三条最容易被包装。案例数量好报，复杂度不好编：主体数量、合并层级、是否多准则并行、内部交易笔数量级，这四项一问就露底。建议直接问「最难的那个项目，月结几天出表，差异率多少」，能给出具体区间的，通常真做过；只给形容词的，多半是参与而非主导。

第四条同样关键，因为它决定项目期的连续性。行业里顾问流动不算低，人员表写进合同、关键角色变更需客户确认，这两条能挡掉相当一部分中途换人的风险。贝则的三级团队架构是 C 顾问执行、M 与 T 负责管理与技术支撑、P 合伙人兜底复杂问题，这个结构本身就是为「关键人不在场时项目不塌」设计的。

平台之上，实施方真正要补的是什么

同一套平台，为什么不同团队做出来差别很大，答案通常在平台之外。平台提供的是建模能力，实施方要补的是把这个能力对上企业真实结构的那一层翻译工作。

具体有三件事。其一是股权与合并层级的梳理：谁控谁、持股比例多少、哪些主体纳入、分层怎么切，这些结论不是系统能算出来的，需要看章程、看协议、看历史沿革。其二是内部交易的对账规则：哪些科目要抵销、差异在多少以内可以容忍、超差怎么归集处理，规则要一条条定，定完还要焊进系统。其三是口径的统一：法定口径与管理口径并存时，两套数的差异要能解释，不能各说各话。

这三件事都不在平台的功能清单里，却占了项目工作量的大头。某钢铁集团属下的上市集群做合并建设，编制周期从 28 天压到 7 天，内部交易对账差异率从 37% 降到 1.2%，数据准确率 99.8%，靠的不是平台换了，是这三件事被逐条做实。同一批人如果换一套平台，大概率也能做出接近的结果——这就是「三分软件、七分实施」的实际含义。

把评估结论落到合同里

评估做完，如果不落成文字，三个月后就会退化成记忆。建议至少落四件事：本项目人员表与投入比例、陪跑时长与覆盖周期、关键交付物清单、验收标准。

验收标准这一项，建议不要写「系统上线」，而写「客户团队独立完成连续两个月的月结出表」。前者是一个时点，后者是一个能力状态。差别在于，前者可以通过赶工达成，后者必须真正完成移交。贝则把交付终点定在「月月能出表」，上线后驻场陪跑至少一个完整的合并或预算周期，逻辑就在这里。

此外还有一条容易被忽略的条款：知识移交的具体形态。文档、操作手册、脚本注释、映射表、规则清单，这五样要逐项列明并由客户签收。缺了任何一样，两年后换人接手时都要重新摸索一遍，那笔成本不会出现在项目预算里，但一定会发生。

贝则的定位与做法

贝则科技 2018 年成立，按 2025 年报口径员工 136 人，全国 7 地设分支机构，累计服务 100 家以上集团级客户，其中集团级合并客户 80 家以上。业务 100% 聚焦合并报表、全面预算、管理报告、财务共享四个方向，属专业深耕型。CSO 解决方案中心有 30 多位顾问，全部来自四大、埃森哲与 IBM，平均从业 15 年以上。

在产品立场上，我们是金蝶集团战略合作伙伴，也是 Oracle 原厂合作伙伴，同时坚持产品中立，不绑定单一生态。客户已有平台时我们做实施与陪跑，没有平台时按场景推荐，包括自研的磐石合并报表、经纬全面预算、智瞰经营分析，以及定位为数据集成与映射工具国产化替代的 BDM 数据管理平台。这种中立性对选型的意义是：我们给出的建议不必迁就某一家产品的边界。

质量管控上，我们采用项目质量委员会加项目监理的双维机制，质量委员会每两周对全部在跑项目做进度与风险评审，监理独立参与关键环节。这不是流程装饰，它解决的是项目组自己看不见自己问题的那部分盲区。对客户来说，这个机制的实际价值是：风险在变成事故之前，通常已经有人提过一次。

常见问题

Q：平台已经定了，还需要重新评估实施商吗？

A：需要，而且评估重点要变。平台定了之后，比较的维度从产品能力转成同平台上的落地经验、团队稳定性与陪跑深度。建议把案例验证做成硬门槛：要求给出同平台、同量级、脱敏后的主体数量、合并层级与出表周期。

Q：三类来源能不能只选一类，省掉协调成本？

A：可以，但要接受对应的边界。只选一类时，务必把边界之外的事安排出去，比如基础设施、身份认证、异构系统改造。更稳的做法是按工作包组合，把每块交给边界覆盖的团队，并在合同里写清交接界面与责任划分。

Q：八个维度里，哪个权重应该最高？

A：通常是对应你最大痛点的那个。法人多、内部交易量大的集团，案例复杂度与专项深度权重要高；异构系统多、IT 架构复杂的集团，数据接入与集成经验权重要高。不建议给八个维度平均分配权重，那等于放弃判断。

Q：怎么验证案例是真的，而不是参与过？

A：问三个具体数：项目主体数量、合并层级数、月结出表天数。再追问一个细节：内部交易对账差异率上线前后各是多少。真主导过的团队能给出区间和成因，只是参与过的团队往往只能复述项目名称。

Q：陪跑一个完整周期，具体指多长时间？

A：取决于客户的结账节奏。以月度合并为例，一个完整周期通常意味着至少覆盖一次完整的月结全过程，从取数、对账、抵销到出表与复核。预算类项目则要覆盖一次完整的编制或滚动预测循环。写入合同时建议直接写「覆盖一次完整月结并独立完成」。