车间例会上最常见的争吵是对不上数：计划员说做了三千件，仓库只点出两千六，报工表上又写着两千八。多数厂长以为是员工填表不认真，其实根子多半在数据模型——工单、BOM、工序、报工这四层数据从第一天就没打通，后面报表做得再花哨也是空中楼阁。这篇文章把这套底层逻辑拆开讲，不管你是自己写代码还是用低代码平台搭，先看懂再动手，能少走一半弯路。
一、为什么大部分生产系统死在数据模型上
见过不少工厂，第一年上系统雄心勃勃，第二年悄悄退回 Excel。复盘下来问题几乎一样：系统照着手头表格画，一张生产日报建一张宽表，字段塞了两百多个，结果每加一道工序就得改一次表结构，三个月后没人维护得动。
数据模型的意义，是让系统跟着业务走，而不是跟着表格走。拆到最小，一套生产系统其实就是几张主表在互相引用，其他功能都是在这上面长出来的。
1. 四张主表各管一摊
- 产品表：管「做什么」，含图号、单位、默认工艺路线；
- BOM 表：管「用什么料」，父件子件层层展开，带用量和损耗率；
- 工单表：管「这次做多少、什么时候要」，是所有动作的挂靠点；
- 报工表：管「实际做到哪了」，每道工序一行记录，人、机、数量、时间全在这。
2. 主表之间靠字段串成链
工单引用产品，报工引用工单和工序，领料引用 BOM。字段对上了，数据才能顺着链路流动；字段没对上，就只剩人工抄录，抄错一格，整条链作废。
二、工单状态机：流转不乱的秘密
很多自建系统图省事，工单只加一个「是否完成」勾选框，结果暂停单、返工单、插单全混在一起，看板上一片虚假的绿。状态机是把一张工单的一生拆成固定几个节点，节点之间的跳转规则写死在系统里，不许口头改。
1. 最小可用的一组状态
| 状态 | 进入条件 | 典型场景 |
|---|---|---|
| 待下达 | 计划创建工单 | 排产待确认 |
| 已下达 | 计划确认下发 | 车间可领料 |
| 生产中 | 首道工序报工 | 正在加工 |
| 暂停 | 缺料或设备故障 | 需写明原因 |
| 已完工 | 末道工序完工 | 待质检入库 |
| 已关闭 | 入库完成 | 对账归档 |
2. 只许前进，回退要留痕
状态只能按规则往前走；确实要退，比如质检打回，必须生成一条回退记录，写明原因和责任人。这条纪律看着苛刻，实际是月底对账时唯一能救你的东西。
三、BOM 与工序路线：先结构化，再谈智能
BOM 是生产系统里最容易埋雷的表。最常见的坑是版本混乱：工程师改了图纸，车间还按老料单领料，做出来的成品对不上。要避免，靠的不是人的细心，是表结构里带版本字段。市面上成熟的离散制造ERP模板基本都按这个思路预置了版本管理，直接参考比从零画快得多。
1. BOM 必须带版本和生效日期
每次变更生成新版本，旧版本不删、只封存。工单下达那一刻锁定当前版本，之后再改 BOM 不影响在产工单，避免「图改了、活没停」的经典事故。
2. 工序路线挂上工时和工价
工序路线是挂在产品下的二级结构：车削—铣削—热处理—检验，每道工序带标准工时、计件单价、是否外协。这组数据平时不起眼，算工资、排产能、算报价时全是硬通货。
四、报工数据：采集、校验、防作弊
报工是整个系统里最脏最累的活，也最见设计功力。原则就一条：录入端越省事，数据越干净。让操作工在手机上点三下完成报工，和在电脑上填十几个字段，数据质量是天壤之别。
1. 三道校验拦住脏数据
- 数量校验：报工数不能超过工单数加合理损耗上限；
- 工序校验：报的是不是当前工序，前道工序完工没有；
- 身份校验：谁报的、什么时间报的，系统自动记录，不许代报。
2. 防作弊靠交叉核对
计件场景下虚报绕不开。单靠人盯不住，要把报工数和入库数、质检合格数做日结对账，差额超阈值自动标红。某六十人的汽配加工厂上线三个月后的内部统计显示，工序数据完整率从约八成升到 99% 上下，月底对账从两天压到半天以内。
五、从数据到报表：追溯链怎么串起来
前面几张表建好，追溯和报表其实是查出来的，不是另外做的。正向追溯从批次查去向：这批原料进了哪些工单、发给了哪些客户；反向追溯从成品查来源：这个件是谁在哪台设备上做的、用的哪批料。出了质量事故，这条链路就是止损线。
1. 一张工单的完整时间线
点开工单，下达、领料、每道工序报工、质检、入库，全部按时间轴排开。客户验货提出异议时，把时间线导出来发过去，比写十封解释邮件都管用。
2. 看板是查询视图，不是另一套数据
进度看板、产量排行、异常工单，全部基于同一批底层数据。有些团队把看板做成单独填报的表，等于又造一个数据源，必然对不上。官方的生产管理系统解决方案里给出的看板示例，底层数据模型和这篇讲的是同一套，可以对照着搭。
六、多车间并发下的取舍
单车间跑顺之后，多车间并发才是真考验。三四十个人同时报工、车间大屏实时刷新，性能和权限要提前想，不然高峰期一卡顿，一线员工就干脆弃用。
1. 权限按车间和数据行切
一车间只看一车间的工单，报工按人锁定，管理层看汇总。权限颗粒度到行，员工互相看不到对方产量，计件纠纷能少一大截。
2. 别为报表牺牲录入体验
性能紧张时，优先保报工写入，报表允许分钟级延迟。一线的每一秒卡顿都在消耗他们对系统的信任，信任没了，系统就名存实亡。
落到结果上：按这套模型搭的系统，有客户上线三个月内部统计，报工录入耗时从每单约十分钟降到两分钟以内，工序数据完整率约 99%，月底核算周期从两天压到半天。模型对了，后面的一切才有意义。
常见问题解答
Q1：没有开发团队的小厂，能照这篇文章自己搭生产系统吗？
可以。用低代码平台按四张主表建表，先跑通工单和报工的闭环，质检、追溯后面再加。一般熟悉业务的管理员跟着文档做，两周左右能把主流程搭起来。
Q2：工单状态机和审批流是一回事吗？
不是。审批流管的是「谁同意」，比如工单下达要不要厂长签核；状态机管的是「这单处于什么阶段」，比如生产中、暂停、已完工。两者可以配合，但不要把几十种生产状态全塞进审批流里，会乱。
Q3：BOM 变更后，已经在产的工单怎么办？
工单下达时锁定当时的 BOM 版本，在产工单继续按旧版本执行，新工单自动用新版本。如果旧单必须切换，走变更单流程并留痕，不要直接改历史数据。
Q4：工人多报产量怎么防？
靠系统交叉核对：报工数不能超工单数加上限，报工数和入库数、质检合格数每日对账，差额超阈值自动标红。人工抽查配合数据对账，比单纯盯人有效得多。
Q5：数据量大了以后系统会不会跑不动？
报工记录增长最快，但按每天几百条量级，几年的数据在低代码平台上没有压力。关键是报表做成查询视图而不是另建数据源，再把明细查询限制时间范围，性能一般不是瓶颈。