先回答一个问题:谁对付款负责
多工厂场景下,采购可能由总部统一谈判、工厂执行;也可能各工厂独立采购。这直接决定应付流程的组织方式。如果总部谈判、工厂执行,但对账和付款责任没有明确,就会出现供应商找工厂要钱、工厂说总部负责的情况。
系统层面的组织设计,本质是把这个职责划分固化下来:谁录入发票、谁做三单匹配、谁审批付款、谁负责与供应商对账。这些都要在配置之前确认。
三种常见的组织模式
| 模式 | 特征 | 适用条件 |
|---|---|---|
| 集中处理 | 总部统一处理所有工厂的应付与付款 | 工厂数量多、单厂业务量小、标准化程度高 |
| 分级处理 | 各工厂自行处理,总部汇总监控 | 工厂业务差异大、地域分散、自主性强 |
| 混合处理 | 标准物资集中、专用物资分散 | 多数集团型制造企业的实际状态 |
混合处理是实践中最常见的状态,也是最难配置的——它要求系统能够按物资类别、金额或供应商类型自动路由到不同的处理流程。配置的复杂度显著上升,但贴合业务现实。
主数据治理是前置条件
多工厂场景下,同一个供应商在不同工厂的系统里可能有三个不同的名称和两个不同的纳税人识别号。这种情况下,三单匹配、集中付款、集团对账都无法顺畅进行。
主数据治理需要回答几个问题:供应商主数据由谁维护、新增供应商的审批流程是什么、各工厂能否自行新增、历史数据的重复项如何合并。这些问题不解决,系统上线后仍会持续产生脏数据。
主数据治理要点
- 供应商编码规则全局统一,不允许各工厂自行编号
- 新增供应商走统一审批,纳税人识别号与工商信息自动校验
- 物料主数据统一,尤其是计量单位与换算系数
- 历史重复数据在上线前完成合并,不要留到上线后
三单匹配在多工厂场景下的变数
单工厂场景下的三单匹配相对简单:订单、入库、发票在同一个组织内闭环。多工厂场景下会出现几种变数:总部下单但分厂收货、工厂间调拨后开票、以及集中采购下的代收代付。
这些情形需要系统支持跨组织的单据关联。如果系统只能在同一组织内匹配,这些业务就只能绕开系统在表外处理——这是很多项目上线后使用率不高的真实原因。
推广节奏的建议
集团型企业不建议一次性全量上线。较稳妥的路径是先在业务标准、配合度高的工厂试点,跑通后沉淀成标准实施包,再分批推广。每批控制在五到十家工厂,便于实施团队集中支持。
同时建议集团层面统一核心规则——主数据标准、审批矩阵的框架、容差规则的口径——各工厂在此基础上做少量个性化配置。允许完全自由配置看似灵活,实际上会让后续的集团分析变得非常困难。