ERP 系统选型检查清单

ERP 是企业运作方式的模型：订单如何转为收入，采购如何转为应付账款，库存如何在仓库和生产线之间流转。在邀请任何供应商之前，先把这个模型写下来。用自己的语言描述十到十五个端到端场景（报价到收款、采购到付款、计划到生产、入职到离职），包括体现贵方业务特点的例外情况。持有寄售库存的分销商、产生副产品的制造商以及按里程碑结算的服务公司，都是通用系统会在毫无预兆的情况下失效的典型案例。

用这些场景主导演示，而不是按供应商的脚本进行。要求每个团队展示完整流程，包括难点：针对部分付款发票开具贷项通知单、盘点结果与系统不符、月末结账时供应商发票迟到。回答的质量比功能清单的长度更能说明问题。

契合度也涉及平台的覆盖范围。在一个数据模型中涵盖财务、销售、库存、制造、人力资源和采购的平台，可省去日后的集成工作；而由各领域最佳专业工具组成的组合，则能让每个部门使用自己偏好的界面。两种方式都没有错，但选择应当经过深思熟虑，因为它决定了组织需要自行承担多少集成工作。

没有任何 ERP 是孤立运行的。它需要与银行、电商店铺、POS 系统、仓储或生产系统、CRM、税务机关的服务交换数据，往往还要与母公司的合并报表工具交换数据。在选型之前先绘制集成图。针对每个连接，确定是批量还是实时、数据归哪个系统所有，以及另一方不可用时如何处理。

然后考察每个候选系统如何开放其数据。最低要求是：有文档的 REST API 且身份认证可由组织自行管控、用于事件通知的 Webhook，以及可自动化的批量导入导出。如果获取数据的唯一途径是由供应商顾问编写存储过程，那么今后的每一次变更都会变成一张采购订单。请要求查看 API 文档，并询问有哪些其他客户已与之集成。

最后，确定集成逻辑放在哪里。点对点连接器构建快，但维护慢；由组织自有的小型集成层起步时工作量较大，但到第三年成本会显著降低。

将迁移视为一个独立的工作流，并指定专门的负责人。从数据盘点开始：哪些主数据（客户、供应商、物料、会计科目表、员工）和哪些未结交易（未结发票、未结采购订单、库存余额、固定资产台账）必须迁移，以及多久以前的历史数据需要在新系统中可查询，而不是放入归档。

在导入之前先清洗数据。重复的客户、有三种计量单位却没有换算系数的物料、税号已失效的供应商，都会在上线周末变成对账难题。尽早编写导入脚本，并在生产环境副本上反复运行，每次都核对控制总数（试算平衡表、应收和应付账龄、库存估值）。最终导入应当平稳无事，因为它已经演练过多次。

与财务部门商定切换方式。在会计期间分界点以期初余额重新开始，比迁移交易历史更简单；如果需要历史数据，应在签字确认前明确商定哪些报表必须能够重现。

第一年就失败的系统，很少是因为功能不对，而往往是因为每天使用系统的人只是被告知变革，而没有参与其中。请让财务、销售和运营的流程负责人加入选型团队，并赋予其实际决策权。由他们主导场景演示，并与 IT 总监共同签字确认未来流程。

临近上线时，按角色和场景规划培训，并使用员工在生产环境中将看到的数据。在培训开始前确定各部门的关键用户，并给他们留出在沙盒中练习的时间。切换后将旧系统保持只读一段时间，便于员工核对数据，然后在提前公布的日期将其关闭。

最后，不要在新系统中重建所有现有报表和界面。其中一些之所以存在，是因为旧系统做不到新系统原生支持的功能。给新流程一个季度的时间，再判断真正缺少什么。