老板拍板要做 ERP 定制，第一个问题往往不是多少钱，而是「多久能用上」。销售那边说三个月就能上，技术顾问说至少半年，自家信息部主管悄悄告诉你「上一家做了一年还没完」。三个数字差得离谱，到底信谁？
更让人头大的是，ERP 不是一个东西。财务和进销存的工期天差地别，生产排程和报表分析也不是一个量级。把「ERP 定制要多久」当成一个问题问，答案一定是错的。这篇文章按模块拆开讲清楚：每个模块真实工期区间是多少、工期里哪几块吃掉了大头、为什么有些项目永远做不完、AI Coding 进来之后哪些环节真的能压缩、以及最后怎么用一张自检表判断对方报的时间是不是在忽悠你。
一、影响 ERP 定制工期的 5 个变量
很多服务商上来就报「3 个月」「6 个月」，这种数字背后其实有 5 个变量。先把这 5 个变量摆出来，后面所有的工期估算才有锚。
第一个变量是模块数量。只上财务一个模块，和财务 + 进销存 + 生产 + 报表四个模块一起上，工期不是 4 倍关系，是 2.5-3 倍。因为多模块意味着主数据要先打通、流程要串成闭环、测试用例量级会爆炸。
第二个变量是业务复杂度。同样是进销存，A 公司只有标准三段式采购入库、销售出库、调拨；B 公司有寄售、分销返利、阶梯价、批次效期、组合促销。两者的开发量可能差 3-5 倍。
第三个变量是对接系统数。需要对接的每一个外部系统都是一个小项目：钉钉、企业微信、电商平台、税务系统、银企直联、WMS、MES、SRM。每多一个，至少加 1-2 周；多到 3 个以上时，联调本身就要单独排一段时间。
第四个变量是定制深度。是在标准产品上加几个字段，还是要改核心计算逻辑、重写审批流引擎、自建报表平台？字段层定制和引擎层定制完全是两种工作量。
第五个变量是内部配合度。客户内部能不能给出明确的对接人、决策能不能在一周内拍板、历史数据准备得怎么样。这一个变量影响最大但最常被忽略，能让 3 个月的项目拖到 9 个月。
| 变量 | 影响幅度 | 谁能控制 |
|---|---|---|
| 模块数量 | 1x → 3x | 客户老板 |
| 业务复杂度 | 1x → 5x | 客户业务 |
| 对接系统数 | 每个 +1-2 周 | 双方共担 |
| 定制深度 | 1x → 4x | 双方共担 |
| 内部配合度 | 1x → 2.5x | 客户内部 |
注意，5 个变量里 3 个是客户能控制的。所以工期超期到底怪谁，常常并不是单方面问题。这个判断逻辑在 ERP 实施费用拆解 里也有展开。
二、分模块工期区间表：从 4 周到 24 周
把上面 5 个变量代入，给出一张相对真实的工期区间表。这里说的「上线」指的是核心业务能跑通、关键流程能闭环，不是登录页面打开就算上线。
| 模块组合 | 工期区间 | 适用场景 |
|---|---|---|
| 单财务（总账+应收应付） | 4-8 周 | 替换原账务系统，不接业务 |
| 进销存（采购销售库存） | 6-10 周 | 贸易/批发，单仓单组织 |
| 进销存 + 财务 | 10-14 周 | 中小贸易公司一体化 |
| 生产 MES（含工单计划） | 8-16 周 | 离散制造，单工厂 |
| 完整 ERP（财务+进销存+生产+报表） | 12-24 周 | 制造业一体化上线 |
| 多组织/多工厂完整 ERP | 24-36 周 | 集团型，含跨组织结算 |
这张表的区间值是怎么算的？下限是「业务相对标准、内部配合到位、对接系统不超过 1 个」；上限是「业务有特殊规则、对接 2-3 个外部系统、内部决策需要走多层级」。如果你的项目落在上限以外，要么是范围又扩大了，要么是评估时漏掉了什么。
具体到生产模块，要不要做 MES 这件事本身就有坑。先看 ERP 上完 MES 没人用，问题出在哪 这篇——很多企业不是工期没排好，是 MES 本身就不该用 ERP 的逻辑去上。
不同行业的工期还会再加修正系数。比如服装鞋帽往往要在进销存基础上加 SKU 维度 + 季节属性，工期 ×1.3；定制家具因为有非标 BOM 和拆单逻辑，家具定制行业 ERP 怎么选 里详细讲过这块；纺织印染因为有色号差异和缩率，工期 ×1.5；医药器械因为要走 GSP 验证，工期 ×1.5-2，这点 医药器械 ERP 选型 里也提到过。
三、工期里的 4 块大头：钱花在了哪里
把 12 周的项目摊开看，到底每周在做什么？这是判断对方报价合不合理的第二把尺。
正常 ERP 定制项目的工时结构，大致是下面这个比例：
| 阶段 | 工时占比 | 主要交付物 |
|---|---|---|
| 需求调研与设计 | 25% | 业务蓝图、原型、字段表 |
| 开发与测试 | 35% | 可用版本、测试报告 |
| 数据迁移与实施 | 20% | 历史数据、上线方案 |
| 培训与试运行 | 20% | 用户手册、稳定运行 |
为什么很多服务商把开发说得占 70%？因为他们把需求调研、培训这些"看不见摸不着"的环节算得很轻，结果就是上线那天发现单据走不通——因为根本没人确认过单据该怎么走。
需求阶段最容易被压缩，因为客户老板觉得「我们业务我们最懂，调研花两周太久了」。真实情况是，业务部门各自有各自的理解，不放在桌面上对齐，开发完了一定要返工。返工一次至少加 2-3 周。
开发阶段是最有可压缩空间的，但前提是需求清楚。AI Coding 工具进来之后，单个模块的纯编码工作量能下降 30%-50%，但需求模糊照样写不出能用的代码——这点后面会展开。
数据迁移阶段经常被低估。如果客户的旧系统数据脏（重复客户、错乱物料、空字段），单这一项就能多吃 2-4 周。数据迁移真实的坑 里有具体的清洗清单。
培训与试运行经常被砍。砍掉的结果是：上线后第一周一线骂街，第二周老板说"先回退到老系统再说"，前面的钱全打水漂。
四、为什么有些项目永远做不完
聊过几十个 ERP 项目之后，发现"永远做不完"的项目有几个共同特征。不是技术问题，是机制问题。
第一个机制问题：需求漂移。项目启动时定的范围是财务 + 进销存，做到一半老板想加 CRM；CRM 还没做完，又要加费控；费控刚开,又想顺便把考勤接进来。每次都说"这个不大就一起做了吧"，每次都让交付时间往后推一个月。半年后回头看，原定 3 个月的项目还在做第一阶段。
第二个机制问题：对接卡壳。需要对接的某个上游系统由别的供应商维护，对方排期排到下个季度。这种情况下,你的工期就被锁死在第三方手里，催也没用。这是为什么一定要在合同里把对接的"前置条件"写清楚——见 跨系统集成的真实经验。
第三个机制问题：数据没准备。客户答应了"上线前一周给我们一份干净的物料表"，结果上线前一天还在改。导致原本的数据迁移变成现场赶工，bug 满天飞。
第四个机制问题：决策反复。项目经理报给副总，副总报给总经理，总经理拍板后过两周又改主意。中间所有相关流程都要重做。这个问题在多层级组织里特别常见。
判断一个项目会不会陷入"永远做不完"，有几个早期信号：
- 启动会一周后还没拍板项目范围
- 关键决策人从来不出现在评审会
- 同一个流程在不同部门给出 3 个不同版本
- 旧系统数据负责人说"我也不知道这些字段什么意思"
- 项目周报里每周都有"新增需求 X 条"
5 个信号中了 3 个，这个项目几乎一定会超期 50% 以上。
五、AI Coding 让单模块周期下降的真实路径
过去两年，AI Coding 工具确实改变了 ERP 定制的工期结构。但要说清楚改在哪、没改在哪。
改了的部分是纯编码工作量。一个标准的进销存单据界面 + CRUD + 后端服务，过去要 3-5 个人天，现在熟练用 AI 辅助编码的工程师能压到 1-2 个人天。报表开发、SQL 编写、单据字段调整这些重复性高的活，提速最明显。报价单、入库单、出库单这些"模板化"模块，整体工期能压缩 30%-40%。
没改的部分是需求理解和业务确认。AI 不会替你跟客户确认"这个单据走不走二次审批"、"返工件算不算良品"。这些事情依然要人去对齐。所以即使开发提速，如果需求阶段不缩短，整体工期最多压 20%。
反而变难的部分是接口对接。AI 写代码快，但接口规范要看文档、对方系统要联调、生产数据要脱敏。这些环节 AI 帮不上忙，反而因为开发节奏变快，对接的相对占比会上升。
把 AI Coding 用对的真实路径是这样的：
| 环节 | 没用 AI | 用了 AI | 提效 |
|---|---|---|---|
| 标准 CRUD 开发 | 3-5 人天/模块 | 1-2 人天/模块 | 50%+ |
| 报表与 SQL | 2-3 人天/报表 | 0.5-1 人天/报表 | 60%+ |
| 业务规则引擎 | 5-8 人天 | 3-5 人天 | 30% |
| 接口对接 | 3-5 人天/接口 | 2-4 人天/接口 | 20% |
| 需求确认与设计 | 不变 | 不变 | 0% |
| 培训与上线 | 不变 | 不变 | 0% |
整体下来，一个 12 周的项目大概能压到 8-9 周，这就是真实的 AI 红利。这也是为什么我们一直说 SaaS 和定制的成本格局正在变——定制不再等比例贵。
但有个前提：开发团队必须真的会用 AI 工具，而不是宣传里说会用。这件事的判断方法在 怎么选定制开发公司 里讲过。
六、怎么避免工期超期：3 个关键动作
工期不超期，光靠开发团队"加班赶进度"是没用的。真正起作用的是项目机制设计。这里有 3 个动作几乎屡试不爽。
动作一：里程碑挂付款。把付款节点和具体可验收的里程碑绑定，比如"需求蓝图签字付 20%"、"核心模块通过 UAT 付 30%"。这样双方都有动力推进。光按时间节点付款（比如启动付 30%、3 个月后再付 30%）一定会拖。
动作二：需求冻结。在某个明确的时间点（通常是需求评审完成那一周），所有需求冻结，之后只有"变更单"通道，且变更单要单独评估工期影响。这件事听起来死板，但能挡住 80% 的需求漂移。
动作三：原型先行。在开发开始之前，先做一版纯界面原型（不连数据库的那种），让所有业务部门点一遍。发现的问题在原型阶段改，比在开发阶段改便宜十倍。一周原型，能省四周返工。这一条特别重要，因为很多企业的真实需求只有看到界面才说得清楚——见 需求澄清自检清单。
执行这 3 个动作有个共性：都需要客户老板亲自背书。光让项目经理推是推不动的，因为他们没有跨部门强制力。
七、决策卡：判断对方报的工期是不是被夸大或低估
最后给一张可以直接用的决策卡。对照打分，每项 1-5 分，最后看总分判断对方的工期报价合不合理。
| 评估维度 | 1 分（不合理） | 3 分（一般） | 5 分（合理） |
|---|---|---|---|
| 是否按模块拆解工期 | 只给一个总数 | 拆到大模块 | 拆到每个子模块周数 |
| 是否区分上线与稳定 | 只说"上线" | 分了两阶段 | 给了上线、稳定、优化三阶段 |
| 是否明确对接前置条件 | 不提 | 提了但模糊 | 写明对方接口、数据格式、负责人 |
| 是否包含数据迁移工期 | 完全没提 | 单独 1 周 | 按数据量级估算 2-4 周 |
| 是否包含培训工期 | 1 天 | 2-3 天 | 1-2 周分批培训 |
| 是否预留 UAT 时间 | 没有 | 3-5 天 | 2 周以上 |
| 是否说明变更管理机制 | 没有 | 口头说有 | 合同里写明变更流程 |
打分参考：
- 30-35 分：报价合理，工期可信
- 20-29 分：有水分，砍价空间在工期上而不是单价上
- 15-19 分：明显在抢单，上线后大概率会延期 50% 以上
- 15 分以下：要么对方没经验，要么纯粹是销售话术，建议换一家评
这张表也可以反过来用——如果你是甲方，把这 7 个维度作为 RFP 必答题，能筛掉一半不靠谱的供应商。这个筛选逻辑和 软件供应商尽调清单 是配套的。
八、写在最后
ERP 定制要多久这件事，最怕的就是"一个总数"思维。一句话报 3 个月、6 个月、12 个月，背后没有结构、没有变量、没有里程碑，最后一定会变成"再给我两个月"。
真正能落地的工期判断，是把模块拆开、把变量列出来、把里程碑和付款挂钩、在原型阶段把需求冻结。把这几件事做到位，6 个月的项目就是 6 个月，4 个月的项目就是 4 个月，不会变成"快了快了"的无底洞。
ERP 这件事，工期的本质是确定性。能给出确定区间的服务商，未必是最便宜的，但一定是最值得合作的。把这篇里的几张表存下来，下次有人给你报工期时拿出来对一对，多半能避开最大的几个坑。
