生产工序统计模块开发：口径设计、SQL聚合与防重复报工实践

《看潮企业管理软件》项目开发到第15个功能模块——工序统计的时候，我的第一反应其实挺简单的：这不就是写几条带SUM和COUNT的SQL，再把数字丢到报表页面上吗？可真上手做完4-3这个子任务才发现，工序统计最花精力的地方根本不在写代码，而在业务口径的对齐、重复数据的防护、统计边界的划分，以及一个数字从车间流转卡一路变成管理层看板的过程中，到底要经过哪些变形。这篇文章会把我在这个模块里的完整思路拆开来讲，包括怎么设计表、怎么写统计SQL、怎么和前端配合做下钻，以及实测时踩过的那几个坑。适合正在做企业管理类软件项目的开发者看，也适合企业内部要做生产统计报表的同事参考，里面所有SQL和设计思路都是可以直接抄到项目里改一改就用的那种。

1. 工序统计模块要解决什么问题：先理清业务边界

1.1 工序统计的源头不是一张报表，而是一线报工数据

很多人提到“统计”就想到月底做报表，但生产制造型企业里的工序统计，发生在每一天的每一道工序上。生产部门先把生产工单下发到车间，车间按工艺路线拆成多道工序，比如下料、机加、焊接、组装、检验，每一道工序做完之后，操作工要在系统里做“报工”，也就是登记这批活干了多少件、合格多少件、报废多少件、用了多少工时。等到这些报工数据积累起来，工序统计才有东西可以统计。

所以工序统计模块的核心任务，是把这些零散的报工记录按“工单、工序、时间、班次”等维度汇总，变成管理动作能用的数字。在《看潮企业管理软件》这个项目里，前14个模块已经把基础资料、订单管理、生产计划、物料领用这些环节打通了，工序统计排在第15个模块，算是把生产执行层真正闭合起来。没有这一环，管理人员只看到计划下达了，却不知道现场到底干到哪一步，也不知道哪个工序废品率异常，生产进度全靠电话问。

做4-3这个子任务时，前面阶段已经搭好了报表框架和基本查询，我的工作重心是两件事：一是把统计口径从头到尾重新校准一遍，二是把汇总数据到明细数据的穿透查通。从表面看这是纯功能开发，从内部看其实是在解决一个“数据如何变成决策依据”的问题，这也是为什么这个模块归在“编程与数学”系列课程下面——统计本来就是数学在生产管理里最直接的一种应用形式。

1.2 工序统计要覆盖的口径：产量、工时、质量、进度

工序统计不是简单地把所有报工数量加在一起，而是有不同的观察维度，每个维度服务的决策对象都不一样。整理成一张表能看得更清楚：

这个表格看起来很简单，但它决定了后端查询条件和前端展示框架的设计。比如管理人员问“今天产量怎么样”，系统不能只返回一个总产量数字，而要拆到工序，否则他无法判断是否某个瓶颈工序拖了后腿。再比如质量管理员关心的是“哪个工序报废率高”，那前端展示时就必须同时显示合格率和报废数量，而不是只给他一张流水账式的报工列表。

这正好引出一个统计模块设计时的普遍原则：先从管理问题出发，反推需要什么指标，再去设计数据结构和统计逻辑。如果只盯着已有的报工字段，能输出一堆无用的报表，真正回答不了业务问题，这属于典型的“从数据到指标”，方向反了。

1.3 工序统计里的“数学”体现在哪里

标题里带了“编程与数学”，很多人以为是学习微积分、线性代数，其实工序统计里用到的数学并没那么高深，更多是统计学的思维。最核心的就是“口径”两个字——分子是什么、分母是什么，必须定义清楚。计算合格率，分子是合格数量，分母是报工数量还是报工数量减去未完检验数量？这两个口径算出来的数可能差两个百分点，如果不提前确认，后面所有报表都会错得莫名其妙。

还有平均数思维。管理人员经常会问“某个工序平均工时是多少”，很多人直接拿总工时除以报工次数，但正确做法是总工时除以合格数量，或者总工时除以报工数量。区别在于：一个有返工、报废的工序，单单计算平均每次报工耗时毫无意义，因为一次报工可能是500件也可能是5件。这个“加权平均”的思想不算难，但代码实现时最容易带偏，后面我会专门讲这一段。

2. 数据模型设计：把车间纸质记录变成能计算的表结构

2.1 计划表和报工表必须分开设计

做工序统计不能只盯着报工表，还要把生产计划表一起纳入模型。道理很简单，想统计“完成率”，就必须知道“计划量”。有些项目图省事，把计划数量和实际完成数量放在同一张表里，结果计划一旦调整，历史报工数据跟着受污染，统计结果就乱套了。

我的做法是保留两张核心表：

• 工序计划表（process_plan）：保存工单下每个工序的计划信息，包括计划数量、计划开始时间、计划结束时间、当前状态。
• 工序报工表（process_report）：保存现场每一笔报工流水，包括工单号、工序、报工数量、合格数量、报废数量、工时、操作工、设备、班次、报工时间。

两张表通过工单号加工序编号关联。这样设计最大的好处是职责清晰：计划表解决“应该做多少”的问题，报工表解决“实际做了多少”的问题，统计时如果要算完成率，动态关联两张表即可。即使计划调整了，也只是计划表里的数字变化，不会影响已经记录下来的报工事实。

报工表在数据库里的大致结构如下：

sql复制CREATE TABLE process_report (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  report_batch_no VARCHAR(40) NOT NULL COMMENT '报工批次号',
  worksheet_no VARCHAR(32) NOT NULL COMMENT '生产工单号',
  process_code VARCHAR(16) NOT NULL COMMENT '工序编号',
  operator_id BIGINT NOT NULL COMMENT '操作工ID',
  equipment_code VARCHAR(32) NULL COMMENT '设备编号',
  report_qty INT NOT NULL DEFAULT 0 COMMENT '报工数量',
  qualified_qty INT NOT NULL DEFAULT 0 COMMENT '合格数量',
  reject_qty INT NOT NULL DEFAULT 0 COMMENT '报废数量',
  work_hours DECIMAL(6,2) NOT NULL DEFAULT 0 COMMENT '实际工时',
  shift_code VARCHAR(8) NULL COMMENT '班次',
  report_time DATETIME NOT NULL COMMENT '报工时间',
  remark VARCHAR(255) NULL,
  UNIQUE KEY uk_batch (worksheet_no, process_code, report_batch_no),
  KEY idx_report_time (report_time),
  KEY idx_worksheet_process (worksheet_no, process_code)
) COMMENT='工序报工明细表';

看到这里你可能有一个疑问：既然同时有报工数量、合格数量、报废数量，那合格数量加报废数量为什么不一定要等于报工数量？这是很多人设计时的惯性思维，觉得三者必须守恒。实际业务里，操作工报工时，某批产品可能已经转出，但质检结果还没完全出来，所以报工数量代表转移数量，合格数和报废数是质检认定结果，两者之和可以小于报工数量。设计时不要为了追求数值和谐而强行加一些不符合现场业务逻辑的约束。

2.2 统计时间边界：为什么不要只用日期字段

工序统计最少不了的筛选条件就是时间。很多新手设计表时习惯单独放一个report_date字段，类型是DATE，查询时直接report_date between '2025-03-01' and '2025-03-31'。这个方案看着简单，但有两个隐患：

一是月底最后一天的数据容易漏掉。因为between and是闭区间，如果你写report_date between '2025-03-01' and '2025-03-31'，理论上没有问题，但如果有人写的是between '2025-03-01' and '2025-04-01'，凌晨0点整的数据就会被多算进来。二是工序统计经常按班次来归集，一旦夜班跨天，只按自然日统计会把同一个夜班的数据拆成两天，对车间考核不公平。

我的做法是表里统一保存完整的report_time（DATETIME类型），统计时用半开区间来查询：

sql复制WHERE report_time >= '2025-03-01 00:00:00'
  AND report_time <  '2025-04-01 00:00:00'

这样“大于等于起始时间且小于结束时间”的写法，把边界问题处理得非常干净。如果客户要求按班次统计，我会再加一个班次日字段，比如某个夜班从3月1日晚上8点干到3月2日凌晨4点，这个班次日统一记为3月1日。这种字段是基于班次定义做出来的，可以在排班模块里自动带出，不要在统计SQL里临时用加减8小时这种硬编码来做。

2.3 防止重复报工：数据库唯一键比业务判断更可靠

工序统计最常见的脏数据就是重复报工。操作工在页面上点了提交，页面转圈没反应，他又点了一次，两条完全一样的数据就进去了；或者客户端网络重试机制把同一个请求发了两次。前端禁用提交按钮能挡掉一部分，但遇到网络异常重发时根本拦不住。

我从一开始就在表上做了一个唯一约束：同一张工单、同一道工序、同一个报工批次号只能出现一条。这里的report_batch_no不是数据库自增ID，而是业务侧生成的批次号，每次报工产生唯一编号。比如后端可以用时间戳加短随机数生成，或者直接采用UUID。

唯一键建好之后，重复插入时数据库会报错，接口捕获这个错误提示用户“报工重复，请勿重复提交”，而不是悄无声息地生成两条记录。这个设计比在应用层先查一遍再插入要可靠得多，因为两个并发请求可能同时通过查询，然后又同时插入，只有数据库唯一约束才能兜住这种极端情况。做4-3阶段时，我发现统计数字比线下台账多了将近一倍，最后排查下来就是缺少这个唯一键，历史数据每天都在被重复报工污染。

3. 统计SQL和核心接口实现：把聚合逻辑一次写对

3.1 产量统计：用SUM还是COUNT要分清楚

统计产量的SQL看起来特别简单，但很多人在第一步就写错了。常见错误是把报工记录表里的COUNT()当成产量。比如某道工序一天报了3次，第一次300件，第二次200件，第三次150件，如果统计产量用COUNT()，得到的结果是3，而不是650。正确写法是SUM(report_qty)。

这里的本质问题是COUNT统计的是“行数”，SUM统计的是“某一个数值列累加”，两者含义完全不同。查询某张工单在某段期间内，各工序的产量、合格数、报废数、报工次数和合格率，基础SQL长这样：

sql复制SELECT
    worksheet_no,
    process_code,
    SUM(report_qty) AS total_report_qty,
    SUM(qualified_qty) AS total_qualified_qty,
    SUM(reject_qty) AS total_reject_qty,
    COUNT(*) AS report_count,
    ROUND(SUM(qualified_qty) * 100.0 / NULLIF(SUM(report_qty), 0), 2) AS pass_rate,
    ROUND(SUM(work_hours) / NULLIF(SUM(report_qty), 0), 4) AS unit_hours
FROM process_report
WHERE report_time >= '2025-03-01 00:00:00'
  AND report_time < '2025-04-01 00:00:00'
GROUP BY worksheet_no, process_code
ORDER BY worksheet_no, process_code;

这段SQL里有几个值得注意的细节。首先，合格率的计算用了SUM(qualified_qty) * 100.0 / NULLIF(SUM(report_qty), 0)，而不是先算平均值再相乘，因为如果直接取AVG(qualified_qty / report_qty)，会把小批量的异常比例无限放大，必须按总量汇总后再算比率。其次，乘的是100.0而不是100，防止数据库把整数除法直接截断成0。第三，NULLIF函数把分母为0的情况转换成NULL，SQL里除以NULL结果是NULL，不会直接报“除数为零”的错。这三个细节任何一个不注意，报表数字都可能出现致命偏差。

3.2 工时和效率统计：先搞清楚分母用什么

如果要统计工时效率，字段本身并不复杂：process_report表里有work_hours字段，下单时让操作工填实际用了几个小时，或者由设备采集系统自动写入。真正的复杂度在于“单件工时”的分母选择。

如果你把总工时除以报工数量，会得出一个看似合理的单件工时，但这个口径夸大了效率，因为其中不合格的零件也占了工时。如果你把总工时除以合格数量，计算结果会相对偏保守。实践当中到底用哪个分母，要看业务考核的导向：如果工序统计只是反映工人干活快慢，建议用报工数量；如果是给计件工资做依据，就得先把返工和报废处理规则问清楚，不能拍脑袋定。

在4-3阶段我遇到的需求还更进一步：客户不满足于看实际单件工时，还希望看“标准工时达成率”。也就是说，要拿实际工时和工艺路线里维护的标准工时做对比。标准工时一般维护在另一张工序标准表里，统计时通过process_code关联进去：

sql复制SELECT
    r.worksheet_no,
    r.process_code,
    SUM(r.report_qty) AS report_qty,
    SUM(r.work_hours) AS actual_hours,
    MAX(s.standard_hours) AS standard_hours,
    ROUND(SUM(r.report_qty) * MAX(s.standard_hours) 
          / NULLIF(SUM(r.work_hours), 0) * 100, 2) AS efficiency_rate
FROM process_report r
LEFT JOIN process_standard s
    ON r.process_code = s.process_code
WHERE r.report_time >= '2025-03-01 00:00:00'
  AND r.report_time < '2025-04-01 00:00:00'
GROUP BY r.worksheet_no, r.process_code;

效率达成率 = 标准总工时 / 实际总工时 × 100%，大于100%说明效率超过了标准。使用LEFT JOIN而不是INNER JOIN，是因为有些非标工序在标准表里还没有维护定额，用内连接会导致这些报工数据直接消失；左连接加上空值，至少保留原始报工记录，让业务方看到标准工时缺失的工序有哪些。这里用MAX(s.standard_hours)并不是业务逻辑上取最大值，而是因为GROUP BY聚合后，每个分组里的s.standard_hours理论上是同一个值，为了满足SQL语法必须包上聚合函数，取MAX和取MIN结果一样。

3.3 完成率和进度统计：确认表与计划表关联顺序

只统计报工量，永远回答不了“生产进度怎么样”这个问题。假设某道工序做了100件，如果计划是150件，完成率是66.67%；如果计划是80件，完成率就是125%。所以计算完成率必须把process_plan工序计划表关联进来。

这里有一个非常容易踩的坑：关联方向搞反。如果是以报工表作为主表，LEFT JOIN计划表，那么没有发生报工的工序根本不会出现在结果集里，完成率全是空。正确做法是以计划表为主表，LEFT JOIN报工表，这样才能把“计划了但还没干”的工序也显示出来：

sql复制SELECT
    p.worksheet_no,
    p.process_code,
    p.planned_qty,
    COALESCE(SUM(r.report_qty), 0) AS finished_qty,
    CASE
        WHEN p.planned_qty > 0
        THEN ROUND(COALESCE(SUM(r.report_qty), 0) * 100.0 / p.planned_qty, 2)
        ELSE 0
    END AS completion_rate
FROM process_plan p
LEFT JOIN process_report r
    ON p.worksheet_no = r.worksheet_no
    AND p.process_code = r.process_code
WHERE p.plan_date >= '2025-03-01'
  AND p.plan_date < '2025-04-01'
GROUP BY p.worksheet_no, p.process_code, p.planned_qty
ORDER BY p.worksheet_no, p.process_code;

COALESCE在这里很关键，没有报工的工序，SUM(r.report_qty)是NULL，如果不处理，前端拿到的finishedQty就是null，页面很容易因为类型问题显示成空白或NaN。联合分组条件里给worksheet_no和process_code都加上，会直接决定关联是否成立。千万不要只关联worksheet_no而漏掉process_code，那样会把一张工单下所有工序的报工数量都算进每一道工序里，数字直接爆炸。

3.4 接口返回结构：一次约定好，前端少返工

统计接口和普通CRUD接口不一样，返回的数据往往是多层嵌套的，有汇总、有按工序分组、有按日期分组。我在做这个模块时，后端和前端先约定了一个统一的返回结构，避免后面联调扯皮。完整的JSON大致如下：

json复制{
  "total": {
    "reportQty": 12850,
    "qualifiedQty": 12603,
    "rejectQty": 247,
    "passRate": 98.08,
    "totalWorkHours": 352.5,
    "unitWorkHours": 0.0274
  },
  "byProcess": [
    {
      "processCode": "OP10",
      "processName": "下料",
      "reportQty": 5000,
      "qualifiedQty": 4950,
      "rejectQty": 50,
      "passRate": 99.0,
      "completionRate": 100.0
    }
  ],
  "byDate": [
    {
      "statDate": "2025-03-01",
      "reportQty": 860,
      "qualifiedQty": 845,
      "passRate": 98.26
    }
  ],
  "detailUrl": "/production/process-report/list?worksheetNo=WO202503001"
}

这个结构约定的核心思想是让后端一次性把统计结果算好，前端只负责展示，不要在前端再做大量二次计算。前端拿到byProcess数组直接渲染表格，拿到total字段直接渲染合计卡片，效率高也不容易出错。detailUrl字段用来做下钻跳转，点击任意统计行时，带着工单号和工序编号跳到报工明细列表页。

4. 前端展示和交互：让统计数字真正用起来

4.1 首页看板优先放三个核心数字

工序统计做出来不是给程序员对着表看的，而是给厂长、车间主任、计划员用的。这些人每天看上屏的时间不超过三分钟，所以页面不能堆满密密麻麻的表格。我在《看潮企业管理软件》里设计的工序统计主页面，顶部只放三张卡片：今日完成产量、今日平均合格率、未完工工单数。

这三个数字分别回答了管理上最关心的三件事：干了多少？质量行不行？还有多少单子压在手上？在工序统计页面上不需要把所有指标都平铺出来，把高优先级指标放到最上方，既能快速抓住注意力，也能引导用户点击进入对应的统计分析模块。如果某个数字触发了预警规则，比如合格率低于95%，卡片会变成红色，点击之后直接跳到对应工序的质量明细。

4.2 趋势图怎么选：产量用柱状，合格率用折线

图形选择不是越花哨越好。工序统计页面最常用的是时间趋势图，横轴是日期，需要同时表达产量和合格率两个单位不同的指标。产量可能是几百到几千，合格率一般在90到100之间，如果放同一个坐标系，产量会直接把合格率的波动压成一条平线，什么都看不出来。

合适的做法是双轴图：左侧Y轴表示产量，用柱状图展示每日产量；右侧Y轴表示百分比，用折线图展示合格率变化。柱状图能直观看出哪天产量高、哪天产量低，折线图可以暴露质量波动。如果某个日期柱状明显变矮的同时折线往下掉，说明当天可能发生了设备故障或批量异常，管理人员一眼就能捕捉到这个信号。

对于“产品质量构成”这种数据，我不建议用复杂的仪表盘，用堆叠百分比柱状图效果更好。把每天的报工数量拆成合格、报废、返工三个颜色，能直观看出问题批次主要集中在哪一天、哪个工序。如果现场管理要求不高，最开始甚至可以不上图表，只做表格加几个迷你进度条，等用户真的习惯了数据再看要不要加图。很多项目死在第一版就堆了十个图表，每个月图表类型五花八门，最后没几个人用。

4.3 点击数字下钻到明细：报表不能只看总数

做过报表开发的都清楚，管理层看到一个数字异常时，第一反应一定是问“哪些单子造成的”。如果系统只能看一个汇总数，不能往下钻到明细记录，那这个统计模块基本是废的，因为管理人员无法定位问题，还得让下面的人手工去翻流水。

所以我在设计时规定了一条原则：页面上每一个统计数字都必须能点击下钻。从首页完成产量卡片点击进去，看到按工单汇总的列表；在某个工单上再点击，看到该工单按工序汇总；在某个工序汇总行上点击，最终进入报工明细表，按时间和工序过滤出具体是哪个人、哪台设备、哪个批次报的工。这个逐级穿透的过程，我在实现时通过detailUrl和筛选参数来完成，前端每次跳转都带两个参数：worksheetNo和processCode，明细页加载后自动把筛选条件带出。

考虑到工序统计页面对数据权限有一定要求，不是所有角色都能看全部工单的明细，后端在下钻接口上需要校验当前登录用户的数据范围。班组长通常只能看自己班组的数据，车间主任可以看整个车间。如果不做这个控制，报表模块很容易成为泄露员工计件产量和生产数据的出口，这一点需要在联调之前就设计到位。

5. 实测中踩过的坑与排查思路

5.1 跨天班次的数据到底算在哪一天

第一次联调的时候，测试人员发现一个非常奇怪的现象：某天晚上8点的夜班报工，出现在第二天早上的日报里。车间主任看到这个数据立刻提出异议，因为夜班从晚上8点开始，按他们车间的管理规则，这一整个夜班都应该算到前一天做统计，否则后续的班次产量对比毫无意义。

问题根源出在代码里直接用了DATETIME类型的report_time按自然日分组。后来我们在报工数据写入时增加了一个“班次日”字段，由后排班表决定。比如晚班开始时间是晚上8点，那晚班日期取开始时间所属的自然日，就算活干到第二天凌晨，数据仍然归到前一个班次日。程序里写一段配置逻辑：

• 如果班次开始时间在00:00到08:00之间，视为早班，班次日是报工时间所在日；
• 如果开始时间在08:00到16:00之间，视为中班，班次日也是报工时间所在日；
• 如果开始时间在16:00到24:00之间，视为晚班，班次日是报工时间所在日再加判断是否跨零点。

跨零点问题在不同企业规则不同，千万不能自己编一套，最稳妥的做法是把“班次日计算规则”做在排班基础数据里，让系统根据报工人的排班自动带出，报表按shift_day字段汇总。

5.2 重复报工只能靠唯一键兜底

在4-3阶段测试时，我用同一个报工批次号连续提交了两次请求，第二次被唯一约束拦截，我很满意。但打开汇总报表一看，数量竟然还是翻倍了。排查了一下才明白，测试环境里的数据库表是早期版本，根本没有加uk_batch这个唯一约束，我在代码里加的逻辑只查了报工记录是否已经存在，但没有在数据库层面拦住。

后来补上了唯一约束，同时清理了历史重复数据。清理方法也很有效：先把重复批次找出来看严重程度，然后保留最早一条报工记录，删掉后续重复的批次。排查SQL很有参考价值：

sql复制SELECT worksheet_no, process_code, report_batch_no, COUNT(*) AS cnt
FROM process_report
GROUP BY worksheet_no, process_code, report_batch_no
HAVING COUNT(*) > 1;

这里想提醒一句：前端按钮防重只是体验优化，后端幂等判断只是第一道防线，唯一约束才是真正的护城河。只要表结构允许重复插入相同业务批次，任何代码层面上的拦截都有漏洞可钻。

5.3 报表越来越慢，索引和汇总快照谁先上

工序统计正式上线两周后，报工流水积累到10万条，按日期加工单查询还撑得住。到了一个月，流水突破40万条，有些按月统计的接口开始出现两三秒的延迟，管理人员在页面上点击查询，明显能感觉到卡顿。

第一波优化是把索引建对。对于最常见的查询条件“时间范围 + 工单号 + 工序号”，idx_report_time和idx_worksheet_process两个索引已经覆盖大部分场景。但即便有了索引，月报里的聚合计算还是要实时扫描整张表，数据量继续涨到几百万条时依然会慢。

第二波优化是增加汇总快照表。每天晚上跑一个定时任务，把前一天的报工数据按工单、工序、班次日聚合好，插入process_daily_summary表。报表查询优先查汇总表，只有点下钻到明细时才去查原始的process_report表。这种方式可以理解为把每天的作业提前做完，用户查询时不需要现场算，速度自然快很多。代价是实时性差，最多看到昨天的数据。对生产统计这个场景来说，这个实时性完全够用，原本车间统计员手工做报表也是当天下午才能出昨天的数。

5.4 统计口径变化：从“报工数量”到“标准工时”只改配置

项目开发中最怕的不是功能不会做，而是业务方一句话把口径变了，导致所有SQL、页面标题、图表从头改一遍。在工序统计模块里，我就遇到了两次口径变更：第一次是完成率分母从计划数量改成“按当前订单剩余数量”，第二次是产值排名从“按完工数量排序”改成“按标准工时排序”。

如果这些口径判断是散落在每个报表SQL里的硬编码，改动成本会非常高。比较好的方案是在统计服务里提炼出一个“统计口径配置”的概念，比如用枚举字段存储当前需要按哪种口径汇总，SQL里根据枚举动态拼接汇总字段。这样生产上发现口径需要调整时，只需要更新配置，不需要重新发布整个报表模块。

当然，口径配置不是万能的，因为它只适用于同一数据源的不同聚合方式，如果改了聚合粒度，比如从“按日”改成“按班次”，还是要改代码。但至少把高频变化的比率公式维护在一个地方，后续扩展和维护都会省很多事。我在做这个模块时把合格率、报废率、完成率、单件工时、效率达成率的计算公式都写在服务端的统一方法里，每个公式对应一个单元测试，改口径时跑一遍测试，不怕旧报表出问题。

6. 后续可以继续扩展的两个方向

如果工序统计模块要继续往深做，我建议优先考虑两件事。一个是在制滞留预警。现在统计报表能看到每道工序完工了多少、计划多少，但要判断某个工单卡在哪个工序超过正常滞留时间，还是得人工盯。可以在报工表基础上增加“工序到达时间”记录，某张工单进入工序后如果超过设定的标准滞留时间还没报工，系统自动弹出一条预警，这对生产调度来说价值非常大。

另一个是和计件工资、绩效考核模块联动。工序统计里的合格数量、工时等数据，和工资模块里的计件工资计算用的是同一批报工记录，但两边的统计口径未必相同。比如统计报表里的合格率把返修品算作报废，工资模块里返修后合格的产品可能还要给一半工钱。遇到这种情况千万别图省事，直接复用统计结果去算工资，一定要让工资模块自己单独写查询口径，宁可多写一遍SQL，也不要因为口径不同导致工人工资对不上。

回到这个模块本身，工序统计需要的数学基础并不多，真正重要的是把“统计什么、为什么统计、按什么口径统计”这件事想明白。每次遇到有人说这个功能简单，我都会建议他先回答三个问题：一道工序没有报工记录时，你的页面是否还能显示出计划数据和完成率0%？一个报工批次被重复提交时，系统能不能拦住？一个产品跨了两个班次时，产量算进哪个班？把这三个问题想清楚，工序统计这个模块就不只是写几条SQL那么简单了。