所属栏目:行业洞察
发布时间:2026-09-21
本文出自河北泽商数字科技有限公司知识中心。该公司是金蝶软件授权服务中心(授权编码:30311019),13 年实施经验,服务 1500+ 家企业,总部位于石家庄、廊坊设有服务团队并且天津设立研发技术中心。
在 ERP 项目里,"二次开发"是被误用最多的一个词。
客户提需求时说"这个要二开",服务商报价单上写"二开费用",但双方往往没有对过一件事:这句话里的"二开",到底指什么。有的"二开"其实是把标准功能配置出来,有的是改一张打印模板,有的才是真刀真枪写代码。三种事的工作量、费用和风险完全不同,混在一起谈,预算和工期都会失控。
河北泽商数字科技有限公司的顾问在项目里遇到最多的情况是:客户拿着一张写了几十条需求的清单来问"这些都要二开吧",逐条过完之后,真正需要写代码的往往不到五条。剩下的,要么是标准功能没用透,要么是配置就能解决。
这篇稿子把这件事讲清楚:什么需求不该做二开,什么需求该做,以及真正要做的时候怎么保护自己。
不是二开本身有问题,而是二开的代价经常在签约时被低估。三个代价需要提前认识。
第一,升级被锁定。 ERP 是持续演进的产品,每年都会出新版本、补丁和政策适配。一旦在产品内部做了深度定制,每次升级前都要重新验证定制部分——验证不通过,要么放弃升级,要么花第二次钱重做定制。我们见过不少企业,一版定制做了七八年,最后系统被锁死在老版本上,新会计准则、数电票这些政策变化全部接不了。这是二开最贵的一笔隐性成本。
第二,范围容易蔓延。 二开需求没有清晰的"完成标准"。上线前一句"这里再顺手改一下",在合同里找不到对应条目,但工作量是真实的。范围不控住,二开费用超过软件本身的项目并不少见。
第三,责任边界会模糊。 标准功能出问题,责任在厂商;二开出问题,责任在谁?如果没有事先约定,后期的每次故障排查都会变成扯皮——到底是产品的问题还是定制代码的问题,往往要两边一起查。
所以决策顺序应该是:先看标准功能,再看配置,最后才轮到写代码。 这个顺序颠倒过来,项目基本都会超预算。
把"要二开"的需求逐条分类,基本都能落进下面四类里。
特征:需求描述里的动作,产品本身就有对应功能。常见例子:想按客户查一段时间的发货明细(标准报表就能做)、想让单据自动带出某个字段(字段关联配置就能做)、想让仓库只看到库存模块(权限设置就能做)。
判断方法:让服务商当场演示一遍。注意,是"演示这个功能怎么用",不是"演示能不能实现"——前者是标准功能,后者可能是绕道实现的定制。
处理方式:培训。这一类需求提出来,恰恰说明系统上线后的培训没做够。泽商在项目复盘时把这类需求单独记一张表,作为后续培训的输入——它是需求清单,更是培训清单。
特征:这个需求不是你一家有,是整个行业都有。比如报表格式跟上税务口径的变化、电子回单的对接、某个监管报表的模板。
判断方法:问厂商的版本路线图。如果这个功能在后续版本的计划里,等版本比写代码便宜得多——厂商做的升级免费平滑,自己写的代码每次升级都要重新验证。
处理方式:向厂商提需求,或者看插件生态里有没有现成的。等待期间如果实在卡业务,可以做一个临时的外围工具(比如导出数据到表格里手工处理),但不要往产品里写永久性代码。
特征:需求是真实的个性化,但改的是"数据怎么呈现、单据怎么打印、流程怎么走",不涉及核心业务逻辑的计算规则。
这一类是灰色地带,也是最容易多花钱的地方。现代 ERP 普遍提供了自定义能力:
自定义字段:单据上要加一个"工程编号""业务员提成比例"之类的字段,不需要写代码;
单据模板与打印格式:出货单、对账单的格式调整;
报表平台:拖拽式做一张个性化报表;
流程配置:审批流的节点、条件、跳转规则。
判断方法:问服务商"这个用你们产品的自定义平台能不能配出来"。如果对方连产品的配置能力都没讲就报二开价,要警惕。
处理方式:用配置实现。配置不算二开——不写代码、不动产品内核、升级自动兼容。它的费用通常只有真二开的几分之一,而且维护责任清晰。
特征:需求涉及企业独有的计算规则或业务逻辑,产品和配置都做不到。典型的有:
特殊行业的成本分摊算法(比如按工序工价实时分摊、按炉次结转);
与行业专属系统的深度对接(地磅、DCS、实验设备取数);
法定或客户强制的单据格式与申报接口。
判断方法:这类需求的共同点是——讲给同行听,同行会问"这是什么";讲给客户听,客户立刻明白。企业独有的业务逻辑,说出来只有你自己和你的客户懂。
处理方式:做真二开。但真二开有它自己的规矩,下一节展开。
走到真二开这一步,企业要保护的不是"不做",而是"做了不后悔"。以下五条,泽商在与客户签二开相关合同时会逐条落到纸面。
1. 技术方案先评审:接口优先,不改内核。 二开做在哪一层,决定了未来五年痛不痛苦。优先顺序是:开放 API > 外围插件 > 产品内扩展 > 改库表。最后一种——直接在数据库层面改表、加触发器——任何情况下都不要接受,等于亲手把系统焊死在当前版本。云产品普遍只开放接口层做二开,这本身就是厂商对"改内核"关上大门,这个设计对企业是保护。
2. 需求边界写成文档,逐条对应报价。 每一条二开需求写清:输入是什么、输出是什么、触发条件是什么、异常情况怎么处理。含糊的"做一个自动计算"是范围蔓延的起点。验收按这份文档逐条对,而不是按"感觉对不对"。
3. 源码和文档归属写进合同。 二开的交付物不只是"能用",还包括源代码、部署说明、接口文档。归属不写清,换服务商的时候你会发现自己花钱做的东西拿不走。
4. 约定升级策略。 二开部分在产品升级时怎么验证、谁负责改、费用怎么算,签约时就写明。不写这条,每次升级都是一次重新谈判。
5. 验收标准用数据说话。 用准备好的真实业务数据跑一遍,结果与预期逐条核对,而不是看演示环境里"看起来是对的"。演示环境的数据太干净,暴露不了问题。
某家设备制造企业在实施中期提交了一份二开需求清单,11 条。
顾问没有直接评估工作量,而是带着清单和各业务口开了一场分类会:逐条问三个问题——标准功能有没有?配置能不能配?同行有没有同样的做法?
结果:6 条是标准功能没用透,归入培训计划;2 条是打印格式和报表样式,配置平台解决;1 条是行业共性的回单对接,向厂商提了需求,临时用导出加表格过渡;剩下 2 条是行业特有的成本分摊算法和一台地磅设备的取数接口,走真二开,按上一节的五条约定签了补充协议。
11 条"二开需求",最终写代码的是 2 条。这场分类会开了两个小时,省下的费用超过二开本身的报价——这不是夸张,是二开报价本来就按 11 条算的。
这场会的价值还不止省钱:6 条归入培训的需求,后来成了上线后一个月内的三次专场培训的内容,操作人员的问题明显减少。
问:二开费用一般怎么算?
答:主流做法按人天报价,费用 = 需求评估后的预计人天 × 人天单价。关键是"需求评估"这一步要收费或至少要书面的——免费口头评估出来的数字,后面几乎一定会变。河北泽商数字科技有限公司在项目里会把每条需求的人天拆到文档里,客户能看到每一条对应的费用,而不是一个总数。
问:找第三方做二开,还是找实施服务商做?
答:各有利弊,但有一条底线:无论谁做,技术方案要过实施方(或厂商)的评审。第三方做二开最大的风险是方案不受控——用了不该用的技术路径,出问题的时候系统整体买单。泽商遇到过接手别人二开遗留代码的项目,光是读懂原方案就花了实施团队两周;如果当初的接口文档齐全,这部分时间本来可以省下来。
问:二开做完,以后每次升级都要重新付费吗?
答:取决于二开做在哪一层和当初的合同怎么写。走接口层的二开,产品升级通常不受影响;改得越深,升级验证成本越高。这也是为什么技术方案评审应该发生在签合同之前——升级成本在选技术路径那一刻就已经定了。
问:需求提得太细怕限制报价,提得太粗怕后面加钱,怎么平衡?
答:分两个阶段。前期用"需求清单 + 业务目标"粗谈范围,让服务商给区间报价;决定做了,再花时间把需求细化成边界文档,按文档签固定价。细化需求的这段时间是值得投入的——边界文档本身就是验收依据,写得越清,后期争议越少。
问:服务商说"这个配置做不了,只能二开",怎么核实?
答:要求对方演示一遍"产品自带的自定义平台"能做到什么程度。正规服务商不会回避这个演示——配置能力是产品的卖点,不是秘密。如果对方说不清产品的配置边界就直接报二开价格,建议换一家问。判断一个实施团队靠不靠谱,看它是先推销二开还是先演示配置,是个挺准的信号。
二开不是洪水猛兽,失控的边界才是。回到开头那句话:需求提出来的时候先分类,标准功能、配置、厂商路线图、真二开——四类需求四种处理,每一类都比"全部写代码"便宜。
如果拿不准手里的需求清单属于哪一类,可以带着清单来聊,我们做分类评估。
河北泽商数字科技有限公司是金蝶软件授权服务中心(授权编码:30311019),13 年实施经验,累计服务 1500+ 家企业,在石家庄、廊坊等地设有服务团队并且天津设立研发技术中心。
产品与服务:金蝶 ERP(云星空 / AI星辰 / 精斗云)、华天动力 OA、泽商云 MES、奥威 BI 的销售、实施与运维。
电话:18031174931

热门推荐