ERP软件选型时最容易被忽视的问题：实施后谁来

一个上线后的真实状态

某企业ERP系统上线一年后，IT部门的工作状态是这样的：每天处理用户的各种操作问题——“单据怎么找不到了”“审批流卡住了”“报表数据对不上”；每个月关账期间，财务部门会反馈一堆数据问题，IT人员要临时写脚本调整；每季度做一次版本升级，提前两周测试，升级后还要花一周修复被破坏的二次开发功能。

原来的项目经理已经被调去做其他项目了。系统上线时他提过“后续需要持续投入运维资源”，但管理层认为系统上线了就结束了，没有再批预算。IT部门的几个人能对付就对付，对付不了就拖着。

这不是个例。ERP系统上线后需要的维护工作量，被大量企业严重低估。选型时关注功能够不够全、界面够不够炫、价格够不够低，很少有人问一句“上线后谁来维护、需要多少人、多大规模”。

选型时容易被忽略的三个维护问题

问题一：二次开发的维护成本

选型时，很多企业会发现标准功能覆盖不了所有业务需求。于是要求软件供应商做二次开发。二次开发在选型阶段看起来只是“加几个功能”的问题，实施阶段也能做出来。但上线之后，二次开发的部分就成了一个长期的维护负担。

标准功能是软件厂商持续维护的，出了Bug由厂商修复，版本升级时厂商会做兼容性测试。二次开发的部分，这些工作都要企业自己承担。自己写的代码自己维护，自己做的功能自己测兼容性。选型时做了多少二次开发，上线后就背着多少技术债。

问题二：数据质量的持续维护

ERP上线前通常会做一次大规模的数据清洗，那时候的数据质量是最高的。但上线之后，新数据不断录入，错误数据慢慢积累。物料编码重复了，客户名称不统一了，BOM版本没人更新了。数据质量的问题不是上线就能解决的，需要持续的维护机制。

谁负责检查物料编码是否重复？谁负责清理不再使用的客户？谁负责在年底结转历史数据？这些问题在选型时很少被问及，但上线后它们会成为日常。

问题三：人员流动带来的知识断层

ERP系统实施时，软件供应商会做知识转移，培训企业内部的IT人员和关键用户。但项目结束后，这些被培训的人可能调岗、离职。新来的人不熟悉系统，遇到问题不知道怎么处理。原来供应商教的那些内容，随着人员流动慢慢流失。

系统还在，但懂系统的人没了。这是很多老ERP用户面临的现实。选型时把“知识转移”写进合同，但“知识”是留在人脑子里的，人走了知识就没了。这是一个合同条款解决不了的问题。

维护工作到底有多少

基于一些企业的实际经验，上线后每年的维护工作量大致包括几个方面。

日常操作支持。用户每天使用系统时会遇到各种问题：忘记操作路径、不理解字段含义、单据提交后找不到。这些问题需要有人响应。用户多的企业，每天可能需要处理十几甚至几十个咨询。

数据维护。物料编码、客户信息、供应商信息、BOM结构，需要持续维护。不是数据错了才维护，而是要定期检查，把问题消灭在萌芽阶段。

系统运维。用户权限管理、后台作业监控、接口状态检查、数据库基础维护。这些工作不需要每天做，但有固定的周期。

变更响应。业务变化了，需要调整系统配置：增加一个审批节点、修改一个报表格式、添加一个字段。小调整频繁发生，需要有人能在几小时内完成，而不是等供应商排期。

版本升级。ERP厂商每年发布一两次版本更新。要不要升级？升级前需要测试哪些功能？测试环境谁搭建？升级失败怎么回退？这些工作都需要人力。

把这些工作量加起来，一个中等规模的企业，上线后通常需要一到两个人的专职维护力量。如果二次开发量大、用户多、业务变化快，人力需求会更高。

选型时需要问的几个问题

选型阶段，除了对比功能、价格、界面，还需要问几个关于“上线后”的问题。

问题一：标准功能对我们业务的覆盖率是多少。覆盖率越高，二次开发越少，后期的维护负担就越轻。选型时可以用实际的业务单据跑一遍标准功能，看哪些走不通、哪些需要开发。

问题二：二次开发的代码由谁维护。如果由软件厂商维护，维护期多长，续费标准是什么。如果由企业内部团队维护，软件厂商是否提供充分的文档和培训。

问题三：软件厂商提供的运维服务包括哪些内容。响应时间是多长，问题解决时间是多久，远程支持还是现场支持。这些内容在服务级别协议里要写清楚。

问题四：版本升级时，软件厂商是否做兼容性测试。如果标准功能升级后破坏了二次开发的功能，谁负责修复。

问题五：企业内部需要配备多少运维人力。软件厂商应该根据企业的业务规模、用户数、二次开发量，给出一个参考建议。

新易编码如何降低ERP的维护负担

新易编码不替代ERP，它解决的是ERP中一个具体的维护难题——编码规则的频繁变动。

在传统ERP中，物料编码规则一旦设定，要改就很难。改规则意味着改数据库结构、改接口逻辑、改报表查询条件，通常需要IT部门介入，开发、测试、上线，走完整流程。每次改动耗时几天到几周。

如果业务发展快，编码规则需要频繁调整，ERP的维护负担就会很重。

新易编码把编码规则的配置和变动从ERP中剥离出来。编码规则由业务人员在新易编码平台上自己维护，不需要改ERP代码。ERP只负责调用新易编码的接口获取编码，或者接收新易编码同步过来的编码数据。规则的变动对ERP来说是透明的——接口没变，数据格式没变，ERP不需要做任何调整。

这种模式下，ERP的维护工作少了一项“应对编码规则变化”的内容。新易编码本身也需要维护，但它的维护边界很清晰：只负责编码的生成和管理，不涉及ERP内的业务流程。两个系统各管一摊，互不干扰。

几点具体的建议

选型时把“上线后的人力需求”算进总成本。软件采购费、实施服务费是一次性投入，运维人力是每年都要花的。这笔账要提前算清楚，不要上线了才发现没人维护。

尽量用标准功能，少做二次开发。标准功能是软件厂商持续维护的，二次开发的代码是自己维护的。每做一次二次开发，就多一份技术债。

在合同里明确知识转移的交付物，不只是“培训了多少人”。操作手册、配置文档、二次开发的技术文档、常见问题库，这些都是知识转移的一部分，比培训几天的价值更持久。

培养内部运维能力，不要太依赖软件厂商。厂商的顾问按小时收费，长期依赖成本高。企业内部要有能力处理日常问题，只有解决不了的才找厂商。从实施阶段就让内部人员深度参与，接手日常运维，而不是等项目结束才开始学。

定期做数据维护，不要等出问题再处理。每个月检查一次物料编码的重复情况，每个季度清理一次不用的客户，每年归档一次历史数据。投入很少，但能避免数据雪崩。

结语

ERP选型时，功能对比表能填满几十行，价格谈判能持续几周，但“上线后谁来维护”这个问题很少被认真讨论。等到系统上线了、实施团队撤了、问题出现了，才发现没人能处理。

这不是软件的问题，是选型时考虑不周的问题。ERP不是“交钥匙工程”，不是上线那一刻就结束了。它是企业持续运作的一部分，需要持续的投入和关注。

选型的时候多问一句“上线后怎么办”，比上线后再想办法要容易得多。

新易编码不解决ERP选型的所有问题，但它提供了一个思路：把那些变化频率高、但逻辑相对独立的业务规则从ERP中抽离出来，单独管理。这样ERP的维护负担就少了一块，核心业务流程也更稳定。这是降低ERP长期维护成本的一个可行方向。

 

如果您有物料编码相关的问题，欢迎咨询新易物料编码