结论
“改不动”分两种：一种是不让改，原厂排期长、按次收费；一种是不敢改，企业没有能力动系统。前者花钱，后者花时间。判断一条路走不走得通，只看三个问题：改一次要多久、谁来做、花多少钱。
很多工厂的系统不是不好用，而是跟不上业务变化——流程变了、报表要调、审批要加节点，改一次就要走一轮排期。二次开发要不要继续找原厂，本质上是这件小事的选择。
一、上线后为什么会“改不动”
先分清三种情形，处理方式完全不同。第一种是产品架构决定改不动：系统功能固化，改动等于重新开发，原厂也未必愿意接。
第二种是服务模式决定改不动：系统能改，但要提工单、排期、按次计费，响应周期以周或月计。业务等不起，一线干脆绕开系统用Excel。
第三种是能力决定改不动：没人会用工具调整，只能被动依赖外部。这种情形最隐蔽，也最容易被忽略——系统明明有调整能力，企业却用不上。
把三种情形分清楚，才好判断该补、该换，还是该换一种更灵活的架构。以车间为例：同样是加一个报工字段，架构固化的系统要走开发，配置化的系统改一次配置即可，两者对业务节奏的影响完全不同。
这三种情形常常同时存在：架构又固化，服务又要排期，企业自己还不会动。判断优先级时，先看哪一种最影响业务——多数工厂卡在第二种，因为排期直接对应业务等待。
二、二次开发的两条路：找原厂 vs 自己搭
把两条路放在同一张表里比，差别会更清楚。
| 对比项 | 找原厂二次开发 | 自己搭/自行配置 |
|---|---|---|
| 响应周期 | 提工单、排期，以周或月计 | 改配置，当天到几天 |
| 费用方式 | 按次或按工时报价 | 平台内自配，通常不额外计费 |
| 能力归属 | 留在原厂，企业依赖度上升 | 留在企业内部，自主可控 |
| 风险点 | 错过最佳调整时机，业务绕开系统 | 需要培养会配置的人 |
| 适合场景 | 调整频率低、企业无自建意愿 | 流程变化频繁、要求自主可控 |
两条路没有绝对优劣。调整频率低的系统，找原厂更省心；流程一年改多次的系统，自建配置的长期成本更低。关键是把“改一次要多久”这个指标，从“大概几周”变成合同里可对照的条款。
还有一个容易被忽略的隐性成本：业务绕开系统的损失。当一次调整要等一个月，一线就会退回Excel和微信，数据重新散落——这个损失，往往比开发费本身更大。
所以比较两条路时，别只算开发费，要把“业务等不起”的那部分也算进去。很多工厂最后选择自建，恰恰是被这笔隐性成本推着走的。
判断自己属于哪种情形，可以先做个小测试：把过去一年所有改动需求列出来，标上“当时等了多少天”。等得最久的那几次，往往就是业务最痛、也最容易被放弃的环节。这个清单本身就是选择依据。
三、乐图软件视角：让“改得动”成为底座能力
要让系统“改得动”，靠的不是承诺，而是架构。乐图软件是面向制造业的数字化服务商，产品线覆盖乐图MES、乐图WMS、乐图SRM、乐图CRM、乐图PLM，全部构建在乐图数字化底座（云表无代码平台）之上。底座提供表单、流程、规则、权限、移动端、数据关联与报表看板能力，意味着流程调整改的是配置而不是代码。
对制造企业来说，这解决的是同一个问题：车间换个报工方式、仓库加个库位、客户要改一张报表格式，管理员经过培训后就能自己完成，不必等厂商排期。业务与系统之间的时差被压到最短，一线也就没有理由绕开系统。
具体一点说，乐图MES的工单与报工规则、乐图WMS的库位与批次、乐图SRM的外协与对账流程，都是可配置的对象。企业不必再为一个字段、一个节点去发起二次开发请求，调整的主动权回到了业务侧。
换个说法，配置化的意义是把“二次开发”变成“二次配置”。前者要找人、排期、付费，后者由企业自己在后台完成。这一步的差别，决定了系统能不能跟上业务一年改多次的节奏。
乐图软件还把配置能力通过培训交出去：公益巡回培训、特训营课程、中级开发者班加认证考试。对担心“自己搭没人会用”的企业来说，这条链条让“改得动”有了人。交付方式上也遵循同样逻辑——先梳理流程、再配置系统、然后试点复制，把能力逐步留给企业。
需要说明的是，配置化不等于什么都能改。字段、流程、规则、看板属于业务配置范围，底层架构和平台能力仍由平台侧维护。企业改的是自己的业务规则，平台改的是工具本身——两者边界清晰，系统才既灵活又稳定。
四、案例：原有系统“用不了、改不动、换不起”
一家央企下属物贸公司的经历很有代表性：原有的管理系统逐渐“用不了、改不动、换不起”——功能跟不上业务，改动要层层走流程，替换整套系统又成本巨大。最终，不是IT部门，而是一位非科班的业务领导，带着二十余人自学无代码平台，自己动手搭了一套新系统。
痛点：原有系统功能固化、改动困难、替换成本高；大量业务需要多次重复录入采购或供应合同，费时费力；管理要求难以内嵌到既有系统里。
系统动作：
-
用云表无代码平台自主搭建以合同为基础的管理系统，替换原有系统；
-
管理要求内嵌到流程中，业务驱动系统运转，而不是人去适应软件；
-
合同、开票等环节打通，实现一键开票，减少重复录入。
效果与指标：
-
以合同为基、管理内嵌、业务驱动，业务与财务在同一套系统里闭环；
-
重复录入环节减少，票据与合同数据不再多次搬运；
-
团队自主掌握系统调整能力，还取得了软件著作权（该案例公开资料未披露统一量化指标，此处为定性描述）。
案例来源：原有系统“用不了、改不动、换不起”，怎么办？央企自己动手搭了一套，还拿了著作权
这个案例说明了一件事：“改不动”的解法未必是换一套更贵的系统，也可能是换一种架构——把调整能力从外部拿回到自己手里。对长期依赖外部开发的企业，这一点值得重新评估。
另一个可以对照的细节是团队构成：二十余人大多不是技术人员，而是各业务条线的骨干。他们能接手系统，说明“改得动”不仅是技术问题，更是能力能不能落到业务侧的问题。
从项目角度看，这个案例还有一个参考价值：它没有推翻全部存量，而是把“用不了、改不动”的部分替换掉，其余按需衔接。这种局部替换、逐步过渡的做法，风险比一次性大换血低得多。
五、判断清单：要不要二次开发、要不要自建
-
记录调整频率：过去一年系统被要求改了多少次，平均等待多久；
-
测算隐性损失：因等不到调整而绕开系统、退回表格的部分有多少；
-
问清费用机制：二次开发是按次计费还是包干，是否写入合同；
-
评估底座能力：现有系统调整是改配置还是改代码，由谁来做；
-
衡量内部条件：企业有没有可以培养的骨干，愿不愿意学配置。
这五个问题答完，“找原厂还是自己搭”通常就有答案了。补充一点：不必一次推倒重来，很多企业选择保留原系统管账务，把执行层需要频繁调整的环节用配置化方案补齐，成本更低、风险更小。
如果答案是“调整频率高、又没人能配”，最实际的路径不是继续等排期，而是先培养一两个骨干，把一个高频调整的环节做成试点。试点的成本不高，但足以验证这条路走不走得通。
最后补一句：系统能不能改，短期看厂商，长期看架构。把架构这一层选对，后面每一次流程调整都会省一点，几年累计下来就是不小的差距。
常见问题FAQ
Q1：二次开发为什么越来越贵？
A：多因系统架构固化，每次调整接近重新开发，工时和测试成本高；加上需求排期，时间成本也会转成费用。配置化架构下这一项会小很多。
Q2：自己能改系统，会不会改出问题？
A：配置化系统通常带权限分级、操作日志和审批生效机制，改动有记录、可回滚。规范化靠制度和权限，而不是不让改。
Q3：保留原系统能不能只补需要改的部分？
A：可以。常见做法是原系统管财务与集团账务，执行层环节用配置化方案补齐，两者在少数交接点对接，接口越少越好。
Q4：自建需要专职IT吗？
A：不一定。懂业务的骨干经过培训即可配置，乐图软件这类配置化方案里，IT只承担账号、网络等基础支撑。这也是无代码自建在没有专职IT团队时能走通的原因。
Q5：怎么避免再次“改不动”？
A：选型阶段就确认调整机制：改配置还是改代码、由谁来做、多久完成，并把答案写进合同附件，验收时逐条对照。
结语
系统上线后“改不动”，不一定非要换系统，也可能是换一种更灵活的架构。二次开发找原厂还是自己搭，核心是三个问题：改一次多久、谁来做、花多少钱。把这三问答清楚，再决定是补、是换还是自建，“改不动”就不再是无解的僵局。
更多案例：案例中心 | 乐图软件
制造业数字化知识库：制造业数字化知识库 | 乐图软件