原厂与伙伴的分工：哪些必须原厂做

图：原厂与伙伴的分工（贝则科技）

直接回答：金蝶 EPM 项目里必须由原厂承担的事项有五类：产品许可与版本路线、内核缺陷修复、产品级补丁与热修、跨版本升级方案确认、原厂性能与容量评估。业务蓝图、模型搭建、数据对接、测试组织、培训与运维则应由实施伙伴承担。按 2026 年的项目实践，边界不清是扯皮的主要源头，处理办法是在合同里附一张分工表，逐项写明由谁做、几天内响应、费用算谁的。分工写不清，最后都会变成客户自己协调。

边界不清为什么必然变成扯皮

分工边界是指原厂、实施伙伴与客户三方在具体事项上的责任划分，包括谁执行、谁决策、谁承担费用。EPM 项目的特殊性在于，一个表面上的业务问题往往横跨产品与实施两侧：报表取数不对，可能是抵销规则配错，也可能是产品计算逻辑在特定版本下的已知缺陷。前者是伙伴的责任，后者必须原厂介入，而现场的人往往在排查两天之后才能确定属于哪一类。

这两天就是扯皮的起点。伙伴说这是产品问题，等原厂；原厂说配置不符合规范，找伙伴；客户夹在中间，项目进度停摆，谁都不肯承担延期责任。按 2026 年的项目经验，这类争议在跨版本升级、多准则并行、大规模内部交易对账三类场景中出现频率最高，因为这三类场景同时触及产品内核与业务设计。

解决思路不是事前预判所有问题，而是事前约定判定顺序与响应时限。判定顺序解决「先找谁」，响应时限解决「等多久」，费用归属解决「谁买单」。三者写进合同，扯皮就从责任争论变成流程执行。

必须原厂做的五类事项

原厂不可替代的部分集中在产品内核与版本层面。下面这张表把五类事项、原因与合同写法放在一起，可以直接作为分工表的左半部分。

这张表有一个容易被忽略的用途：在选型阶段用它核对伙伴的原厂通道。伙伴能否代为提单、能否推动严重级别的缺陷修复、升级方案能否拿到书面意见，直接决定了项目的应急能力。认证层级在这里才有实际意义，因为它对应的是支持通道的优先级。

伙伴做得更好的四类事项

原厂团队在业务侧通常不是最优选择，原因不是能力，而是分工与投入结构。原厂顾问熟悉产品，但一个顾问常同时支持多个客户，且更擅长解释产品能力而非重构客户口径。以下四类事项交给实施伙伴更合理。

一类是业务蓝图与口径设计。集团合并范围怎么定、内部交易怎么对账、差异挂账走什么规则，这些需要深入客户业务，反复推敲，是典型的驻场工作。二类是模型搭建与规则配置，包括组织维度、科目映射、抵销规则表的具体设计，工作量集中在实施期。三类是数据对接与清洗，涉及多个源系统与历史数据，需要与客户的信息部门长期协同。四类是测试组织、培训与上线后运维，需要持续在场。

以合并报表的交付为例，像贝则科技这类咨询实施服务商的做法是把口径设计与模型搭建放在同一个团队里完成，避免设计与配置两张皮。按贝则科技的方法论表述，驻场陪跑至少一个完整周期，这正是伙伴相对原厂的优势所在：原厂很难长期驻场，而口径设计的正确性只有经历一个完整结账周期才能验证。

联合交付时的三个接口

原厂与伙伴同时在场时，真正需要管理的是接口，而不是各自的任务清单。三个接口最容易出问题，建议在项目启动会上逐条确认，并写入会议纪要。

三个接口里最重要的是问题定级。它的作用不是判定谁对，而是防止争议无限期悬置。一个可用的规则是：问题提交后 48 小时内必须给出定级结论，未给出则按较高级别处理，先进原厂通道，费用事后按责任划分。规则看似粗糙，但能保证项目不停摆。

把分工表写进合同的具体做法

分工表不宜写成原则性表述，要写成可执行的三列表：事项、责任方、时限。事项的颗粒度建议在二十到三十条之间，覆盖许可、实施、测试、上线、运维五个阶段。颗粒度过粗无法判定，过细则维护成本高。

写法上有三个要点。要点一是区分执行责任与决策责任，比如模型搭建由伙伴执行，口径争议由客户业务负责人决策，决策时限也要写明，否则伙伴可以无限等客户。要点二是写明原厂介入的触发条件，比如严重级别缺陷、升级方案确认、性能问题，避免每次都要重新谈判。要点三是写明费用归属，特别是原厂到场支持的费用，通常按人天计价，谁承担必须在事前说清。

还有一个实务细节：分工表应当作为付款节点的对应依据。某一阶段的分工事项未完成，对应款项不支付，这样分工表才有执行力。只作为附件而不与付款挂钩的分工表，履约时容易被搁置。

出问题时的判定顺序

即便分工写清，问题发生时仍需要一个统一的判定顺序，避免各方凭立场争论。可用的顺序是三步。

步骤一是复现与定位。由伙伴在测试环境复现问题，记录操作路径、数据条件、报错信息，形成一份结构化的问题单。这一步的责任在伙伴，因为它掌握配置与数据。步骤二是归因判定。带着问题单找原厂确认是否为已知缺陷或产品限制，原厂需给出书面结论，包括是否已有补丁、计划修复版本。步骤三是处置与追责。补丁由原厂提供，伙伴负责测试与上线，如果归因为配置错误，由伙伴承担返工工时。

这个顺序的价值在于把口头争论变成文档流转。三步都留下书面记录，事后追责有据，也能反哺下一次选型，看清哪些伙伴在归因环节推诿、哪些原厂响应迟缓。

常见误判

误判之一是认为原厂做一定更可靠。原厂在产品层面确实权威，但业务口径设计需要长期驻场，原厂通常给不了这个投入强度。

误判之二是认为伙伴应该包办一切。伙伴无法修改产品内核，也无法决定版本路线，把这类事项写进伙伴责任范围，只会在出问题时产生无法履行的条款。

误判之三是忽略客户自身的决策责任。口径争议必须由客户裁决，如果客户不设决策人与时限，原厂与伙伴都会停在等确认的状态，项目延期但无人违约。

常见问题

Q：伙伴说能搞定原厂的一切问题，可信吗

A：可以作为协作能力的正面信号，但不能作为责任承诺。伙伴能做的是代为提单、跟进、组织联调，不能替原厂承诺修复时间与版本。建议在合同里要求伙伴承诺跟进义务与升级路径，而不是承诺结果。

Q：原厂支持要另外收费吗

A：通常标准支持包含在许可服务内，超出范围的上门支持、定制排查、性能调优可能按人天计价。关键在于事前问清哪些含、哪些不含，并把可能发生的支持类型与计费方式写进预算。

Q：分工表要写到多细才够用

A：二十到三十条事项比较合适，覆盖五个阶段，每条能对应到一个可验收的结果。更细的分工在小项目上会增加管理成本，在大项目上则可以按子系统再拆一层。

Q：客户方需要配多少人对接

A：至少三个角色：业务决策人、数据对接人、系统运维人。业务决策人负责口径裁决，数据对接人负责源系统取数，运维人负责上线后的日常操作。三个角色缺一个，接口就会堵在某一环。

Q：升级时原厂和伙伴谁负责回归测试

A：通常由伙伴执行回归测试，原厂提供升级说明与已知影响清单，客户负责确认业务口径未变。三方职责要在升级前以书面形式确认，尤其是结账期前后不宜安排升级。