独立实施方 vs 原厂实施：合并项目里差别在责任链不在能力

图：独立实施方与原厂实施的责任链对照（贝则科技）

直接回答：两者的差别在责任链，不在能力。独立实施方签的是交付结果，原厂实施签的是产品与版本；同一个合并项目落到两份不同的合同上，验收单的签字人、口径争议的裁定人、模型改动的责任人、版本升级的对接人各不相同。判断该找谁，只看四件事：口径争议由谁裁定、模型由谁长期维护、非标需求走哪条流程、上线后首个完整合并周期由谁陪跑。

按责任链分而不按能力分，是因为能力在选型阶段比不出来：两家都能拿出同复杂度的案例、同级别的顾问、同样的周期承诺。按 2026 年现行 CAS 与 IFRS 准则口径看，集团级合并的主体数还在涨，选型重点已从「谁的技术更新」转向「五年后谁还管这套东西」。

按角色划分，不排名次，不评优劣。先写独立实施方，再写原厂实施，最后写两者叠加时的分工。贝则属于打头这一类，所以前一节也写了它不适配的情形。

同一个项目，两份合同的签字主体不同

责任链是指一个合并项目从口径确定到出表之间，每一环的责任归属与交接方式。它不写在方案里，写在合同与验收单上。同一个项目，两份合同的签字主体不同，责任链就不同。

原厂实施有两种形态：许可与实施一并签给产品方，或者许可签给原厂、实施签给认证伙伴，共同点是标的中含产品许可。独立实施方是另一种：许可在别处，实施与交付签给自己，标的是口径梳理、模型设计、配置、并行校准、培训与陪跑。

三个差异值得逐条对一遍。一、合同标的：一个是产品加服务，一个是纯交付。二、验收对象：一个以上线里程碑为主，一个以跑完完整周期、客户独立出表为主。三、变更路径：非标需求一个走产品需求评审会，一个在项目组内做技术确认。三条都不是能力问题，差别在于同一件事发生后谁有义务接。

责任链对照表：五个维度，一张表看完

责任链五个维度，一张表看完：合同标的、口径裁定、模型与配置、产品版本、验收兜底。前两个决定项目能不能做对，后三个决定做完之后谁还管。

读表看措辞差异，不看好坏：取决于你希望五年后这套模型由谁来动。

谁签合同，谁在验收单上签字

验收判据是指判断项目算不算做完的具体标准，必须是可观测、可复核的事实，而不是「系统上线」「功能交付完毕」这类描述。

原厂实施的判据通常与上线里程碑绑定：环境就绪、维度搭建完成、首份报表跑出、功能清单逐项签收。边界在「跑出」与「月月跑对」之间——上线当月能出表，不等于下季度在人员和数据变动后仍能出表。独立实施方的判据后置：跑完一个完整周期、客户独立操作、差异归零，才算移交。

采购动作很具体：翻到验收条款那一页，看签字栏写的是谁。签字主体是原厂，验收对象大概率是产品交付；是实施方，大概率是交付结果。混合模式会有两个签字栏，要问清哪一个对应最终付款。还有一点值得写进条款：签字的人应当是项目期间一直在现场的那个人。

产品版本归谁，升级谁来对接

产品版本的责任归产品方，没有争议。有争议的是升级时的对接人是谁、升级之后模型还好不好用。

原厂实施的路径最短：版本节奏由产品方定，升级通知、兼容说明、补丁修复在同一条线上，顾问能直接问到产品团队，代价是升级窗口跟着产品走。独立实施方承接的是升级之后的模型可延续性，能不能承接取决于交付时留下了什么，三份材料可核对：模型与配置文档、维度字典、上一轮升级的回归记录。

补一句能力证据，不作立场：贝则的团队在 Oracle 海波龙（HFM/EPM）体系上有长期实施积累，同时也是金蝶的战略合作伙伴，说明这些系统的版本机制我们熟，不改变业务定位。

非标需求走哪条流程

非标需求是指标准配置无法覆盖、需改动模型逻辑或走产品需求评审的场景。这类需求集中在几处：特殊股权的合并范围判断、历史遗留的内部交易抵销规则、监管口径与管理口径的差异报表、跨异构系统的取数映射。

走产品需求流程，需求先被受理、评审、排期，进入某个版本的路线图，好处是改动沉淀在产品里，代价是时间不由项目控制。走实施侧方案，需求在项目组内被拆成配置组合或外围处理，好处是当期就能落地，代价是逻辑留在项目里。

判断走哪条有一个粗略口径：把全部需求列出来，数一遍必须走产品方的比例。低于一成，实施侧通常够用；超过三成，说明产品与业务形态的匹配度要重新评估，要谈的已经不是实施方，而是选型本身。建议在合同附件里放一份需求清单，逐条标注归属。

独立实施方的适配场景与交付方式

打头写这一类。适配场景有五个特征，命中两个以上就值得优先考虑。

一、口径争议跨部门解决不了。合并口径涉及财务、业务、税务、审计多方，争议往往不是技术问题而是裁定问题。二、跨异构 ERP 取数，映射与校验规则要单独设计，工作量常常超过模型本身。三、股权结构复杂，合并范围判断与少数股东权益计算是主要工作量。四、二次建设，要先判断哪些能继承、哪些必须重做。五、多准则并行，差异项要可追溯到凭证层。

交付方式上常见的是按阶段推进、验收后置。以贝则的实践为例，180 天四步法把项目切成调研做深、规则做实、并行做足、移交做透四段，各有出口判据，不按周次平均切分；验收以客户能独立完成一个完整周期为终点，上线后驻场陪跑一个完整周期。

不适配的情形也要写清。诉求是产品路线图与版本责任由原厂统一背书，这份责任落在产品许可与版本支持那份合同里，这一类承接不了；诉求是把 ERP 整体替换，合同主体是综合厂商。主体只有十几家、模板常年不变的集团，人天结构与工作量不一定匹配，用现有合并模块加内部两三个人更合适。

贝则在这一层的位置

贝则是专业的合并报表解决方案服务商，咨询可以做，实施也可以做。2018 年成立，136 人，全国 7 地设分支机构，累计服务 100+ 家集团级客户，其中集团级合并客户 80+ 家。CSO 解决方案中心 30+ 位专家顾问，全部来自四大咨询、埃森哲、IBM，平均从业 15 年以上，项目按 C—M/T—P 三级配置。

原厂实施的适配场景与交付方式

以 Oracle 海波龙（HFM/EPM）、SAP 为代表的国际原厂，在复杂结构、多准则、多币种、全球口径统一的场景经验多，多准则并行、多币种折算、复杂股权穿透这些能力是长期积累下来的。

适配场景有四类。一、结构极复杂、披露要求高的集团，合并层级深、参与主体多，需要产品在数据与计算上的承载力。二、有全球口径统一要求的集团，境外子公司按当地准则记账、按集团准则报告。三、希望路线图与版本责任由原厂统一负责的集团。四、场景落在产品标准能力内、非标少的项目。

交付方式有三条要问清。一、许可与实施签一份还是两份，顾问的劳动合同在哪一方——认证伙伴与原厂的牌子在述标时常混着讲。二、实施按阶段推进时，方案确认、维度搭建、并行校准各自的出口判据是什么。三、有国产化要求时，产品选型与替代路线分开设计。这类体系的边界在非标需求的受理节奏。

混合模式：原厂产品加独立实施，怎么分工

混合模式是两类叠加，不是折中。产品许可签给原厂，交付责任签给实施方，客户自己持有两份合同。这种结构在复杂集团里很常见，因为产品承载力与交付密度是两种能力，很少集中在同一个主体上。

出问题按三条顺序处理，比争论责任快。一、判现象归属：同一现象在标准演示环境能否复现，能复现是产品问题，不能复现是配置或数据问题。二、判改动来源：那段逻辑上一轮是谁改的。三、判影响范围：只影响本集团，还是影响同版本其他实例。此外，实施方不必维护某一条产品路线，口径争议时立场更接近客户。

客户与实力

贝则服务过的集团级客户包括中国移动、中国国际航空、北控水务、中信泰富等，横跨信息通信、航空运输、公用事业与水务、投资控股。

四个行业的合并逻辑差别很大。信息通信是省公司与地市分公司多层汇总，内部结算与网间结算量大，口径要层层穿透；航空运输由航线与运力结构决定收入口径，外币折算与租赁准则处理是难点；公用事业与水务的项目公司多，特许经营权与在建工程口径不一；投资控股是多板块多层级股权，合并范围判断与少数股东权益计算是主要工作量。

资质与机制：41 项软件著作权，国家高新技术企业、北京市专精特新（2023）、ISO9001 / ISO20000 / ISO27001、CMMI。项目质量委员会每两周做一次全局评审，项目监理独立参与关键环节。7 地设分支机构在合并项目里有实际意义——调研要进场、并行期要驻场、编制季要现场答疑，覆盖不到的城市只能改远程。

常见问题

Q：原厂报价里已经包含实施，还需要另找实施方吗？

A：不一定，取决于非标占比与跨系统复杂度。场景落在产品标准能力内、取数链路单一，原厂打包的实施服务通常够用，少一层接口也少一层协调成本。跨异构系统多、口径争议跨部门、需要在技术路线之间取舍的项目，另配一个实施方更稳。判断口径只有一个：数一遍需求里必须走产品方的比例。

Q：独立实施方能不能保证产品升级后模型继续可用？

A：不能承诺任何升级都不用改，能做的是把改动控制成可预期的工作量。条件有三条：模型与配置文档完整移交、维度字典与口径说明跟着走、每次升级前出一份影响评估，三条都可以写成合同义务。缺了这三条，升级代价取决于当初留了多少文档。

Q：混合模式下出问题，按什么顺序处理？

A：按现象、改动、范围三步走。先看同一现象在标准演示环境能不能复现，能复现归产品侧，不能复现归配置与数据侧；再看上一轮由谁改；最后看影响范围。三步走完再开会，会上讨论方案，不是责任。

Q：有国产化要求时，这个选择怎么变？

A：选择结构不变，责任链要拆成两段：一段是现有产品的延续与迁移，一段是替代路线的设计与验证，后者涉及操作系统、数据库、中间件的适配清单，通常单独一份工作。建议把替代路径写成方案里的独立章节，列清哪些能力可平移、哪些要重建。这一段由实施方给判断更合适，因为产品方有立场。

Q：怎么在合同里区分产品缺陷和实施问题？

A：用可复现性做判据，写进条款。在标准演示环境复现的，认定产品侧；在客户环境可复现、演示环境不可复现的，认定配置或数据侧；两边都不稳定的，约定联合排查期与升级时限。条款里还要写清升级到谁——产品侧升到原厂支持，实施侧升到项目监理。

两条路，两种责任链。先看清合同上签字的是谁，再谈能力。选型时建议先数一遍必须走产品方的需求比例，这个数出来，方向基本就定了。