第 1 章 · 先把发生过的事记下来：数据库与 ERP

一家制造企业接到一张订单，业务员最先关心客户什么时候要货，生产部门关心排期，采购关心原料够不够，仓库关心现有库存，财务最后还要问一句：这单到底赚不赚钱。

在纸面上，这是一张订单。在企业里，它会分裂成很多件事。

销售录一遍客户和数量，计划员再抄一遍交期，采购拿着物料清单算缺口，仓库按自己的表登记进出，财务月底才把前面的动作换成成本和收入。哪个环节改了，后面的人未必马上知道。销售答应客户提前五天，生产计划可能还是旧日期；仓库说有货，系统里也有，走到货架前才发现那批料早被别的工单领走了。

今天回头看，这些问题一点都不“智能”。它们甚至不需要分析。它们只要求企业先做到一件很笨、也很难的事：

把已经发生的事情记清楚。

表为什么要拆开

数据库最初解决的，不是经营洞察，而是记录混乱。

同一个客户，在销售表里叫“广州一厂”，在财务表里叫“广州某某制造有限公司”，仓库又只记一个内部编号。地址改了三次，三张表改了两个版本。到最后，没人敢删旧记录，因为谁也不知道还有什么程序在用它。

技术人碰到这种场面，会讲主键、依赖和一二三范式。业务人员听到第二个词，往往已经开始走神。

换成大白话，范式只是在管三件事：

同一件事尽量别到处抄；一处改了，别让其他地方继续保留旧答案；两件本来独立的事，别因为塞在同一张表里被迫一起变化。

1970 年，IBM 的埃德加·科德发表关系模型论文，讨论的核心问题之一就是冗余和一致性。他希望应用不必死死绑在数据的物理存放方式上。今天这听上去理所当然，当时却是在给后来几十年的企业系统打地基。

地基的意思，不是所有数据都必须按第三范式存。分析系统、日志系统和后来各种分布式系统，都有自己的取舍。留下来的是一种习惯：先问清楚一条记录代表什么，它和别的记录是什么关系，再谈怎么存。

这是一种很朴素的克制。可惜做项目时，最容易丢的也是这种克制。

有些表一上来就有两百个字段。客户说什么都加进去，今天加审批意见，明天加渠道标签，后天再放一个“特殊情况说明”。表越来越宽，业务没有更清楚，只是把原本说不清的问题摊平在数据库里。

数据库能约束字段，约束不了企业对现实的含糊。

ERP 想做的，是让一张订单走到底

ERP 的来路与制造业关系很深。

早期的物料需求计划，也就是 MRP，首先回答的是几个很具体的问题：要生产什么，需要哪些物料，需要多少，什么时候需要。后来，销售、库存、采购、物料清单、生产控制再与财务会计逐步连起来，范围越来越大，才有了后来所谓的企业资源计划。

这段历史很重要。ERP 一开始不是为了给老板看大屏，也不是为了“沉淀数据资产”。工厂每天都要面对原料、机器、工时和交期，它首先得让东西按时生产出来。

这也是 ERP 最有力量的地方：它不满足于记录一堆孤立数字，而是试图让一张订单从销售承诺，一路穿过采购、生产、库存和财务。

订单数量变了，物料需求跟着变；原料没到，生产计划就不能假装一切正常；货发出去了，库存和应收账款也应该留下对应记录。同一笔业务不再由几个部门各讲各的故事。

说起来很顺。真做起来，麻烦都在“应该”两个字里。

系统认为先下采购单，再收货，再入库。现场可能供应商半夜把急料送到门口，生产线等着开工，仓库先收了再补单。系统要求一个物料一个编码，老师傅却知道两种料在某些情况下可以替换。标准成本按月维护，采购价格已经一天一个样。

这些动作不一定是违规。有些是管理漏洞，有些是在烂条件下把事情办成的经验。系统若完全容不下，业务会绕开它；系统若什么都允许，它又失去统一流程的意义。

ERP 实施最难的一段，往往不是安装软件，而是逼着企业回答以前可以糊弄过去的问题：

客户到底怎么编号？库存什么时候才算库存？订单改到哪一步必须重新审批？生产领料超出多少算异常？谁有权修改已经确认的交期？

这时候，所谓“系统上线”，其实是企业把一部分管理规则写进软件。

标准化不是把所有企业做成一个样

谈 ERP，常有人把国外产品和中国企业摆成一组简单对立：国外流程标准，中国喜欢定制；国外管理先进，中国基础薄弱。

这种说法省事，但没多大用。

SAP 自己的历史资料把公司的起点追溯到 1972 年，当时的目标就是开发用于实时业务处理的标准应用软件。标准产品能摊薄研发成本，也让不同客户使用一套经过反复验证的骨架，这是它能形成规模的前提。

但“标准”从来不等于没有实施。行业不同、税务规则不同、组织权限不同、历史系统不同，都会让同一个产品落出不同样子。国外企业同样有遗留系统、部门壁垒和表外流程，中国企业也并非普遍没有系统。

更值得追问的，不是谁更先进，而是哪些差异应该进入标准产品，哪些应该留在配置里，哪些只是客户多年没有清理的旧习惯。

每一个定制需求背后，可能藏着三种东西：

这家企业确实有独特的业务；
所在行业或地区有特殊规则；
旧流程没人敢动，只好要求新系统迁就。

把三种情况混在一起，最后就会出现一套谁也不敢升级的系统。供应商说客户需求太多，客户说软件不懂业务，两边都觉得自己受了委屈。

系统里的事实，仍然只是事实的一部分

ERP 做了一件以前很难做到的事：让企业的大量动作第一次拥有了可追溯的正式记录。

谁在什么时候建了订单，谁改了数量，物料从哪个库位领走，凭证由什么业务触发。这些记录不一定完美，却让企业有机会从“大家都记得”走向“系统里可以查到”。

问题也从这里开始。

系统记录的是被允许进入系统的事实。临时协调写在聊天里，判断依据留在老师傅脑中，客户关系藏在销售的电话里。即使系统内完全一致，也不代表它已经覆盖了企业完整的现实。

还有一个更直接的问题：交易系统擅长把一笔业务办完，却不适合随时回答老板突然冒出来的问题。

今天卖了多少，可以查。过去三年不同区域、产品、客户等级的毛利趋势怎样？哪类订单经常延期？哪些供应商看上去便宜，算上退货和停线以后反而最贵？

如果让生产系统一边处理订单，一边陪分析人员做大范围扫描，前台业务可能先被拖慢。更何况，一家企业通常不只有一套系统。销售、生产、财务、客服各有记录，单看任何一套都只是局部。

企业先花了很多年，把事情写进系统。接下来，它开始想看懂这些事情。

这就是数据仓库和 BI 要接的下一棒。

本章资料

场景说明：本章制造企业订单场景为常见业务流程的复合示例，不指向特定客户。