ARTICLE · 1247121

写给生鲜软件人看的ERP简史(1)

发布时间：2026-10-25 13:35:09 最近访问：2026-10-25 13:35:10

写给生鲜软件人看的ERP简史(1)

一种零件，一次做多少、隔多久做一次，总成本最低？做多了，库存资金占用和保管成本上升；做少了，换产准备与订货成本频繁发生。

于是，经济订货批量（EOQ）诞生了。

有了 EOQ，企业还需要回答另一个问题：什么时候下单？

于是，再订货点（ROP）诞生了。当库存降到 ROP 以下，就按 EOQ 下单补充。

看起来解决，但有一个致命缺陷——适用于市场直接决定的需求，而非生产相关需求。

假设桌子由 1 张桌面和 4 条桌腿组成，客户下了一张 1000 张桌子的订单。

用再订货点法管理库存会发生什么？桌腿的消耗速率取决于"什么时候生产桌子"，而桌子的生产取决于订单——这些需求彼此强相关。于是经典的灾难场景出现了：

桌腿库存在某个时点跌破ROP，触发大批补货——但那时根本没有方桌的生产计划；与此同时桌面库存充足，无需补货；结果：桌腿堆积如山，桌面缺货停产。库存总额上升，齐套率反而下降。

于是，MRP 诞生了。MRP 解决这么几个问题：

最终，浓缩成一个公式：净需求 = 毛需求 + 已分配量 + 安全库存 − 计划在途 − 实际在途 − 现有库存

让这个公式真正有用的是时界。

每种物料都有提前期（从下达订单到可用的时间），MRP 从"第 N 周交付 1000 张方桌"出发，沿着产品结构树逐层倒推：桌面要提前 2 周投产，板材要提前 4 周采购……

最终把"要什么"翻译成"什么时候、买多少"的完整时间表。

再往下说，就是更复杂的 MRPⅡ 了……先暂时停住，回到生鲜配送行业。

生鲜配送行业在这个问题的计算上更加苛刻，因为生鲜的保质期短，所以对库存更敏感，最好控制在安全库存=现有库存=0。

这样一来：净需求 = 毛需求 + 已分配量 − 计划在途 − 实际在途

生鲜保质期短的特点还体现在订单履约周期上，基本上在下单的 24 小时内交付，这也意味着提前期对生鲜行业的作用不大，因此，已分配量=计划在途=0

于是：净需求 = 毛需求 − 实际在途

也就是以销定采。

生鲜配送把复杂的 MRP 简化了，但也带来了新的问题：

因为履约周期要求苛刻，所以不能等毛需求完全确定了再去计算净需求，因为时间来不及。

实际在途量，其中会有包含但不限于质量问题导致的损耗，这对于生鲜很常见，所以账面上的实际在途量，不一定全部可用。

实际还有更复杂的问题，因为生鲜属于非标品，所以客户下单的同一个商品，实际上不一定的同一个，例如下单土豆，有表皮漂亮的土豆，还有表皮有坑洼的土豆，有些高档酒店对土豆外形有要求……

所以，如今的生鲜配送 ERP，其实还在解决 MRP 阶段需要解决的问题，几乎没有哪个生鲜配送 ERP，解决了 MRPⅡ 要解决的问题，只是单纯的把记账这件事加了进来，远没有把物流和资金在同一个计划闭环。

MRPⅡ 转向 ERP，重要的标志是集成，对内集成各个部门的业务，不限于供应链，对外集成供应链上的所有合作伙伴，并且在技术架构上，放弃一个套件管所有事的梦想，改用松耦合的联邦式组合。

这一点，生鲜配送 ERP 很好的延续下来，成为了我们熟悉的生鲜配送 ERP。

2019~2021，有专家提出了 EBC，也就是从 ERP 的关注过程转变到关注结果，由业务需求转向数据驱动。这个转变其实对生鲜配送 ERP 的影响很小，因为 MRP 要解决的事情还没解决。

2021 年业界提出了 Composable ERP，通俗来说就是像搭积木一样构建 ERP 在客户业务的实际形态，解决交付速度和变化速度的矛盾。值得细品的还有，2018~2021 国内的业务中台战略。

当复用收益小于中台团队与前台业务之间不断升高的协调成本时，任何漂亮的架构都会在组织上瓦解。技术上，前台灵活/后台稳定的分层永远成立；组织上，能力中心的所有者必须与使用者的目标一致。

可惜，大部分生鲜配送 ERP 服务商都没能意识到这一点，在技术 leader 驱动下开展风风火火的改造运动，有些直到今天还在继续。

回顾一下：

相关学习资料