金蝶二开能做什么：我们接的 7 类需求，和 3 类建议你别做

客户来问二开，最常问的一句是「我这个需求你们能不能做」。这篇文章把我们做过的需求整理成 7 类，也把 3 类我们通常会劝客户先别做的说清楚——哪些接、哪些不建议做，一次讲明白，后面还附了一份能直接拿去用的需求描述模板。

一、先说清楚：二开解决的是什么问题

标准产品覆盖的是通用业务。当你的业务规则有自己的特殊性、标准功能走不通时，才轮到二开。

判断标准很简单：这件事能不能用标准功能加配置解决？能，就不该开发；不能，才考虑二开。

所以二开不是「越多越好」的东西。它的价值在于精确补上标准产品覆盖不到的那一小块。改动越少、离标准产品越远，系统越稳，后续维护成本越低。

二、我们常接的 7 类二开需求

按需求性质分，我们接得最多的是下面这 7 类。

这 7 类里，第 6 类通常是企业最先碰上的——业务跑在多个系统里，数据得来回走。第 3 类最容易被低估：不少企业上系统半年后才发现，标准报表看不了自己真正想看的数。

三、这 3 类需求，我们建议你先别急着开发

说能做什么不难，难的是把不该做的说清楚。下面这三类，我们通常会先劝客户停一停。

第一类：业务规则还没定就先开发。需求天天变，开发永远追不上。今天说折扣按客户等级，明天说还要看回款情况，改到第三版连最初要解决什么都不清楚了。这种项目的正确做法是先把规则写在纸上讨论清楚、定稿再动手——前期多花的那几天，比后面反复返工便宜得多。

第二类：用二开去补标准产品本来就有的能力。有些需求其实是配置问题或版本问题。比如想要某个业务环节的管控，而标准产品在对应模块或更高版本里本来就有，只是当前没开。这种情况升级或开通模块比二开更便宜也更稳，因为它是产品自身在维护，后续升级不用额外操心。

第三类：用二开硬撑明显超出产品定位的业务。业务复杂度上去了——多事业部协同、复杂的生产编排、跨区域核算——继续在当前产品上加字段、打补丁，只会越维护越贵，每次升级都是一场硬仗。这种我们通常会直接建议评估更合适的平台，而不是继续接这个二开。少赚一笔，但客户后面省下的钱更多。

四、怎么写一份能直接报价的二开需求

很多客户找来时，需求只有一句话：「能不能把订单改一下」。这种描述没法评估工作量，也报不出准确价格。按下面 7 项写清楚，供应商基本能直接给方案和报价。

1. 业务场景：这件事现在怎么做的，为什么必须改
2. 涉及的单据或模块：改的是哪张单、哪个环节
3. 具体规则：什么条件下触发，按什么逻辑计算或判断
4. 例外情况：有没有特殊情况要单独处理
5. 操作角色：谁来做这个动作、需要什么权限
6. 期望结果：改完之后界面或数据上应该看到什么
7. 关联系统：有没有别的系统要一起动

这 7 项写下来通常不超过一页纸，但能省掉后面好几轮来回确认。

五、我们怎么保证二开扛得住后续升级

这是客户问得第二多的问题：做完之后，标准产品升级了会不会出问题？

这个问题其实在动手之前就决定了答案。核心原则是让改动离标准产品远一点——优先走接口和自定义对象，其次是把逻辑挂在标准单据的公开事件上；直接改标准对象只在前两者都走不通时才考虑，而且改动必须写到最薄。

另外，我们交付时会一并给出四样东西：每段逻辑的说明、这次二开的影响范围、升级后需要回归的测试点清单、后续变更记录。多花的这点时间，换的是几年后遇到升级不用靠猜。

六、一份需求交给我们之后

流程大致六步：先看需求，判断能不能用标准功能解决；再出方案与报价，把软件、实施、开发、服务分开列清楚；确认后定开发计划；开发完在测试环境验收；上线并做数据核对；最后交付文档并跟进一段时间。

整个过程客户主要参与两个节点：确认方案、确认验收。中间的开发与测试由我们推进，进度定期同步。

七、小结

二开的价值在于精确补上标准产品覆盖不到的那一块，而不是越多越好。判断要不要做、做在哪一层，比写得快不快重要得多。

如果你手上有类似需求，可以按第四节的 7 项整理一下发过来——我们会先判断能不能做、建议做在哪一层，一个工作日内回方案。

广州市九蝶科技有限公司，金蝶铂金代理商、ISV 开发服务商。二开需求评估、方案设计这类需求，欢迎交流：13632123901。