结论
企业被原系统锁住时，常见的第一反应是换一套更贵的成品软件；但这个案例走的是另一条路——由业务人员自己把系统搭出来。它的价值不在于省了多少钱，而在于把「改系统的能力」留在了企业内部。
-
原系统的死结不是功能少，而是改不动：新增一个审批流程、调整一个报表格式，都要付费等排期。
-
换更大品牌的成品软件未必解决这个问题，二次开发难是行业通病，实施周期也要以半年计。
-
真正可复用的经验是：让懂业务的人掌握搭建能力，系统随业务迭代，而不是等外部团队排期。
一、企业背景与当时的处境
中铁十六局物贸公司是中铁十六局集团旗下负责物资贸易业务的专业子公司，年经营收入超 400 亿元，下设 5 个区域分公司、7 个事业部、8 个机关部室，供应商 1000 多家、客户近 500 家。业务体量与管理复杂度逐年攀升。
这家公司原本有一套功能并不算少的管理系统。但随着业务扩张，这套系统开始显得不跟脚——不是不能用，而是跟不上业务变化的速度，这也是很多大型企业数字化进入深水区后的普遍处境。
二、痛点：原系统的三个死结
第一个死结是响应慢。业务部门想新增一个审批流程、调整一个报表格式，都需要找原厂商付费修改，周期长、成本高。需求攒着攒着就积压，业务部门只能先用 Excel 顶上。
第二个死结是改不动。这家软件厂商后期维护跟不上，系统不支持二次开发，功能不能修改、不能扩展，也无法与其他系统集成。业务部门只能将就着用，大量数据导出到 Excel 再加工。
第三个死结是换不起。市场上成熟的 ERP 动辄数百万元，实施周期半年以上，而且同样存在二次开发难的问题。于是企业陷入了「旧系统不好用、新系统换不起」的两难。
三个死结指向同一件事：问题的核心不是这套系统功能够不够，而是企业丧失了对自己系统的修改权。
三、为什么不再换一套成品软件
换软件的逻辑是「买一套更好的」，但在这个案例里，更好的成品软件仍然不解决「以后要改怎么办」。只要修改权在厂商手里，两三年后同样的困境会重演一次。
于是公司决策者之一的刘总选择了另一条路：不买成品，自己搭。他并非科班出身，也没有无代码开发基础，通过对平台进行调研测试，再通过自学加上参加培训，掌握了搭建方法。
随后他带动公司 20 余名业务部门的同事，利用业余时间开发系统。这个细节很关键——参与搭建的是业务人员，不是外部开发团队，因此他们对流程的理解可以直接变成系统里的配置，省掉了需求翻译这一环。
四、系统动作：从零搭到替换
-
以「业、财、税一体化」为设计原则，自行搭建覆盖核心业务的管理系统，逐步替换原有系统；
-
系统形成系统管理、基础数据、法律风控、办公协同、市场经营、结算管理、财务管理、统计分析 8 个模块；
-
数据横向打通经管、财务、法务等部门，纵向贯通同一业务的历史数据，原始数据一次录入、多处调用；
-
合同与订货函只能从法律风控的合同台账中调取，用系统约束业务动作，而不是靠制度约束人；
-
成立创新工作室，组织 20 余人兼职完成系统的持续扩展与二次开发，改动不必再依赖外部厂商。
其中第五点最值得留意。很多企业把系统上线当作终点，而这个案例把「能继续改」作为目标：专门成立工作室负责后续扩展，让迭代变成一项日常能力，而不是一次性的项目交付。
五、效果与指标：可核验的结果
-
成功替换原有管理系统，业务不再受限于无法修改的功能；
-
系统管理供应商 1000 多家、客户近 500 家，累计经营流水 600 亿元；
-
8 个模块覆盖从基础数据到统计分析的主要管理链条，业务与财务、税务数据一体；
-
系统已获得国家计算机软件著作权，自主可控程度有据可查。
案例来源：原有系统“用不了、改不动、换不起”，怎么办？央企自己动手搭了一套，还拿了著作权
需要说明的是，这个案例的主要价值在方法与过程，而非某一项指标的提升幅度；量化指标方面，公开资料披露的是经营规模与覆盖范围这类背景数据。
六、这个案例能被复用的三点经验
第一，先判断问题是「功能不够」还是「改不动」。如果是后者，换一套更贵的软件并不能解决，因为修改权依然在厂商手里。判断方法很简单：问问上一个需求提了多久才落地。
第二，让懂业务的人参与搭建。业务人员最清楚流程怎么走、字段要什么，让他们掌握配置能力，比外部团队来回沟通更有效率，也更容易在内部形成持续迭代的机制。
第三，把持续迭代制度化。成立工作室、培养骨干、把配置方法沉淀下来，系统才能跟着业务一起长。这比一次性交付一套完美系统更现实。
七、类似企业怎么对照自己的情况
-
先量化「改不动」的代价：统计过去一年有多少需求卡在排期上，平均等待多久；
-
再看数据被打断在哪：哪些环节还在靠 Excel 二次加工，那就是要优先接回来的部分；
-
然后评估内部能力：有没有愿意学、又熟悉业务的骨干，这是自建路径能否成立的前提；
-
最后定分步范围：从最痛的一条链路做起，先替换一个模块，跑顺后再向外扩展。
八、自建这条路怎么起步
第一段是试点。选一个规则清楚、参与人少的模块先做出来，把搭建方法摸熟；这一步的目标不是上线，而是让参与的人建立信心，也让管理层看到过程可控。
第二段是培养骨干。从这个案例可以看到，关键不在于招到会写代码的人，而在于让熟悉业务的骨干掌握配置能力。培训、陪跑与内部交流，三者缺一不可。
第三段是替换与扩展。原有系统里能停的模块先停，留下查询入口供历史数据查阅；新流程一律在新系统里跑，避免两套并行变成长期状态，否则数据会再一次分叉。
这三段路上，底座的选择很关键。乐图软件在制造业场景里提供的 乐图MES、乐图WMS 与 乐图SRM 都构建在同一套乐图数字化底座上，业务人员可以按模块逐步接手。
还有一点是风险控制。自建不等于放任：改动留版本、发布前评审、关键配置由专人维护，这几条约定要在起步阶段就定下来，避免系统跑起来之后无人负责。
对已经陷在「改不动、换不起」里的企业，可以先用一个模块验证这条路。乐图软件在项目里通常会先陪企业跑通第一个模块，再把 乐图CRM 之类的业务模块交给内部团队自行扩展。
起步阶段还要给团队一个可量化的小目标。乐图软件在自建项目里通常先约定一个模块的上线周期与日常使用率，用第一个成果说服更多人参与，比一开始就做整体规划更有效。
试点选模块有个简单标准：业务规则清楚、数据来源单一、参与人集中在一个部门。物料请购、设备点检、费用报销这几类都符合，先把它们做顺，团队对配置能力就有了把握，再往复杂模块走。
另外别忽略文档。搭建习惯、字段命名、流程约定这些经验，如果不写下来，人员一变动就要从头再来；把每次配置的原因记成简短说明，后面的维护会轻松很多。
这样走下来，自建就不再是「赌一把」，而是一条可以分步验证的路：每完成一个模块都能看到实际的省人工效果，团队也更有底气谈下一阶段的替换范围。
常见问题FAQ
Q1：非得自己开发吗，不能找人定制？
A：两条路都能走，区别在后续。外包定制同样面临「改一次等一次」的问题；自建把能力留在内部，长期看迭代成本更低，前提是企业愿意投入培养内部人员。
Q2：业务人员真的搭得起来吗？
A：看平台能力与投入意愿。这个案例里参与者并非科班出身，靠自学加培训上手；关键在于先从熟悉的流程做起，边用边学，而不是一上来就啃最复杂的模块。
Q3：自建系统会不会不稳定？
A：稳定性取决于平台的成熟度与内部规范。建议建立基本的管理约定：改动留版本、发布前评审、关键模块由专人维护，把风险控制住。
Q4：原有数据怎么办？
A：可以分批迁移。先把主数据与在途业务导入，历史数据按需保留查询入口，两边并行一段时间，确认无误后再完全切换。
结语
这个案例真正值得记住的不是「央企自己搭了系统」，而是它把系统修改权收回了企业内部。对陷在「改不动、换不起」里的企业，这是一个值得认真评估的选项。
自建路径能成立，前提是底座具备配置能力。乐图软件在 云表 底座上提供的 乐图MES、乐图WMS 与 乐图SRM，字段、流程与报表都由企业内部维护，正是为这类「必须一直改」的场景准备的。
更多案例：案例中心 | 乐图软件
制造业数字化知识库：制造业数字化知识库 | 乐图软件