先判断：你的业务到底需不需要定制
在金边做软件这行12年，团队28个人，每年交付的项目量在100个上下，客户分布在柬埔寨、菲律宾、越南、老挝、泰国、印尼、马来西亚这几个市场。主攻的行业是电商、娱乐、金融/交易、地产、物流。见得最多的场景是：企业上了一套标准ERP，跑了两三年，最后卡在几个不起眼的边界场景上——一笔销售退货要同时回补库存、冲红应收、回滚成本；一个审批流在金额超过阈值时要自动升级到总监和财务双签。标准系统改不动，二次开发又受限于底层结构，最后只能靠人工线下补流程。
但说句实话，不是所有企业都需要从零定制ERP。接需求之前，通常会先帮客户过三个判断维度，不合适定制也会直说。
流程标准化程度。如果企业80%的业务动作和行业通用模式一致，比如零售业的进销存、批发业的采购分销，标准产品的总拥有成本大概率更低。但一旦出现按项目型生产、按批次回款、按渠道拆佣金这类独特规则，标准ERP的配置项基本就捉襟见肘了。主攻的五个行业里，金融/交易、地产、物流这三类在流程上普遍存在较强的非标特征，电商和娱乐则要看具体业务模式——电商类系统本身有成品，开箱即用，很多客户用成品就能跑起来，不需要从零开发。
权限管控粒度。标准系统大多只提供角色级权限，比如“销售经理”能看到什么菜单。但实际业务中，销售经理A和销售经理B管的团队不同，财务只能看到已审批通过的付款单，区域总监只能看自己大区的数据——这种数据行级权限在标准产品里很难实现。定制开发可以直接在数据访问层做过滤，按组织、按品类、按金额等级分权。
集成复杂度。如果企业已经有MES、WMS、CRM在跑，且标准ERP的开放接口不足以支撑数据编排，定制开发可以基于API网关把数据流统一管起来。反过来，如果系统相对单一，标准产品的原生集成能力可能就够用了。
还有一种常见的折中做法：核心财务和采购用成熟标准产品，外围的项目成本、佣金计算、定制报表做开发。这样基础模块的风险可控，业务创新又不必等厂商排期。给客户做方案时，经常把这个选项放在第一条，尤其是预算有限、又不想被标准产品锁死的中型企业。
五个核心模块的数据关系，比功能清单更重要
谈ERP定制开发，如果只列功能清单，很容易变成堆砌。真正决定系统能不能用的，是模块之间的数据关联和状态流转。下面这张表把五个核心模块的关联要点整理出来：
| 模块 | 核心功能 | 数据关联要点 |
|---|---|---|
| 采购管理 | 供应商准入、询比价、采购订单、到货质检 | 采购单确认后自动生成入库单，同时更新应付账款 |
| 库存管理 | 多仓库/多货位、批次追溯、安全库存预警 | 入库/出库动作即时更新库存台账，触发销售锁库 |
| 销售管理 | 客户信用控制、报价单转订单、发货拆单 | 销售出库后自动生成应收账款，并扣减可用库存 |
| 财务管理 | 应收应付核销、费用报销、总账凭证生成 | 业务单据完成后，系统按预设规则自动生成会计凭证 |
| 审批流引擎 | 多级审批、会签、条件分支 | 审批状态驱动业务单据流转，超时自动升迁 |
这里要强调一个容易被忽略的点：跨模块操作必须保证原子性。举例来说，一张销售退货单在系统里不是孤立记录，它要同时完成三件事——库存回补、应收账款冲红、成本核算回滚。如果只靠接口同步，中间任何一步失败都会造成数据不一致。正确的做法是在数据库事务层面处理，要么全部成功，要么全部回滚。这类细节在需求阶段不显眼，上线后却是对账差异的主要来源。交付过的系统里，部分成品有几十家客户在运营使用，这类跨模块一致性问题在验收阶段被发现的概率远高于功能缺失——不是因为功能没做，而是因为状态流转的边界条件没考虑全。
数据打通：以业务单据为最终凭证
ERP和现有业务系统的数据集成，是定制开发中出问题最集中的环节。实际项目里，通常按数据时效性要求分成三种处理方式：
- 高频实时同步：比如库存变动，WMS发货后通过消息队列（Kafka或RabbitMQ）异步通知ERP更新库存表。这样做的好处是解耦，WMS不必等ERP响应就能继续作业。
- 低频重要数据同步：比如供应商档案、客户信用额度，通过RESTful接口在API网关层统一处理鉴权、限流和日志记录。
- 定时批处理：财务对账、月末结转这类场景，用ETL任务在夜间窗口完成全量或增量同步，避免影响日间业务。
但技术方案只是手段，数据一致性真正要守住的底线是“以业务单据为最终凭证”。也就是说，销售订单在CRM中生成后，必须通过状态机流转至ERP，不允许两个系统各自维护订单状态。一旦出现数据冲突，以ERP中的最新状态为准，同时记录冲突日志供人工排查。这个原则如果不在一开始就明确，后面集成越复杂，排查和协调的工作量越大。
权限设计：从角色级下沉到数据行级
权限是ERP定制开发中另一个高频需求点。标准产品的权限模型通常是“角色—菜单”两级，而定制场景下往往需要做到三级甚至四级：
- 菜单级：控制用户能看到哪些功能入口
- 操作级：控制用户能执行哪些动作（查看、编辑、删除、审批）
- 数据行级：控制用户能访问哪一部分数据（销售经理只能看自己团队的客户，财务只能看已审批的付款单）
- 字段级：控制用户能看到哪些字段（如隐藏成本价、隐藏供应商联系方式）
行级权限的实现方式一般有两种：在数据访问层加过滤条件，或者在查询时动态注入权限上下文。前者性能更好，后者更灵活。具体选哪种，取决于数据量和权限规则的复杂程度。这块在需求调研阶段就要明确，因为后期补权限模型比一开始就设计好要贵得多——改权限模型往往意味着要动底层的查询逻辑和数据结构，已经上线的系统再动这些，风险和工作量都成倍增加。
开发风险和成本控制的几个实际建议
ERP定制开发的风险，大部分不在代码层面，而在需求和项目管理上。在金边这12年，每年交付的项目量摆在那里，有几个点值得提前注意。
需求蔓延是工期失控的首要原因。业务部门在开发过程中不断提新增功能，项目越拖越长。做法是在项目启动前固定基线版本，所有新增需求统一放入二期规划，不在开发中途插入。这个规则需要在启动会上和客户方最高决策人确认，否则执行到一半，业务部门绕过项目负责人直接找开发提需求，项目边界就形同虚设。
数据迁移失败的概率比想象中高。旧系统历史数据往往存在重复、缺失、编码不一致的问题。上线前至少做两次试迁移和校验，把清洗规则提前验证，而不是等到正式切换那天才发现问题。在东南亚几个国家做的项目里，历史数据里最常见的坑是编码体系不统一——同一个客户在旧系统里有两个编码，或者同一个SKU在不同仓库用不同编码，这种问题不提前清洗，上线后库存和应收应付全对不上。
性能瓶颈要提前压测。高并发场景下，库存锁表、订单超时是常见故障。架构设计阶段就要做压测，必要时考虑读写分离或缓存降级。具体能压到什么量级，取决于业务模型和部署环境，不同项目之间差异很大，没法给出一个统一的数字。但有一点是确定的：不压测就上线的系统，在业务高峰时暴露问题的概率非常高，尤其是库存扣减和订单创建这两个链路。
成本控制方面，有几个实际可操作的做法：
- 复用开源框架：基于Odoo或Axelor二次开发，而不是从零编写。这些框架已经包含基础权限、工作流引擎、报表模板，能节省相当比例的工作量。
- 模块化迭代：先打通核心价值链（采购—库存—销售—财务），非核心功能后期通过插件扩展。
- 分阶段验收：每完成一个模块就验收一次，避免一次性投入过大。
上线节奏：不要一次性切全模块
ERP上线最忌讳“大爆炸式”切换。建议的节奏是：
- 环境准备阶段：搭建开发、测试、预生产、生产四套环境，配置好CI/CD流水线。
- 模块灰度阶段：优先上线采购与库存模块，运行2周稳定后再接入销售与财务。这样如果出现问题，影响面可控。
- 用户培训与UAT：关键用户做场景测试，重点验证审批流和数据一致性。这一阶段发现的问题修复成本远低于上线后。
- 正式切换：选择业务低峰期操作，先停旧系统再启动新系统，旧系统保留只读权限1个月作为过渡。
关于交付周期，电商类系统因为已有成品、开箱即用，交付可以压缩到几天；完整的ERP定制开发，小项目通常几天到两周，大项目一般在两个月左右。报价不写具体数字，需要面谈或通过Telegram按功能清单逐项评估，付款方式为先付30%启动，验收后结清尾款。支付通道只负责对接，通道资源由客户自己提供，这块不在服务范围内。
系统上线后，bug修复免费，新增功能按工作量另行计算。日常沟通用中文，TG响应是分钟级的，同时有AI运维辅助监控。如果正在规划企业的数字化升级，建议先从业务流程梳理和数据治理入手，再评估定制开发的可行性。